Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[Philippe Verdy]

Les FIXME c'est justement pour ce que le validateur ne détecte pas ou
ne peut pas détecter, par exemple des données à affiner ou vérifier
sur le terrain.

En revanche, mettre "FIXME" dans une valeur de tag (par exemple
name=FIXME) est inutile. Mais FIXME est tout à fait utilisable en tant
que clé, et prend alors une valeur textuelle expliquant ce qui devrait
être réglé (mais pas la peine de mentionner non plus un FIXME s'il
manque soit un nom soit une référence pour une route).

Exemples de FIXME :

* mentionner qu'il y a désaccord entre plusieurs sources, ou une
ambiguité sur les dates de ces sources, ce qui ne permet pas de
prendre une décision.

* mentionner que des données d'un import n'ont pas pu être traitées de
façon automatique, et qu'un tag (par exemple description) contient des
données à interpréter depuis la description, données qu'on peut alors
reclasser dans d'autres tag.

* mentionner un doûte sur une valeur

* mentionner un tracé douteux, même si le validateur ne signale rien,
par exemple des numéros de voies différents dans la même commune et
pour le même nom alors que ces voies sont connectées, ou bien deux
voies éloignées (non connectées), qui utilisent le même nom et la même
référence au sein de la même zone de numérotation (par exemple dans la
commune pour les voies communales, dans le département pour une route
départementale ou un chemin départemental, le pays entier pour une
route nationale ou une autoroute)

Noter cependant ces disjonctions arrivent dans certains cas sur un
tronçon où la route change temporairement de classification car le
tronçon de raccordement n'est pas encore construit ou aménagé (un
exemple en est l'A84 qui est disjointe à Avranche, car le tronçon de
raccordement se fait encore par la N 175 qui traverse la ville (et se
prolonge ensuite : il manque encore le tronçon autoroutier en rocade
d'Avranche, qui ne figure même pas encore sur les chantiers; en
attendant c'est la nationale, qui a été réaménagée, mais pas
suffisamment pour avoir la classification autoroutière).

Ces disjonctions ne sont donc pas toujours des erreurs, raison pour
laquelle le validateur ne signale rien. Un FIXME en revanche peut être
utilisé temporairement pour des erreurs à vérifier et corriger plus
tard. Si la vérification a eu lieu, et qu'il n'y a pas d'erreur, ce
FIXME sera à remplacer par une note mentionnant que la disjonction est
normale en l'état actuel des lieux.

Osmose n'affiche pas réellement les fixme mis en valeurs d'une clé
(hormi si cela est contraire à d'autres règles de toponymie ou de
typographie et capitalisation), mais détecte bien les noms de clés
"fixme" ou "FIXME". La présence d'un tel FIXME ne permet aucune
correction automatique. Il faut un contrmole humain qui ne se
contentera pas de le supprimer car ils ont une raison d'être.


Le 8 février 2012 18:00, Vincent de Chateau-Thierry  a écrit :
>
>> De : "HELFER Denis"
>>
>> Je lance une idée en l'air (pour voir où elle peut retomber) :
>> - injecter le fichier osm brut de fonderie (ou générer directement à partir 
>> du pdf)
> une base locale PostGIS
>> - utiliser les outils de PostGIS pour signaler les éléments problématiques
>> * points trop rapprochés (seuil de tolérance à définir)
>> * superposition d'objets
>> * détection de surfaces inférieures à un autre seuil
>> * etc
>> - le signalement est rabattu sur un élément FIXME ; des corrections simples 
>> peuvent
> peut-être déjà intervenir au sein de la base
>> - export de PostGIS vers osm
>>
>> Si l'utilisateur voit dans JOSM tous les FIXME, cela peut l'aider à corriger 
>> plus
> facilement, non ?
>> Je ne sais pas si c'est faisable, mais cela mérite peut-être qu'on y 
>> réfléchisse
>>
>
> +1 pour le pré-traitement des fichiers "-houses" avant leur mise à 
> disposition,
> pour leur appliquer des corrections, que ce soit via PostGIs ou les scripts 
> de Bruno par
> ex.
> En revanche je ne crois pas à l'intérêt d'ajouter des FIXME dans le fichier. 
> Pour moi
> la fonction d'avertissement est déjà (bien) assurée par le Validator, je 
> crains que ces
> FIXME ne se retrouvent directement en base. Ignorer un warning du Validator 
> ou ignorer un
> FIXME, je vois peu de différence (vu de ma lorgnette).
>
> 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
> 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 bâti => nettoyage des données cleo carto

[Romain MEHUT]

Le 8 février 2012 14:57, Etienne Trimaille  a
écrit :

>
>
> Le 8 février 2012 14:54, Romain MEHUT  a écrit :
>
> Le 8 février 2012 14:52, Pieren  a écrit :
>>
>> 2012/2/8 Romain MEHUT :
>>> > J'ajoute qu'au delà des chevauchements, il y a les bâtiments scindés en
>>> > plusieurs morceaux (par les limites de parcelles) qui prennent
>>> nettement
>>> > plus de temps à corriger.
>>>
>>> Non. Si les polygones sont correctement attachés, la fusion des deux
>>> se fait en une touche avec JOSM.
>>>
>>
>> Laquelle?
>>
>
>
> Maj + J ;-)
>
> Faut regarder dans les menus ce que propose JOSM ;-)
>

Merci. Voici un peu de temps de gagné!

 Pieren
>>
>>>
>>> ___
>>> 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
>>
>>
>
> ___
> 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 bâti => nettoyage des données cleo carto

[Vincent de Chateau-Thierry]

> De : "HELFER Denis" 
> 
> Je lance une idée en l'air (pour voir où elle peut retomber) :
> - injecter le fichier osm brut de fonderie (ou générer directement à partir 
> du pdf) 
une base locale PostGIS
> - utiliser les outils de PostGIS pour signaler les éléments problématiques
> * points trop rapprochés (seuil de tolérance à définir)
> * superposition d'objets
> * détection de surfaces inférieures à un autre seuil
> * etc
> - le signalement est rabattu sur un élément FIXME ; des corrections simples 
> peuvent 
peut-être déjà intervenir au sein de la base
> - export de PostGIS vers osm
> 
> Si l'utilisateur voit dans JOSM tous les FIXME, cela peut l'aider à corriger 
> plus 
facilement, non ?
> Je ne sais pas si c'est faisable, mais cela mérite peut-être qu'on y 
> réfléchisse 
> 

+1 pour le pré-traitement des fichiers "-houses" avant leur mise à disposition,
pour leur appliquer des corrections, que ce soit via PostGIs ou les scripts de 
Bruno par 
ex.
En revanche je ne crois pas à l'intérêt d'ajouter des FIXME dans le fichier. 
Pour moi
la fonction d'avertissement est déjà (bien) assurée par le Validator, je crains 
que ces
FIXME ne se retrouvent directement en base. Ignorer un warning du Validator ou 
ignorer un
FIXME, je vois peu de différence (vu de ma lorgnette). 

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
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[HELFER Denis]

> -Message d'origine-
> De : sly (sylvain letuffe) [mailto:li...@letuffe.org]
> Envoyé : mercredi 8 février 2012 14:32
> À : Discussions sur OSM en français
> Objet : Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo
> carto
> 
> > > Frédéric Rodrigo :
> > > - Il y a peut être une solution pas trop compliqué à mettre en
> œuvre
> > > pour corriger les deux cas d'erreur avec postgis 2.0 et la fonction
> > > http://postgis.org/documentation/manual-svn/ST_Snap.html
> 
> Je pense que c'est une solution valable pour nettoyer sa propre copie
> de la
> base, pas une méthode pour corriger en amont celle de OSM.

Je lance une idée en l'air (pour voir où elle peut retomber) :
- injecter le fichier osm  brut de fonderie (ou générer directement à partir du 
pdf) une base locale PostGIS
- utiliser les outils de PostGIS pour signaler les éléments problématiques
* points trop rapprochés (seuil de tolérance à définir)
* superposition d'objets
* détection de surfaces inférieures à un autre seuil
* etc
- le signalement est rabattu sur un élément FIXME ; des corrections simples 
peuvent peut-être déjà intervenir au sein de la base
- export de PostGIS vers osm

Si l'utilisateur voit dans JOSM tous les FIXME, cela peut l'aider à corriger 
plus facilement, non ?
Je ne sais pas si c'est faisable, mais cela mérite peut-être qu'on y 
réfléchisse 

Mes 0,02€
Denis

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

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[Eric Sibert]

J'ajoute qu'au delà des chevauchements, il y a les bâtiments scindés en
plusieurs morceaux (par les limites de parcelles) qui prennent nettement
plus de temps à corriger.


Comme ça vient d'être signalé, il y a des bâtiments mitoyens  
construits indépendamment sur des parcelles voisines (typiquement dans  
les centres anciens) qui n'ont pas lieu d'être fusionnés. Et  
inversement, des bâtiments uniques construits sur plusieurs parcelles  
qui eux doivent être fusionnés. Les données du cadastre seul ne  
permettent pas de choisir. Donc, pas de fusion/correction automatique,  
uniquement du manuel après contrôle sur le terrain.


Sinon, j'ai aussi rencontré des cas de bâtiments récents sur parcelle  
unique mais découpés en plusieurs morceaux. Dans ce cas, je serais  
plus favorable à un traitement automatisé.


Il semble qu'à un moment donné (durant automne 2011), cleo carto  
faisait la fusion en automatique. Vous confirmez?


Eric


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

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[Vincent de Chateau-Thierry]

Bonjour,

> De : "Etienne Trimaille" 
> Le 8 février 2012 14:54, Romain MEHUT  a écrit :
> > 2012/2/8 Romain MEHUT :
> >> > J'ajoute qu'au delà des chevauchements, il y a les bâtiments scindés en
> >> > plusieurs morceaux (par les limites de parcelles) qui prennent nettement
> >> > plus de temps à corriger.
> >>

N'empêche que ce temps, aussi long soit il, reste d'un volume ridicule en 
comparaison de 
tracer tout le bâti à la main, comme ça se faisait, sans autre choix, jusqu'à 
juin 2010. 
Ce temps (Denis parlait de transpiration, on parle de la même chose) figure une 
forme de 
valeur ajoutée, qui distingue de l'import brut, associé au recalage ou au tracé 
du
filaire de voies.
Ne pas oublier qu'il n'y a aucune obligation à importer du bâti, tout comme il 
n'y a
aucune obligation de faire du chiffre / du volume d'upload.
De mon côté je garde une logique assez simple : je n'importe que là où je peux 
ajouter
autre chose que ce que donne le cadastre : ne serait-ce qu'un POI, mais ce sera 
forcément
un endroit où j'ai déjà mis les pieds. Oui, ça limite le nombre de patelins, 
mais ça
limite aussi les imports "à l'aveugle". Je pense qu'on met forcément un peu plus
d'énergie à bien faire en s'occupant de coins qu'on connaît et qu'on pratique.

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
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[julien]

On Wed, 8 Feb 2012 14:32:25 +0100, sly (sylvain letuffe) wrote:

> Frédéric Rodrigo :
> - Il y a peut être une solution pas trop compliqué à mettre en 
œuvre
> pour corriger les deux cas d'erreur avec postgis 2.0 et la 
fonction

> http://postgis.org/documentation/manual-svn/ST_Snap.html


Je pense que c'est une solution valable pour nettoyer sa propre copie 
de la

base, pas une méthode pour corriger en amont celle de OSM.



Bruno :
Un des 2 scripts précédemment postés fait un "J" JOSM ("Join Node to
Way")sur tous les noeuds, et donc recolle les bâtiments.
Mais j'ai bien compris que vous n'en vouliez pas de mes bidules ;-)


Pas du tout, je pense que tu te trompes ! Je te soutiens à donf et je
suis sûr
que la majorité serait pour un nettoyage automatique, si suffisamment 
bien

fait, de la base OSM (justement pour éviter de se le taper à la main)


C'est peut etre mes expériences désastreuse d’écriture de robot (ou 
plutot leurs executions), mais je me mefie toujours un peut des 
correction automatique.

Il y aura toujours des cas de la vrai vie auquel on n'aura pas pensé

Un exemple tout bete :
les batiments
http://www.openstreetmap.org/browse/way/81188412
et
http://www.openstreetmap.org/browse/way/81188234
sont bien séparés de 20cm, il ne faut pas les recoller.

--
JB



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

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[Etienne Trimaille]

Le 8 février 2012 14:54, Romain MEHUT  a écrit :

> Le 8 février 2012 14:52, Pieren  a écrit :
>
> 2012/2/8 Romain MEHUT :
>> > J'ajoute qu'au delà des chevauchements, il y a les bâtiments scindés en
>> > plusieurs morceaux (par les limites de parcelles) qui prennent nettement
>> > plus de temps à corriger.
>>
>> Non. Si les polygones sont correctement attachés, la fusion des deux
>> se fait en une touche avec JOSM.
>>
>
> Laquelle?
>


Maj + J ;-)

Faut regarder dans les menus ce que propose JOSM ;-)


>
>
>> Pieren
>>
>> ___
>> 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
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[Romain MEHUT]

Le 8 février 2012 14:52, Pieren  a écrit :

> 2012/2/8 Romain MEHUT :
> > J'ajoute qu'au delà des chevauchements, il y a les bâtiments scindés en
> > plusieurs morceaux (par les limites de parcelles) qui prennent nettement
> > plus de temps à corriger.
>
> Non. Si les polygones sont correctement attachés, la fusion des deux
> se fait en une touche avec JOSM.
>

Laquelle?


> Pieren
>
> ___
> 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 bâti => nettoyage des données cleo carto

[Pieren]

2012/2/8 Romain MEHUT :
> J'ajoute qu'au delà des chevauchements, il y a les bâtiments scindés en
> plusieurs morceaux (par les limites de parcelles) qui prennent nettement
> plus de temps à corriger.

Non. Si les polygones sont correctement attachés, la fusion des deux
se fait en une touche avec JOSM.

Pieren

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

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[Romain MEHUT]

J'ajoute qu'au delà des chevauchements, il y a les bâtiments scindés en
plusieurs morceaux (par les limites de parcelles) qui prennent nettement
plus de temps à corriger.

Romain

Le 8 février 2012 14:18, sly (sylvain letuffe)  a écrit :

> On mardi 7 février 2012, DH wrote:
> > Le 07/02/2012 18:43, sly (sylvain letuffe) a écrit :
> > > Il semblerait qu'on passe à 2-2, mais je ne partage pas tout à fait
> l'avis
> de
> > > christian.
> >
> > Ni moi le tien. C'est ce qui fait le charme (?) de cette liste.
>
> C'est même un de ces buts ! confronter des idées et des choix pour tenter
> d'obtenir une meilleure cohérance.
>
> A lire les débats, je crois que moi et christian perdons sur un score sans
> appel de 7-2
>
> J'appliquerais donc, au delà de ce que j'en pense, ce qui resort de ce
> débat
> démocratique.
> C'est à dire suspendre mes imports du bâti. Vu qu'il est exclus que je
> fasse à
> la main ce qu'un robot pourrait faire, je laisse ça à d'autres, et j'arrête
> de mettre mes cochonneries dans la base.
>
> > Denis, tâcheron, moucheron, fourmi, cigale, cœlacanthe selon l'humeur
>
> Je me qualifierais de fourmi raisonnée ou de cigale assumée.
>
>
> --
> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[sly (sylvain letuffe)]

> > Frédéric Rodrigo :
> > - Il y a peut être une solution pas trop compliqué à mettre en œuvre
> > pour corriger les deux cas d'erreur avec postgis 2.0 et la fonction
> > http://postgis.org/documentation/manual-svn/ST_Snap.html

Je pense que c'est une solution valable pour nettoyer sa propre copie de la 
base, pas une méthode pour corriger en amont celle de OSM.


> Bruno :
> Un des 2 scripts précédemment postés fait un "J" JOSM ("Join Node to 
> Way")sur tous les noeuds, et donc recolle les bâtiments.
> Mais j'ai bien compris que vous n'en vouliez pas de mes bidules ;-)

Pas du tout, je pense que tu te trompes ! Je te soutiens à donf et je suis sûr 
que la majorité serait pour un nettoyage automatique, si suffisamment bien 
fait, de la base OSM (justement pour éviter de se le taper à la main)

Le problème a mon avis, il est là :
- 10 personnes sur cette liste savent lancer ton programme en python
- 6 ont les compétences de l'analyser le tester et l'améliorer
- et 0.5 ont le temps de le faire !

En clair, tu as accompli une très bonne première étape : fournir un soft pour 
nettoyer.
Frédéric et/ou jocelyn ont fourni l'outil pour repérer les erreurs (osmose)
et Philippe a fourni un export basé sur le soft qadastre de je sais plus qui, 
qui malheureusement ne fourni pas un export cadastre assez "propre" (ce n'est 
pas un reproche)

Maintenant, on passe au "yaka", c'est à dire trouver celui qui va proposer non 
pas une brique, mais un résultat final, qui soit facile (ou plutôt très très 
facile) à contrôler par d'autres. Puis proposer un plan d'action, obtenir 
l'accord d'une majorité d'exprimés, et le faire.

Comme toujours, facile à dire. Donc non, c'est pas qu'on en veut pas, c'est 
qu'on voudrait bien que tu fasses tout ;-)))

Dans la limite de mes compétences+temps, je veux bien filer un coup de main, 
je vais regarder ce qu'il fait ton bidule et voir comment je peux l'utiliser 
et voir comment je pourrais par exemple présenter un échantillon avant/après 
d'un fichier -houses.osm d'une commune.


-- 
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 bâti => nettoyage des données cleo carto

[sly (sylvain letuffe)]

On mardi 7 février 2012, DH wrote:
> Le 07/02/2012 18:43, sly (sylvain letuffe) a écrit :
> > Il semblerait qu'on passe à 2-2, mais je ne partage pas tout à fait l'avis 
de
> > christian.
> 
> Ni moi le tien. C'est ce qui fait le charme (?) de cette liste.

C'est même un de ces buts ! confronter des idées et des choix pour tenter 
d'obtenir une meilleure cohérance.

A lire les débats, je crois que moi et christian perdons sur un score sans 
appel de 7-2

J'appliquerais donc, au delà de ce que j'en pense, ce qui resort de ce débat 
démocratique.
C'est à dire suspendre mes imports du bâti. Vu qu'il est exclus que je fasse à 
la main ce qu'un robot pourrait faire, je laisse ça à d'autres, et j'arrête 
de mettre mes cochonneries dans la base.

> Denis, tâcheron, moucheron, fourmi, cigale, cœlacanthe selon l'humeur

Je me qualifierais de fourmi raisonnée ou de cigale assumée.


-- 
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 bâti => nettoyage des données cleo carto

[julien]

par contre, j'ai justement corrigé pas mal de truc de ce genre dont
l'auteur etait le pieren_bot... ;)


je tiens a faire ici publiquement mes excuses au bot,
il n'est que le dernier modificateur de bâtiments qui était déjà en 
erreurs.


--
JB


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

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[Bruno Cortial]

Le 8 février 2012 10:05, Frédéric Rodrigo  a écrit :

> Bonjour,
>
> J'ai deux points que j'aimerais ajouter à ce débat.
> - Il y a deux fois plus d'erreurs que ce que relève osmose. En plus
> des chevauchements il y a les vides incorrects entre les bâtiments.
> - Il y a peut être une solution pas trop compliqué à mettre en œuvre
> pour corriger les deux cas d'erreur avec postgis 2.0 et la fonction
> http://postgis.org/documentation/manual-svn/ST_Snap.html
>
> Frédéric
>
>
Un des 2 scripts précédemment postés fait un "J" JOSM ("Join Node to
Way")sur tous les noeuds, et donc recolle les bâtiments.
Mais j'ai bien compris que vous n'en vouliez pas de mes bidules ;-)

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

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[Frédéric Rodrigo]

Bonjour,

J'ai deux points que j'aimerais ajouter à ce débat.
- Il y a deux fois plus d'erreurs que ce que relève osmose. En plus
des chevauchements il y a les vides incorrects entre les bâtiments.
- Il y a peut être une solution pas trop compliqué à mettre en œuvre
pour corriger les deux cas d'erreur avec postgis 2.0 et la fonction
http://postgis.org/documentation/manual-svn/ST_Snap.html

Frédéric

Le 7 février 2012 21:08, DH  a écrit :
> Le 07/02/2012 18:43, sly (sylvain letuffe) a écrit :
>
>> Il semblerait qu'on passe à 2-2, mais je ne partage pas tout à fait l'avis
>> de
>> christian.
>
>
> Ni moi le tien. C'est ce qui fait le charme (?) de cette liste.
>
>> Hé ben je ne dois pas être tombé sur les bonnes communes, mais ça ne me
>> semble
>> pas "pas tant" que ça.
>
>
> un cadastre importé, c'est un cadastre importé. C'est sûr si c'est un
> patelin de 300 habitants, c'est moins de boulot qu'une banlieue de plusieurs
> milliers d'âmes (genre Kingersheim au hasard).
> L'enjeu et le travail reste le même :
> 1. on laisse faire les outils en attendant qu'ils s'améliorent (sur quels
> critères d'abord ?) et on a ce que l'on mérite
> 2. on connaît les limites de 1, mais le sang de la fourmi ne fait qu'un seul
> tour quand elle découvre que des miettes de qualité peuvent être grapillées
> (la fourmi est écolo dans l'âme). La fourmi est besogneuse, sinon c'est une
> cigale déguisée en fourmi.
>
>>> L'import de masse est déjà sévèrement critiqué par nos voisins. Alors
>>> si en plus, on ne corrige pas les erreurs géométriques, ça va être
>>> encore pire pour notre (déjà mauvaise) réputation.
>>
>> Je suis bien d'accord.
>>
>>> Une critique que
>>> j'ai déjà entendu concerne Corine qui parfois chevauche aussi d'autres
>>> polygones landuse (sans doute suite à une intervention manuelle, soit
>>> dans l'import, soit dans la création du doublon) et qui perdure dans
>>> la base pendant des années.
>>
>> Je suis aussi d'accord
>
>
> A l'analyse, il semble que les outils (et autre méthodes d'import de masse)
> soient tolérés dans la mesure où la "colonie" ne s'assied pas sur le tas de
> données produit d'un air satisfait : "ça c'est fait", mais prend pelle et
> pioche pour remuer le tout et l'intéger au reste de la base.
>
>>> Certains regrettent d'avantage les imports sans voirie, ou sans
>>> correction sur les voiries qui se croisent alors avec le bâti. Mais
>>> c'est le même mécanisme qui entre en jeu, celui de dire que d'autres
>>> s'en chargeront plus-tard.
>>
>> Pas d'accord. Le mécanisme dont il est question, c'est la possibilité de
>> réparer de manière automatique ce que des humains devraient faire sinon.
>> Dans celui que tu cites, je n'arrive pas à imaginer un processus
>> automatique
>> pour placer des rues entre les bâtiments ou pour savoir où passerait
>> vraiment
>> la rue. Donc là, oui, je suis d'accord pour condamner ces imports avec
>> chevauchement car aucun robot ne pourra le corriger plus tard.
>>
> Repense à HAL9000
>
> Chacun est responsable de ses apports (tiens cela ressemble encore trop à
> imports) à la base. Chaque contributeur est, de fait, responsable du niveau
> de qualité qu'il injecte dans la base. Noboby is perfect (as a ro(b)ot ?),
> mais on moins on aura mis de la transpiration dans cette base ; c'est ce qui
> devrait faire son odeur si particulière, appréciée par certains.
>
> Denis, tâcheron, moucheron, fourmi, cigale, cœlacanthe selon l'humeur
>
>
> ___
> 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 bâti => nettoyage des données cleo carto

[DH]

Le 07/02/2012 18:43, sly (sylvain letuffe) a écrit :

Il semblerait qu'on passe à 2-2, mais je ne partage pas tout à fait l'avis de
christian.


Ni moi le tien. C'est ce qui fait le charme (?) de cette liste.

Hé ben je ne dois pas être tombé sur les bonnes communes, mais ça ne me semble
pas "pas tant" que ça.


un cadastre importé, c'est un cadastre importé. C'est sûr si c'est un 
patelin de 300 habitants, c'est moins de boulot qu'une banlieue de 
plusieurs milliers d'âmes (genre Kingersheim au hasard).

L'enjeu et le travail reste le même :
1. on laisse faire les outils en attendant qu'ils s'améliorent (sur 
quels critères d'abord ?) et on a ce que l'on mérite
2. on connaît les limites de 1, mais le sang de la fourmi ne fait qu'un 
seul tour quand elle découvre que des miettes de qualité peuvent être 
grapillées (la fourmi est écolo dans l'âme). La fourmi est besogneuse, 
sinon c'est une cigale déguisée en fourmi.

L'import de masse est déjà sévèrement critiqué par nos voisins. Alors
si en plus, on ne corrige pas les erreurs géométriques, ça va être
encore pire pour notre (déjà mauvaise) réputation.

Je suis bien d'accord.


Une critique que
j'ai déjà entendu concerne Corine qui parfois chevauche aussi d'autres
polygones landuse (sans doute suite à une intervention manuelle, soit
dans l'import, soit dans la création du doublon) et qui perdure dans
la base pendant des années.

Je suis aussi d'accord


A l'analyse, il semble que les outils (et autre méthodes d'import de 
masse) soient tolérés dans la mesure où la "colonie" ne s'assied pas sur 
le tas de données produit d'un air satisfait : "ça c'est fait", mais 
prend pelle et pioche pour remuer le tout et l'intéger au reste de la base.

Certains regrettent d'avantage les imports sans voirie, ou sans
correction sur les voiries qui se croisent alors avec le bâti. Mais
c'est le même mécanisme qui entre en jeu, celui de dire que d'autres
s'en chargeront plus-tard.

Pas d'accord. Le mécanisme dont il est question, c'est la possibilité de
réparer de manière automatique ce que des humains devraient faire sinon.
Dans celui que tu cites, je n'arrive pas à imaginer un processus automatique
pour placer des rues entre les bâtiments ou pour savoir où passerait vraiment
la rue. Donc là, oui, je suis d'accord pour condamner ces imports avec
chevauchement car aucun robot ne pourra le corriger plus tard.


Repense à HAL9000

Chacun est responsable de ses apports (tiens cela ressemble encore trop 
à imports) à la base. Chaque contributeur est, de fait, responsable du 
niveau de qualité qu'il injecte dans la base. Noboby is perfect (as a 
ro(b)ot ?), mais on moins on aura mis de la transpiration dans cette 
base ; c'est ce qui devrait faire son odeur si particulière, appréciée 
par certains.


Denis, tâcheron, moucheron, fourmi, cigale, cœlacanthe selon l'humeur

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

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[didier2020]

- Mail d'origine -
De: sly (sylvain letuffe) 
À: Discussions sur OSM en français 
Envoyé: Tue, 07 Feb 2012 18:43:59 +0100 (CET)
Objet: Re: [OSM-talk-fr]    Import bâti => nettoyage des données cleo carto

>Je ne suis pas d'accord sur le "c'est pas grave", je pense juste que corriger 
>à la main est une perte de temps qui serait mieux employé.

sur ce point je suis et d'accord et pas d'accord
j'ai recherché les zones ayant le plus grand nombre d'erreur de chevauchement 
(cumul des erreurs detectées par osmose)

La premiere source d'erreur , c'etait des upload ratés (beaucoup trop...)
après soit 
 - il n'y avait que des erreurs de chevauchement minime
 - beaucoup d'autres erreur : highway residential/unclassified vs building
 - probleme de delimitation de communes et de batiment sur 2 communes

pour les fichiers cadastre, le nombre d'erreurs que j'ai corrigé est compris 
entre 0 et plus de 800...
(ce n'est pas forcement lié au nombre de building). 

didier
--mapeur amateur--

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

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[partir-en-vtt]

Personnellement, j'ai développé un traitement sous FME qui
enlevait/corrigeait les superpositions.

Les points dupliqués peuvent être aussi traités. Le seul souci résidait dans
le fait de détecter les mauvaises découpes dans le bâti...Malheureusement on
aura pas un noyau FME à dispo pour les traitements à moins que safe software
fasse un geste en nous mettant à dispo un FME server à disposition pour le
projet OSM.

--
View this message in context: 
http://gis.19327.n5.nabble.com/Import-bati-nettoyage-des-donnees-cleo-carto-tp5432658p5464122.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 bâti => nettoyage des données cleo carto

[Bruno Cortial]

Salut,
Il y a quelques temps, j'avais proposé 2 scripts python pour améliorer les
fichiers Cléo.
http://lists.openstreetmap.org/pipermail/talk-fr/2011-August/035156.html

Ca n'avait pas eu un grand succès à l'époque je retente ce soir: si des
testeurs pouvaient faire un retour sur la qualité des fiabilisations. Pas
la peine de faire un import, un petit coup de validator avant/apres, une
superposition des couches pour vérifier que l'on respecte la géométrie,
qu'on perd pas les relations multipolygone Et on pourrait mettre ça
dans la chaîne de génération Cléo, et (presque) fermer le robinet.

L'étape suivante c'est l'automate évoqué par sly : appliquer l'équivalent
au bâti OSM détecté en ano par Osmose.

A+
Bruno
#!/usr/bin/python
# -*- coding: utf8 -*-

from rtree import Rtree
import OsmSax, sys

DIST_MIN = 1.0e-12

def coords(n):
return (n.lat, n.lon)

def distance2(a,b):
xa, ya = coords(a)
xb, yb = coords(b)
return (xa-xb)**2 + (ya-yb)**2


class Node(object):
def __init__(self, id=None, lon=None, lat=None, tags=None):
self.id = id
if lon != None: self.lon, self.lat = float(lon), float(lat)
if tags:
self.tags = tags
else:
self.tags = {}
self.inWay = set()
self.inRel = set()

class Way(object):
def __init__(self, id=None, nodes=None, tags=None):
self.id = id
if nodes:
self.nodes = nodes
else:
self.nodes = []
if tags:
self.tags = tags
else:
self.tags = {}

class Relation(object):
def __init__(self, id, members=None, tags=None):
self.id = id
if members:
  self.members = members
else:
  self.members = []
if tags:
  self.tags = tags
else:
  self.tags = {}
def __repr__(self):
  return "Relation(id=%r, members=%r, tags=%r)" % (self.id, self.members, self.tags)

class Cache:
def __init__(self):
self.nods = {}
self.ways = {}
self.rels = {}
def NodeCreate(self, data):
self.nods[data["id"]] = Node(id=data["id"],lon=data["lon"],lat=data["lat"],tags=data["tag"])
def WayCreate(self, data):
self.ways[data["id"]] = Way(id=data["id"],nodes=data["nd"],tags=data["tag"])
def RelationCreate(self, data):
self.rels[data["id"]] = Relation(id=data["id"],tags=data["tag"],members=data["member"])

###

fout = sys.argv[2]
data = OsmSax.OsmSaxReader(sys.argv[1])
cache = Cache()
print 'Parse du fichier...'
data.CopyTo(cache)


idxNode = Rtree()
tabindx = {}
print 'Indexation...'
i = 0
for k in cache.nods.keys():
i += 1
idxNode.insert(i, coords(cache.nods[k]))
tabindx[i] = cache.nods[k]

# set des chemins utilisant un noeud
for w in cache.ways.values():
for nid in w.nodes: cache.nods[nid].inWay.add(w)
# set des relations utilisant un noeud
for r in cache.rels.values():
for m in r.members:
if m['type'] == 'node': cache.nodes[m['ref']].inRel.add(r)

print 'Simplification des noeuds...'
# balayage des noeuds à simplifier
for noeud in cache.nods.values():
#print 'traitment', noeud.id
# le noeud a-t-il déjà été supprimé
if not cache.nods.has_key(noeud.id): continue
# recherche des noeuds proches
for i in idxNode.nearest(coords(noeud),4):
np = tabindx[i]
if np == noeud: continue
if distance2(noeud, np) < DIST_MIN:
noeud.tags['fixme']='simplify'
#remplacement du np par noeud dans les ways
for w in np.inWay:
while np.id in w.nodes :
ind = w.nodes.index(np.id)
w.nodes[ind]=noeud.id
#suppression np de l'index
idxNode.delete(i,coords(np))
#suppression de la liste des noeuds
del cache.nods[np.id]
 
print 'Nettoyage des chemins...'
for w in cache.ways.values():
i = 1
# balayage des segments d'un way
while  (len(w.nodes) > 1) & (i < len(w.nodes)):
if w.nodes[i-1] == w.nodes[i]:
w.nodes.pop(i)
continue
i += 1

print 'Ecriture...'
out = OsmSax.OsmSaxWriter(fout, "UTF-8")
out.startDocument()
out.startElement("osm", {'version':'0.6'})
for n in cache.nods.values():
out.NodeCreate({'id':n.id,'lon':n.lon,'lat':n.lat,'tag':n.tags})
for w in cache.ways.values():
out.WayCreate({'id':w.id,'nd':w.nodes,'tag':w.tags})
for r in cache.rels.values():
out.RelationCreate({'id':r.id,'member':r.members,'tag':r.tags})

out.endElement("osm")

#!/usr/bin/python
# -*- coding: utf8 -*-

from rtree import Rtree
import OsmSax, sys
from shapely.geometry import Point, LineString

DIST_MIN = 2.0e-6

def coords(n):
return (n.lat, n.lon)



def procheWay(nd, p1, p2):
   #renvoie vrai si node est pres du segment formé par p1,p2
   no=Point(coords(nd))
   no1=Point(coords(p1))
   no2=Point(coords(p2))
   seg 

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[Romain MEHUT]

Le 7 février 2012 18:43, sly (sylvain letuffe)  a écrit :

> Il semblerait qu'on passe à 2-2, mais je ne partage pas tout à fait l'avis
> de
> christian.
>

+1 pour Pieren ce qui fait 3-2 ;)
Pour avoir fait pas mal d'import du bâti, je me suis toujours "astreint" à
corriger les chevauchements. Cela me semble normal que de ne pas envoyer
des données pleines d'erreurs et franchement ce n'est pas si la mort que
ça...


> Je ne suis pas d'accord sur le "c'est pas grave", je pense juste que
> corriger
> à la main est une perte de temps qui serait mieux employé.
>
> Je suis bien évidement pour qu'un courageux nous développe l'outil qui
> corrigera ce qui peut se corriger de manière automatique.
>
> > Corriger le bâti ne nécessite pas tant de travail que ça.
>
> Hé ben je ne dois pas être tombé sur les bonnes communes, mais ça ne me
> semble
> pas "pas tant" que ça.
>
> > Pensez à
> > tous les autres pays qui font ça à la mano en traçant sur l'imagerie
> > et vous comprendrez...
>
> Tant pis pour eux, justement, on a pas cette non-chance, c'est pas parce
> que
> c'est pire ailleurs qu'on doit accepter de se transformer en robots !
>
> > L'import de masse est déjà sévèrement critiqué par nos voisins. Alors
> > si en plus, on ne corrige pas les erreurs géométriques, ça va être
> > encore pire pour notre (déjà mauvaise) réputation.
>
> Je suis bien d'accord.
>
> > Une critique que
> > j'ai déjà entendu concerne Corine qui parfois chevauche aussi d'autres
> > polygones landuse (sans doute suite à une intervention manuelle, soit
> > dans l'import, soit dans la création du doublon) et qui perdure dans
> > la base pendant des années.
>
> Je suis aussi d'accord
>
> > Je ne fais évidemment pas partie du camps des "anti-import" mais il
> > faut toujours exiger un minimum de qualité. Déclarer "un script s'en
> > chargera plus-tard", c'est prendre le risque que les erreurs ne soient
> > jamais corrigées
>
> Pas d'accord, quand bien même l'hypothèse qu'aucun script n'existe jamais,
> cela n'invalide pas que l'on puisse quand même le faire, a posteriori, à la
> main.
> Alors entre le faire tout de suite, et le faire peut-être plus tard, je
> préfère le "peut-être plus tard"
>
> > Certains regrettent d'avantage les imports sans voirie, ou sans
> > correction sur les voiries qui se croisent alors avec le bâti. Mais
> > c'est le même mécanisme qui entre en jeu, celui de dire que d'autres
> > s'en chargeront plus-tard.
>
> Pas d'accord. Le mécanisme dont il est question, c'est la possibilité de
> réparer de manière automatique ce que des humains devraient faire sinon.
> Dans celui que tu cites, je n'arrive pas à imaginer un processus
> automatique
> pour placer des rues entre les bâtiments ou pour savoir où passerait
> vraiment
> la rue. Donc là, oui, je suis d'accord pour condamner ces imports avec
> chevauchement car aucun robot ne pourra le corriger plus tard.
>
>
>
> --
> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[julien]

On Tue, 7 Feb 2012 17:49:24 +0100, Pieren wrote:

2012/2/7 Christian Quest :


+1



-1 (comme d'hab)


+1 avec pieren

par contre, j'ai justement corrigé pas mal de truc de ce genre dont 
l'auteur etait le pieren_bot... ;)


j'essaye de faire en sorte qu'il n'y ai plus d'erreur validator/JOSM 
quand j'importe du bati.

Ou tout du moins que je ne rajoute pas d'erreurs.



Corriger le bâti ne nécessite pas tant de travail que ça.


ca depend des communes
quand il y a +300 erreurs, c'est un peut decourageant.




Pensez à
tous les autres pays qui font ça à la mano en traçant sur l'imagerie
et vous comprendrez...
L'import de masse est déjà sévèrement critiqué par nos voisins. Alors
si en plus, on ne corrige pas les erreurs géométriques, ça va être
encore pire pour notre (déjà mauvaise) réputation. Une critique que
j'ai déjà entendu concerne Corine qui parfois chevauche aussi 
d'autres

polygones landuse (sans doute suite à une intervention manuelle, soit
dans l'import, soit dans la création du doublon) et qui perdure dans
la base pendant des années.
Je ne fais évidemment pas partie du camps des "anti-import" mais il
faut toujours exiger un minimum de qualité. Déclarer "un script s'en
chargera plus-tard", c'est prendre le risque que les erreurs ne 
soient

jamais corrigées (c'est un peu ce qu'on lit entre les lignes, "après
tout, ça n'est pas si grave"). Et à partir de quel pourcentage on
considère que le chevauchement est "grave", donc "une erreur" ou un
"doublon" ? Faudra-t-il aussi accepter ce genre de chevauchements 
pour

d'autres entités comme les landuse ou les boundaries ?
Certains regrettent d'avantage les imports sans voirie, ou sans
correction sur les voiries qui se croisent alors avec le bâti. Mais
c'est le même mécanisme qui entre en jeu, celui de dire que d'autres
s'en chargeront plus-tard. Notre "discours" dans ce domaine doit
vraiment rester dans la recherche constante de l'amélioration des
données et non du statu quo (c'est aussi très important vis-à-vis des
nouveaux arrivants qui peuvent nous lire).

Pieren

___
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 bâti => nettoyage des données cleo carto

[sly (sylvain letuffe)]

Il semblerait qu'on passe à 2-2, mais je ne partage pas tout à fait l'avis de 
christian.

Je ne suis pas d'accord sur le "c'est pas grave", je pense juste que corriger 
à la main est une perte de temps qui serait mieux employé.

Je suis bien évidement pour qu'un courageux nous développe l'outil qui 
corrigera ce qui peut se corriger de manière automatique.

> Corriger le bâti ne nécessite pas tant de travail que ça. 

Hé ben je ne dois pas être tombé sur les bonnes communes, mais ça ne me semble 
pas "pas tant" que ça.

> Pensez à 
> tous les autres pays qui font ça à la mano en traçant sur l'imagerie
> et vous comprendrez...

Tant pis pour eux, justement, on a pas cette non-chance, c'est pas parce que 
c'est pire ailleurs qu'on doit accepter de se transformer en robots !

> L'import de masse est déjà sévèrement critiqué par nos voisins. Alors
> si en plus, on ne corrige pas les erreurs géométriques, ça va être
> encore pire pour notre (déjà mauvaise) réputation. 

Je suis bien d'accord.

> Une critique que 
> j'ai déjà entendu concerne Corine qui parfois chevauche aussi d'autres
> polygones landuse (sans doute suite à une intervention manuelle, soit
> dans l'import, soit dans la création du doublon) et qui perdure dans
> la base pendant des années.

Je suis aussi d'accord

> Je ne fais évidemment pas partie du camps des "anti-import" mais il
> faut toujours exiger un minimum de qualité. Déclarer "un script s'en
> chargera plus-tard", c'est prendre le risque que les erreurs ne soient
> jamais corrigées 

Pas d'accord, quand bien même l'hypothèse qu'aucun script n'existe jamais, 
cela n'invalide pas que l'on puisse quand même le faire, a posteriori, à la 
main.
Alors entre le faire tout de suite, et le faire peut-être plus tard, je 
préfère le "peut-être plus tard"

> Certains regrettent d'avantage les imports sans voirie, ou sans
> correction sur les voiries qui se croisent alors avec le bâti. Mais
> c'est le même mécanisme qui entre en jeu, celui de dire que d'autres
> s'en chargeront plus-tard. 

Pas d'accord. Le mécanisme dont il est question, c'est la possibilité de 
réparer de manière automatique ce que des humains devraient faire sinon.
Dans celui que tu cites, je n'arrive pas à imaginer un processus automatique 
pour placer des rues entre les bâtiments ou pour savoir où passerait vraiment 
la rue. Donc là, oui, je suis d'accord pour condamner ces imports avec 
chevauchement car aucun robot ne pourra le corriger plus tard.



-- 
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 bâti => nettoyage des données cleo carto

[simon]

Le mardi 07 février 2012 17:49:24, Pieren a écrit :
> 2012/2/7 Christian Quest :
> > +1
> 
> -1 (comme d'hab)
> 
> Corriger le bâti ne nécessite pas tant de travail que ça. Pensez à
> tous les autres pays qui font ça à la mano en traçant sur l'imagerie
> et vous comprendrez...
> L'import de masse est déjà sévèrement critiqué par nos voisins. Alors
> si en plus, on ne corrige pas les erreurs géométriques, ça va être
> encore pire pour notre (déjà mauvaise) réputation. Une critique que
> j'ai déjà entendu concerne Corine qui parfois chevauche aussi d'autres
> polygones landuse (sans doute suite à une intervention manuelle, soit
> dans l'import, soit dans la création du doublon) et qui perdure dans
> la base pendant des années.
> Je ne fais évidemment pas partie du camps des "anti-import" mais il
> faut toujours exiger un minimum de qualité. Déclarer "un script s'en
> chargera plus-tard", c'est prendre le risque que les erreurs ne soient
> jamais corrigées (c'est un peu ce qu'on lit entre les lignes, "après
> tout, ça n'est pas si grave"). Et à partir de quel pourcentage on
> considère que le chevauchement est "grave", donc "une erreur" ou un
> "doublon" ? Faudra-t-il aussi accepter ce genre de chevauchements pour
> d'autres entités comme les landuse ou les boundaries ?
> Certains regrettent d'avantage les imports sans voirie, ou sans
> correction sur les voiries qui se croisent alors avec le bâti. Mais
> c'est le même mécanisme qui entre en jeu, celui de dire que d'autres
> s'en chargeront plus-tard. Notre "discours" dans ce domaine doit
> vraiment rester dans la recherche constante de l'amélioration des
> données et non du statu quo (c'est aussi très important vis-à-vis des
> nouveaux arrivants qui peuvent nous lire).
> 
> Pieren
> 

+1

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

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[Pieren]

2012/2/7 Christian Quest :

> +1
>

-1 (comme d'hab)

Corriger le bâti ne nécessite pas tant de travail que ça. Pensez à
tous les autres pays qui font ça à la mano en traçant sur l'imagerie
et vous comprendrez...
L'import de masse est déjà sévèrement critiqué par nos voisins. Alors
si en plus, on ne corrige pas les erreurs géométriques, ça va être
encore pire pour notre (déjà mauvaise) réputation. Une critique que
j'ai déjà entendu concerne Corine qui parfois chevauche aussi d'autres
polygones landuse (sans doute suite à une intervention manuelle, soit
dans l'import, soit dans la création du doublon) et qui perdure dans
la base pendant des années.
Je ne fais évidemment pas partie du camps des "anti-import" mais il
faut toujours exiger un minimum de qualité. Déclarer "un script s'en
chargera plus-tard", c'est prendre le risque que les erreurs ne soient
jamais corrigées (c'est un peu ce qu'on lit entre les lignes, "après
tout, ça n'est pas si grave"). Et à partir de quel pourcentage on
considère que le chevauchement est "grave", donc "une erreur" ou un
"doublon" ? Faudra-t-il aussi accepter ce genre de chevauchements pour
d'autres entités comme les landuse ou les boundaries ?
Certains regrettent d'avantage les imports sans voirie, ou sans
correction sur les voiries qui se croisent alors avec le bâti. Mais
c'est le même mécanisme qui entre en jeu, celui de dire que d'autres
s'en chargeront plus-tard. Notre "discours" dans ce domaine doit
vraiment rester dans la recherche constante de l'amélioration des
données et non du statu quo (c'est aussi très important vis-à-vis des
nouveaux arrivants qui peuvent nous lire).

Pieren

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

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[Christian Quest]

Le 7 février 2012 16:31, sly (sylvain letuffe)  a écrit :

> On mardi 7 février 2012, partir-en-vtt wrote:
> > JOSM propose la correction automatique de la superposition de bâtiment ?
> Je
> > n'ai pas trouvé. Comment procéder ?
>
> Pour ma part, j'ai abandonné ce genre de corrections. Oui oui, je sais,
> c'est
> pas bien. Explications :
>
> - C'est un boulot manuel de fou
> - Y'a déjà du pourri dans la base
> - un logiciel pourrait en réparer une grande partie automatiquement
> - D'autres ne feront de toute façon pas cette effort
>
> J'ai donc jugé qu'il n'y avait que peu d'issues valables à cet état de
> fait :
> 1) développer un robot qui nettoye le merdier des bâtiments
> 2) ne rien faire
>
> Dans les deux cas, rien ne justifie selon moi de perdre du "temps
> contributeur" qui serait mieux employé à autre chose.
>
> ps: je n'ai pas dis que réparer le problème en amont (fichier -houses)
> n'était
> pas une bonne idée, je dis que ça n'est de toute façon pas suffisant
>
>

+1

Je ne vois pas non plus quel problème cela pose réellement d'avoir des
petits chevauchements de bâti et un de ces 4 on aura bien un algo qui
remettra ça au propre.
Par contre, les chevauchements avec les highway existants sont à corriger...

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

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[sly (sylvain letuffe)]

On mardi 7 février 2012, partir-en-vtt wrote:
> JOSM propose la correction automatique de la superposition de bâtiment ? Je
> n'ai pas trouvé. Comment procéder ?

Pour ma part, j'ai abandonné ce genre de corrections. Oui oui, je sais, c'est 
pas bien. Explications :

- C'est un boulot manuel de fou
- Y'a déjà du pourri dans la base
- un logiciel pourrait en réparer une grande partie automatiquement
- D'autres ne feront de toute façon pas cette effort

J'ai donc jugé qu'il n'y avait que peu d'issues valables à cet état de fait :
1) développer un robot qui nettoye le merdier des bâtiments 
2) ne rien faire

Dans les deux cas, rien ne justifie selon moi de perdre du "temps 
contributeur" qui serait mieux employé à autre chose.

ps: je n'ai pas dis que réparer le problème en amont (fichier -houses) n'était 
pas une bonne idée, je dis que ça n'est de toute façon pas suffisant

-- 
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 bâti => nettoyage des données cleo carto

[partir-en-vtt]

C'était pour un nouvel import et bon 70 retouches à la mano, ce n'est quand
même pas la joie. Je vais donc continuer à créer une moulinette corrigeant
ces soucis.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Import-bati-nettoyage-des-donnees-cleo-carto-tp5432658p5463462.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 bâti => nettoyage des données cleo carto

[julien]

On Tue, 7 Feb 2012 06:39:08 -0800 (PST), partir-en-vtt wrote:

Bonjour et merci pour la réponse,

La superposition n'est pas représenté comme une erreur mais un
avertissement.


le validator leve plusieurs erreurs
- des ways en double, donc des batiments en double/triple depuis le 
cadastre
- des points qui ont les même coordonnées mais qui sont deux points 
différents
- des points qui sont mis deux fois dans le même way (et pas pour 
boucler le batiment)

- d'autres

dans les 2 premiers cas, je crois qu'il propose l'action de correction

De plus, lorsque je clic sur le nœud, le bouton réparer n'est pas 
disponible

et j'en déduit qu'il faut donc le faire à la main ?


pour certains cas, oui

tu a un ID de way ?

--
JB

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

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[didier2020]

- Mail d'origine -
De: partir-en-vtt 
À: talk-fr@openstreetmap.org
Envoyé: Tue, 07 Feb 2012 15:39:08 +0100 (CET)
Objet: Re: [OSM-talk-fr]    Import bâti => nettoyage des données cleo carto

Bonjour et merci pour la réponse,

La superposition n'est pas représenté comme une erreur mais un
avertissement.
=> les noeuds ne doivent pas avoir exactement les memes coordonnées ...

De plus, lorsque je clic sur le nœud, le bouton réparer n'est pas disponible
et j'en déduit qu'il faut donc le faire à la main ?
=> cela semble la seule issue ... oui !

--
View this message in context: 
http://gis.19327.n5.nabble.com/Import-bati-nettoyage-des-donnees-cleo-carto-tp5432658p5463295.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

-- 
didier
--mapeur amateur--

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

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[Vincent de Chateau-Thierry]

Bonjour,

> De : "partir-en-vtt" 
> 
> La superposition n'est pas représenté comme une erreur mais un
> avertissement.
> 
> De plus, lorsque je clic sur le nœud, le bouton réparer n'est pas disponible
> et j'en déduit qu'il faut donc le faire à la main ?
> 

Le Validator passe une erreur pour 2 bâtiments rigoureusement superposés (même
suite de nodes pour définir les 2 bâtiments). Dans ce cas, on a une erreur 
"Chemins
dupliqués" et la possibilité de "réparer" en un clic. Idem pour des noeuds 
superposés.
En revanche pour des bâtiments partiellement superposés (chacun n'ayant qu'une 
partie de
sa surface superposée à l'autre), on n'a en effet qu'un warning "Bâtiments se
chevauchant", et là, il faut sa souris, son clavier, et un peu de temps :-)

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
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[partir-en-vtt]

Bonjour et merci pour la réponse,

La superposition n'est pas représenté comme une erreur mais un
avertissement.

De plus, lorsque je clic sur le nœud, le bouton réparer n'est pas disponible
et j'en déduit qu'il faut donc le faire à la main ?

--
View this message in context: 
http://gis.19327.n5.nabble.com/Import-bati-nettoyage-des-donnees-cleo-carto-tp5432658p5463295.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 bâti => nettoyage des données cleo carto

[didier2020]

- Mail d'origine -
De: partir-en-vtt 
À: talk-fr@openstreetmap.org
Envoyé: Tue, 07 Feb 2012 14:45:00 +0100 (CET)
Objet: Re: [OSM-talk-fr]    Import bâti => nettoyage des données cleo carto

JOSM propose la correction automatique de la superposition de bâtiment ? Je
n'ai pas trouvé. Comment procéder ?

+ lancer la validation.
+ dans la fenetre ou apparait l'analyse du validator
+ clic sur le sens interdit pour faire apparaitre le détail des erreurs
+ clic sur le type d'erreur => il apparait le bouton réparer.

je te dis cela de souvenir, je n'ai pas josm sous la main...

didier


--
View this message in context: 
http://gis.19327.n5.nabble.com/Import-bati-nettoyage-des-donnees-cleo-carto-tp5432658p5463162.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

--
didier
--mapeur amateur--

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

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[partir-en-vtt]

JOSM propose la correction automatique de la superposition de bâtiment ? Je
n'ai pas trouvé. Comment procéder ?

--
View this message in context: 
http://gis.19327.n5.nabble.com/Import-bati-nettoyage-des-donnees-cleo-carto-tp5432658p5463162.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 bâti => nettoyage des données cleo carto

[Philippe Pary]

Le 26/01/2012 15:56, jul...@krilin.org a écrit :


Que les bâtiments se superposent,
Qu'il y a parfois des nœuds en doublons,


le plugin validtor de josm propose des corrections automatique pour ca.


Si quelqu'un veut se pencher sur le code de Qadastre (le mieux) ou créer 
un code/script pour nettoyer les fichiers cléo (pis aller), pas de 
soucis, je le mets en place.


Philippe

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

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[Romain MEHUT]

Le 26 janvier 2012 15:56,  a écrit :

> On Thu, 26 Jan 2012 03:44:20 -0800 (PST), partir-en-vtt wrote:
>
>> J'avais il y a quelque temps ouvert un sujet similaire: L'objectif était
>> de
>> proposer une moulinette pour nettoyer les erreurs de l'import du bâti.
>> L'outil cleo-carto est extraordinaire pour générer les fichiers. Il me
>> semble qu'il y a moins d'erreurs qu'avant.
>>
>> Pour autant tout n'est pas parfait et j'ai repéré que la majorité des
>> erreurs sont :
>>
>> Que les bâtiments se superposent,
>> Qu'il y a parfois des nœuds en doublons,
>>
>
> le plugin validtor de josm propose des corrections automatique pour ca.
>
>
>  Qu'il y a parfois une utilisation trop importante de nœuds,
>> Qu'il y a des coupures dans les bâtiments qui sont inutiles.
>>
>
> comment savoir si la coupure est "justifié" ou pas ?
>

Ce sont effectivement les erreurs les moins évidentes à identifier. De mon
côté, je m'aide de la couche cadastrale, de l'imagerie Bing et en dernier
ressort de l'observation sur le terrain mais tout ça c'est "à la main" donc
long.


>  C'est le quatrième souci qui n'est pas facile à traiter. En effet, comment
>> déterminer automatiquement si oui ou non il s'agit d'un artefact ?
>>  Faut-il
>> fusionner les morceaux qui sont triangulaires et/ou qui ont une surface
>> déterminée ? Je fais appel à vos idées.
>>
>
> josm propose une selection par la surface.
> On peut sortir tous les building qui ont une surface = 0m^2
> ___
> 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 bâti => nettoyage des données cleo carto

[julien]

On Thu, 26 Jan 2012 03:44:20 -0800 (PST), partir-en-vtt wrote:
J'avais il y a quelque temps ouvert un sujet similaire: L'objectif 
était de
proposer une moulinette pour nettoyer les erreurs de l'import du 
bâti.
L'outil cleo-carto est extraordinaire pour générer les fichiers. Il 
me

semble qu'il y a moins d'erreurs qu'avant.

Pour autant tout n'est pas parfait et j'ai repéré que la majorité des
erreurs sont :

Que les bâtiments se superposent,
Qu'il y a parfois des nœuds en doublons,


le plugin validtor de josm propose des corrections automatique pour ca.


Qu'il y a parfois une utilisation trop importante de nœuds,
Qu'il y a des coupures dans les bâtiments qui sont inutiles.


comment savoir si la coupure est "justifié" ou pas ?

C'est le quatrième souci qui n'est pas facile à traiter. En effet, 
comment
déterminer automatiquement si oui ou non il s'agit d'un artefact ?  
Faut-il
fusionner les morceaux qui sont triangulaires et/ou qui ont une 
surface

déterminée ? Je fais appel à vos idées.


josm propose une selection par la surface.
On peut sortir tous les building qui ont une surface = 0m^2



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

Re: [OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[PhQ]

Pour ma part, quand j'ai un doute, je regarde avec l'imagerie disponible. Il
est vrai que dans le Puy de Dôme, j'ai la chance de disposer de Bing 2010-11
avec une précision de 30cm ainsi que CRAIG 2009. (même précision).

Reste que c'est un boulot de ... dentelière.  (  :) )

--
View this message in context: 
http://gis.19327.n5.nabble.com/Import-bati-nettoyage-des-donnees-cleo-carto-tp5432658p5432997.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

[OSM-talk-fr] Import bâti => nettoyage des données cleo carto

[partir-en-vtt]

J'avais il y a quelque temps ouvert un sujet similaire: L'objectif était de
proposer une moulinette pour nettoyer les erreurs de l'import du bâti.
L'outil cleo-carto est extraordinaire pour générer les fichiers. Il me
semble qu'il y a moins d'erreurs qu'avant.

Pour autant tout n'est pas parfait et j'ai repéré que la majorité des
erreurs sont :

Que les bâtiments se superposent,
Qu'il y a parfois des nœuds en doublons,
Qu'il y a parfois une utilisation trop importante de nœuds,
Qu'il y a des coupures dans les bâtiments qui sont inutiles.


Pour le premier problème, j'ai réussi à le traiter et j'effectue un
nettoyage de ces superpositions (c'est je pense le plus gros problème et
celui qui prend du temps à traiter),
Pour le second, ça doit pouvoir aussi s'arranger, il suffit de supprimer les
superpositions de noeuds
Pour le troisième, idem, on peut arranger ça avec une simplification

C'est le quatrième souci qui n'est pas facile à traiter. En effet, comment
déterminer automatiquement si oui ou non il s'agit d'un artefact ?  Faut-il
fusionner les morceaux qui sont triangulaires et/ou qui ont une surface
déterminée ? Je fais appel à vos idées.

Merci et à bientôt.

--
View this message in context: 
http://gis.19327.n5.nabble.com/Import-bati-nettoyage-des-donnees-cleo-carto-tp5432658p5432658.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