Re: [OSM-dev-fr] Beta-test du support des fichiers du cadastre dans JOSM

[Vincent de Château-Thierry]

> De: "Vincent Privat" 
> 
> Hello,
> Les données du Cadastre doivent normalement apparaître d'ici vendredi
> sur data.gouv.fr :
> http://www.data.gouv.fr/fr/datasets/pci-vecteur-plan-cadastral-informatise/
> 
> On peut déjà avoir un accès anticipé aux données en demandant
> directement sur Twitter:
> https://twitter.com/jdesboeufs/status/910196623984164867
> 
> Ce que j'ai fait la semaine dernière, et il en ressort une nouvelle
> version du plugin cadastre-fr de JOSM qui supporte le format
> "Edigéo" utilisé par la DGFiP:
> https://twitter.com/VincentPrivat/status/912353254562025472

Simplement classe :)

> Pour l'instant il n'y a pas encore d'API permettant de télécharger
> les données d'une bbox, il faut connaître le numéro du lot Edigéo
> (mais ça va venir).
> 
> Je cherche des beta testeurs pour le support de ce format de fichier,
> je n'ai testé que sur 2 ou 3 communes de Haute-Garonne, des gens
> intéressés ?

Oui, mais ça implique un peu d'assistance de ta part, pour la prise en main. Tu 
vois si tu peux...

merci
vincent

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

Re: [OSM-dev-fr] Open Earth View - tuiles 3D

[Vincent de Château-Thierry]

Bonsoir,

Le 14/01/2016 22:21, clem...@igonet.fr a écrit :

Comme quoi, j'aurais bien besoin d'aide...

Le 14 janvier 2016 20:57:07 UTC+01:00, "Frédéric Rodrigo"
 a écrit :

Petit retour rapide. J'ai juste testé la démo.
Je trouve la navigation à la sourie complètement contre intuitive.
click gauche devrait faire du drag, le zoom molette est à l'inverse de
ce qu'il se fait habituellement.
bref pour la première démo je ne suis pas arrivé a visualiser quelque
chose en navigant.


J'ai testé http://www.openearthview.net/ et c'est vrai que j'ai un peu 
bataillé avec ma souris. Pour le zoom-molette, c'est un coup à prendre. 
Mais j'ai surtout eu du mal à me déplacer (pan) sur le fond de carte 
pour le centrer correctement avant de zoomer.
J'ai vu pousser des bâtiments en zoomant sur Manhattan, c'est prometteur 
! Mais j'ai mis du temps à voir dans le coin haut-gauche le curseur avec 
le décompte du chargement. Une fois vu, on attend. Mais avant, j'avais 
tendance à zoomer-dézoomer un peu frénétiquement, et forcément rien 
n'avait le temps de s'afficher.


Bon courage pour la suite et merci pour les démos que tu voudras bien 
diffuser, pour test et feed-back.


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

[Vincent de Château-Thierry]

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

Re: [OSM-dev-fr] Way splitté en base

[Vincent de Château-Thierry]

Le 22/08/2015 10:06, sly (sylvain letuffe) a écrit :



Est-ce que ça dit quelquechose à quelqu'un ?


Oui. C'est dans pg-output.c (si ça existe toujours) que le code du split est.

Mon soupçon est

qu'osm2pgsql

splitte les longs ways, plus ou moins arbitrairement


C'est pile poil ça. La valeur est en dur dans le code.


Le code a bougé depuis, mais j'ai retrouvé ça :
https://github.com/openstreetmap/osm2pgsql/blob/aaddc60fb61bdce80b67145951ec0511ac55886e/ChangeLog#L523
qui dit la raison du pourquoi : limiter la bbox de chaque way, au moins 
pour éviter de la part de Mapnik des requêtes avec emprise délirante.


Merci Sly !

vincent

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

Re: [OSM-dev-fr] requete pour trouver un way qui intersecte plusieurs communes

[Vincent de Château-Thierry]

Bonjour,

Le 08/05/2015 12:24, didier2020 a écrit :

voila c'est dans le titre ...

depuis que je banote j'ai remarqué plusieur fois :
un nom est mis sur une voie mais comme celle-ci n'est pas découpée,
ce nom est erroné sur la commune voisine.

donc
le but est de trouver l'id d'un way
de type route (primary, secondary,unclassified, ...)
qui est long = tri decroissant par la longueur
qui a un nom
qui a une intersection avec au moins 3 communes
= c'est la que je coinse !

etape suivante
si que 2 il faudrait connaitre la longueur sur les 2... pour avoir une
longueur significative (2km,1km par exemple)


Le souci à corriger peut commencer avec un way (pas forcément long) qui 
est à cheval sur 2 communes, dès lors qu'il croise la limite de commune 
plutôt que d'être confondu avec elle.


Tu es dans quel environnement technique pour ça : une BD PostGIS ? En 
supposant que oui, ta recherche revient à détecter les ways ayant 
certains de leurs points strictement inclus dans un polygone limite de 
commune et d'autres points dans une autre commune, toujours en stricte 
inclusion, donc pas superposés à la limite.
Une manière d'approcher le résultat si tu as les ways et polygones sous 
la main :
SELECTion de l'ID du way, et du code INSEE du polygone admin 8 dans 
lequel est inclus le 1er point du way,

UNION
SELECTion de l'ID du way, et du code INSEE du polygone admin 8 dans 
lequel est inclus le dernier point du way


Ça va te sortir une liste où, pour un way inclus dans une seule commune, 
tu auras une seule ligne en sortie (vu que le UNION dédoublonne). Ce qui 
va t'intéresser c'est les ways pour lesquels tu as 2 lignes qui sortent 
: ils sont à cheval sur 2 communes au moins.


Ca ne gère pas tout, notamment les cas où le way commence et finit dans 
la même commune mais fait un détour par une commune voisine. Mais ça 
devrait permettre de dégrossir.


Pour le 1er et le dernier point des ways tu as ST_StartPoint et 
ST_EndPoint tous cuits.


vincent

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

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

[Vincent de Château-Thierry]

Bonjour,

Le 27/04/2014 13:02, didier2020 a écrit :



j'ai essayé sur nimes (30)


Le dimanche 27 avril 2014 à 12:30 +0200, didier2020 a écrit :

Le dimanche 27 avril 2014 à 11:28 +0200, Tyndare a écrit :

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.

j'ai essayé avec 2 navigateurs (under linux) = ça marche
parfaitement !


sur ma commune ...
j'ai essayé sur nimes (30) , il ne se passe rien (?)

sinon détail pour la page html:
title=Transforme les lettres B,T,Q en bis, ter, quater et rajoute un
espace pour les autres checked/

le / est en trop



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


Ça marche aussi très bien chez moi (Win 8.1 + Chrome).
En revanche j'ai mis du temps à comprendre que la case à cocher 
Sélectionner une zone à exporter ne fonctionnait qu'une fois une ville 
sélectionnée au dessus. A posteriori c'est logique, mais je ne l'ai 
compris qu'en regardant le code JS. Donc un petit message peut aider, 
pour faire comprendre que ce mode de sélection est en complément du 
choix de la ville, et non une alternative à celui-ci.


vincent

___
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

[Vincent de Château-Thierry]

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

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

[Vincent de Château-Thierry]

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

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

[Vincent de Château-Thierry]

Le 05/03/2014 23:33, Christian Quest a écrit :

ok, donc je peux virer ce log ?


à mon avis oui.

___
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

[Vincent de Château-Thierry]

Bonsoir,

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

J'ai un peu exploré les différents fichiers produits.

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 nœud 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.


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...



La projection des points adresse en façade pour des bâtiments éloignés
de la voirie donne actuellement des résultats parfois très étranges.


Là dessus, il faudrait indiquer un/des cas en donnant... leur adresse 
histoire de voir ce qui cloche.


vincent

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

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

[Vincent de Château-Thierry]

Bonsoir,

Tyndare a présenté récemment [1] une démarche qui permet d'extraire du 
cadastre vectoriel les informations d'adresse. Nous avons creusé le 
sujet ensuite, notamment ici même dans ce fil [2].
Suite à ces discussions, nous vous mettons à disposition une interface 
afin que chacun puisse tester l'intégration d'adresses, sur les communes 
(vectorielles) de son choix.


Les discussions ayant réaffirmé l'absence de consensus sur la manière de 
modéliser les adresses, vous trouverez pour chaque commune 6 (oui six !) 
lots de données. Il y en a pour tout le monde : les partisans des 
relations associatedStreet comme ceux du tag addr:street, les fans du 
point en bord de rue comme ceux du tag sur building ou encore du point 
en façade.


Seule la modélisation avec relation bénéficie, autant que possible, de 
l'ajout des codes FANTOIR.


Pour expliquer la démarche, un peu de littérature sur cette page :
http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_adresses

Quant à l'interface elle-même, elle est ici :
http://cadastre.openstreetmap.fr/adresses/

Tout retour d'expérience sur la manipulation des fichiers est la 
bienvenue. Considérez que vous inaugurez le service :) En fonction des 
retours, on reparlera de tout ça sur talk-fr pour une mise à disposition 
de tous.


Merci à Jocelyn et Christian pour leur support et la mise à disposition 
d'une infrastructure d'OSM-Fr, qui héberge le service.


Tyndare  vincent

[1] : 
https://lists.openstreetmap.org/pipermail/talk-fr/2014-January/065794.html
[2] : 
https://lists.openstreetmap.org/pipermail/dev-fr/2014-January/001951.html


___
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

[Vincent de Château-Thierry]

Bonjour,

Le 01/02/2014 15:04, Nicolas Dumoulin a écrit :


Ça marche pas trop mal. Mais il y a des loups dans les zones denses. Par
exemple Rue Nationale à Beaumont, j'ai :
  - des numéros qui n'ont pas récupéré leur bâtiment (qui ne sont pourtant pas
les plus petits) : 12, 41B, 66, 74, 94, …
  - des numéros qui se sont retrouvés du mauvais côté : 81, 99, 25B (sur le mur
mitoyen !), …   


Pour les n° qui n'ont pas récupéré leur bâtiment, 2 cas :
- pour le 94, le building est à cheval sur 4 parcelles, chacune avec une 
adresse différente. Si tu affiches le cadastre en fond ça se voit bien. 
Ça fait donc 4 adresses possibles pour le même point, et dans ce cas il 
n'y a pas de rapprochement automatique, au bonhomme de lever l'ambiguïté.
- pour les autres : ils sont bien chacun dans une seule parcelle, mais à 
chaque fois c'est une parcelle avec plusieurs adresses. C'est souvent à 
l'angle de 2 rues, ça n'est pas un hasard.
Au final ces 2 cas n'en sont donc qu'un seul : si plusieurs adresses 
pour un seul bâtiment, pas d'automatisation...


Pour les n° du mauvais côté : merci pour ces cas ! Ça met en évidence un 
critère qu'il faudrait travailler, pour donner une prime à la façade la 
plus longue _et_ la plus proche de la rue. À affiner mais l'idée est 
celle-là je pense. Y'a un peu de taf :-)
Pour le n° sur le mur mitoyen il faut que je creuse car là en revanche 
c'est pas normal.


*
J'en profite pour signaler un nouveau jeu-test, et c'est du lourd : 
Montpellier. +2000 relations associatedStreet crées, gros morceau, à 
déguster ici :

http://osm.vdct.free.fr/adresses/adresses_MONTPELLIER_34_FB172_140201.zip

Merci pour vos retours dessus.

*



En tous cas, beau boulot :-)

On avance ! Merci pour ton retour ;-)

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

[Vincent de Château-Thierry]

Bonsoir

J'ai pu produire une première version du tiercé 1. Pour rappel, il 
s'agit de faire porter l'adresse à un noeud intégré à un way de type 
building.
Dans cette version, le rattachement automatique est fait sur 1 seul 
building par adresse.
Le building élu est obligatoirement complètement inclus dans une seule 
adresse, quel que soit le nombre de parcelles rattachées à cette 
adresse. Ensuite, on choisit de préférence :

- un bâtiment en dur de + de 15m2
- sinon un bâtiment avec 'wall=no' de + de 15m2
- enfin le plus grand bâtiment de l'adresse

Pour le choix du segment de facade qui hérite du numéro : c'est une 
portion d'au moins 2m de long, et qui donne sur l'extérieur. Les limites 
communes à deux buildings sont exclues.


J'ai produit cette fois-ci des jeux-test sur :
Toul (54)
Beaumont (63)
Courbevoie (92)
Gentilly (94)

Pour chacune, les versions 'tiercé 1' et 'tiercé 2' sont présentes. Tout 
est ici :

http://osm.vdct.free.fr/adresses/adresses_tierce_1_et_2_140131.zip

merci pour vos avis, et n'hésitez pas à demander la génération d'une 
autre commune : c'est simple à produire et si ça permet de brasser plus 
d'avis, ça vaut le coup.


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

[Vincent de Château-Thierry]

Le 29/01/2014 23:09, Nicolas Dumoulin a écrit :


À Beaumont, les adresses de l'Allée du Parc sont des immeubles. La plupart des
bâtiments ne sont pas séparés, et donc le script ne peut pas associer
l'addresse sur le bâtiment. Je ne sais pas comment ça se passe dans le script,
mais le résultat est là.


La grande parcelle de l'Allée du Parc (ref cadastre P0032000BE0018) a 
rien moins que 17 adresses associées. Et en effet dans le script, dès 
qu'on a plusieurs adresses pour une même parcelle, les bâtiments ne 
récupèrent aucune des adresses dans leurs tags (tiercé 2).



En revanche, le 19 correspond à un seul bâtiment (au sens du cadastre), et la
relation est donc bien créée sur ce bâtiment. Mais, du coup, c'est dommage,
car le 19 sur le cadastre est super bien placé, pile devant la porte
d'entrée. Avec ce tiercé 2 (adresse sur le bâtiment), on perd donc de
l'information qui a son intérêt : la navigation entre ces immeubles n'est pas
évidente, donc connaître l'emplacement des entrées est un plus.


En comparant la position des entrées d'immeuble sur le terrain et la 
position des n° sur le cadastre, sur Paris XVI, j'avais très souvent 
constaté que les 2 n'avaient pas de rapport. Du coup je suis un peu 
frileux sur la déduction de la position de l'entrée depuis la position 
du n°. En revanche, je viens de tester sur ton exemple, quand les n° 
sont à un pouillème du bord du bâtiment, ça va très vite de les 
rattacher manuellement : selection du node puis 'J' puis 'L'. Même pas 
besoin de 2 souris ;-). Juste pour dire que ça n'est pas ce qui 
m'inquiète le plus car ça n'est pas chronophage, dans la mesure où la 
configuration plusieurs adresses pour une parcelle est très minoritaire.



Est-ce qu'on peut envisager de mettre un entrance=main (je suis plus sûr du
tag) en face du numéro sur le polygône lorsque ces deux derniers sont à une
distance de moins d'1m ? Est-ce que c'est généralisable ?


Dans le tiercé 1, on peut tout à fait imaginer faire porter le addr:hsnr 
à un node qui aurait déjà le tag entrance=main. Il faut juste avoir 
mappé les entrées... Et comme tu dis, on peut blinder ça avec un critère 
de distance.



Comme ça, on ne perd pas l'info de la localisation de l'entrée, et on ajoute
le lien au bâtiment lorsqu'on n'a pas pu le faire avant.

Bref, revenir sur le tiercé 1 en fait :-)

Oui, dans ce cas là, on pourrait même empêcher le tiercé 2.

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

[Vincent de Château-Thierry]

Le 28/01/2014 17:31, V de Chateau-Thierry a écrit :



De : Tyndare

Je vais suivre ça.


Je vous fait part d'une première étape : l'affectation du n° d'adresse 
au building, en tant que tag du way (le n°2 du tiercé).
C'est toujours packagé par rue, mais cette fois-ci on peut trouver dans 
chaque fichier des buildings issus directement de la base, et modifiés 
car porteurs d'un n°. Pour ces cas la relation associatedStreet 
référence ces bâtiments avec la rôle 'house'.
Pour les n° situés sur des parcelles à plusieurs adresses, le node 
addr:housenumber fabriqué par Tyndare est repris tel que.


Pour le rattachement aux buildings, pour l'instant il n'y a aucun 
filtre, c'est à dire que tous les bâtiments d'une même parcelle héritent 
d'un tag addr:housenumber. C'est pas faux mais un brin redondant.

Je pense implémenter la règle suivante :
- lorsqu'il existe sur la parcelle au moins un bâtiment de plus de 10m2, 
alors les bâtiments de moins de 10m2 ne récupèrent pas de tag adresse. 
Le seuil de surface est à affiner mais en gros ça éliminerait les 
garages et les cabanes de jardin.
- lorsqu'il existe au moins un bâtiment 'en dur', alors les bâtiments 
avec wall=no ne récupèrent pas de tag adresse. Ça évite de tagguer un 
way véranda ou hangar.


Règles à discuter bien sûr.

Pour ceux qui souhaiteraient se faire une idée, et aussi alimenter la 
réflexion, j'ai généré 4 communes :

Gentilly (94)
Beaumont (63)
Sainte-Adresse (76) (un nom pareil, ça vous oblige :) )
Thal-Marmoutier (67)

Tout est regroupé dans cette archive (1.5 Mo):
http://osm.vdct.free.fr/adresses/adresses_tierce2_140128.zip

merci pour vos retours,
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

[Vincent de Château-Thierry]

Bonjour,

Le 23/01/2014 09:11, Romain MEHUT a écrit :


Mais l'essentiel c'est bien de connaître le point d'accès d'une adresse,
non?


Ça c'est dans une optique centrée sur le routage (soit un usage bien 
réel, c'est clair). Mais on peut aussi se dire que l'adresse a un 
rayonnement plus large que le simple point d'accès. Une adresse concerne 
parfois une simple cage d'escalier d'immeuble, mais va jusqu'à plusieurs 
parcelles cadastrales, d'où la remarque de Christian. Un point d'accès 
aura ses tags en propre, notamment entrance=* [1]. Les infos d'adresse 
peuvent être portées par le même point, mais dans ce cas on peut espérer 
que le node qui porte tous ces tags participe à la délimitation du 
terrain. C'est l'exemple de l'école.
Pour prendre un autre exemple : une bibliothèque municipale, qui occupe 
un bâtiment en retrait de la rue, avec de la verdure devant, sans muret 
ou grille. En plaçant le point d'adresse sur le trottoir, à l'endroit où 
démarre par exemple un footway qui va jusqu'à l'entrée du bâtiment, on 
n'a pas de lien entre l'adresse et le bâtiment. Déduire l'adresse de la 
bibliothèque, pas forcément pour y accéder en guidage, mais pour 
combiner les infos adresse et nature ou nom du bâtiment, n'a rien de 
trivial, puisque le lien entre les deux n'est pas organisé dans la base. 
D'où ma préférence pour associer explicitement les infos d'adresse au 
bâtiment (public comme privé, au passage). Cette association est une 
valeur ajoutée.


vincent

[1] : http://wiki.openstreetmap.org/wiki/Key:entrance

ps. si le service que permet l'outil de Tyndare se met en place de 
manière pérenne, nulle doute que la discussion reviendra rapidement sur 
talk-fr. On gagnerait en efficacité en synthétisant la présente 
discussion quelque part sur le wiki, avec les arguments pour et contre 
chaque méthode.


___
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

[Vincent de Château-Thierry]

Le 23/01/2014 13:35, Christian Quest a écrit :

Je comprends tout à fait le besoin de lier tel ou tel objet (comme un
bâtiment) à une adresse, mais de là à considérer que c'est le bâtiment
qui doit porter l'adresse me semble abusif.


Ça n'est pas la seule solution. Mais encore une fois, celle (la seule) 
qui me rebute est celle où l'adresse est portée par un point isolé, lié 
à rien.



En fait une adresse c'est comme un point kilométrique sur une voirie
d'accès. C'est bien pour ça que les numéros sont liés à la voirie (cas
général). Une parcelle de terrain est proche d'un (ou plusieurs) de ces
points, mais là aussi il n'y a pas toujours de lien 1 vers 1
adresse/parcelle comme pour les bâtiments. Je pense que c'est pour cette
raison qu'on a du mal à se mettre d'accord sur un modèle.


Je pense qu'on commence à bien distinguer les approches. D'un côté, ceux 
pour qui adresse = point d'accès. De l'autre, ceux pour qui adresse = 
emprise incluant (notamment) des bâtiments.
Je suis pour la 2e approche. Dans le cas d'une habitation sur une 
parcelle, avec une seule adresse associée, on ne peut pas mettre 
d'adresse sur l'emprise, vu qu'on ne trace pas les limites de parcelle 
dans OSM. Le bâtiment est alors la solution de repli, puisqu'il 
matérialise, indirectement, l'existence d'une propriété avec une 
adresse. On aurait les parcelles, c'est bien sûr la parcelle qui 
porterait l'adresse, bien mieux que le bâtiment. On saurait par suite
- emmener à l'adresse, en combinant les infos d'adresse et la situation 
du point entrance

- donner la surface bâtie de l'adresse
- donner le périmètre de la propriété de l'adresse
- etc
tout simplement parce qu'on aurait un lien entre les infos d'adresse et 
ce qui se situe à cette adresse.
J'espère vous montrer avec cet exemple que l'intérêt d'un lien entre 
adresse et emprise physique dépasse le simple besoin de se rendre à une 
adresse, dans une optique de routage.



Le minimum sur lequel on semble plutôt d'accord c'est bien cette notion
de position ponctuelle lié à un filaire de voirie... non ?


Là je ne comprends pas ce que tu veux dire, car ça m'évoque la solution 
3), contre laquelle je suis (= le numéros qui flottent dans le vide).
Mon impression, si on revient au tiercé d'hier, est que le consensus 
serait plutôt sur la solution 1) : les adresses comme des ponctuels (des 
nodes) qui font partie d'un way, de type amenity, building, landuse, etc.


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

[Vincent de Château-Thierry]

Le 22/01/2014 20:19, Romain MEHUT a écrit :


Bonsoir,

Le 22 janvier 2014 16:15, V de Chateau-Thierry v...@laposte.net
mailto:v...@laposte.net a écrit :

- les déplacer pour les intégrer au way qui dessine un contour de
building. Cas
typique des adresses multiples pour un même bâtiment, mais valide
aussi pour les
bâtiments mono adresses
par ex.: http://www.openstreetmap.org/#map=19/48.82502/2.35161

- les supprimer en transférant leurs tags et leur appartenance à la
relation
associatedStreet à un way building [1]. Ce cas est spécifique des
bâtiments n'ayant
qu'une seule adresse
par ex.: http://www.openstreetmap.org/#map=19/48.98516/2.26167

- les déplacer en bord de rue, à l'endroit supposé d'une entrée de
propriété et/ou
boîte au lettre.
par ex.: http://www.openstreetmap.org/#map=19/48.80725/2.48116


Il n'y a peut être pas de consensus mais il y a quand même une forte
incitation à choisir ce second schéma!


Ah ? Je ne sais pas sur quoi tu t'appuies car le second est, des 3, le 
seul qui n'est pas applicable partout. Il est donc impossible à généraliser.


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

[Vincent de Château-Thierry]

Le 22/01/2014 21:10, Christian Quest a écrit :

Mon tiercé ? 1 3 2

1) c'est le plus clean, mais ça prend du temps si on doit déplacer
chaque adresse à la main... si on peut la faire coller automatiquement
par un script avant upload c'est ma préférée dans le cas des bâtiments
qui donnent directement sur la rue bien sûr

3) ça correspond à l'emplacement des numéros dans la rue... c'est propre
au rendu et conforme au terrain, ça ne prends pas de temps avant upload
(c'est ce que j'ai fait pour les adresses de la moulinette, sinon
oubliez les 1000 adresses/heure).

2) ça pose pas mal de problème... que faire quand il y a plusieurs
bâtiments à la même adresse ? plusieurs adresses sur le même bâtiment ?
bref un truc assez bâtard et moche en plus sur les rendus.


Alors si on parle tiercé : pour moi il y a photo entre 1 et 2, mais le 3 
est loin derrière.
Les 2 premiers ont l'intérêt de lier un bâtiment à une (voire des) 
adresses, ce qui apporte une plus-value pour les bâtiments. Les deux 
sont chronophages en l'état des outils, mais le résultat est plus riche.
Pour le 3, les adresses qui flottent dans le vide, comment associer 
adresse et bâtiment ? Cas tout bête : un bâtiment en amenity school. Le 
n° n'est pas porté par le bâtiment mais déposé en bord de rue. Comment 
connaître l'adresse de l'école ? Le principe de je regarde où est le 
bâtiment et grâce à mon super algorithme je récupère le point adresse le 
plus proche et hop c'est gagné ne marche pas. Il y a un aléa fort à 
faire le pari que le plus proche est le bon. C’est là toute la plus 
value des 1 et 2 : le temps consommé à associer le n° au bâtiment lève 
l'ambiguïté / l'incertitude du schéma 3.


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

[Vincent de Château-Thierry]

Le 22/01/2014 23:46, Vincent Pottier a écrit :

Le 22/01/2014 21:10, Christian Quest a écrit :

Mon tiercé ? 1 3 2

+1

Pour le cas mentionné de l'école, il y a fort à parier que l'école, pas
seulement le bâtiment mais l' polygone amenity=school englobant le
bâtiment, la cour, que l'école est sur rue. Le node housenumber doit
donc être apposé sur le bord du area, en bourdure de rue. Cas 3 mâtiné
de 1, où on considère l'area amenity plutôt que le bâtiment.


En fait je n'ai pas de souci dès qu'on sait rattacher le n° à quelque 
chose. Mon exemple avec l'école est donc mal choisi, vu que vous lui 
tordez le cou :-).
Pour le dire autrement : ce que je regrette comme pratique, c'est celle 
de poser un n° comme un node isolé de tout (building comme amenity ou 
landuse), surtout lorsque l'environnement est truffé de points 
d'accroche potentiels, dont les ways building bien sûr, mais pas que, 
comme vous le soulignez.


Mais bon, y'a pas consensus, oui, je sais :-)

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

[Vincent de Château-Thierry]

Le 21/01/2014 13:24, Christian Quest a écrit :

Oui bien sûr, on est vraiment en phase de test de ce futur nouvel outil,
mais bon, pour le principe quand même et pour l'exemple ;)


J'ai ajouté quelques traitements sur les noms pour améliorer la mise en 
correspondance entre noms OSM et noms Fantoir/Cadastre : gestion des 
chiffres, des articles, et des types de voies en plusieurs mots (jusque 
3). Ça améliore le taux de correspondance, mais à la marge seulement.
Plus je teste et plus je me dis qu'un bénéfice non négligeable de cette 
intégration va être la détection des rues non nommées voire non 
tracées... :-)


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

É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.)


L'idée est de se faire un avis collégial sur le résultat actuel, sur la 
facilité / pénibilité de l'intégration.


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

[Vincent de Château-Thierry]

Le 21/01/2014 00:45, Christian Quest a écrit :

si je peux mettre en place une ch'tite requête pour te sortir un truc en
automatique sans passer par overpass, ça t'irai ?


Pas forcément. Le SQL c'est bien, mais pas partout :-) Et ça deviendrait 
vite illisible dans notre cas avec un festival de CASE et autres OUTER 
JOIN. Là on est sur de petits jeux de données, donc faire des 
traitements hors base, en script, n'a aucun impact sur les temps de 
réponses, mais surtout on gagne en souplesse.


On pourra revoir tout ça au moment de consolider un service façon 
cadastre.openstreetmap.fr, en attendant j'ai beaucoup bouchonné : 
fichiers plats pour le Fantoir, fichier plat pour la correspondance 
insee - id relation admin8. Tout ça changera évidemment. Par exemple 
je pense que si tu veux ouvrir une API Fantoir comme on disait 
récemment, ça sera directement utile.



J'ai une table abréviations qui me sert à le faire en automatique, sur
tout les mots (cf ma requête à rallonge d'hier).
Je dois pouvoir sortir la liste des id des ways, voire l'id de la
relation si elle existe, le code fantoir correspondant...

Par contre, il faudra aussi gérer les incohérences
cadastre/osm/terrain... sur mes tests à Perrigny (94) le cadastre a dans
une même rue, des adresses pour Chemin des Châtaigners et des adresses
pour Rue des Châtaigniers... incohérence dans leur données de parcelles.


Un cas qu'on rencontre : une impasse avec le même mot directeur qu'une 
rue, et qui se termine dans cette rue. Si on dégrade trop les noms faute 
de reconnaissance exacte, on va tout agréger dans une seule relation.



Je ne parle pas des erreurs de libellé par rapport aux plaques de rue.
Hier soir, je suis aller vérifier vers chez moi l'Avenue Vintimille ou
Avenue de Vintimille... il y a les deux plaques qui se font face dans la
rue !

Autre cas tordu... les rues limitrophes (plusieurs cas sur Nogent). Bien
sûr il faut jouer avec name:felt / name:right mais JOSM râle comme quoi
la rue est dans deux relations associatedStreet et que les noms ne
collent pas ;)


Oui, les cas tordus on en aura. Sans parler des manques ! Dans mes 
tests, j'étais étonné de ne pas matcher certaines rues à l'orthographe 
toute simple. Et en fait, c'est parce qu'elles n'existent pas dans OSM ! 
En centre ville de proche banlieue parisienne ça m'a calmé ;-)


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

[Vincent de Château-Thierry]

Bonsoir,

Le 19/01/2014 18:41, Tyndare a écrit :


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 ?


Oui, volontiers !


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 ?


C'est pile là-dessus que j'ai voulu avancer (un peu) aujourd'hui : grâce 
à la position des nodes, je télécharge les way highway=* dans l'emprise 
de la relation associatedStreet et je cherche à matcher les ways avec le 
même nom (aux écarts d'écriture qu'on connaît : accents, abrev., 
majuscules, etc.) histoire de placer l'ID des ways reconnus dans la 
relation, avec un rôle 'street'. Et quand ça matche, c'est le nom 
récupéré sur les ways qui devient le 'name' de la relation, plutôt que 
le nom du cadastre. Si ça ne matche pas, alors pas de rôle 'street' dans 
la relation, c'est lors de l'intégration qu'il faut aller piocher les 
bonnes portions de voie.
Pour avancer là-dessus, il faut que j'intègre le dictionnaire des 
abréviations de Christian, et que je télécharge les highways dans 
l'emprise d'une relation admin, afin de limiter les appels. Pour mes 
premiers tests je fais un appel par rue, ça pourra pas durer longtemps 
comme ça :-).


On avance et on s'amuse :-)

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

[Vincent de Château-Thierry]

Le 19/01/2014 19:28, Vincent de Château-Thierry a écrit :

Bonsoir,

Le 19/01/2014 18:41, Tyndare a écrit :


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 ?


Oui, volontiers !


Comme le fichier que tu produis a désormais les relations créées, je 
suis reparti de ça. Pour ce soir, je n'ai fait que revenir au stade 
d'hier, c'est à dire que je rapproche le contenu de ton fichier des 
données du Fantoir.
La sortie a un peu évolué en revanche : je génère un fichier par 
relation. Pour l'avoir testé hier, ça me semble l'unité de livraison la 
plus adequate. On peut toujours fusionner plusieurs fichiers dans JOSM 
facilement, en revanche splitter un fichier d'une commune en n petits 
fichiers est plus galère (de mon point de vue). Bref, à discuter.


Le script correspondant à ton nouveau format s'appelle addrfantoir.py, 
toujours ici : https://github.com/vdct/associatedStreet


Il nécessite un contenu Fantoir = voir le readme qui explique comment.


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 ?


C'est pile là-dessus que j'ai voulu avancer (un peu) aujourd'hui : grâce
à la position des nodes, je télécharge les way highway=* dans l'emprise
de la relation associatedStreet et je cherche à matcher les ways avec le
même nom (aux écarts d'écriture qu'on connaît : accents, abrev.,
majuscules, etc.) histoire de placer l'ID des ways reconnus dans la
relation, avec un rôle 'street'. Et quand ça matche, c'est le nom
récupéré sur les ways qui devient le 'name' de la relation, plutôt que
le nom du cadastre. Si ça ne matche pas, alors pas de rôle 'street' dans
la relation, c'est lors de l'intégration qu'il faut aller piocher les
bonnes portions de voie.
Pour avancer là-dessus, il faut que j'intègre le dictionnaire des
abréviations de Christian, et que je télécharge les highways dans
l'emprise d'une relation admin, afin de limiter les appels. Pour mes
premiers tests je fais un appel par rue, ça pourra pas durer longtemps
comme ça :-).


Sur le nommage correct de la relation et l'inclusion des membres 
'street', c'est à suivre.


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

[Vincent de Château-Thierry]

Bonjour,

Le 18/01/2014 09:07, Christian Quest a écrit :

On doit pouvoir automatiser ces différentes étapes:
- récupérer les nœuds adresses (fait)
- récupérer (en même temps) les parcelles
- trouver la parcelle la plus proche d'une adresse (fait)
- chercher son adresse (fait)
- regrouper les adresses par nom de voie (fait)
- reprendre l'identifiant FANTOIR
- regrouper les associatedStreet par FANTOIR
- sortir un magnifique .osm

C'est bien parti tout ça !

Vous voulez une petite API pour interroger FANTOIR ?
Sinon, à mouliner pour avoir ça sous forme d'une base SQlite locale
utilisée par le script.


Une API, si c'est pas trop de boulot pour toi, ce serait je pense le 
mieux, sachant 1) que la fourniture FANTOIR (fichier national de 800 Mo 
ou fichiers par depts zippés par région, g) n'est pas pratique, 2) 
que tu as déjà bossé dessus, et 3) que si un jour prochain tout ça se 
consolide j'imagine que ce sera sous la forme d'un outil osm-fr. Donc 
que des raisons pour l'API, vu de chez moi :-)


Comme requêtes, la basique me semble être la récupération en une fois de 
la liste de toutes les voies d'une commune, associées à leur code 
Fantoir. Ça me semble le plus pratique, en revanche quid du volume quand 
on parle d'une grande ville ? La requête prendrait en entrée le code de 
la ville donné par le cadastre.


Côté aval, pour livrer le résultat formaté en .osm, je me dis qu'un 
fichier par associatedStreet est la granularité préférable comparé à ce 
que j'ai commencé hier. Oui, ça fait beaucoup de fichiers mais ça incite 
à intégrer pas à pas, à l'inverse du fichier monobloc que certains 
auront toujours la tentation d'uploader d'un seul coup, alors que le 
premier travail sur ce fichier serait de le morceler. À moins 
d'organiser des paquets géographiques avec un nombre seuil d'adresses, 
en gardant intègres les relations bien sûr.


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

[Vincent de Château-Thierry]

Bonsoir,

Le 18/01/2014 18:10, Christian Quest a écrit :


Pour le reste, content que ça progresse, je pense qu'on va pouvoir
avancer nettement plus vite sur l'intégration d'adresses.
J'ai utilisé la récupération de nœuds pour mettre à jour Evry et
Créteil, mais aussi vérifier si il n'y avait pas quelques manques sur
les communes que je pensais avoir fait à 100% (Saint-Maur,
Fontenay-sous-Bois et quelques arrondissements parisiens).


J'ai continué sur le rapprochement avec le Fantoir, à partir d'extraits 
par communes (en attendant une API ?). Je n'ai testé que sur des villes 
de banlieue parisienne, dont certains gros morceaux comme Argenteuil où 
le match sur les noms entre Cadastre et Fantoir est à 100%. J'ai 
globalement de très bons résultats (souvent 100%), 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.


Comme parmi mes tests il y avait St-Maur, voici le lien :-) :
https://github.com/vdct/associatedStreet/blob/master/Z0068-parcelles-adresses_associatedStreet.osm

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

[Vincent de Château-Thierry]

Bonsoir,

Le 16/01/2014 12:24, Tyndare a écrit :


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.


J'ai utilisé le résultat de 
http://37.187.60.59/cadastre-housenumber/adresses.php pour fabriquer des 
relations associatedStreet. J'ai testé sur 3 communes et ça semble 
fonctionner. Pas grand mérite, vu que les fichiers 
parcelles-adresses.osm sont impecs en entrée :-)


Le script (python) et quelques explications ici :
https://github.com/vdct/associatedStreet
Vous y trouverez aussi le résultat du script pour Mulhouse.

Je n'ai pas cherché à combiner avec le Fantoir mais ça serait une des 
étapes suivantes, comme tu le suggérais. Une autre serait de placer les 
points d'adresse là où le cadastre les indique, et non au centre des 
parcelles. Dans tous les cas ça n'exempte par de les repositionner 
manuellement, mais le placement donné par le cadastre est plus intuitif 
que celui issu des parcelles.


Par ailleurs le script ne cherche pas à inclure de voie avec un rôle 
street, ça fait aussi partie du reste à faire (à la main).


vincent

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

Re: [OSM-dev-fr] Un utilisateur fantome

[Vincent de Château-Thierry]

Bonsoir,

Le 12/01/2014 21:46, Pierre Béland a écrit :

oups, tel que rapporté par Richar Weait, il existe des données. pour
interroger l'API, il fallait plutôt utiliser le lien
http://api.openstreetmap.org/api/0.6/changeset/19860227/download

Mais effectivement, l'usager n'existe pas. Étrange.


L'explication a ensuite été donnée par Tom Hughes : l'utilisateur à 
l'origine de ce changeset a demandé à ce que son compte soit effacé.


vincent

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

Re: [OSM-dev-fr] osm2psql what is wrong ?

[Vincent de Château-Thierry]

Le 23/12/2013 21:30, Vincent Pottier a écrit :

$ osm2pgsql -s -vl -U postgres -S
/home/vincent/Documents/cartographie/Data/styles/france.style -d osm -C
2000 /home/vincent/tmp/france.osm.pbf --prefix france
osm2pgsql SVN version 0.80.0 (64bit id space)

Using projection SRS 4326 (Latlong)
Couldn't open style file
'/home/vincent/Documents/cartographie/Data/styles/france.style':
Permission denied
Error occurred, cleaning up

Pourtant j'ai tout essayé en chmod et chown

ls me retourne
8 -rwxrw-rw-  1 postgres vincent 5693 nov.  13 18:40 france.style*


le '*' à la fin de la ligne, il fait partie du nom du fichier ?
Sinon dans la série c'est bidon mais ça coûte rien, une copie du 
fichier ailleurs et/ou sous un autre nom, puis recours au nouveau 
fichier avec osm2pgsql, ça dit quoi ?


vincent


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

Re: [OSM-dev-fr] Bug plugin cadastre JOSM

[Vincent de Château-Thierry]

Le 17/05/2013 10:57, Pieren a écrit :

2013/5/16 Cyrille Giquello cyrill...@gmail.com:


Je ne connais pas se problème, mais une piste: as tu essayer l'OpenJdk 7 ?


Quelqu'un avait signalé des problèmes avec openJdk. Mais il faut
tenter le coup. Sinon, il y a aussi quelqu'un qui avait des problèmes
avec la version 64bits de java mais c'était sur windows. Un autre test
à faire avec la version 32 bits, pour voir.



J'ai eu le même problème sous Windows 7 64 bits avec les planches raster 
: la première OK, impossible de charger les suivantes. Mais je n'ai pas 
creusé, car c'était avec le lanceur JNLP, alors qu'en local aucun souci. 
Du coup je suis revenu au local.


vincent

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