from:"Tyndare"

Re: [OSM-dev-fr] Validation de bâtiments fractionnés par le cadastre

2017-01-08 Par sujet Tyndare




Le 03/01/2017 à 21:38, Frédéric Rodrigo a écrit :

Tout pareil, superbe !

Je trouve juste le zoom par défaut un peut trop fort.

Il ma proposé ce way avec deux bâtiments diff :
https://www.openstreetmap.org/way/125318528

Par contre tu en fais quoi des résultats ensuite ?

Frédéric.


Premier commit à partir des contributions: 173 fusions de bâtiments:
http://nrenner.github.io/achavi/?changeset=45013492

Il y a par ailleurs 14 fusions qui n'ont pas était faites parce qu'elles 
avaient des bâtiments en communs, et 1 car les tags différaient:

http://cadastre.openstreetmap.fr/segmented/#22451

Il y en a qui sont aussi exclues pour le moment car il reste des cas non 
traités tout proche.





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

Re: [OSM-dev-fr] Validation de bâtiments fractionnés par le cadastre

2017-01-04 Par sujet Tyndare



Petite mise à jour:
- j'ai viré l'haricot rose et mis des boutons tout simple: + - ?
- j'ai changé le mode de zoom pour moins zoomer pour les tout petits 
cas, mais peut être que ça zoom plus pour les plus gros cas donc je sais 
pas si c'est mieux.
- j'ai rajouté un #id dans l'url pour pouvoir partagé des cas 
problématiques plus facilement.


Le 03/01/2017 à 21:38, Frédéric Rodrigo a écrit :

Tout pareil, superbe !

Je trouve juste le zoom par défaut un peut trop fort.

Il ma proposé ce way avec deux bâtiments diff :
https://www.openstreetmap.org/way/125318528

Par contre tu en fais quoi des résultats ensuite ?

Frédéric.

Le 03/01/2017 à 21:24, Christian Quest a écrit :

Impeccable !

La BD Ortho est limite en résolution sur la Guadeloupe, à tester en
métropole sur une ortho haute-def...

Les icônes pour les 3 choix ne sont pas très explicites, les haricots
roses ça fait bizarre ;)


Le 3 janvier 2017 à 21:14, Tyndare <tynd...@wanadoo.fr
<mailto:tynd...@wanadoo.fr>> a écrit :



Le 03/01/2017 à 13:56, Vincent de Château-Thierry a écrit :

Bonjour,
J'ai testé quelques minutes. Je n'ai eu que des cas à
fusionner, ce qui donne envie de prendre ton algo de détection
pour argent comptant. J'exagère mais ça interpelle.


L'algo essaye d'être sélectif, ça marche plutôt bien en rase
campagne, mais il se plante tellement souvent dans les villes que
ça compense.

Manifestement la Guadeloupe c'était un très mauvais choix pour
tester la page, sur 300 contributions 1 seule personne a osé
cliquer sur le bouton du milieu (et en plus c'était moi)

S'il y a que des cas positifs ça deviens monotone comme activité.
Peut être qu'il faudrait chercher a évaluer un indice de confiance
des prédictions, et mixer des propositions de cas où la confiance
est bonne et d'autres moins bonne.

J'ai parfois été dérouté par les divergences entre les sources
: sur ta zone de test, la date de màj de l'ortho et celle du
cadastre divergent franchement par endroits, et on en vient à
ne pas pouvoir s'aider de l'ortho tant elle n'est pas raccord
avec le cadastre.

Dans ces cas là il ne faut pas hésiter a cliquer sur le bouton "?"

Ca ne change rien à l'efficacité de l'interface, tu as su faire
simple comme OpenSolarMap, c'est tout bon.

Merci Vincent, et surtout merci à Christian pour OpenSolarMap !

Je viens de mettre à jour pour rajouter des statistiques comme sur
la page de référence.


___
dev-fr mailing list
dev-fr@openstreetmap.org <mailto:dev-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/dev-fr
<https://lists.openstreetmap.org/listinfo/dev-fr>




--
Christian Quest - OpenStreetMap France


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




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


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

Re: [OSM-dev-fr] Validation de bâtiments fractionnés par le cadastre

2017-01-03 Par sujet Tyndare



Le 03/01/2017 à 22:03, Christian Quest a écrit :

Un bug: des propositions de fusion de polygones de nature différent
(wall=no d'un côté et normal de l'autre).


e veux des preuves ;-)
En fait l'analyse est uniquement basée sur les données OSM, et il y a 
beaucoup d'endroit ou les wall=no sont manquants dans OSM.


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

Re: [OSM-dev-fr] Validation de bâtiments fractionnés par le cadastre

2017-01-03 Par sujet Tyndare




Le 03/01/2017 à 21:24, Christian Quest a écrit :

Impeccable !

La BD Ortho est limite en résolution sur la Guadeloupe, à tester en
métropole sur une ortho haute-def...

Les icônes pour les 3 choix ne sont pas très explicites, les haricots
roses ça fait bizarre ;)




Quoi il sont pas beau mes œeufs roses qui fusionnent ?
J'étais pourtant content de mon idée, mais j'ai pas vraiment de talent 
de graphiste ou de designer.

j'attends vos propositions !

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

Re: [OSM-dev-fr] Aide pour Osmose et SQL: buildings cadastre fractionnés

2016-06-08 Par sujet Tyndare

J'ai mis à jour la détection des bâtiments fractionnés:

- j'ai amélioré les fichiers d'exemples servant à l'apprentissage
(j'avais raté des bâtiment fractionnés, il en manque peu être
encore) (http://cadastre.openstreetmap.fr/segmented_building_data/)

- Jai finalement abandonné SVM pour passer à une classification avec
KNeighbors qui donne de meilleurs résultats. PB: c'est bien plus lent
à l'exécution et ça annule les gains que j'avais obtenu en recodant
une partie en C. De nouveau ma rajoute 40' pour analyser
la région Rhône-Alpes avec Osmose-backend.

Si vous voulez voire un résultat d'analyse vous pouvez regarder les
fichiers -prediction_segmente.osm générés sur cadastre.openstreetmap.fr

comme ici: http://cadastre.openstreetmap.fr/data/040/

Pensez-vous que la qualité soit suffisante pour une intégration dans
Osmose ?

On 31/05/2016 19:12, Tyndare wrote:

Grâce notamment à Didier et Jocelyn les résultats d'analyse sont
visibles pour l'Alsace ici:

http://dev.osmose.frontend.dirif.info/fr/map/#country=france*=1=7=12=47.8762=7.4456=Mapnik=T

En essayant de faire des changements pour améliorer les résultats il
faut que je me rende à l'évidence: je n'ai rien compris à SVM et si ce
que j'ai obtenu initialement semble presque cohérent c'est un coup de
bol...

Bon sinon j'ai passé une partie du python en C pour améliorer les
performances.

On 27/05/2016 00:37, Tyndare wrote:

Je relance ce vieux sujet.

J'ai fait une nouvelle tentative:
https://github.com/tyndare/osmose-backend/commit/51ae035847b23af05804b1f6e32387e3f6d435e9

Cette fois j'ai arrêté de vouloir faire le malin en SQL, j'ai mis quasi
que du python qui teste chaque couple de bâtiment qui se touche en
appelant un classifier SVM
(celui qui se trouve désormais dans l'export cadastre sur osm104)
Je pense que le taux de faux positifs est acceptable pour être intégré
dans Osmose (a vérifier)

J'ai lancé l'analyse pour la région Rhône-Alpes, il a trouvé 22 000 cas.
Sur un pc portable avec ssd, je pense que mon code a pris à lui tout
seul environ 40'.
En extrapolant, pour la France j'imagine que ça rajouterais environ 8h.
Je crois que c'est surtout du temps CPU qui est utilisé, faudrait voire
si on ne peut pas paralléliser l'appel des callbacks de
l'Analyser_Osmosis pour aller plus vite sur multi cœur.

"8h de plus" pour l'analyser_osmosis_building_overlaps, il y a un
serveur Osmose quelque part qui peut supporter ça ou c'est mort ?

Est-ce qu'il existe un frontend Osmose de test vers lequel je pourrait
essayer d'envoyer mes résultats pour validation ?

On 16/11/2015 23:38, Frédéric Rodrigo wrote:

Pour l’exécuté dans le backend principal d'Osmose ça dépendent du
temps que ça prend et de la base de données que ça utilise.
Mais rien n’empêche a n'importe quel programme de devenir un backend
d'Osmose en envoyant directement des rapports au frontend d'Osmose.

Ce genre de grosse requête est quand un long processus d'affinage.

Le 16/11/2015 23:27, Tyndare a écrit :

Mais du coup c'est envisageable de faire ce genre d'analyse ou les
serveurs Osmose sont déjà trop chargés ?

En tout cas merci beaucoup Frédéric pour tes conseils.
En gros il faut que je réécrive tout ;-) (je dois dire que je m'y
attendais un peu)

Le 16 novembre 2015 22:33, Frédéric Rodrigo <fred.rodr...@gmail.com>
a écrit :

Salut,

Les requêtes actuelles sont déjà assez lourde. C'est assez
difficile de
faire des choses dans le domaine du bâti.

Tu peux déjà éviter d'utiliser une fonction, c'est joli, mais c'est
lent.
Essayes d'utiliser des temps tables avec des index dessus si
besoin, et
essaye de réduire le nombre de jointures.
Essaye d'éviter d'utiliser way_nodes, tu as aussi les id des nodes
dans
ways.nodes.
De plus way_nodes ne supporte pas le mode diff tu ne peux pas faire
touched_way_nodes.

Dans osmose la projection est un paramètre de l'analyse.

Frédéric.

Le 16/11/2015 19:46, Tyndare a écrit :

Bonjour,

J'ai voulu essayer de faire une analyse osmose pour détecter des
bâtiments
fractionnés à cause du cadastre.
Pour l'instant ce n'est pas vraiment une réussite, je ne sais pas
si il y
aurait des volontaires pour m'aider, je ne maîtrise pas du tout
SQL ou
PostGIS en fait...

Ce que j'ai voulu faire c'est détecter les situations où un
bâtiment est
collé à un autre de manière rectiligne, mais dont l'angle avec la
section
commune ne soit pas à 90°:

-+
/
/
--+---

J'ai deux problèmes:

1. Le principe marche relativement bien dans les zones modernes (où
les
bâtiments sont à peut près carrés), mais trouves beaucoup trop de
faux
positifs dans les vielles villes.
Si quelqu'un à une idée d'heuristique pour réduire le nombre de faux
positifs je suis preneur.

2. Ma requête SQL est beaucoup trop compliquée, et elle génère des
tables
intermédiaires de taille exponentielle...
Si une âme charitable est motivé pour jeter un œuil à mon horrible
requête
SQL et me donner quelques conseils d'optimisation:

Re: [OSM-dev-fr] Aide pour Osmose et SQL: buildings cadastre fractionnés

2016-05-31 Par sujet Tyndare

Grâce notamment à Didier et Jocelyn les résultats d'analyse sont
visibles pour l'Alsace ici:

http://dev.osmose.frontend.dirif.info/fr/map/#country=france*=1=7=12=47.8762=7.4456=Mapnik=T

Bon sinon j'ai passé une partie du python en C pour améliorer les
performances.

On 27/05/2016 00:37, Tyndare wrote:

Je relance ce vieux sujet.

J'ai fait une nouvelle tentative:
https://github.com/tyndare/osmose-backend/commit/51ae035847b23af05804b1f6e32387e3f6d435e9

"8h de plus" pour l'analyser_osmosis_building_overlaps, il y a un
serveur Osmose quelque part qui peut supporter ça ou c'est mort ?

Est-ce qu'il existe un frontend Osmose de test vers lequel je pourrait
essayer d'envoyer mes résultats pour validation ?

On 16/11/2015 23:38, Frédéric Rodrigo wrote:

Ce genre de grosse requête est quand un long processus d'affinage.

Le 16/11/2015 23:27, Tyndare a écrit :

Mais du coup c'est envisageable de faire ce genre d'analyse ou les
serveurs Osmose sont déjà trop chargés ?

En tout cas merci beaucoup Frédéric pour tes conseils.
En gros il faut que je réécrive tout ;-) (je dois dire que je m'y
attendais un peu)

Le 16 novembre 2015 22:33, Frédéric Rodrigo <fred.rodr...@gmail.com>
a écrit :

Salut,

Les requêtes actuelles sont déjà assez lourde. C'est assez difficile de
faire des choses dans le domaine du bâti.

Tu peux déjà éviter d'utiliser une fonction, c'est joli, mais c'est
lent.
Essayes d'utiliser des temps tables avec des index dessus si besoin, et
essaye de réduire le nombre de jointures.
Essaye d'éviter d'utiliser way_nodes, tu as aussi les id des nodes dans
ways.nodes.
De plus way_nodes ne supporte pas le mode diff tu ne peux pas faire
touched_way_nodes.

Dans osmose la projection est un paramètre de l'analyse.

Frédéric.

Le 16/11/2015 19:46, Tyndare a écrit :

Bonjour,

Ce que j'ai voulu faire c'est détecter les situations où un
bâtiment est
collé à un autre de manière rectiligne, mais dont l'angle avec la
section
commune ne soit pas à 90°:

-+
/
/
--+---

J'ai deux problèmes:

1. Le principe marche relativement bien dans les zones modernes (où
les
bâtiments sont à peut près carrés), mais trouves beaucoup trop de faux
positifs dans les vielles villes.
Si quelqu'un à une idée d'heuristique pour réduire le nombre de faux
positifs je suis preneur.

https://github.com/tyndare/osmose-backend/commit/6dd5e773ac7e0f5480518c066ed2bd4b0c50a04e

Merci,

Tyndare.

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

Re: [OSM-dev-fr] Ecriture de requêtes pour Osmose

2015-11-28 Par sujet Tyndare

Le 28 novembre 2015 13:33, François Lacombe
 a écrit :
> Ici : 
> https://github.com/osm-fr/osmose-backend/blob/master/analysers/analyser_osmosis_powerline.py
> On voit dans presque tous les WHERE des requêtes des opérateurs ? et
> ->. Où puis-je trouver de la doc dessus ?

C'est nouveau pour moi aussi donc je ne garantie pas l'exactitude de
ce que je raconte.
Les opérateurs ? sont décrit dans la doc des hstore (cad table de
hachage, le type utilisé pour les colonnes 'tags'):
http://www.postgresql.org/docs/current/static/hstore.html

> Il semble qu'il y ai des tables en plus que nodes, ways, relations...
> (power_line_junction, line_terminators)
> Comment sont-elles crées ? Peut-on les modifier ? Peut-on en rajouter ?

Elles sont créées lors de l'exécution, par exemple dans le code que tu
a référencé il y a
sql31 = """ CREATE VIEW power_line_junction AS...

Je sèche pour les autres questions.

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

Re: [OSM-dev-fr] Aide pour Osmose et SQL: buildings cadastre fractionnés

2015-11-17 Par sujet Tyndare

Oui tu as raison, il faudra que je teste ça, merci.

Le 17 novembre 2015 10:48:03 GMT+01:00, "Vincent de Château-Thierry" .
>Pour l'adresse commune entre les portions de bâtiment, je ne dis pas
>que ça ne laisse pas de côté certains cas (comme la limite de commune)
>mais tu parlais d'heuristique, et le test sur l'adresse me semblait
>typiquement un moyen de cibler une majorité de cas à peu de frais.
>
>vincent


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

Re: [OSM-dev-fr] Aide pour Osmose et SQL: buildings cadastre fractionnés

2015-11-17 Par sujet Tyndare

Merci pour ces suggestions, plein de bonnes idées, je retiens surtout
les premières car les suivantes me semblent trop compliquées à
programmer (cad identifier une zone à risque pour moduler les critères
de recherches aux alentours).

Ça me fait penser à une approche totalement différente auquel j'ai
rêvé sans avoir la moindre des compétences pour la mettre en œuvre:
utiliser un algo d'apprentissage.
On pourrait utiliser des villes qu'on sait avoir été corrigées dans
OSM et comparer à l'extrait du cadastre pour l’alimenter en cas
positif/négatif.
Problème c'est que je n'y connais absolument rien dans ce domaine, et
je ne sais pas trop ce qu'il faudrait lui donner à manger exactement.
Quelqu'un connaît une solution opensource qu'on pourrait utiliser pour
faire ce genre d'apprentissage ?


Le 17 novembre 2015 16:41, didier2020 <didier2...@free.fr> a écrit :
> deja bonjour!
>
> pour l'optimisation je ne sais pas ...mais après avoir trituré un peu
> les batiments, j'ai remarqué
>
> - les batiments peuvent avoir des angles bizares sans pour autant etre
> morcelé (une petite pointe) => calcul des angles sur des segments
> suffisement grand , plutot que 90°, tres pointu .
> mon dernier calcul du nombre moyen de node pour un batiment etait de 5
> => ecarter les segments faisant moins de périmetre/5 (ou plus) ?
>
> - il suffit de trouver un batiment morcelé pour en avoir d'autre a coté
> (ce qui rejoint l'analyse de vincent pour les parcelles)
>
> - les zones industrielles , d'activités sont par nature plus favorable
> au morcellement => recherche par surface (avec josm ca marche bien)
>
> - recherche par nombre de nodes (avec josm ca marche bien) pour la
> simplification ou les reservoir coupés n morceaux
>
>
>
> Le lundi 16 novembre 2015 à 19:46 +0100, Tyndare a écrit :
>>
>> Bonjour,
>>
>> J'ai voulu essayer de faire une analyse osmose pour détecter des
>> bâtiments fractionnés à cause du cadastre.
>> Pour l'instant ce n'est pas vraiment une réussite, je ne sais pas si
>> il y aurait des volontaires pour m'aider, je ne maîtrise pas du tout
>> SQL ou PostGIS en fait...
>>
>> Ce que j'ai voulu faire c'est détecter les situations où un bâtiment
>> est collé à un autre de manière rectiligne, mais dont l'angle avec la
>> section commune ne soit pas à 90°:
>>
>> -+
>>  /
>> /
>> --+---
>>
>> J'ai deux problèmes:
>>
>> 1. Le principe marche relativement bien dans les zones modernes (où
>> les bâtiments sont à peut près carrés), mais trouves beaucoup trop de
>> faux positifs dans les vielles villes.
>> Si quelqu'un à une idée d'heuristique pour réduire le nombre de faux
>> positifs je suis preneur.
>>
>>
>> 2. Ma requête SQL est beaucoup trop compliquée, et elle génère des
>> tables intermédiaires de taille exponentielle...
>> Si une âme charitable est motivé pour jeter un œuil à mon horrible
>> requête SQL et me donner quelques conseils d'optimisation:
>>
>> https://github.com/tyndare/osmose-backend/commit/6dd5e773ac7e0f5480518c066ed2bd4b0c50a04e
>>
>> Merci,
>>
>> Tyndare.
>>
>> ___
>> dev-fr mailing list
>> dev-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/dev-fr
>
>
>
> ___
> dev-fr mailing list
> dev-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev-fr

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

Re: [OSM-dev-fr] Aide pour Osmose et SQL: buildings cadastre fractionnés

2015-11-17 Par sujet Tyndare

La meilleur information est effectivement à récupérer du cadastre.
Mais je ne suis pas sur qu'on puisse être systématique avec ton
approche non plus. Sur les communes où les adresses sont composées
uniquement de lieux dits, les parcelles du centre ville ont toutes la
même adresse. À contrario, j'ai constaté que pour des propriétés
composées de plusieurs parcelles, le numéro et nom de rue étaient
parfois attribués à une seule des parcelles, les autres gardant comme
adresse le nom de l'ancien lieu dit (mais je n'ai pas vérifié ça pour
les bâtiments fractionnés, peut être que ça n'arrive quasiment pas
pour eux).
Les bâtiments collés à la même adresse peuvent aussi correspondre à
des bâtiments différents: une maison collée à un garage, une grange ou
un hangar par exemple, qui sont sensés avoir un tag building différent
et qu'il ne faudrait donc pas fusionner.
En plus des limites de parcelle, l'autre source de fractionnement que
j'ai identifié sont les ruisseaux enterrées, en générale tracées en
pointillés sur le cadastre.

Il faudrait essayer de faire l'intersection entre l'analyse je
proposais avant et celle que tu propose.

Est-ce que par hasard vous auriez gardé les PDF utilisés pour
alimenter BANO ? (ça me permettait de basculer un peu en python plutôt
que de lutter en SQL ;-)


Le 17 novembre 2015 20:25, Christian Quest  a écrit :
> J'ai une autre idée en tête pour détecter ces buildings découpés à cause des
> parcelles.
> On a potentiellement les données dans les extractions du cadastre faites
> pour BANO.
>
> Si on a des polygones de buildings qui se touchent et qui appartiennent à
> des polygones de parcelles à la même adresse... on devrait pouvoir proposer
> de les fusionner...
> Cette analyse se ferait sur les données brutes du cadastre et pas sur les
> données OSM... ensuite il faut recroiser avec les polygones dans OSM, mais
> au moins ça donne un bon indice.
>
> Qu'en pensez-vous ?
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> dev-fr mailing list
> dev-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev-fr
>

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

Re: [OSM-dev-fr] Aide pour Osmose et SQL: buildings cadastre fractionnés

2015-11-16 Par sujet Tyndare

Mais du coup c'est envisageable de faire ce genre d'analyse ou les
serveurs Osmose sont déjà trop chargés ?

En tout cas merci beaucoup Frédéric pour tes conseils.
En gros il faut que je réécrive tout ;-) (je dois dire que je m'y
attendais un peu)


Le 16 novembre 2015 22:33, Frédéric Rodrigo <fred.rodr...@gmail.com> a écrit :
> Salut,
>
> Les requêtes actuelles sont déjà assez lourde. C'est assez difficile de
> faire des choses dans le domaine du bâti.
>
> Tu peux déjà éviter d'utiliser une fonction, c'est joli, mais c'est lent.
> Essayes d'utiliser des temps tables avec des index dessus si besoin, et
> essaye de réduire le nombre de jointures.
> Essaye d'éviter d'utiliser way_nodes, tu as aussi les id des nodes dans
> ways.nodes.
> De plus way_nodes ne supporte pas le mode diff tu ne peux pas faire
> touched_way_nodes.
>
> Dans osmose la projection est un paramètre de l'analyse.
>
>
> Frédéric.
>
>
>
> Le 16/11/2015 19:46, Tyndare a écrit :
>>
>>
>> Bonjour,
>>
>> J'ai voulu essayer de faire une analyse osmose pour détecter des bâtiments
>> fractionnés à cause du cadastre.
>> Pour l'instant ce n'est pas vraiment une réussite, je ne sais pas si il y
>> aurait des volontaires pour m'aider, je ne maîtrise pas du tout SQL ou
>> PostGIS en fait...
>>
>> Ce que j'ai voulu faire c'est détecter les situations où un bâtiment est
>> collé à un autre de manière rectiligne, mais dont l'angle avec la section
>> commune ne soit pas à 90°:
>>
>> -+
>>  /
>> /
>> --+---
>>
>> J'ai deux problèmes:
>>
>> 1. Le principe marche relativement bien dans les zones modernes (où les
>> bâtiments sont à peut près carrés), mais trouves beaucoup trop de faux
>> positifs dans les vielles villes.
>> Si quelqu'un à une idée d'heuristique pour réduire le nombre de faux
>> positifs je suis preneur.
>>
>>
>> 2. Ma requête SQL est beaucoup trop compliquée, et elle génère des tables
>> intermédiaires de taille exponentielle...
>> Si une âme charitable est motivé pour jeter un œuil à mon horrible requête
>> SQL et me donner quelques conseils d'optimisation:
>>
>>
>> https://github.com/tyndare/osmose-backend/commit/6dd5e773ac7e0f5480518c066ed2bd4b0c50a04e
>>
>> Merci,
>>
>> Tyndare.
>>
>>
>> ___
>> dev-fr mailing list
>> dev-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/dev-fr
>
>
>
> ___
> dev-fr mailing list
> dev-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev-fr

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

Re: [OSM-dev-fr] Aide pour Osmose et SQL: buildings cadastre fractionnés

2015-11-16 Par sujet Tyndare

Merci Vincent, mais là j'avoue je n'ai pas tout compris, il faudrait
que je regarde à quoi ressemble le format osm2pgsql.

Je ne suis pas sur que les bâtiments fractionnés soient forcément sur
des parcelles ayant la même adresse.
(il y a même quelques bâtiments fractionnés par des limites communales...)

Le 16 novembre 2015 22:46, Vincent de Château-Thierry
<osm.v...@free.fr> a écrit :
> Bonsoir,
>
> Le 16/11/2015 22:33, Frédéric Rodrigo a écrit :
>>
>> Le 16/11/2015 19:46, Tyndare a écrit :
>>>
>>>
>>> 1. Le principe marche relativement bien dans les zones modernes (où
>>> les bâtiments sont à peut près carrés), mais trouves beaucoup trop de
>>> faux positifs dans les vielles villes.
>>> Si quelqu'un à une idée d'heuristique pour réduire le nombre de faux
>>> positifs je suis preneur.
>
>
> En prenant les buildings dans un schéma type osm2pgsql plutôt qu'osmosis, et
> en commençant par filtrer les voisinages sur un critère d'adresse de
> parcelle* (tous les bâtiments devant avoir la même adresse pour être
> confrontés), tu devrais pouvoir récupérer de plus petites populations de
> bâtiments, dans lesquelles ensuite tu pourrais lancer la décomposition
> polygones > ways > nodes pour mesurer les angles et la détection de portions
> communes.
>
> vincent
>
> * On a via ton travail pré-BANO accès aux parcelles, que j'ai chargées dans
> la base Cadastre d'osm104.
>
>
> ___
> dev-fr mailing list
> dev-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev-fr

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

Re: [OSM-dev-fr] Aide pour Osmose et SQL: buildings cadastre fractionnés

2015-11-16 Par sujet Tyndare

Ok merci, je te reposerais la question si jamais j'arrive à avoir des
détections potables.

Le 16 novembre 2015 23:38, Frédéric Rodrigo <fred.rodr...@gmail.com> a écrit :
> Pour l’exécuté dans le backend principal d'Osmose ça dépendent du temps que
> ça prend et de la base de données que ça utilise.
> Mais rien n’empêche a n'importe quel programme de devenir un backend
> d'Osmose en envoyant directement des rapports au frontend d'Osmose.
>
> Ce genre de grosse requête est quand un long processus d'affinage.
>
>
> Le 16/11/2015 23:27, Tyndare a écrit :
>>
>> Mais du coup c'est envisageable de faire ce genre d'analyse ou les
>> serveurs Osmose sont déjà trop chargés ?
>>

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

Re: [OSM-dev-fr] Aide html/javascript

2014-04-28 Par sujet Tyndare

Le 28 avril 2014 14:36, Philippe Verdy verd...@wanadoo.fr a écrit :
 Ce ne serait pas une limite de sécurité des XmlHttpRequest imposée par IE8
 pour une requête inter-domaine qui empêche la requête de s'exécuter ?

A mon avis, étant donné qu'on ne précise pas le domaine de la requête
il s'agit d'une requête sur le même domaine.

 Deux lignes bizarres (dans ton main.js):

 xhr.setRequestHeader( Content-length, params.length );
 xhr.setRequestHeader( Connection, close );

 Pour la première ce n'est pas la bonne valeur, car tu compte le nombre de
 caractères UTF-16 de la chaîne Javascript et non son encodage dans la
 requête (UTF-8) et aussi il manque le réencodage HTTP des sauts de ligne.
 Tout dépend de ce qui est dans params.
 De plus tu utilises à la fois des param_tres POST et des paramètres GET dans
 une requête POST:
 xhr.open(POST, getDepartement.php?ville= + ville, true );
 Pour pas simplement dans ce cas ne pas tout mettre dans la query string et
 utiliser une requête GET?

Ce n'est pas moi qui avait écrit cette partie à la base, je n'ai pas
voulu trop la changer pour éviter de casser un truc qui marche, mais
effectivement une requête GET semblerais plus logique.

 Pour la seconde, Connection:close est suspect. A priori on ne précise que la
 condition keep-alive (si la requête se fait en HTTP/1.0 et sinon rien en
 HTTP/1.1).

 Les deux entêtes Connection:close et Content-length:* sont marqués unsafe
 par la console de Chrome mais je soupçonne que le vieux XmlHTTPRequest d'IE8
 soit plus radical et rejette ta requête. A priori c'est au composant
 XMLHttpRequest de s'en charger.

 Enfin XMLHttpRequest dans IE a été un activeX nécessitant une autorisation
 spéciale et qui peut sinon t'empêcher de faire une requête interdomaine.
 Mais ici l'URL que tu utilises dans xhr.open() ne précise pas le domaine et
 si XmlHTTPRequest est un composant externe, il n'aura pas accès tout seul à
 l'URL de base de ton document. Il faut alors préciser l'URL complète et pas
 une URL relative;

Le composant axtiveX c'était je crois pour ie6, pas ie8.

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

Re: [OSM-dev-fr] Aide html/javascript

2014-04-28 Par sujet Tyndare

J'ai pu tester sur IE9 et il a manifestement le même problème qu'IE8.
Apparemment le problème n'a rien a voir avec la requête XmlHttpRequest
qui fonctionne très bien, le problème est du à un bug d'IE quand on
affecte l'innerHTML d'un élément select [1].

Merci quand même Philippe pour tes remarques sur le XHR, même si je
n'ai pas tout compris j'ai essayé de passer en mode GET et j'ai
supprimé le paramètre 'ville' qui n'était plus vraiment utile.

[1] http://support.microsoft.com/kb/276228/fr

Le 28 avril 2014 18:31, Philippe Verdy verd...@wanadoo.fr a écrit :

 Le 28 avril 2014 16:16, Tyndare tynd...@wanadoo.fr a écrit :

 Le composant axtiveX c'était je crois pour ie6, pas ie8.


 Je ne suis pas certain qu'il soit disparu même si IE donne une interface
 native pour l'instancier. Utiliser directement les XHR pose des problèmes de
 compatibilité. Cela fait longtemps que je n'utilise plus les XHR de cette
 façon, mais j'utilise un framework.
 Il y a même une intégration plus poussée avec le framework Leaflet pour ses
 mixins.

 Sinon j'en ai soupé de suivre les versions d'IE qui changent leurs API sans
 arrêt ou la façon de les utiliser en préservant la compatibilité de ce qui
 se faisait dans les versions d'avant (et pas toujours des moyens simples
 pour détecter la bonne façon de faire).

 Tu peux déjà essayer en utilisant une URL absolue et non une URL relative
 (la question qui se pose est bien  relative à quoi ? Il est possible que
 cette requête ne s'exécute pas du tout en fait (rien envoyé au serveur, ou
 erreur HTTP 404, j'ai déjà eu des trucs bizarres avec les XHR utilisant des
 URL relatives mal résolues, parfois liées à des threads concurrents qui
 interrogent d'autres serveurs XHR)

 Sinon, les XHR sont un peu obsolètes, les requêtes JSON ont une intégration
 native et plus sécurisée (et moins de contraintes et plus de performance,
 même si ici les requêtes ne sont pas énormes et fréquentes). Même si au
 final tes requêtes XHR ne servent pas à charger du XML nécessitant un
 parseur lourd côté client.

 Enfin sur Chrome la première requête effectuée (si on n'a encore rien saisi
 dans la commune) en sélectionnant un département est
 .http://cadastre.openstreetmap.fr/getDepartement.php?ville=undefined

 Tu noteras la présence de undefined qui signale une variable non
 initialisée (le nom de la ville cherchée). Je ne sais pas ce qui est
 transmis en valeur sous IE et comment cela affecte ensuite la recherche des
 communes...





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


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

[OSM-dev-fr] Aide html/javascript

2014-04-27 Par sujet Tyndare

Si jamais il y a des personnes compétentes en html/javascript et
volontaires pour tester et investiguer je suis preneur...

J'ai essayé de rajouter une option sur le site d'extraction du bâti
depuis le cadastre [1]

Elle marche pour moi, mais manifestement pas pour tout le monde [2]
donc je me dis que le problème est lié au navigateur web.

L'option a tester est la case à cocher
«Sélectionner une zone à exporter»
Lorsqu'on l'active c'est censé afficher une carte leaflet et un
rectangle de sélection, si on l'active, l'extraction du bâti devrais
se limiter à cette zone.

Le code est ici [3] mais c'est aussi simple de regarder le code depuis
le navigateur.


[1] http://cadastre.openstreetmap.fr/
[2] http://trac.openstreetmap.fr/ticket/552#comment:3
[3] https://github.com/osm-fr/export-cadastre/tree/master/web

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

Re: [OSM-dev-fr] Service de pré-intégration d'adresses

2014-03-05 Par sujet Tyndare

Apparemment il y a beaucoup de messages d'erreur liés à l'extraction du
bâti.

Le 5 mars 2014 22:53, Christian Quest cqu...@openstreetmap.fr a écrit :

 le log complet est sur /more/error.log.0 en cours de bzippage... avec un
 chmod a+r donc lisible par tous sauf erreur.


 Le 5 mars 2014 22:33, Vincent de Château-Thierry v...@laposte.net a
 écrit :

 Bonsoir,

 Le 05/03/2014 22:18, Christian Quest a écrit :

  Les scripts ne généreraient ils pas plein de choses dans error.log
 d'apache ?

 J'ai trouvé 154Go de log... peut être quelques trucs pas trop
 indispensables dedans à retirer, non ?


 Quelques, oui, peut-être :)

 Ce serait intéressant d'avoir quelques lignes de ces logs (hors liste)
 pour analyse. Certaines grosses communes ont eu des plantages récemment.

 vincent


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




 --
 Christian Quest - OpenStreetMap France
 Conférence State Of The Map France du 4 au 6 avril à 
 Parishttp://openstreetmap.fr/sotmfr

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


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

Re: [OSM-dev-fr] Service de pré-intégration d'adresses

2014-03-05 Par sujet Tyndare

Pour moi oui pas de souci.

Le 5 mars 2014 23:33, Christian Quest cqu...@openstreetmap.fr a écrit :

 ok, donc je peux virer ce log ?


 Le 5 mars 2014 23:27, Vincent de Château-Thierry v...@laposte.net a
 écrit :


 Le 05/03/2014 23:07, Tyndare a écrit :

  Apparemment il y a beaucoup de messages d'erreur liés à l'extraction du
 bâti.


 Même constat : aucune mention 'adresse' sur les 154 Go, mais beaucoup de
 Qadastre, y compris du contenu brut (des coordonnées) : ça peut rapidement
 faire du volume.

 À surveiller dans les prochains jours ?


 vincent

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




 --
 Christian Quest - OpenStreetMap France
 Conférence State Of The Map France du 4 au 6 avril à 
 Parishttp://openstreetmap.fr/sotmfr

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


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

Re: [OSM-dev-fr] Generer des fichiers OSM

2014-03-04 Par sujet Tyndare

Concernant le XML, j'avais codé un truc pour l'extraction des adresses du
cadastre [1].
Ce n'es pas documenté ni des plus intuitif mais ça correspondait à mon
besoins, cad manipuler des fichiers .osm
Exemple (non testé) pour créer un noeud:
o = Osm({})
o.add_node( Node(
{lon:str(4.1545656), lat:str(48.6645)},
{shop:bakery}))
OsmWriter(o).write_to_file(test.osm)

[1]:
https://github.com/osm-fr/export-cadastre/blob/master/bin/cadastre-housenumber/osm.py



Le 4 mars 2014 11:53, Rodolphe Quiédeville rodol...@quiedeville.org a
écrit :

 Bonjour,

 Connaissez-vous une lib qui permette de générer des fichiers de données
 xml ou pbf en python ? Autant il en existe pas mal pour parser les
 fichiers mais je n'en ai pas trouvé pour le générer, j'ai surement mal
 cherché :)


 Merci pour vos retours


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

Re: [OSM-dev-fr] Service de pré-intégration d'adresses

2014-02-25 Par sujet Tyndare

Le 24 février 2014 13:26, Christian Quest cqu...@openstreetmap.fr a écrit
:

 Le 24 février 2014 11:26, Tyndare tynd...@wanadoo.fr a écrit :

 Le 23/02/2014 10:28, Christian Quest a écrit :

 Il manque à mon avis un fichier mix entre les points isolés et les
 points sur façade.


 Cela correspond aussi à ma façon de mapper, je vais essayer de faire
 quelque chose dans ce sens (mais il me faut un peu de temps, je voudrais
 essayer d'utiliser l'angle que fait le numéro dessiné sur le cadastre pour
 déterminer la direction ou projeter le numéro).


 Ah oui, c'est une info qui peut aider, mais il faut faire attention car il
 y aura forcément des numéros non orientés vu la disparité dans les données
 vectorielles du cadastre.


J'ai rajouté un nouveau fichier de sortie, qui correspond au mix point en
façade ou point isolé.
L'angle avec lequel le numéro est dessiné sur le cadastre n'est utilisé
pour projeter sur la façade que:
 - si le numéro n'est pas dessiné horizontalement, sinon c'est une
projection orthogonale qui est faite.
 - et que si la projection n'arriverais bas trop de biais sur la façade
(incidence max de 30°), sinon le point adresse reste isolé.
Les numéros sont fusionnés aux bâtiments jusqu'à 2m de distance.
Je peux adapter ces paramètres si vous pensez que les valeurs actuelles
peuvent poser problème.



 L'idéal serait d'arriver à trouver un consensus sur la modélisation et de
 ne proposer que des fichiers correspondant à ce consensus histoire d'avoir
 au final des données homogènes sur toute la France (à défaut de pouvoir
 homogénéiser sur le monde entier).


Manifestement on arrivera pas à un consensus entre nous, donc je suis
d'accord avec Vincent et Pieren: il faudrait élargir cette discussion.
L'outil peut être utilisé plus largement maintenant je pense, du moins pour
contribuer dans les zones où il n'y a encore aucune adresse dans OSM.
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Service de pré-intégration d'adresses

2014-02-24 Par sujet Tyndare

Le 23 février 2014 21:54, Vincent de Château-Thierry v...@laposte.net a
écrit :

 Le 23/02/2014 10:28, Christian Quest a écrit :

 Il manque à mon avis un fichier mix entre les points isolés et les
 points sur façade.

 En effet, ma façon manuelle de positionner les adresses est la suivante:
 - si la façade du bâtiment donne sur la rue, je met le point adresse en
 façade du bâtiment sur un noeud du polygone
 - si le bâtiment principal ne donne pas sur la rue, je met le point
 adresse en limite de parcelle

 J'ai l'impression que je ne suis pas le seul à procéder comme ça et là
 je suis obligé de passer d'un fichier à l'autre ce qui bien sûr ne fait
 pas vraiment gagner de temps au final.


Cela correspond aussi à ma façon de mapper, je vais essayer de faire
quelque chose dans ce sens (mais il me faut un peu de temps, je voudrais
essayer d'utiliser l'angle que fait le numéro dessiné sur le cadastre pour
déterminer la direction ou projeter le numéro).


 Le parti pris implicite dans les fichiers, c'est une modélisation homogène
 au sein d'un même fichier (1 fichier = 1 rue) sachant qu'il y a déjà une
 combinatoire entre 3 implantations et 2 modélisations. Le risque d'usine à
 gaz n'est jamais loin...


Pour ce qui est de mon code, je crois que j'ai déjà atteint le niveau usine
à gaz vu que j'ai du mal à me relire...
Si ce fichier mix intermédiaire correspond mieux à ceux que certains
attendent peut-être que l'on pourra supprimer la version points tous
isolés découpés par rue.

Par contre il a un fichier points tous isolés non découpé par rue, un
seul gros fichier, qui est actuellement caché, et je me pose la question de
le rendre publique.
Je m'en sert souvent, non pas pour intégrer, mais pour vérifier une zone
déjà mappée, ou quand je ne comprends pas pourquoi le découpage par rue a
exclus certains numéros de tel ou telle rue. Je trouve qu'il a une vrais
utilité.
Je le génère dorénavant avec l'option upload=false pour que JOSM dissuade
son envoie directe dans OSM.

Que pensez vous de rendre ce fichier accessible à tous ?
Ou alors sous condition, comme pour les fichiers eau ?


Tyndare.
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Service de pré-intégration d'adresses

2014-02-18 Par sujet Tyndare

Le 18 février 2014 14:32, sly (sylvain letuffe) lis...@letuffe.org a
écrit :

  On lundi 17 février 2014, Vincent de Château-Thierry wrote:

  Merci à Jocelyn et Christian pour leur support et la mise à disposition

  d'une infrastructure d'OSM-Fr, qui héberge le service.



 En reprenant la page d'accueil de http://cadastre.openstreetmap.fr, vous
 avez également repris le lien permettant l'ouverture d'un ticket sur trac,
 dont un premier a d'ailleurs été ouvert :

 http://trac.openstreetmap.fr/ticket/483



 Si vous ne souhaitez pas utiliser trac, je vous suggère de retirer le lien.

 Si par contre vous le souhaitez, je peux définir un composant sur trac
 rien que pour cet outil si vous préférez.

 Ou alors, on peut partager le même composant, je n'y vois pas
 d'inconvénients, mais si l'un de vous (ou les deux) pouvait créer ou me
 donner son compte sur trac.openstreetmap.fr, je pourrais alors vous
 ré-attribuer les tickets.



 --

 sly

 qui suis-je : http://sly.letuffe.org



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


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

Re: [OSM-dev-fr] Service de pré-intégration d'adresses

2014-02-18 Par sujet Tyndare

Le 18 février 2014 14:32, sly (sylvain letuffe) lis...@letuffe.org a
écrit :

  En reprenant la page d'accueil de http://cadastre.openstreetmap.fr, vous
 avez également repris le lien permettant l'ouverture d'un ticket sur trac,
 dont un premier a d'ailleurs été ouvert :

 http://trac.openstreetmap.fr/ticket/483



Déssolé un premier mail est parti tout seul.

Merci aussi à toi Sylvain pour le site web du cadastre dont on a
effectivement repris sans scrupules la page web.

Si on décide de rendre le service accessible au plus grand nombre, il
faudra qu'on discute si c'est souhaitable et envisageable de rendre les
deux services (Quadastre2OSM et adresses) accessibles ensemble depuis la
page web principale, avec par exemple un «radio button» pour choisir entre
les deux.
Le problème de la génération d'adresse c'est (qu'en plus d'être moins
stable) elle est beaucoup plus lente, il faudrait donc à mon avis garder un
retour à l'utilisateur sur l'avancée de l'opération.

Pour trac, si on peut garder le même composant ça me vas très bien,
J'ai aussi créé un compte trac: tyndare

Merci.
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr

2014-02-02 Par sujet Tyndare

De la même manière que je détectais les numéros dessinés sur le cadastre,
j'ai essayé de détecter les noms (de rue ou de quartier).
C'est des données brutes pas exploitables directement.
Voici un exemple de ce que ça donne pour Montpellier:
http://37.187.60.59/cadastre-housenumber//data/034/FB172/FB172-noms.osm

Pour arriver a distinguer le u du n (ou le b du q) qui sont les
même caractères à l'envers j'ai du prendre en compte l'angle d'affichage du
texte, et du coup j'ai stocké cette info pour les noms mais aussi pour les
numéros de rues.

Quelqu'un verrais une utilisation pour ces données ?
Le cadastre n'est pas beaucoup plus fort que moi en orthographe mais je me
dit que  ça pourrait quand même servir à mettre des accents sur les
adresses pour lesquelles on n'a pas fait le rapprochement avec les noms de
rue d'OSM.

Je ne garantie pas de détecter tout les caractères (en particulier les
accentués), donc n'hésitez pas à me signaler les cas problématiques si vous
en rencontrez.

C'est testable au même endroit:
http://37.187.60.59/cadastre-housenumber//adresses.php
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr

2014-01-28 Par sujet Tyndare

Le 28 janvier 2014 14:47, V de Chateau-Thierry v...@laposte.net a écrit :

 Argh. J'espère que ça ne t'as pas pris trop de temps. Car pour avancer
 sans rien casser,
 je travaille désormais sur un autre script, issu du précédent mais avec
 une grosse remise
 à plat :

 https://github.com/vdct/associatedStreet/blob/master/addr_fantoir_building.py


Je vais suivre ça.
Si tu peut faire an sorte que je puisse faire un import python de ton
script pour pouvoir en réutiliser les fonctions sans forcément le lancer
depuis une ligne de commande ça pourrait m'aider ;-)


 Il n'est pas encore opérationnel mais il permettra deux approches, compte
 tenu des
 discussions ici :
 - soit l'adresse comme point sur le way building (tiercé 1),
 - soit l'adresse comme tag du building (tiercé 2).
 Ceci bien sûr quand le building n'a qu'une seule adresse affectée.

 Le bémol : j'ai recours à PostGIS en coulisses pour les opérations de
 rapprochement entre
 adresses et buildings. Je dis bémol car ça alourdit la solution, mais
 c'est quand même
 très pratique, aussi.


Juste à récemment je ne savais même pas à quoi correspondait lo nom
PostGIS, tout ça pour dire que ce n'est pas trop mon domaine, mais si tu
cherches quelque chose de plus léger, je me suis de mon côté mis à utiliser
la bibliothèque python Shapely que je trouve très pratique:
https://pypi.python.org/pypi/Shapely



 Dans le cas 1), le choix de l'endroit où placer le point adresse peut
 donner matière à
 discussion. Pour amorcer, je pense partir sur : le mi-chemin du plus
 proche segment du

point adresse initial.


Pour info j'avais déjà essayé d'implémenter le cas 1) dans le script
https://www.gitorious.org/cadastre-housenumber/cadastre-housenumber/source/fusion_osm_avec_housenumbers.py
Ce script n'est pas à jour, il ne marche qu'avec un fichier d'entré ne
contenant que des noeuds addr:housenumber (sans relation ni rien), et il
n'utilise ni les info de parcelles ni la lib Shapely (j'y penserais si j'y
retravaille dessus).

Mes expérimentations m'avait amené à choisir de faire uniquement des
projections orthogonales vers un segment d'un building ou d'une barrier le
plus proche. Et donc de ne pas intégrer le numéro au building si il n'était
pas en face ! (si la projection orthogonale tombe en dehors des extrémités
du segment). Dans la majorité des cas ça donnait le résultat que te
trouvais le plus satisfaisant, et ça évitait aussi d'intégrer le numéro au
building des voisins (dans le cas ou il était plus proche de la route) car
sans les adresses des parcelles je n'avait pas à l'époque de moyen de
vérification.

Une erreur que faisait mon script c'était d'intégrer le numéro à un segment
du building même si à la base il était dessiné à l'intérieur du building,
c'était un très mauvais choix car si le numéro est dessiné à l'intérieur il
est forcément très mal placé, donc dans ce cas là il faut bien mieux le
laisser là où il est, cela sera plus facile de l'intégrer manuellement au
bon segment par la suite.
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr

2014-01-24 Par sujet Tyndare

Sur la même page web, j'ai rajouté la génération:
- d'un ZIP des données que j'obtenais précédemment mais découpé avec un
fichier par rue, et les numéros ambigus ou sans rues à part.
- d'un fichier -houssenumber.osm contenant juste des numéros là où ils sont
dessinés sur le cadastre
- d'un fichier -parcelles.osm contenant la limites des parcelles et les
adresses associées.

Le 23 janv. 2014 17:44, V de Chateau-Thierry v...@laposte.net a écrit :


  De : Tyndare
 
  Je récupère bien la géométrie des parcelles, je peut générer facilement
un fichier .osm
  correspondant si certains sont intéressés à pouvoir réaliser ce genre
de traitement
 Volontaire :-)
 Si tu peux, quand tu auras branché une sortie .osm, me donner une URL où
je peux générer
 ces fichiers, je teste volontiers.

 merci

 vincent
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr

2014-01-24 Par sujet Tyndare

Je n'ai toujours pas corrigé le problème HTTP Error 500.
J'ai essayé de renouveler le cookie de session au bout de 5min mais a
priori ce n'est pas ça le problème.
J'ai l'impression que c'est une erreur transitoire côté site du cadastre,
et si ça se reproduit il faut réessayer.

Pour extraire les données de Rennes j'ai du corriger un autre plantage du
script, tu peu retenter je pense.
 Le 22 janv. 2014 13:28, Julien Balas jul...@krilin.org a écrit :


 Je trouverais bénéfique que des courageux testent l'exercice d'intégration
 des adresses en l'état de notre chaîne de traitements.
 Étape 1 : la génération des fichiers d'adresses issues du cadastre, c'est
 ici :
 http://37.187.60.59/cadastre-housenumber/adresses.php

 Est ce que toutes les communes sont censé etre présente ou bien c'est lié
 a la dispo vectorielle du cadastre ?
 Le bugue (CP 24260) n'est pas dispo par exemple

 Pour Rennes (CP 35000),
 http://37.187.60.59/cadastre-housenumber/adresses.php?dep=035com=FK238
 ca plante

 Teléchargement des adresses cadastrales de la commune FK238 : RENNES (35000)
 Téléchargement du cadastre au format PDF:
 Découpe la bbox en 5 * 5
 FK238-0-0.pdf 
 RGF93CC48:1346181.63,7219082.00,1348181.63,7221082.00
 FK238-0-1.pdf 
 RGF93CC48:1346181.63,7221082.00,1348181.63,7223082.00
 FK238-0-2.pdf 
 RGF93CC48:1346181.63,7223082.00,1348181.63,7225082.00
 FK238-0-3.pdf 
 RGF93CC48:1346181.63,7225082.00,1348181.63,7227082.00

 Traceback (most recent call last):

   File ../../../cadastre_vers_osm_adresses.py, line 649, in

 cadastre_vers_adresses(sys.argv)

   File ../../../cadastre_vers_osm_adresses.py, line 635, in 
 cadastre_vers_adresses

 export_pdfs = download_pdfs(cadastreWebsite, code_departement, 
 code_commune)

   File /var/www/cadastre-housenumber/cadastre_vers_pdf.py, line 63, in 
 download_pdfs

 cadastreWebsite.open_pdf(sous_bbox, largeur, hauteur),

   File /var/www/cadastre-housenumber/cadastre.py, line 201, in open_pdf

 return self.url_opener.open(url, urllib.urlencode(post_data))

   File /usr/lib/python2.7/urllib2.py, line 406, in open

 response = meth(req, response)

   File /usr/lib/python2.7/urllib2.py, line 519, in http_response

 'http', request, response, code, msg, hdrs)

   File /usr/lib/python2.7/urllib2.py, line 444, in error

 return self._call_chain(*args)

   File /usr/lib/python2.7/urllib2.py, line 378, in _call_chain

 result = func(*args)

   File /usr/lib/python2.7/urllib2.py, line 527, in http_error_default

 raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)

 urllib2.HTTPError: HTTP Error 500: Erreur Interne de Servlet





 Étape 2 : le rapprochement avec les contenus Fantoir (pour le code RIVOLI)
 et OSM (pour l'association aux ways de la bonne rue). C'est là :
 https://github.com/vdct/associatedStreet
 (Si ça vous rebute de jouer un script, faites au moins l'étape 1 et
 indiquez-moi ici (ou en privé) l'existence du résultat via son URL. Je peux
 jouer l'étape 2 et vous envoyer le résultat.)

 une fois qu'on a le fichier osm fait avec l'etape 1, il faut lancer quel
 script de l'etape 2 ?
 addrfantoir ou addr2associatedStreet ? ou les deux ?

 pour le 1er script les données ont l'air OK,
 sur une commune de test (Balazé) les 24 points a faire manuellement sont
 en rase campagne, sans vraiment de nom de rue je pense.
 Comment lire les infos console du script ?
 notamment la ligne
  avec rapprochement OSM : 17 (44%)
 quels conclusion peut on tirer du pourcentage ?
 - qu'il manque des rue dans OSM ?
 - qu'elles existent mais orthographié différement ?
 - autre chose ?
 -
 fichier adresses : FP015-adresses.osm
 Code INSEE : 35015
 mise en cache des voies...
 mise en cache des adresses...
 rapprochement...
 Nombre de relations creees  : 38
  avec code FANTOIR  : 29 (76%)
  avec rapprochement OSM : 17 (44%)
 24 points addresses à affecter manuellement a la bonne rue
 Voir le fichier numeros_ambigus_a_verifier.osm



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


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

Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr

2014-01-23 Par sujet Tyndare

Je récupère bien la géométrie des parcelles, je peut générer facilement un
fichier .osm correspondant si certains sont intéressés à pouvoir réaliser
ce genre de traitement, mais mon tiercé étant le même que Christian, je ne
suis pas super motivé pour le faire moi même.

Le 23 janvier 2014 14:54, V de Chateau-Thierry v...@laposte.net a écrit

 Tyndare a montré qu'on savait retrouver une info de parcelle. Je ne sais
 pas si ça va
 jusqu'à savoir récupérer la géométrie de la parcelle, mais on doit pouvoir
 avancer dans
 cette direction. Une fois la limite de la parcelle reconstituée, il est
 trivial de
 retrouver quel(s) bâtiment(s) en font partie. Et, dans le cas d'une
 parcelle à une
 seule adresse, on devrait pouvoir affecter le n° d'adresse au bâtiment
 ayant, par
 exemple, la plus grande surface parmi ceux inclus. C'est de la reflexion à
 voix haute
 sans test, mais ça me semble une logique de départ à creuser.
 Ça ne réglerait que le cas de 1 adresse pour n parcelles (n = 1) mais
 c'est déjà
 énorme. Pour le cas de n adresses pour une parcelle, on devrait intégrer
 manuellement,
 un peu comme ce que les fichiers d'associatedStreet proposent en ce moment.
 En tout cas ça mérite d'être creusé.

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

Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr

2014-01-21 Par sujet Tyndare

Le 20 janvier 2014 22:33, Vincent de Château-Thierry v...@laposte.net a
écrit :

 Hier soir j'avais pris le parti (un peu rapidement) de regrouper tous les
 nodes ayant un tag fixme dans un même fichier. On peut splitter en autant
 de fichiers qu'il y a de cas, à la rigueur, mais dans l'idée je pense qu'il
 faut faire simple, je suis donc aussi pour ce type de fichier à traiter à
 part (et en dernier, je pense, une fois les autres adresses intégrées).


Pour les numéros sans association à une rue ou avec deux associations, je
suis d'accord de les regrouper à part. Mais pour ceux associés a une seule
rue, je trouve ça dommage de les séparer juste parce qu'il ont un fixme,
dans la majorité des cas l'association à la rue est quand même la bonne,
donc je trouve que ça rajouterais inutilement  du boulot manuel si on la
supprimais.

Je serais toi je ne me prendrais pas trop la tête sur un regroupement de
 relations, avec les galères de récursivité. Je plaide pour un fichier par
 rue avec dedans uniquement les adresses non ambigües, et un fichier avec
 'le reste'.


Ok je vais faire des fichier à part pour les numéros sans association ou
avec deux choix d'association.



  Sinon, j'aurais aimé votre avis par rapport aux valeurs du tag fixme que
 je met dans le fichier. J'arrive à me comprendre quand je les lis, mais
 je voudrais être sur que ceux qui ne connaissent pas l'algo sous-jacent
 arrivent aussi à comprendre qu'elle est l’ambiguïté et comment essayer
 de la résoudre.
 J'ai 4 types de fixme:
 1) a verifier et associer a la bonne rue (quand il n'y a pas de rue
 associée)

 rue à déterminer par vous-même


En fait il ne s’agit pas uniquement de déterminer la rue, la validité du
numéro peut aussi être mise en doute car il peut s'agir de doublons (mais
comme l'a remarqué Christian, parfois mieux placé que celui déjà associé à
la rue), et dans quelques cas il s'agit de numéro historique qui n'ont plus
vraiment d'existence aujourd'hui.

 2) choisir l'association a la bonne rue (quand il y a deux rues
 associées)

pour moi celui là est clair car il y a les 2 noms de rues dans addr:street.
 En revanche je mettrais plutôt tout dans le fixme, pour éviter d'envoyer
 malencontreusement en base un tag addr:street avec deux noms en majuscules
 séparés par un |

ok



  3) trouver la position exacte de ce numero (je voulais y ajouter le
 texte  associe a la parcelle P)

 position à préciser. Parcelle associée : n° xxx

je prends



  4)  X m de la parcelle P: verifier la position et/ou l'association a la
 rue

 ok

 De mon côté je poursuis l'association avec les ways OSM pour le nom de la
 relation et les rôles 'street'.

 vincent

 ps. j'ai eu ce soir un plantage en fin de process pour Beauvais :
 http://37.187.60.59/cadastre-housenumber/adresses.php?dep=060com=O0057


Merci pour ce cas de test,  le problème provenais d'une parcelle ayant 2
fois exactement la même adresse.
Les deux numéros (identiques) étaient bien dessinés sur le cadastre, mais
je n'ai par réussi à dépatouiller mon code pour qu'il associe les deux
numéros sans retomber dans un plantage, donc du coup, dans ce cas de figure
je ne considère qu'une seule instance de l'adresse, et un seul des numéros
sera associé (ici le moins bien placé au centre de la parcelle).
Le résultat déjà généré:
http://37.187.60.59/cadastre-housenumber/data/060/O0057/O0057-adresses.osm



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

Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr

2014-01-21 Par sujet Tyndare

Le 21 janvier 2014 11:08, Pieren pier...@gmail.com a écrit :

 2014/1/21 Christian Quest cqu...@openstreetmap.fr:

  Il est sur le changeset ;)
 
  Merci à JOSM qui a rendu tellement plus facile l'ajout de ce tag !

 Ca veux dire que ces adresses, lorsqu'elles seront extraitent du
 prochain planet.osm, n'auront aucune indication sur la source. C'est
 une violation de la clause d'attribution du cadastre. Petit rappel :
 on ne peut pas généraliser la pratique du source sur le changeset avec
 le cadastre (de même qu'on ne peut pas dire que toutes les adresses en
 France sont issues du cadastre et donc faire une clause générale
 d'attribution).

 Pieren


Je suis d'accord, je pense que le tag source doit être associé à chaque
nœud addr:housenumber.
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr

2014-01-21 Par sujet Tyndare

Le 21 janvier 2014 12:01, V de Chateau-Thierry v...@laposte.net a écrit :

 Oui, j'ai vu que ce qui plantait hier remarchait ce matin (et même plus
 rapidement j'ai
 l'impression ?). Donc j'ai sorti quelques gros fichiers pour avoir du
 grain à moudre :-)
 En revanche à l'instant j'ai un plantage sur Castres, mais avec une erreur
 HTTP 500, donc
 pas certain que tu puisses jouer dessus. Je te mets les messages en
 dessous [1].
 [1] :
 http://37.187.60.59/cadastre-housenumber/adresses.php?dep=081com=UL065


Je n'avais jamais testé de ville avec une aussi grande surface.
Chez moi la récupération des exports pdf de cette ville a complètement
bloqué au bout d'un moment (au bout de 36 pdf). C'est peut être un problème
d'expiration de la session de connexion avec le site du cadastre, je ne
sais pas trop pour l'instant.

Pieren comment tu détectes l'expiration de la session associée au cookie
dans le plugin cadastre de JOSM ?
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr

2014-01-19 Par sujet Tyndare

Le 18 janvier 2014 23:34, Vincent de Château-Thierry v...@laposte.net a
écrit :

 mais un superbe 0% sur Boulogne-Billancourt car le fichier .osm extrait du
 cadastre contient pour chaque adresse le texte '92100 BOULOGNE' en plus du
 nom de voie. Moche.


Ah oui effectivement, je me contentais de supprimer la dernière ligne
d'adresse pour vouloir éliminer le code postale et la ville, mais
Boulogne-Billancourt étant trop gros il prends 2 lignes et du coup
j'élimine que Billancourt.
Je vais faire une expression régulière pour éliminer à partir du code
postal.
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr

2014-01-19 Par sujet Tyndare

J'ai mis à jour l'outil (et désactivé l'ancien pour l'instant):
http://37.187.60.59/cadastre-housenumber/adresses.php
(Il est encore plus lent, je crois que si on voulait faire une extraction
massive du cadastre il lui faudrait plusieurs années...)

J'ai gardé un fixme uniquement dans les cas suivants:
 - numéro sans rue (j'ai pas trouvé de parcelle correspondante)
 - numéro sans position exacte (j'ai une adresse de parcelle mais je n'ai
pas trouvé le numéro sur le dessin du cadastre donc je l'ai mis au milieu
de la parcelle.
 - numéro associé à plusieurs rues... oui ça arrive qu'une parcelle ait
plusieurs adresses avec le même numéro, donc ne sachant pas choisir,
j'associe chacun des numéros à chacune des rues.
 - numéro trouvé à plus de 10m de la parcelle (donc il faut mieux vérifier)
Dites moi si la limite des 10m vous parait suffisante ou pas.

Voici un exemple de résultat
http://37.187.60.59/cadastre-housenumber/data/026/CL281/CL281-adresses.osm

il y a quand même plus de 600 fixme... cad 7%

Un exemple plus simple:
http://37.187.60.59/cadastre-housenumber/data/050/KN078/KN078-adresses.osm


Petit bonus:
 - j'ai créé des place=neighbourhood pour les adresses sans numéro comme
suggéré par Mickaël
 - si le numéro est à moins de 2 m de la parcelle, je le déplace sur la
limite de la parcelle
 - j'ai essayé d'améliorer la reconnaissance des lettres jusqu'à S pour
Évry.

Il faut encore que je modifie les lettre B T Q en bis ter quart si
approprié comme tu l'a proposé Christian.

Vincent, est-ce que tu pourras adapter ton script au nouveau format du
fichier que je génère ?
Et dans ton fichier les nom de rue contiennent toujours des abréviations,
est-ce qu'il y a moyen de trouver le nom complet dans OSM ?
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr

2014-01-18 Par sujet Tyndare

Je viens de progresser un petit peut.

Pour résumé la situation:
1) D'un côté on récupère les export PDF du cadastre, j'arrive à en extraire:
  - des numéros de rue (mais sans la rue associée)
 - des limites de parcelle (sans identification)
2) De l'autre côte on récupère des infos sur chaque parcelles:
 - id, bounding box, surface,
  - position du libellé (vers le centre, ou à côté de la parcelle pour les
petites)
 - une liste d'adresses associées (numéro si existant, nom de rue ou lieu
dit, code postal et ville)

Les numéros qu'on trouve dans l'export PDF sont en général bien positionné,
mais on ne sais pas à quelle rue il faut les rattacher.
Les adresses des parcelles sont complètes (numéro et nom de rue), mais on
ne connaît pas précisément où positionner le numéro.

J'ai essayé de faire le lien entre les deux sources d'info.
Grâce aux valeur de surface et de bounding box des parcelles de la source
2, j'arrive a faire la correspondance quasi parfaite avec leur limite
(source 1)

Je peut donc ensuite faire une recherche des numéros de rue de la source 1)
à proximité des limites de la parcelle, qui correspondent à ses adresses
(source 2)

J'ai testé dans une petite ville, Tain l'Hermitage dans la Drôme,
dans 93% des cas je trouve un numéro correspondant à moins de 2m des
limites de la parcelle, mais il m'a fallut chercher jusqu'à 150m des
limites des parcelles pour tous leur trouver une affectation.
Je n'ai pas tout vérifié, mais celui à 150 m de distance était correcte, le
numéro était en fait dessiné au bout du chemin, le long de la rue.

Au final il me reste 2 numéros non affecté à une parcelle, numéros écrit
avec un  bis en toute lettre que je n'extrait pas correctement des export
PDF (mais c'est peut être corrigeable)
Il me reste aussi 90 adresses qui n'ont pas trouvé la position de leur
numéro, mais c'est a priori car une autre parcelle avait la même adresse et
avait déjà pris le numéro, il faudra que je filtre ça.

Voici un fichier qui visualise la fusion entre les deux sources de données
pour la ville de Tain, je n'ai pas encore intégré ça dans un script un peut
propre.
http://37.187.60.59/cadastre-housenumber/data/test.osm
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr

2014-01-16 Par sujet Tyndare

J'ai pu récupérer les adresses de toutes les parcelles d'une commune.
Je fait des requêtes par zone d'environ 700m de large et je temporise un
peut entre chaque requête donc c'est très lent.
http://37.187.60.59/cadastre-housenumber/adresses.php

Voici par exemple le résultat pour Mulhouse:
http://37.187.60.59/cadastre-housenumber/data/068/QP224/QP224-parcelles-adresses.osm

Je ne sais pas trop quoi faire de ce résultat en fait.
Est-ce que ça pourrait être utile de croiser ces données avec le fichier
FANTOIR ?

Je crois que je vais essayer de faire le lien avec les addr:housenumber que
je récupère par ailleurs pour pouvoir leur assigner une rue de manière plus
fiable.
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr

2014-01-15 Par sujet Tyndare

Pas de parcelle ici, ça doit être du domaine publique, j'ai corrigé pour
qu'il affiche NOT FOUND dans ce cas là.

2014/1/15 Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net

 Bonjour,

 Le script plante pour cette requête :

 http://37.187.60.59/cadastre-housenumber/adresse.php?dep=063com=P0032lat=45.75024lon=3.08482
 python cadastre_vers_adresse.py 63 P0032 45.75024 3.08482

 Il ne trouve pas la parcelle. Je me suis trompé ?

 Merci


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

Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr

2014-01-15 Par sujet Tyndare

Pieren pier...@gmail.com a écrit :


 
 http://wiki.openstreetmap.org/wiki/WikiProject_Cadastre_Fran%C3%A7ais/Aspects_techniques_du_cadastre_en_ligne#G.C3.A9ocodage_invers.C3.A9_des_parcelles

 Merci. Bon, y a à boire et à manger là-dedans. On pourra surement
 trier et simplifier la requête. On va voir ça.


Le serveur m'a l'air un peut stricte par rapport au format accepté pour les
requêtes xml, par exemple il n'aime pas les espaces superflus ou les
retours à la ligne.

Sur l'interface web du cadastre j'ai découvert qu'il y a un mode avancé qui
permet de faire des requêtes sur toute une zone (box) au lieu de parcelles
individuelles.
On récupère un pdf, son filtrage par le programme pdftotext semble
exploitable.
Je ne me voyais pas trop faire des milliers de requêtes pour récupérer d'un
coup les adresses de toutes les parcelles d'une commune, mais si je peux
grouper, ça deviens envisageable, je vais essayer.
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

[OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr

2014-01-14 Par sujet Tyndare

Bonjour,

j'ai basculé sur la liste dev-fr pour faire suite au mail de Denis, grâce
auquel j'ai découvert qu'il était possible de demander au site
cadastre.gouv.fr l'adresse correspondant à une position donnée.
Pour cela il faut procéder en deux étape: demander quel est l'id de la
parcelle à cette position, puis demander les infos correspondant à cette
parcelle.
J'ai essayé de faire ça en python et cela semble bien marcher:
http://37.187.60.59/cadastre-housenumber/adresse.php (il faut choisir, le
département, la commune en enfin les coordonnées).
Le code est la (class CadastreWebsite) :
https://www.gitorious.org/cadastre-housenumber/cadastre-housenumber/source/cadastre_vers_pdf.py

A moins que Pieren ne se lance sur le sujet, j’essaierais bien de modifier
l'outil Adresse du plugin cadastre-fr pour avoir cette info dans JOSM.
Mon idée, serait de rajouter un TextArea à la fenêtre qui s'ouvre en mode
Adresse, et lorsque l'on cliquerais à un endroit de la carte avec la touche
modificatrice ALT activée, cela lancerais la requête au cadastre pour
l'adresse à cette position, puis remplierais le TextArea avec le résultat,
et si l'adresse résultat commence par un numéro, choisirais ce numéro comme
le prochain numéro à rentrer.
Si quelqu'un a une autre suggestion, je suis preneur.

C'est la première fois que j'ouvre le code de JOSM donc je ne garantie rien
pour l'instant, et si Pieren tu veux t'en charger, tiens moi au courant.

Ludo.


Le 13 janvier 2014 14:30, HELFER Denis denis.hel...@rff.fr a écrit :

  · L’ensemble des adresses n’est pas affiché sur le plan
 cadastral. Parfois, il faut aller sur le site du cadastre, choisir une
 parcelle et afficher les informations. Il faut donc jongler entre JOSM et
 le cadastre à moins qu’une développeur fou ne nous permette de remonter
 l’info dans JOSM. Une bière (ou plus si affinités) à la clé !

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

Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr

2014-01-14 Par sujet Tyndare

Normalement c'est corrigé.

Le 14 janvier 2014 12:02, Etienne Trimaille etienne.trimai...@gmail.com a
écrit :

 Je voulais juste tester ton outil pour voir la qualité du géocodage
 inverse, mais j'obtiens malheureusement une erreur 1.

 http://37.187.60.59/cadastre-housenumber/adresse.php?dep=025com=CB047lat=47.35034550182916lon=6.371492891198871envoyer=Requette+Adresse

 J'ai essayé avec 2 adresses, idem.

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

Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr

2014-01-14 Par sujet Tyndare

Le 14 janvier 2014 12:48, Pieren pier...@gmail.com a écrit :

 Je veux bien essayer de faire quelque chose. Je ne connais pas
 d'exemple où l'adresse existe mais n'est pas affichée directement sur
 le plan. Pourrais-tu m'en donner un ?


Je n'ai pas d'exemple pour le numéro de rue non affiché, peut être que
Denis Helfer en aurais eu, par contre voici un exemple qui permet de
trouver le nom d'une rue non affiché sur le cadastre:
http://37.187.60.59/cadastre-housenumber/adresse.php?dep=026com=CL271lat=45.0133374lon=4.8432698
Ça peut donc aussi servir pour trouver où sont les rues du FANTOIR...

J'ai aussi un exemple qui permet de vérifier que le cadastre dessine
parfois le numéro du mauvais côté de la parcelle, cad le long de la
mauvaise rue...
http://37.187.60.59/cadastre-housenumber/adresse.php?dep=007com=61086lon=4.7373876lat=45.1078604



 Est-ce que ça fonctionne aussi
 avec les plans images ?

Avec un plan images, je m'arrive pas à avoir l'information avec l'interface
web depuis un navigateur, donc je ne pense pas que ce soit possible mais si
quelqu'un a un exemple où il y arrive je veux bien regarder.


 Pourrais-tu mettre les détails de la requête ici:

 http://wiki.openstreetmap.org/wiki/WikiProject_Cadastre_Fran%C3%A7ais/Aspects_techniques_du_cadastre_en_ligne


Je me suis contenté de dumper les requêtes web quand je me connecte depuis
un navigateur, donc je ne maitrise pas vraiment ce que j'ai fait mais je
vais essayer de retranscrire mon code python en langage plus naturel.


 Que faire en cas de retour de plusieurs adresses ? Je préfère le
 modèle un noeud, un numéro et là, on risque de multiplier les
 valeurs multiples.


Si il y a plusieurs adresses sur une parcelle, il faudrait effectivement
que l'utilisateur puisse créer  plusieurs nœuds, normalement les numéros
distincts devraient apparaitre sur le cadastre. J'ai trouvé un lotissement
où chaque parcelle avait 2 adresses, une ancienne qui n'a plus court, et
une nouvelle, donc dans ce cas l’utilisateur devrait pouvoir en choisir
qu'une.


 Ou alors faire un drop liste pour choisir...


Quitte à choisir je préfèrerais un tableau déroulant plutôt qu'une drop
liste, ça limite le nombre de click nécessaires et ont voit plus rapidement
qu'il y a plusieurs réponses je trouve.
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr

2014-01-14 Par sujet Tyndare

 Pourrais-tu mettre les détails de la requête ici:

 http://wiki.openstreetmap.org/wiki/WikiProject_Cadastre_Fran%C3%A7ais/Aspects_techniques_du_cadastre_en_ligne


J'ai rajouté une section Géocodage inversé des parcelles:
http://wiki.openstreetmap.org/wiki/WikiProject_Cadastre_Fran%C3%A7ais/Aspects_techniques_du_cadastre_en_ligne#G.C3.A9ocodage_invers.C3.A9_des_parcelles
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Import addr:housenumber depuis le cadastre

2013-10-31 Par sujet Tyndare

Le 25 octobre 2013 14:53, Frédéric Rodrigo fred.rodr...@gmail.com a écrit
:

 Tu peux également utiliser directement les opérateur de dessin de base du
 PDF, ça évite un passage en SVG. Soit directement dans le code de Qadastre,
 soit en exécutant un script depuis Quadastre en lui passant les primitives
 (c'est comme ça que j'avais fait)


Cela serait surement beaucoup plus efficace en terme de performance, mais
je ne suis pas très à l'aise en C++, et je me suis perdu dans la spec du
format PDF. SVG m'a parut plus simple, mais je me trompe peut être.



 Pour détecter les numéros de rue, j'ai codé en dure un path (au sens
 svg) correspondant à chaque numéro (0-9 et les lettres B,T,Q,A,B,C,D,E,F),
 et je fait une transformation pour les comparer. Je filtre ensuite selon la
 taille pour ne garder que les numéros de rue (et éviter les numéros de
 parcelles).


 Quel genre de transformations et de comparaison tu fais (je n'ai pas pris
 le temps de regarder le code) ?
 J'avais rencontré des problèmes la dessus : détermination de l'orientation
 du texte, du mal à comparer les shapes entres elles pour déterminer le
 caractère. Le path variait en fonction de la taille de la commune et de son
 orientation.


Je commence par comparer les commandes qui composent les paths, si ce sont
exactement les mêmes, alors je compare les coordonnées de la liste des
points qui composent les paths (par rapport au format SVG j'ai en fait
normalisé la représentation des path pour n'avoir que des coordonnées
absolue, pas de valeur relatives). Je transforme donc les points avec pour
chaque path:
 - une mise à l'échèle de telle manière que le point le plus loin du
premier se retrouve à une distance de 1.0
 - une rotation pour que le premier point et le 6ème (choix arbitraire) se
retrouvent à l'horizontal
Une fois ces transformations effectuées, je vérifie que la distance
maximale entre les points des deux paths soit  0.05
Je pense donc avoir une vérification assez fiable et ne pas pouvoir
confondre un chiffre avec un autre, le risque est plus d'en rater certains
pour des problème de précision.

J'avais aussi à l'origine un problème de variation des path selon la taille
de la commune, mais je pense que c'était en fait un problème de précision
du au format PDF, et je crois l'avoir résolu en découpant la récupération
du cadastre en plusieurs fichiers PDF de taille raisonnable (comme le
script import-bati.sh).



 J'espère que a court et moyen terme on pourra avoir accès aux données
 d'adresses du cadastre sans avoir à les extraire depuis le WMS. Ces
 informations sont dans les EDIGEO et il faut à mon avis pousser pour avoir
 accès à ces données, on a commencé à la faire département par département,
 il faut poursuivre


Passer par les fichier EDIGEO serait effectivement plus sûr et plus
logique, mais là on sort de mon domaine de compétence.
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Import des numéros de rue (addr:housenumber) depuis le Cadastre

2011-11-03 Par sujet Tyndare

Je suis partis sur une approche plus simpliste qui doit être similaire
à ta première tentative. Je me contente des données récupérée par
qadastre: un Path composé d'une liste de commandes (moveto, lineto,
curveto) et une liste de coordonnées associées.
J'ai pris comme à priori que les numéros de rue seraient toujours
écris avec la même police et devrais donc être composés exactement des
même commandes dans le même ordre.Ensuite pour comparer la liste des
coordonnées associées aux commandes, j'applique une transformation
(déplacement et rotation) pour ramener la première de la liste à (0,0)
et la troisième  à l'horizontale (en choisissant la deuxième ça ne
marchait pas pour le chiffre 3) et je met le tout à échelle pour que
ça rentre dans un carré d'1 de large.
Ca a l'air très fiable si les coordonnées sont assez précises, et je
pense que c'est généralisable au texte (chaque mot génère un Path mais
il faut ensuite les assembler).

Je n'ai pas regardé la simplification faite par qadastre, c'est où le
bouton pou la désactiver ?

Pour les problèmes de tailles, je commence à me dire qu'il n'y a pas
d'autre solution que de repartir sur un découpage des requêtes au
cadastre en plusieurs pdf comme le fait le script import-bati.sh

Le programme de Benoît ROUSSEAU avait l'air très avancé. J’essaierais
de le contacter directement si il ne se manifeste pas.

Ludo.


Le 3 novembre 2011 09:49, Frédéric Rodrigo fred.rodr...@gmail.com a écrit :
 Bonjour,
 J'ai également tenté de faire ça. Mais généralisé à tout le texte.
 J'avais commencé par faire une approche par signature de forme sur les
 composantes du chemin décrivant la forme (comme la tentative de 2010).
 Mais pour les raisons précédemment évoquées c'est vite limité. Au
 passage noter que qadastre fait une simplification qu'il faut
 désactiver pour faire des analyses sur la forme d'origine.
 J'étais donc parti sur une autre piste. Le détection des caractères
 pas comparaison de critère : ratio de taille, de périmètre, nombre de
 ligne droites significatives, détection d'angles, d'intérieurs... le
 tout avec une détection et la correction de l'orientation du texte
 pour diminuer les faux positif. Le résultat est bien indépendant de la
 taille du pdf. Mais la qualité n'est toujours pas suffisante pour
 donner un résultat exploitable même en augmentant la base statistique
 de référence.

 Je peux te donner les sources, c'est un qadastre modifié avec une
 extension en ruby.

 Fred

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

43 matches

Mail list logo