Re: [OSM-talk-fr] Publication OpenData du cadastre

2017-10-14 Par sujet Frédéric Rodrigo 
Je me suis lancé dans l'extraction et la compilation thématique des 
couches de données. Dans le but d'avoir des données découpées par 
thématiques et non par feuilles cadastrales.


Je n'ai volontairement pris que l'habillage (pas de parcelle, bâtiment 
et numéro de rue).


Le résultat est disponible là :
http://osm110.openstreetmap.fr/~fred/cadastre-2017-07-06-edigeo/
et là
https://www.data.gouv.fr/fr/datasets/58e5924b88ee3802ca255566/

Pour la description du schéma de données voir la "Documentation du 
standard EDIGÉO" sur data.gouv.fr.


Ce sont des consolidations des données brutes, je n'ai fait aucun 
traitement dessus mis à part l'ajout du code insee pour connaître la 
commune d'origine.


Attention, les fichiers sont gros.
L'extraction conversion à pris 6.5j (on doit pouvoir faire plus rapide...)

Frédéric.


Le 03/10/2017 à 14:47, Christian Quest a écrit :

Oui, officiellement dispo depuis hier... :)

Les données brutes de la DGFiP sont au format EDIGEO, format peu 
courant mais ouvrable avec gdal (donc QGis).


Dans cette première livraison, Etalab propose une extraction des 
principales couches d'infos surfaciques remise au format geojson en 
WGS84: limites de communes, de section cadastrale, de parcelle, et 
l'emprise des bâtiments.


Des données sont téléchargeables par département et par communes pour 
les geojson et par département et feuille cadastrale pour l'EDIGEO.


Ces données seront mises à jour trimestriellement.


Les nouveautés à venir pour les contributeurs:

- la prochaine version de JOSM va pouvoir ouvrir directement les 
fichier EDIGEO de la DGFiP.
- l'extraction du bâti de cadastre.openstreetmap.fr 
 deviennent en partie inutiles
- les script d'extraction d'adresses de cadastre.openstreetmap.fr 
 et de BANO vont aussi pouvoir 
évoluer prochainement.


Il y a d'autres données provenant du cadastre qui seront bientôt 
disponibles:

- le PCI Image et  les localisants de parcelles
- l'historique des évolutions des parcelles (la parcelles XXX est 
séparée en YYY et ZZZ)



Les fichiers EDIGEO permettent bien plus que ce qu'on a pu faire 
jusqu'à maintenant. On a par exemple les dates de création et de 
dernière modification des objets.
On y trouve aussi des filaires portant les noms des voies pour 
l'habillage des plan... j'ai commencé à travailler dessus pour les 
rapprocher de FANTOIR, il se peut que ce type de traitement soit fait 
sur les données mises à disposition par Etalab en geojson.
D'autres traitements sont aussi envisagés par Etalab pour améliorer 
les données, les lier à d'autres, etc. Ceci devrait arriver d'ici la 
fin de l'année.


Etalab va aussi mettre en place des API pour interroger ces données, 
comme ça a pu être fait en mettant en place un géocodeur pour 
faciliter la réutilisation de la BAN.



Il mes semble utile qu'on réfléchisse ensemble au meilleur moyen 
d'exploiter ces données et surtout de le penser dans le long terme 
pour les mises à jour. Pour cela, évitons de nous précipiter sur des 
imports à partir de ces données pour l'instant très brutes.
Ces données font parti du "Service Public de la Donnée de Référence" 
dont le slogan est "Des données sur lesquelles vous pouvez compter"... 
c'est donc là pour longtemps ;)



Le 3 octobre 2017 à 14:20, David Marchal > a écrit :


Cher tous,


Je viens de voir que le cadastre, en tout cas certaines
informations, viennent d’être publiées en OpenData, et en
vectoriel, s’il vous plaît :

https://www.nextinpact.com/brief/le-cadastre-est-accessible-en-open-data-329.htm


 Sans
doute ce que Christian Quest disait être dans les tuyaux.
D’emblée, je vois l’utilisation du GeoJSON pour l’importation du
bâti, mais on doit pouvoir en tirer beaucoup plus. Merci à la
DGFiP et à Etalab pour ça, ça devrait nous aider.


Cordialement.


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





--
Christian Quest - OpenStreetMap France


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




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

Re: [OSM-talk-fr] Publication OpenData du cadastre

2017-10-12 Par sujet Vincent Privat 
Hello,
Si vous constatez des bugs du support geojson dans JOSM merci de les
remonter ici: https://github.com/JOSM/geojson/issues
A+
Vincent

Le 12 octobre 2017 à 12:04, Christian Quest <cqu...@openstreetmap.fr> a
écrit :

> C'est un comportement habituel (bug pour moi) de JOSM avec les geojson, et
> pas spécifique aux fichiers du cadastre à ce qu'il me semble.
>
> Le 12/10/2017 à 10:49, David Marchal a écrit :
>
> Bonjour.
>
>
> En effet, j’ai résolu les problèmes, mais, si ça peut être automatisé,
> autant le faire, je pense, non ?
>
>
> Cordialement.
>
>
> --
> *De :* HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE APPUI
> PERFORMANCE) <denis.hel...@reseau.sncf.fr> <denis.hel...@reseau.sncf.fr>
> *Envoyé :* mercredi 11 octobre 2017 09:09
> *À :* Discussions sur OSM en français
> *Objet :* Re: [OSM-talk-fr] Publication OpenData du cadastre
>
>
> Hello,
>
>
>
> Tu sélectionnes  tous tes objets avec type :way puis tu demandes la
>  validation  des objets puis la réparation et hop JOSM ne râle plus
>
>
>
> *De :* David Marchal [mailto:pene...@live.fr <pene...@live.fr>]
> *Envoyé :* mercredi 11 octobre 2017 08:33
> *À :* Discussions sur OSM en français <talk-fr@openstreetmap.org>
> <talk-fr@openstreetmap.org>
> *Objet :* Re: [OSM-talk-fr] Publication OpenData du cadastre
>
>
>
> Bonjour.
>
>
>
> Je viens de remarquer un bug sur l’import du GéoJSON du bâti : les
> polygones des bâtiments ne sont pas fermés, ce qui fait hurler JOSM ;
> apparemment, les bâtiments sont constitués d’une ligne dont le premier et
> le dernier point ont les mêmes coordonnées, mais ne sont pas le même point.
> Pour JOSM, le polygone n’est pas fermé.
>
>
>
> Cordialement.
>
>
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Publication OpenData du cadastre

2017-10-12 Par sujet Christian Quest 
C'est un comportement habituel (bug pour moi) de JOSM avec les geojson, 
et pas spécifique aux fichiers du cadastre à ce qu'il me semble.



Le 12/10/2017 à 10:49, David Marchal a écrit :


Bonjour.


En effet, j’ai résolu les problèmes, mais, si ça peut être automatisé, 
autant le faire, je pense, non ?



Cordialement.




*De :* HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE APPUI 
PERFORMANCE) <denis.hel...@reseau.sncf.fr>

*Envoyé :* mercredi 11 octobre 2017 09:09
*À :* Discussions sur OSM en français
*Objet :* Re: [OSM-talk-fr] Publication OpenData du cadastre

Hello,

Tu sélectionnes  tous tes objets avec type :way puis tu demandes la 
 validation  des objets puis la réparation et hop JOSM ne râle plus


*De :*David Marchal [mailto:pene...@live.fr]
*Envoyé :* mercredi 11 octobre 2017 08:33
*À :* Discussions sur OSM en français <talk-fr@openstreetmap.org>
*Objet :* Re: [OSM-talk-fr] Publication OpenData du cadastre

Bonjour.

Je viens de remarquer un bug sur l’import du GéoJSON du bâti : les 
polygones des bâtiments ne sont pas fermés, ce qui fait hurler JOSM ; 
apparemment, les bâtiments sont constitués d’une ligne dont le premier 
et le dernier point ont les mêmes coordonnées, mais ne sont pas le 
même point. Pour JOSM, le polygone n’est pas fermé.


Cordialement.




--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] Publication OpenData du cadastre

2017-10-12 Par sujet David Marchal 
Bonjour.


En effet, j’ai résolu les problèmes, mais, si ça peut être automatisé, autant 
le faire, je pense, non ?


Cordialement.



De : HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE APPUI PERFORMANCE) 
<denis.hel...@reseau.sncf.fr>
Envoyé : mercredi 11 octobre 2017 09:09
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Publication OpenData du cadastre


Hello,



Tu sélectionnes  tous tes objets avec type :way puis tu demandes la  validation 
 des objets puis la réparation et hop JOSM ne râle plus



De : David Marchal [mailto:pene...@live.fr]
Envoyé : mercredi 11 octobre 2017 08:33
À : Discussions sur OSM en français <talk-fr@openstreetmap.org>
Objet : Re: [OSM-talk-fr] Publication OpenData du cadastre



Bonjour.



Je viens de remarquer un bug sur l’import du GéoJSON du bâti : les polygones 
des bâtiments ne sont pas fermés, ce qui fait hurler JOSM ; apparemment, les 
bâtiments sont constitués d’une ligne dont le premier et le dernier point ont 
les mêmes coordonnées, mais ne sont pas le même point. Pour JOSM, le polygone 
n’est pas fermé.



Cordialement.





De : Vincent Privat <vincent.pri...@gmail.com<mailto:vincent.pri...@gmail.com>>
Envoyé : mardi 3 octobre 2017 23:34
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Publication OpenData du cadastre



Hello,

Quelques compléments d'info sur JOSM.

Le support du cadastre est disponible, il faut utiliser la toute dernière 
version stable (12921) de JOSM et la version 33690 du greffon cadastre-fr.

J'ai annoncé la nouvelle version du greffon il y a quelques jours sur la liste 
dev-fr, et on en a parlé aussi au dernier meeting toulousain, j'ai déjà corrigé 
quelques soucis de jeunesse suite aux tests préliminaires des mappeurs 
toulousains :)



Le greffon permet d'ouvrir les lots Edigéo via file/open, file/open location, 
ou en drag, soit de l'archive tar.bz2, soit du fichier .THF.

Les géométries sont automatiquement simplifiées pour éviter d'avoir des 
piscines avec 500 nœuds. Le souci des bâtiments coupés en 2 au milieu d'une 
limite de parcelle ne se pose pas, vu qu'il s'agit des géométries natives du 
cadastre (sauf dans les cas de bâtiments à cheval sur plusieurs planches).

Actuellement sont chargés le bâti, les limites administratives, les parcelles & 
sections, les adresses, la voirie, et diverses autres choses (puits, pylônes, 
cimetières, bâtiment de culte, etc.). Tout est sourcé avec le tag habituel 
"cadastre-fr ... DGFiP 2017 etc.".

Ne sont pas chargés: les infos de mitoyenneté (mur, fossé) parce que 
représentées par un nœud, et les choses qui sont bizarrement regroupées dans le 
cadastre telles que "terrains de sport et petits ruisseaux" (WTF?!), ou bien 
"parking, terrasse, surplomb", etc.

Pour les curieux la correspondance entre les données du cadastre et les tags 
OSM se fait ici:

https://github.com/openstreetmap/josm-plugins/blob/master/cadastre-fr/src/org/openstreetmap/josm/plugins/fr/cadastre/edigeo/pci/EdigeoPciReader.java#L37

[https://avatars1.githubusercontent.com/u/261431?v=4=400]<https://github.com/openstreetmap/josm-plugins/blob/master/cadastre-fr/src/org/openstreetmap/josm/plugins/fr/cadastre/edigeo/pci/EdigeoPciReader.java#L37>


openstreetmap/josm-plugins<https://github.com/openstreetmap/josm-plugins/blob/master/cadastre-fr/src/org/openstreetmap/josm/plugins/fr/cadastre/edigeo/pci/EdigeoPciReader.java#L37>

github.com

josm-plugins - Mirror of the JOSM plugin repository in Subversion






Les calques chargés ainsi dans JOSM sont flaggués "envoi dissuadé". C'est à 
dire: JOSM va vous crier dessus si vous essayez d'envoyer ces données vers OSM, 
pour sensibiliser tout le monde qu'il y a un gros travail de vérification & 
d'intégration à mener avant de faire ça. Si je vois qu'il y a des dérives et 
des imports massifs sans travail préalable, je basculerai rapidement en mode 
"envoi interdit", ce qui bloquera complètement l'envoi direct à partir de ces 
calques.



Il me manque à exploiter la date de dernière mise à jour (je pense à la mettre 
dans un tag source:date).



J'attends l'API Etalab avec impatience, ça permettra à JOSM de télécharger les 
données du cadastre pour une zone donnée (actuellement il faut connaître le 
numéro de planche du cadastre).



Si vous trouvez des bugs n'hésitez pas à me les remonter :)



A+

Vincent











Le 3 octobre 2017 à 14:47, Christian Quest 
<cqu...@openstreetmap.fr<mailto:cqu...@openstreetmap.fr>> a écrit :

Oui, officiellement dispo depuis hier... :)



Les données brutes de la DGFiP sont au format EDIGEO, format peu courant mais 
ouvrable avec gdal (donc QGis).



Dans cette première livraison, Etalab propose une extraction des principales 
couches d'infos surfaciques remise au format geojson en WGS84: limites de 
communes, de section cadastrale, de parcelle

Re: [OSM-talk-fr] Publication OpenData du cadastre

2017-10-11 Par sujet Philippe Verdy 
Le 11 octobre 2017 à 08:32, David Marchal  a écrit :

> Bonjour.
>
>
> Je viens de remarquer un bug sur l’import du GéoJSON du bâti : les
> polygones des bâtiments ne sont pas fermés, ce qui fait hurler JOSM ;
> apparemment, les bâtiments sont constitués d’une ligne dont le premier et
> le dernier point ont les mêmes coordonnées, mais ne sont pas le même point.
> Pour JOSM, le polygone n’est pas fermé.
>

Ce n'est PAS un bogue du GeoJSON fourni mais une limite de ce format qui ne
code pas les noeuds membres d'un way comme des entités séparées mais
représente les polygones fermés en indiquant seulement les même coordonnées
de fin que celle du début (ce n'est pas une obligation cependant car les
types "Polygon" et "MultiPolygon" d'un GeoJSON ne contiennent QUE des
chemins fermés pour représenter des surfaces, éventuellement avec des
"trous", et la fermeture est donc implicite; les chemins ouverts sont codés
en GeoJSON avec les types "LineString" ou "MultiLineString" pour les
graphes de lignes non nécessairement continues entre elles ; un "Polygon"
représente une surface connexe éventuellement trouée, un "MultiPolygon"
représente plusieurs de ces surfaces, par exemple des îles, y compris des
enclaves incluses dans une surface trouée et sans connexion de ces enclaves
avec la surface englobante)

Bref ce n'est pas une anomalie du fichier cadastral.

C'est plutôt un bogue (une limite) de l'extension d'import de GeoJSON, qui
crée des objets noeuds séparés pour chaque paire de coordonnées [x,y] dans
le GeoJSON sans les fusionner quand elles sont identiques.

C'est très facile à régler cependant: une fois le GeoJSON chargé, cliquer
sur "Valider" et le validateur de JOSM trouvera tous les noeuds superposés
créés par le plugin d'import de GeoJSON. Sélectionner ce groupe, et cliquer
sur "Corriger" pour fusionner un un clic ces noeuds.

Une autre limitation de l'import de GeoJSON dans JOSM est qu'un attribut
OSM "area=yes" n'est pas automatiquement ajouté à chacun des "Polygon"
GeoJSON importés: la surface importée devient alors une simple "ligne" dans
JOSM.

L'import de GeonJSON ne crée une relation OSM "type=multipolygon" que si un
des Polygon est "troué" (donc quand un "Polygon" contient plus d'un élément
dans son tableau "coordinates": le premier élément du tableau prendra dans
la relation créée par le plugin un rôle OSM "outer", et les suivants auront
un rôle OSM "inner"; dans un MultiPolygon, c'est le nombre d'éléments au
second niveau d'indice qui détermine si une relation OSM
"type=multipolygon" sera créée ou pas, un Multipolygone pouvant contenir
plusieurs "Polygon" troués ou pas...).

Pour un "MultiLineString" GeoJSON, le plugin d'import dans JOSM ne crée
aucune relation OSM "type=multipolygon", il crée juste des ways OSM séparés
(et là encore sans tenter de fusionner les noeuds superposés.

Bref GeoJSON représente différemment les géométries.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Publication OpenData du cadastre

2017-10-11 Par sujet HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE APPUI PERFORMANCE) 
Hello,

Tu sélectionnes  tous tes objets avec type :way puis tu demandes la  validation 
 des objets puis la réparation et hop JOSM ne râle plus

De : David Marchal [mailto:pene...@live.fr]
Envoyé : mercredi 11 octobre 2017 08:33
À : Discussions sur OSM en français <talk-fr@openstreetmap.org>
Objet : Re: [OSM-talk-fr] Publication OpenData du cadastre


Bonjour.



Je viens de remarquer un bug sur l’import du GéoJSON du bâti : les polygones 
des bâtiments ne sont pas fermés, ce qui fait hurler JOSM ; apparemment, les 
bâtiments sont constitués d’une ligne dont le premier et le dernier point ont 
les mêmes coordonnées, mais ne sont pas le même point. Pour JOSM, le polygone 
n’est pas fermé.



Cordialement.


De : Vincent Privat <vincent.pri...@gmail.com<mailto:vincent.pri...@gmail.com>>
Envoyé : mardi 3 octobre 2017 23:34
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Publication OpenData du cadastre

Hello,
Quelques compléments d'info sur JOSM.
Le support du cadastre est disponible, il faut utiliser la toute dernière 
version stable (12921) de JOSM et la version 33690 du greffon cadastre-fr.
J'ai annoncé la nouvelle version du greffon il y a quelques jours sur la liste 
dev-fr, et on en a parlé aussi au dernier meeting toulousain, j'ai déjà corrigé 
quelques soucis de jeunesse suite aux tests préliminaires des mappeurs 
toulousains :)

Le greffon permet d'ouvrir les lots Edigéo via file/open, file/open location, 
ou en drag, soit de l'archive tar.bz2, soit du fichier .THF.
Les géométries sont automatiquement simplifiées pour éviter d'avoir des 
piscines avec 500 nœuds. Le souci des bâtiments coupés en 2 au milieu d'une 
limite de parcelle ne se pose pas, vu qu'il s'agit des géométries natives du 
cadastre (sauf dans les cas de bâtiments à cheval sur plusieurs planches).
Actuellement sont chargés le bâti, les limites administratives, les parcelles & 
sections, les adresses, la voirie, et diverses autres choses (puits, pylônes, 
cimetières, bâtiment de culte, etc.). Tout est sourcé avec le tag habituel 
"cadastre-fr ... DGFiP 2017 etc.".
Ne sont pas chargés: les infos de mitoyenneté (mur, fossé) parce que 
représentées par un nœud, et les choses qui sont bizarrement regroupées dans le 
cadastre telles que "terrains de sport et petits ruisseaux" (WTF?!), ou bien 
"parking, terrasse, surplomb", etc.
Pour les curieux la correspondance entre les données du cadastre et les tags 
OSM se fait ici:
https://github.com/openstreetmap/josm-plugins/blob/master/cadastre-fr/src/org/openstreetmap/josm/plugins/fr/cadastre/edigeo/pci/EdigeoPciReader.java#L37
[https://avatars1.githubusercontent.com/u/261431?v=4=400]<https://github.com/openstreetmap/josm-plugins/blob/master/cadastre-fr/src/org/openstreetmap/josm/plugins/fr/cadastre/edigeo/pci/EdigeoPciReader.java#L37>

openstreetmap/josm-plugins<https://github.com/openstreetmap/josm-plugins/blob/master/cadastre-fr/src/org/openstreetmap/josm/plugins/fr/cadastre/edigeo/pci/EdigeoPciReader.java#L37>
github.com
josm-plugins - Mirror of the JOSM plugin repository in Subversion



Les calques chargés ainsi dans JOSM sont flaggués "envoi dissuadé". C'est à 
dire: JOSM va vous crier dessus si vous essayez d'envoyer ces données vers OSM, 
pour sensibiliser tout le monde qu'il y a un gros travail de vérification & 
d'intégration à mener avant de faire ça. Si je vois qu'il y a des dérives et 
des imports massifs sans travail préalable, je basculerai rapidement en mode 
"envoi interdit", ce qui bloquera complètement l'envoi direct à partir de ces 
calques.

Il me manque à exploiter la date de dernière mise à jour (je pense à la mettre 
dans un tag source:date).

J'attends l'API Etalab avec impatience, ça permettra à JOSM de télécharger les 
données du cadastre pour une zone donnée (actuellement il faut connaître le 
numéro de planche du cadastre).

Si vous trouvez des bugs n'hésitez pas à me les remonter :)

A+
Vincent





Le 3 octobre 2017 à 14:47, Christian Quest 
<cqu...@openstreetmap.fr<mailto:cqu...@openstreetmap.fr>> a écrit :
Oui, officiellement dispo depuis hier... :)

Les données brutes de la DGFiP sont au format EDIGEO, format peu courant mais 
ouvrable avec gdal (donc QGis).

Dans cette première livraison, Etalab propose une extraction des principales 
couches d'infos surfaciques remise au format geojson en WGS84: limites de 
communes, de section cadastrale, de parcelle, et l'emprise des bâtiments.

Des données sont téléchargeables par département et par communes pour les 
geojson et par département et feuille cadastrale pour l'EDIGEO.

Ces données seront mises à jour trimestriellement.


Les nouveautés à venir pour les contributeurs:

- la prochaine version de JOSM va pouvoir ouvrir directement les fichier EDIGEO 
de la DGFiP.
- l'extraction du bâti de 
cadastre.openstreetmap.fr<http://cadastre.openstreetmap.fr&

Re: [OSM-talk-fr] Publication OpenData du cadastre

2017-10-11 Par sujet David Marchal 
Bonjour.


Je viens de remarquer un bug sur l’import du GéoJSON du bâti : les polygones 
des bâtiments ne sont pas fermés, ce qui fait hurler JOSM ; apparemment, les 
bâtiments sont constitués d’une ligne dont le premier et le dernier point ont 
les mêmes coordonnées, mais ne sont pas le même point. Pour JOSM, le polygone 
n’est pas fermé.


Cordialement.



De : Vincent Privat <vincent.pri...@gmail.com>
Envoyé : mardi 3 octobre 2017 23:34
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Publication OpenData du cadastre

Hello,
Quelques compléments d'info sur JOSM.
Le support du cadastre est disponible, il faut utiliser la toute dernière 
version stable (12921) de JOSM et la version 33690 du greffon cadastre-fr.
J'ai annoncé la nouvelle version du greffon il y a quelques jours sur la liste 
dev-fr, et on en a parlé aussi au dernier meeting toulousain, j'ai déjà corrigé 
quelques soucis de jeunesse suite aux tests préliminaires des mappeurs 
toulousains :)

Le greffon permet d'ouvrir les lots Edigéo via file/open, file/open location, 
ou en drag, soit de l'archive tar.bz2, soit du fichier .THF.
Les géométries sont automatiquement simplifiées pour éviter d'avoir des 
piscines avec 500 nœuds. Le souci des bâtiments coupés en 2 au milieu d'une 
limite de parcelle ne se pose pas, vu qu'il s'agit des géométries natives du 
cadastre (sauf dans les cas de bâtiments à cheval sur plusieurs planches).
Actuellement sont chargés le bâti, les limites administratives, les parcelles & 
sections, les adresses, la voirie, et diverses autres choses (puits, pylônes, 
cimetières, bâtiment de culte, etc.). Tout est sourcé avec le tag habituel 
"cadastre-fr ... DGFiP 2017 etc.".
Ne sont pas chargés: les infos de mitoyenneté (mur, fossé) parce que 
représentées par un nœud, et les choses qui sont bizarrement regroupées dans le 
cadastre telles que "terrains de sport et petits ruisseaux" (WTF?!), ou bien 
"parking, terrasse, surplomb", etc.
Pour les curieux la correspondance entre les données du cadastre et les tags 
OSM se fait ici:
https://github.com/openstreetmap/josm-plugins/blob/master/cadastre-fr/src/org/openstreetmap/josm/plugins/fr/cadastre/edigeo/pci/EdigeoPciReader.java#L37
[https://avatars1.githubusercontent.com/u/261431?v=4=400]<https://github.com/openstreetmap/josm-plugins/blob/master/cadastre-fr/src/org/openstreetmap/josm/plugins/fr/cadastre/edigeo/pci/EdigeoPciReader.java#L37>

openstreetmap/josm-plugins<https://github.com/openstreetmap/josm-plugins/blob/master/cadastre-fr/src/org/openstreetmap/josm/plugins/fr/cadastre/edigeo/pci/EdigeoPciReader.java#L37>
github.com
josm-plugins - Mirror of the JOSM plugin repository in Subversion



Les calques chargés ainsi dans JOSM sont flaggués "envoi dissuadé". C'est à 
dire: JOSM va vous crier dessus si vous essayez d'envoyer ces données vers OSM, 
pour sensibiliser tout le monde qu'il y a un gros travail de vérification & 
d'intégration à mener avant de faire ça. Si je vois qu'il y a des dérives et 
des imports massifs sans travail préalable, je basculerai rapidement en mode 
"envoi interdit", ce qui bloquera complètement l'envoi direct à partir de ces 
calques.

Il me manque à exploiter la date de dernière mise à jour (je pense à la mettre 
dans un tag source:date).

J'attends l'API Etalab avec impatience, ça permettra à JOSM de télécharger les 
données du cadastre pour une zone donnée (actuellement il faut connaître le 
numéro de planche du cadastre).

Si vous trouvez des bugs n'hésitez pas à me les remonter :)

A+
Vincent





Le 3 octobre 2017 à 14:47, Christian Quest 
<cqu...@openstreetmap.fr<mailto:cqu...@openstreetmap.fr>> a écrit :
Oui, officiellement dispo depuis hier... :)

Les données brutes de la DGFiP sont au format EDIGEO, format peu courant mais 
ouvrable avec gdal (donc QGis).

Dans cette première livraison, Etalab propose une extraction des principales 
couches d'infos surfaciques remise au format geojson en WGS84: limites de 
communes, de section cadastrale, de parcelle, et l'emprise des bâtiments.

Des données sont téléchargeables par département et par communes pour les 
geojson et par département et feuille cadastrale pour l'EDIGEO.

Ces données seront mises à jour trimestriellement.


Les nouveautés à venir pour les contributeurs:

- la prochaine version de JOSM va pouvoir ouvrir directement les fichier EDIGEO 
de la DGFiP.
- l'extraction du bâti de 
cadastre.openstreetmap.fr<http://cadastre.openstreetmap.fr> deviennent en 
partie inutiles
- les script d'extraction d'adresses de 
cadastre.openstreetmap.fr<http://cadastre.openstreetmap.fr> et de BANO vont 
aussi pouvoir évoluer prochainement.

Il y a d'autres données provenant du cadastre qui seront bientôt disponibles:
- le PCI Image et  les localisants de parcelles
- l'historique des évolutions des parcelles (la parcelles XXX est séparée en 
YYY et ZZZ)


Le

Re: [OSM-talk-fr] Publication OpenData du cadastre

2017-10-05 Par sujet David Marchal 


> Le 4 oct. 2017 à 18:28, Christian Quest  a écrit :
> 
> Le 04/10/2017 à 16:30, David Marchal a écrit :
>> * un truc qu’on perd, je trouve, ou alors je n’ai pas compris comment 
>> l’avoir : on ne peut plus connaître l’étendue d’un lieu-dit, ni son code 
>> FANTOIR d’ailleurs, avec les nouvelles données, car on perd le lien entre 
>> l’étiquette du lieu-dit et son emprise, et ces données ne contiennent pas le 
>> FANTOIR ;
> 
> Il y a une couche correspondant aux emprises des lieux-dits, par contre, tout 
> comme les filaires de voirie, il n'y a pas de lien avec FANTOIR... là aussi, 
> un retraitement intermédiaire serait plus utile qu'un accès direct depuis 
> JOSM.
Je crains de ne pas avoir trouvé laquelle ; j’ai trouvé les fichiers pour les 
limites de sections, de feuilles et de communes, mais pas un pour les limites 
de lieux-dits, qui sont apparemment à plusieurs par section, mais je peux me 
tromper. En plus, comme, autant que je sache, les étiquettes de lieu-dit sont 
rarement au barycentre du polygone alors que c’est censé être le cas pour 
l’import sur OSM, si on perd le lien entre l’étiquette et la limite, on a 
beaucoup de mal à vérifier le placement du nœud place=*.
> 
>> * une autre amélioration possible : si la relation des frontières de la 
>> commune est présente, donner la possibilité de télécharger en un clic tout 
>> ou partie des données publiées pour la commune, grâce au code INSEE présent 
>> dans la relation ;
> 
> Dans quel but ? Pour affichage ou pour retravailler dessus et upload ?
> Vu le volume je crains qu'on fasse de l'import sans réel affinage des données.
Pour affichage, pas pour de l’import massif, surtout sans travail dessus. 
Actuellement, il faut télécharger les différentes données manuellement, mais ça 
devrait pouvoir être automatisé si on a le code INSEE.

> Il me semble utile d'expérimenter et d'explorer ces données, mais d'être très 
> prudent dans un premier temps sur la ré-utilisation qu'on peut en faire.
> 
> Il est urgent d'attendre un peu, surtout que pas mal d'autres choses 
> devraient arriver à courte échéance et qui rendra sûrement l'exploitation des 
> EDIGEO moins intéressante.
> 
> -- 
> Christian Quest - OpenStreetMap France
Cordialement.

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

Re: [OSM-talk-fr] Publication OpenData du cadastre

2017-10-04 Par sujet ades_...@orange.fr 
signalé dans un post voisin, je n’avait pas encore vu ce fil.
Le cadastre proposé semble très moyen ;-) pour ce qui concerne le bâti. des 
édifices nettement différencié sur car.gouv.fr sont regroupé en un seul, que ce 
soit en jsom ou en edigeo… à prendre avec des pincettes donc… ??
> Le 4 oct. 2017 à 18:28, Christian Quest  a écrit :
> 
> 

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

Re: [OSM-talk-fr] Publication OpenData du cadastre

2017-10-04 Par sujet Christian Quest 

Le 04/10/2017 à 16:30, David Marchal a écrit :


Bonjour.

Merci pour le travail déjà fait sur le support ; après un rapide coup d’œil, 
j’ai quelques retours :
* le plugin pourrait-il prémâcher les tags des bâtiments du GeoJSON, par 
exemple en mettant directement building=yes, source=… et wall=no sur les 
polygones ? Il semble que, pour ces polygones, le tag type vaille 02 pour un 
bâtiment léger, et 01 pour les autres, mais il vaudrait sans doute mieux 
demander confirmation à l’Etalab ;


C'est bien ça et toute la doc concernant les fichiers EDIGEO est disponible:

https://www.data.gouv.fr/s/resources/plan-cadastral-informatise/20170906-150737/standard_edigeo_2013.pdf


* la création de highway=residential avec le cadastre est une bonne idée quand 
les voies n’existent pas déjà ; toutefois, en milieu rural, là où les données 
seront le plus susceptibles d’être importées dans OSM, ce sera plus souvent des 
chemins que des rues, donc peut-être que highway=track serait plus approprié ? 
Sinon, highway=road ; en plus, cela attirerait l’attention du contributeur sur 
ces chemins qu’il essaierait d’envoyer dans OSM sans les avoir vérifiés au 
préalable, puisque jOSM n’aime pas envoyer des highway=road ;


A mon avis ces géométries (couche zoncommuni) ne devraient être 
qu'indicatives et utilisées par des bot de comparaison. Elle sont 
parfois incohérentes (un seul linestring pour plusieurs rues). A mettre 
de côté pour l'instant à mon avis.



* un truc qu’on perd, je trouve, ou alors je n’ai pas compris comment l’avoir : 
on ne peut plus connaître l’étendue d’un lieu-dit, ni son code FANTOIR 
d’ailleurs, avec les nouvelles données, car on perd le lien entre l’étiquette 
du lieu-dit et son emprise, et ces données ne contiennent pas le FANTOIR ;


Il y a une couche correspondant aux emprises des lieux-dits, par contre, 
tout comme les filaires de voirie, il n'y a pas de lien avec FANTOIR... 
là aussi, un retraitement intermédiaire serait plus utile qu'un accès 
direct depuis JOSM.




* une autre amélioration possible : si la relation des frontières de la commune 
est présente, donner la possibilité de télécharger en un clic tout ou partie 
des données publiées pour la commune, grâce au code INSEE présent dans la 
relation ;


Dans quel but ? Pour affichage ou pour retravailler dessus et upload ?
Vu le volume je crains qu'on fasse de l'import sans réel affinage des 
données.




* les emprises de rivières sont importées comme waterway=riverbank, or il me 
semble que ce schéma est déprécié et en perte de vitesse par rapport à 
natural=water+water=river, qu’alors il vaudrait sans doute mieux utiliser. 
Sinon, mettre seulement natural=water seul ; comme ça, cela éviterait de mettre 
des tags erronés sur les étangs, s’ils ont les mêmes : au lieu d’avoir des tags 
erronés sur les étangs, on aurait des tags à préciser sur tous les polygones. 
Dommage que le sens d’écoulement manque dans ces données, ça aurait pu 
permettre un import direct d’un chemin waterway=stream/ditch/river…


Là aussi c'est de l'habillage et pas forcément très à jour. On avait 
d'ailleurs suspendu la génération de cette couche sur cadastre.gouv.fr 
vu la mauvaise qualité par rapport à ce qu'on constate sur le terrain.



Attention, je dis tout ça naïvement, sans savoir ce que ça représente comme 
travail de développement. Quoi qu’il en soit, déjà un bon boulot de fait ; 
merci Vincent et Christian pour ces avancées.



Il me semble utile d'expérimenter et d'explorer ces données, mais d'être 
très prudent dans un premier temps sur la ré-utilisation qu'on peut en 
faire.


Il est urgent d'attendre un peu, surtout que pas mal d'autres choses 
devraient arriver à courte échéance et qui rendra sûrement 
l'exploitation des EDIGEO moins intéressante.


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Publication OpenData du cadastre

2017-10-04 Par sujet David Marchal 
Bonjour.

Merci pour le travail déjà fait sur le support ; après un rapide coup d’œil, 
j’ai quelques retours :
* le plugin pourrait-il prémâcher les tags des bâtiments du GeoJSON, par 
exemple en mettant directement building=yes, source=… et wall=no sur les 
polygones ? Il semble que, pour ces polygones, le tag type vaille 02 pour un 
bâtiment léger, et 01 pour les autres, mais il vaudrait sans doute mieux 
demander confirmation à l’Etalab ;
* la création de highway=residential avec le cadastre est une bonne idée quand 
les voies n’existent pas déjà ; toutefois, en milieu rural, là où les données 
seront le plus susceptibles d’être importées dans OSM, ce sera plus souvent des 
chemins que des rues, donc peut-être que highway=track serait plus approprié ? 
Sinon, highway=road ; en plus, cela attirerait l’attention du contributeur sur 
ces chemins qu’il essaierait d’envoyer dans OSM sans les avoir vérifiés au 
préalable, puisque jOSM n’aime pas envoyer des highway=road ;
* un truc qu’on perd, je trouve, ou alors je n’ai pas compris comment l’avoir : 
on ne peut plus connaître l’étendue d’un lieu-dit, ni son code FANTOIR 
d’ailleurs, avec les nouvelles données, car on perd le lien entre l’étiquette 
du lieu-dit et son emprise, et ces données ne contiennent pas le FANTOIR ;
* une autre amélioration possible : si la relation des frontières de la commune 
est présente, donner la possibilité de télécharger en un clic tout ou partie 
des données publiées pour la commune, grâce au code INSEE présent dans la 
relation ;
* les emprises de rivières sont importées comme waterway=riverbank, or il me 
semble que ce schéma est déprécié et en perte de vitesse par rapport à 
natural=water+water=river, qu’alors il vaudrait sans doute mieux utiliser. 
Sinon, mettre seulement natural=water seul ; comme ça, cela éviterait de mettre 
des tags erronés sur les étangs, s’ils ont les mêmes : au lieu d’avoir des tags 
erronés sur les étangs, on aurait des tags à préciser sur tous les polygones. 
Dommage que le sens d’écoulement manque dans ces données, ça aurait pu 
permettre un import direct d’un chemin waterway=stream/ditch/river…

Attention, je dis tout ça naïvement, sans savoir ce que ça représente comme 
travail de développement. Quoi qu’il en soit, déjà un bon boulot de fait ; 
merci Vincent et Christian pour ces avancées.

Cordialement.


De : Vincent Privat <vincent.pri...@gmail.com>
Envoyé : mardi 3 octobre 2017 23:34
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Publication OpenData du cadastre
  

Hello,
Quelques compléments d'info sur JOSM.
Le support du cadastre est disponible, il faut utiliser la toute dernière 
version stable (12921) de JOSM et la version 33690 du greffon cadastre-fr.
J'ai annoncé la nouvelle version du greffon il y a quelques jours sur la liste 
dev-fr, et on en a parlé aussi au dernier meeting toulousain, j'ai déjà corrigé 
quelques soucis de jeunesse suite aux tests préliminaires des mappeurs 
toulousains :)



Le greffon permet d'ouvrir les lots Edigéo via file/open, file/open location, 
ou en drag, soit de l'archive tar.bz2, soit du fichier .THF.
Les géométries sont automatiquement simplifiées pour éviter d'avoir des 
piscines avec 500 nœuds. Le souci des bâtiments coupés en 2 au milieu d'une 
limite de parcelle ne se pose pas, vu qu'il s'agit des géométries natives du 
cadastre (sauf dans les cas  de bâtiments à cheval sur plusieurs planches).
Actuellement sont chargés le bâti, les limites administratives, les parcelles & 
sections, les adresses, la voirie, et diverses autres choses (puits, pylônes, 
cimetières, bâtiment de culte, etc.). Tout est sourcé avec le tag habituel 
"cadastre-fr ... DGFiP  2017 etc.".
Ne sont pas chargés: les infos de mitoyenneté (mur, fossé) parce que 
représentées par un nœud, et les choses qui sont bizarrement regroupées dans le 
cadastre telles que "terrains de sport et petits ruisseaux" (WTF?!), ou bien 
"parking, terrasse, surplomb",  etc. 
Pour les curieux la correspondance entre les données du cadastre et les tags 
OSM se fait ici:
https://github.com/openstreetmap/josm-plugins/blob/master/cadastre-fr/src/org/openstreetmap/josm/plugins/fr/cadastre/edigeo/pci/EdigeoPciReader.java#L37

 https://avatars1.githubusercontent.com/u/261431?v=4=400 

openstreetmap/josm-plugins
github.com
josm-plugins - Mirror of the JOSM plugin repository in Subversion



Les calques chargés ainsi dans JOSM sont flaggués "envoi dissuadé". C'est à 
dire: JOSM va vous crier dessus si vous essayez d'envoyer ces données vers OSM, 
pour sensibiliser tout le monde qu'il y a un gros travail de vérification & 
d'intégration à mener  avant de faire ça. Si je vois qu'il y a des dérives et 
des imports massifs sans travail préalable, je basculerai rapidement en mode 
"envoi interdit", ce qui bloquera complètement l'envoi direct à partir de ces 
calques.


Il me manque à exploiter la date de dernière mise à jour (j

Re: [OSM-talk-fr] Publication OpenData du cadastre

2017-10-03 Par sujet Vincent Privat 
Hello,
Quelques compléments d'info sur JOSM.
Le support du cadastre est disponible, il faut utiliser la toute dernière
version stable (12921) de JOSM et la version 33690 du greffon cadastre-fr.
J'ai annoncé la nouvelle version du greffon il y a quelques jours sur la
liste dev-fr, et on en a parlé aussi au dernier meeting toulousain, j'ai
déjà corrigé quelques soucis de jeunesse suite aux tests préliminaires des
mappeurs toulousains :)

Le greffon permet d'ouvrir les lots Edigéo via file/open, file/open
location, ou en drag, soit de l'archive tar.bz2, soit du fichier .THF.
Les géométries sont automatiquement simplifiées pour éviter d'avoir des
piscines avec 500 nœuds. Le souci des bâtiments coupés en 2 au milieu d'une
limite de parcelle ne se pose pas, vu qu'il s'agit des géométries natives
du cadastre (sauf dans les cas de bâtiments à cheval sur plusieurs
planches).
Actuellement sont chargés le bâti, les limites administratives, les
parcelles & sections, les adresses, la voirie, et diverses autres choses
(puits, pylônes, cimetières, bâtiment de culte, etc.). Tout est sourcé avec
le tag habituel "cadastre-fr ... DGFiP 2017 etc.".
Ne sont pas chargés: les infos de mitoyenneté (mur, fossé) parce que
représentées par un nœud, et les choses qui sont bizarrement regroupées
dans le cadastre telles que "terrains de sport et petits ruisseaux"
(WTF?!), ou bien "parking, terrasse, surplomb", etc.
Pour les curieux la correspondance entre les données du cadastre et les
tags OSM se fait ici:
https://github.com/openstreetmap/josm-plugins/blob/master/cadastre-fr/src/org/openstreetmap/josm/plugins/fr/cadastre/edigeo/pci/EdigeoPciReader.java#L37

Les calques chargés ainsi dans JOSM sont flaggués "envoi dissuadé". C'est à
dire: JOSM va vous crier dessus si vous essayez d'envoyer ces données vers
OSM, pour sensibiliser tout le monde qu'il y a un gros travail de
vérification & d'intégration à mener avant de faire ça. Si je vois qu'il y
a des dérives et des imports massifs sans travail préalable, je basculerai
rapidement en mode "envoi interdit", ce qui bloquera complètement l'envoi
direct à partir de ces calques.

Il me manque à exploiter la date de dernière mise à jour (je pense à la
mettre dans un tag source:date).

J'attends l'API Etalab avec impatience, ça permettra à JOSM de télécharger
les données du cadastre pour une zone donnée (actuellement il faut
connaître le numéro de planche du cadastre).

Si vous trouvez des bugs n'hésitez pas à me les remonter :)

A+
Vincent





Le 3 octobre 2017 à 14:47, Christian Quest  a
écrit :

> Oui, officiellement dispo depuis hier... :)
>
> Les données brutes de la DGFiP sont au format EDIGEO, format peu courant
> mais ouvrable avec gdal (donc QGis).
>
> Dans cette première livraison, Etalab propose une extraction des
> principales couches d'infos surfaciques remise au format geojson en WGS84:
> limites de communes, de section cadastrale, de parcelle, et l'emprise des
> bâtiments.
>
> Des données sont téléchargeables par département et par communes pour les
> geojson et par département et feuille cadastrale pour l'EDIGEO.
>
> Ces données seront mises à jour trimestriellement.
>
>
> Les nouveautés à venir pour les contributeurs:
>
> - la prochaine version de JOSM va pouvoir ouvrir directement les fichier
> EDIGEO de la DGFiP.
> - l'extraction du bâti de cadastre.openstreetmap.fr deviennent en partie
> inutiles
> - les script d'extraction d'adresses de cadastre.openstreetmap.fr et de
> BANO vont aussi pouvoir évoluer prochainement.
>
> Il y a d'autres données provenant du cadastre qui seront bientôt
> disponibles:
> - le PCI Image et  les localisants de parcelles
> - l'historique des évolutions des parcelles (la parcelles XXX est séparée
> en YYY et ZZZ)
>
>
> Les fichiers EDIGEO permettent bien plus que ce qu'on a pu faire jusqu'à
> maintenant. On a par exemple les dates de création et de dernière
> modification des objets.
> On y trouve aussi des filaires portant les noms des voies pour l'habillage
> des plan... j'ai commencé à travailler dessus pour les rapprocher de
> FANTOIR, il se peut que ce type de traitement soit fait sur les données
> mises à disposition par Etalab en geojson.
> D'autres traitements sont aussi envisagés par Etalab pour améliorer les
> données, les lier à d'autres, etc. Ceci devrait arriver d'ici la fin de
> l'année.
>
> Etalab va aussi mettre en place des API pour interroger ces données, comme
> ça a pu être fait en mettant en place un géocodeur pour faciliter la
> réutilisation de la BAN.
>
>
> Il mes semble utile qu'on réfléchisse ensemble au meilleur moyen
> d'exploiter ces données et surtout de le penser dans le long terme pour les
> mises à jour. Pour cela, évitons de nous précipiter sur des imports à
> partir de ces données pour l'instant très brutes.
> Ces données font parti du "Service Public de la Donnée de Référence" dont
> le slogan est "Des données sur lesquelles vous pouvez compter"... c'est
> donc là pour longtemps ;)
>
>

Re: [OSM-talk-fr] Publication OpenData du cadastre

2017-10-03 Par sujet Christian Quest 
Oui, officiellement dispo depuis hier... :)

Les données brutes de la DGFiP sont au format EDIGEO, format peu courant
mais ouvrable avec gdal (donc QGis).

Dans cette première livraison, Etalab propose une extraction des
principales couches d'infos surfaciques remise au format geojson en WGS84:
limites de communes, de section cadastrale, de parcelle, et l'emprise des
bâtiments.

Des données sont téléchargeables par département et par communes pour les
geojson et par département et feuille cadastrale pour l'EDIGEO.

Ces données seront mises à jour trimestriellement.


Les nouveautés à venir pour les contributeurs:

- la prochaine version de JOSM va pouvoir ouvrir directement les fichier
EDIGEO de la DGFiP.
- l'extraction du bâti de cadastre.openstreetmap.fr deviennent en partie
inutiles
- les script d'extraction d'adresses de cadastre.openstreetmap.fr et de
BANO vont aussi pouvoir évoluer prochainement.

Il y a d'autres données provenant du cadastre qui seront bientôt
disponibles:
- le PCI Image et  les localisants de parcelles
- l'historique des évolutions des parcelles (la parcelles XXX est séparée
en YYY et ZZZ)


Les fichiers EDIGEO permettent bien plus que ce qu'on a pu faire jusqu'à
maintenant. On a par exemple les dates de création et de dernière
modification des objets.
On y trouve aussi des filaires portant les noms des voies pour l'habillage
des plan... j'ai commencé à travailler dessus pour les rapprocher de
FANTOIR, il se peut que ce type de traitement soit fait sur les données
mises à disposition par Etalab en geojson.
D'autres traitements sont aussi envisagés par Etalab pour améliorer les
données, les lier à d'autres, etc. Ceci devrait arriver d'ici la fin de
l'année.

Etalab va aussi mettre en place des API pour interroger ces données, comme
ça a pu être fait en mettant en place un géocodeur pour faciliter la
réutilisation de la BAN.


Il mes semble utile qu'on réfléchisse ensemble au meilleur moyen
d'exploiter ces données et surtout de le penser dans le long terme pour les
mises à jour. Pour cela, évitons de nous précipiter sur des imports à
partir de ces données pour l'instant très brutes.
Ces données font parti du "Service Public de la Donnée de Référence" dont
le slogan est "Des données sur lesquelles vous pouvez compter"... c'est
donc là pour longtemps ;)


Le 3 octobre 2017 à 14:20, David Marchal  a écrit :

> Cher tous,
>
>
> Je viens de voir que le cadastre, en tout cas certaines informations,
> viennent d’être publiées en OpenData, et en vectoriel, s’il vous plaît :
> https://www.nextinpact.com/brief/le-cadastre-est-
> accessible-en-open-data-329.htm Sans doute ce que Christian Quest disait
> être dans les tuyaux. D’emblée, je vois l’utilisation du GeoJSON pour
> l’importation du bâti, mais on doit pouvoir en tirer beaucoup plus. Merci à
> la DGFiP et à Etalab pour ça, ça devrait nous aider.
>
>
> Cordialement.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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