Hauteur et nombre d'étages des bâtiments

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Hauteur et nombre d'étages des bâtiments

Vincent Frison
Le 26 mars 2015 23:23, Vincent Frison <[hidden email]> a écrit :
En tout cas merci pour vos remarques constructives, je vais revoir me copie avec une version un peu plus soft : un seul update par bâtiment et surtout avec un score minimum (surface équivalente au minimum à 90% par ex). J'essayerai ce WE de modifier mon programme pour faire quelques petites statistiques...

J'ai donc fait des changements notamment pour diviser le processus en plusieurs phases séparées : load > match > update (désactivable) > stats. Cela permet en autres d'avoir qu'un seul update par bâtiment OSM.

Voici quelques stats, toujours sur ma zone de test Nation / Bastille / Gare de Lyon (surface d'environ 1/30e de Paris) :

Number of matched elements : 2568
Number of bad elements : 83
Element repartition by best matching scores :
- between 0% and 10% : 37 (1%) elements including 0 that are updatable
- between 10% and 20% : 62 (2%) elements including 0 that are updatable
- between 20% and 30% : 136 (5%) elements including 0 that are updatable
- between 30% and 40% : 220 (8%) elements including 0 that are updatable
- between 40% and 50% : 270 (10%) elements including 0 that are updatable
- between 50% and 60% : 275 (10%) elements including 0 that are updatable
- between 60% and 70% : 176 (6%) elements including 0 that are updatable
- between 70% and 80% : 201 (7%) elements including 0 that are updatable
- between 80% and 90% : 302 (11%) elements including 0 that are updatable
- between 90% and 100% : 806 (31%) elements including 0 that are updatable

C'est normal d'avoir toujours 0 éléments updatable car je n'ai pas encore réinitialisé les données sur le serveur de test, ils ont donc tous un nombre d'étage présent et du coup ils ne sont pas modifiable par mon programme...

Il faut que j'affine tout ça (notamment comprendre pourquoi 83 éléments n'ont pas de score valide) mais il est déjà intéressant de voir que je ne peux matcher que seulement 1/3 des bâtiments avec score supérieur à 0.9 (pour rappel le score est le ratio de la surface entre le bâtiment OSM et le bâtiment importé).

J'ai en tête quelques pistes pour améliorer un peu le truc, par ex. si un bâtiment OSM correspond avec 3 bâtiment importés :
- un avec 5 étages et score de 65%
- un avec 5 étages et score de 30%
- un avec 0 étages et score de 5%
Dans ce cas je pourrais faire comme s'il y avait un bâtiment de 5 étages qui match plus de 90%.






_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Hauteur et nombre d'étages des bâtiments

erwan salomon
je dit peut-être une connerie :
les 83 éléments non valides sont peut-être des éléments pour les-quels le score dépasse 100 % ? (bâtiment OSM plus petit que le bâtiment de l'import)

sinon ça fait pas beaucoup de correspondances précises en effet
dans une zone moins urbaine (avec moins d'immeubles regroupés) le résultat serait sans doute meilleur

erwan [glyo]

Le 30 mars 2015 à 19:16, Vincent Frison a écrit :

Le 26 mars 2015 23:23, Vincent Frison <[hidden email]> a écrit :
En tout cas merci pour vos remarques constructives, je vais revoir me copie avec une version un peu plus soft : un seul update par bâtiment et surtout avec un score minimum (surface équivalente au minimum à 90% par ex). J'essayerai ce WE de modifier mon programme pour faire quelques petites statistiques...

J'ai donc fait des changements notamment pour diviser le processus en plusieurs phases séparées : load > match > update (désactivable) > stats. Cela permet en autres d'avoir qu'un seul update par bâtiment OSM.

Voici quelques stats, toujours sur ma zone de test Nation / Bastille / Gare de Lyon (surface d'environ 1/30e de Paris) :

Number of matched elements : 2568
Number of bad elements : 83
Element repartition by best matching scores :
- between 0% and 10% : 37 (1%) elements including 0 that are updatable
- between 10% and 20% : 62 (2%) elements including 0 that are updatable
- between 20% and 30% : 136 (5%) elements including 0 that are updatable
- between 30% and 40% : 220 (8%) elements including 0 that are updatable
- between 40% and 50% : 270 (10%) elements including 0 that are updatable
- between 50% and 60% : 275 (10%) elements including 0 that are updatable
- between 60% and 70% : 176 (6%) elements including 0 that are updatable
- between 70% and 80% : 201 (7%) elements including 0 that are updatable
- between 80% and 90% : 302 (11%) elements including 0 that are updatable
- between 90% and 100% : 806 (31%) elements including 0 that are updatable

C'est normal d'avoir toujours 0 éléments updatable car je n'ai pas encore réinitialisé les données sur le serveur de test, ils ont donc tous un nombre d'étage présent et du coup ils ne sont pas modifiable par mon programme...

Il faut que j'affine tout ça (notamment comprendre pourquoi 83 éléments n'ont pas de score valide) mais il est déjà intéressant de voir que je ne peux matcher que seulement 1/3 des bâtiments avec score supérieur à 0.9 (pour rappel le score est le ratio de la surface entre le bâtiment OSM et le bâtiment importé).

J'ai en tête quelques pistes pour améliorer un peu le truc, par ex. si un bâtiment OSM correspond avec 3 bâtiment importés :
- un avec 5 étages et score de 65%
- un avec 5 étages et score de 30%
- un avec 0 étages et score de 5%
Dans ce cas je pourrais faire comme s'il y avait un bâtiment de 5 étages qui match plus de 90%.





_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr


_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Hauteur et nombre d'étages des bâtiments

Vincent Frison
Le 30 mars 2015 20:59, erwan salomon <[hidden email]> a écrit :
je dit peut-être une connerie :
les 83 éléments non valides sont peut-être des éléments pour les-quels le score dépasse 100 % ? (bâtiment OSM plus petit que le bâtiment de l'import)

Normalement le score est forcément compris entre 0 et 1 (si le bâtiment d'OSM est plus petit que l'import j'inverse le ratio) mais il faut que je debug..
 
sinon ça fait pas beaucoup de correspondances précises en effet
dans une zone moins urbaine (avec moins d'immeubles regroupés) le résultat serait sans doute meilleur

Oui je pense aussi.. Paname et ses dizaines de milliers de vieux immeubles imbriqués n'était sans doute pas le cas le plus facile pour commencer.. mais l'avantage c'est qu'il y a de l'OpenData et contrairement aux autres grandes villes il y a le nombre d'étage pour chacun des bâtiments. J'ai regardé vite fait sur Nice, Lyon et je sais plus quelle autre ville française et apparemment il n'y avait pas le nombre d'étages (et encore moins la hauteur). Mais en cherchant un peu plus il devrait y avoir d'autres données exploitables.. à commencer par la base de PSS sur laquelle je n'ai pas encore perdu espoir ! 


_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Hauteur et nombre d'étages des bâtiments

Vincent Frison
Le 30 mars 2015 21:24, Vincent Frison <[hidden email]> a écrit :
Le 30 mars 2015 20:59, erwan salomon <[hidden email]> a écrit :
je dit peut-être une connerie :
les 83 éléments non valides sont peut-être des éléments pour les-quels le score dépasse 100 % ? (bâtiment OSM plus petit que le bâtiment de l'import)

Normalement le score est forcément compris entre 0 et 1 (si le bâtiment d'OSM est plus petit que l'import j'inverse le ratio) mais il faut que je debug..

Erf j'avais tout simplement oublié un petit '=' et ces 83 mauvais éléments correspondaient en fait à des éléments parfait puisqu'avec un score de 1.0 :)

Dans ma zone de test il y a donc un peu plus de 34% de bâtiment ayant un import dont le score est d'au moins 90%.

Je vais essayer d'implémenter l'astuce décrite dans mon précédent mail : pour chacun des bâtiments OSM regrouper les imports par nombre d'étages pour voir si je peux les "cumuler" afin d'atteindre le bon score minimal.
 

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Hauteur et nombre d'étages des bâtiments

Vincent Frison
Le 31 mars 2015 10:52, Vincent Frison <[hidden email]> a écrit :
Dans ma zone de test il y a donc un peu plus de 34% de bâtiment ayant un import dont le score est d'au moins 90%.

Je vais essayer d'implémenter l'astuce décrite dans mon précédent mail : pour chacun des bâtiments OSM regrouper les imports par nombre d'étages pour voir si je peux les "cumuler" afin d'atteindre le bon score minimal.

J'ai refait quasiment tout mon programme afin d'être bien générique (il peut travailler sur n'importe quel tag de n'importe quel élément et non pas simplement sur le nombre d'étage des bâtiments) et surtout pour avoir ce "cumul" des scores des imports.

Voici donc les stats avec l'ancienne et la nouvelle méthode : pour chaque bâtiment l'ancienne méthode ne considère que l'import avec le meilleur score alors que la nouvelle méthode regroupe les imports ayant le même nombre d'étages pour additionner leur score ce qui permet d'avoir des résultats légèrement meilleurs.

 INFO === Statistics ===
 INFO *** Statistics with the old matching method ***
 INFO Number of matched elements: 2568
 INFO Number of updatable elements: 0
 INFO Number of updated elements: 0
 INFO Repartition by matching scores:
 INFO - between 0% and 10% : 37 (1%) elements including 0 that have been updated (0 were updatable)
 INFO - between 10% and 20% : 62 (2%) elements including 0 that have been updated (0 were updatable)
 INFO - between 20% and 30% : 136 (5%) elements including 0 that have been updated (0 were updatable)
 INFO - between 30% and 40% : 220 (8%) elements including 0 that have been updated (0 were updatable)
 INFO - between 40% and 50% : 275 (10%) elements including 0 that have been updated (0 were updatable)
 INFO - between 50% and 60% : 270 (10%) elements including 0 that have been updated (0 were updatable)
 INFO - between 60% and 70% : 176 (6%) elements including 0 that have been updated (0 were updatable)
 INFO - between 70% and 80% : 201 (7%) elements including 0 that have been updated (0 were updatable)
 INFO - between 80% and 90% : 302 (11%) elements including 0 that have been updated (0 were updatable)
 INFO - between 90% and 100% : 889 (34%) elements including 0 that have been updated (0 were updatable)
 INFO *** Statistics with the new matching method ***
 INFO * Statistics for the updatable tag building:levels
 INFO Number of matched elements: 2550
 INFO Number of updatable elements: 0
 INFO Number of updated elements: 0
 INFO Repartition by matching scores:
 INFO - between 0% and 10% : 31 (1%) elements including 0 that have been updated (0 were updatable)
 INFO - between 10% and 20% : 23 (0%) elements including 0 that have been updated (0 were updatable)
 INFO - between 20% and 30% : 50 (1%) elements including 0 that have been updated (0 were updatable)
 INFO - between 30% and 40% : 150 (5%) elements including 0 that have been updated (0 were updatable)
 INFO - between 40% and 50% : 263 (10%) elements including 0 that have been updated (0 were updatable)
 INFO - between 50% and 60% : 265 (10%) elements including 0 that have been updated (0 were updatable)
 INFO - between 60% and 70% : 202 (7%) elements including 0 that have been updated (0 were updatable)
 INFO - between 70% and 80% : 209 (8%) elements including 0 that have been updated (0 were updatable)
 INFO - between 80% and 90% : 335 (13%) elements including 0 that have been updated (0 were updatable)
 INFO - between 90% and 100% : 1022 (39%) elements including 0 that have been updated (0 were updatable)
Avec la nouvelle méthode la tranche des 90%->100% passe ainsi de 34% à 39%, c'est toujours ça de pris.

Personnellement j'aimerais bien qu'on prenne également la tranche des 80%->90% car il faut bien voir que le découpage d'OSM est vraiment grossier par rapport à celui d'OpenDataParis et qu'il y a forcément des différences de surfaces assez importantes. Si on se dit que ma zone de test dans le 12e arrondissement est assez représentative (on aura à peu près les mêmes pourcentages sur l'ensemble de Paris) et qu'on accepte cette tranche de 80%->90% cela permettrait de mettre à jour plus de la moitié des immeubles parisiens (39 + 13 = 52%). Mais je comprends tout à fait que cela puisse vous gêner et que vous préfériez ne rien mettre à jour plutôt que de mettre à jour des données "fausses" (même si pour moi elles ne sont pas fausses mais juste légèrement simplistes en raison des données existantes ;p).

Voila j'attends vos retours avant de me lancer mon programme sur le serveur live.

++ Vincent.


_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Hauteur et nombre d'étages des bâtiments

Brice MALLET-3
A mon avis, il serait possible d'éprouver ton programme d'import, en
acceptant jusqu'à  80 %, en générant un import sur une zone clairement
délimité, afin de pouvoir juger sur pièces.

En comparant avec cadastre, openstreetview, terrain, ... chacun pourra
juger du degré d'approximation tolérable à son sens.

Brice


Le 02/04/2015 11:13, Vincent Frison a écrit :

> Le 31 mars 2015 10:52, Vincent Frison <[hidden email]
> <mailto:[hidden email]>> a écrit :
>
>     Dans ma zone de test il y a donc un peu plus de 34% de bâtiment
>     ayant un import dont le score est d'au moins 90%.
>
>     Je vais essayer d'implémenter l'astuce décrite dans mon précédent
>     mail : pour chacun des bâtiments OSM regrouper les imports par
>     nombre d'étages pour voir si je peux les "cumuler" afin
>     d'atteindre le bon score minimal.
>
>
> J'ai refait quasiment tout mon programme afin d'être bien générique
> (il peut travailler sur n'importe quel tag de n'importe quel élément
> et non pas simplement sur le nombre d'étage des bâtiments) et surtout
> pour avoir ce "cumul" des scores des imports.
>
> Voici donc les stats avec l'ancienne et la nouvelle méthode : pour
> chaque bâtiment l'ancienne méthode ne considère que l'import avec le
> meilleur score alors que la nouvelle méthode regroupe les imports
> ayant le même nombre d'étages pour additionner leur score ce qui
> permet d'avoir des résultats légèrement meilleurs.
>
>  INFO === Statistics ===
>  INFO *** Statistics with the old matching method ***
>  INFO Number of matched elements: 2568
>  INFO Number of updatable elements: 0
>  INFO Number of updated elements: 0
>  INFO Repartition by matching scores:
>  INFO - between 0% and 10% : 37 (1%) elements including 0 that have
> been updated (0 were updatable)
>  INFO - between 10% and 20% : 62 (2%) elements including 0 that have
> been updated (0 were updatable)
>  INFO - between 20% and 30% : 136 (5%) elements including 0 that have
> been updated (0 were updatable)
>  INFO - between 30% and 40% : 220 (8%) elements including 0 that have
> been updated (0 were updatable)
>  INFO - between 40% and 50% : 275 (10%) elements including 0 that have
> been updated (0 were updatable)
>  INFO - between 50% and 60% : 270 (10%) elements including 0 that have
> been updated (0 were updatable)
>  INFO - between 60% and 70% : 176 (6%) elements including 0 that have
> been updated (0 were updatable)
>  INFO - between 70% and 80% : 201 (7%) elements including 0 that have
> been updated (0 were updatable)
>  INFO - between 80% and 90% : 302 (11%) elements including 0 that have
> been updated (0 were updatable)
>  INFO - between 90% and 100% : 889 (34%) elements including 0 that
> have been updated (0 were updatable)
>  INFO *** Statistics with the new matching method ***
>  INFO * Statistics for the updatable tag building:levels
>  INFO Number of matched elements: 2550
>  INFO Number of updatable elements: 0
>  INFO Number of updated elements: 0
>  INFO Repartition by matching scores:
>  INFO - between 0% and 10% : 31 (1%) elements including 0 that have
> been updated (0 were updatable)
>  INFO - between 10% and 20% : 23 (0%) elements including 0 that have
> been updated (0 were updatable)
>  INFO - between 20% and 30% : 50 (1%) elements including 0 that have
> been updated (0 were updatable)
>  INFO - between 30% and 40% : 150 (5%) elements including 0 that have
> been updated (0 were updatable)
>  INFO - between 40% and 50% : 263 (10%) elements including 0 that have
> been updated (0 were updatable)
>  INFO - between 50% and 60% : 265 (10%) elements including 0 that have
> been updated (0 were updatable)
>  INFO - between 60% and 70% : 202 (7%) elements including 0 that have
> been updated (0 were updatable)
>  INFO - between 70% and 80% : 209 (8%) elements including 0 that have
> been updated (0 were updatable)
>  INFO - between 80% and 90% : 335 (13%) elements including 0 that have
> been updated (0 were updatable)
>  INFO - between 90% and 100% : 1022 (39%) elements including 0 that
> have been updated (0 were updatable)
> Avec la nouvelle méthode la tranche des 90%->100% passe ainsi de 34% à
> 39%, c'est toujours ça de pris.
>
> Personnellement j'aimerais bien qu'on prenne également la tranche des
> 80%->90% car il faut bien voir que le découpage d'OSM est vraiment
> grossier par rapport à celui d'OpenDataParis et qu'il y a forcément
> des différences de surfaces assez importantes. Si on se dit que ma
> zone de test dans le 12e arrondissement est assez représentative (on
> aura à peu près les mêmes pourcentages sur l'ensemble de Paris) et
> qu'on accepte cette tranche de 80%->90% cela permettrait de mettre à
> jour plus de la moitié des immeubles parisiens (39 + 13 = 52%). Mais
> je comprends tout à fait que cela puisse vous gêner et que vous
> préfériez ne rien mettre à jour plutôt que de mettre à jour des
> données "fausses" (même si pour moi elles ne sont pas fausses mais
> juste légèrement simplistes en raison des données existantes ;p).
>
> Voila j'attends vos retours avant de me lancer mon programme sur le
> serveur live.
>
> ++ Vincent.
>
>
>
> _______________________________________________
> Talk-fr mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/talk-fr


_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Hauteur et nombre d'étages des bâtiments

althio
In reply to this post by Vincent Frison

2015-04-02 11:13 GMT+02:00 Vincent Frison <[hidden email]>:
le découpage d'OSM est vraiment grossier par rapport à celui d'OpenDataParis et qu'il y a forcément des différences de surfaces assez importantes.

Tu veux dire que la base d'opendata.paris.fr est meilleure et pourrait être une source pour le bâti en surface au sol, sans même parler du volume ? A rajouter en plus du cadastre, imageries, ... ?

Si c'est le cas, c'est un travail préliminaire de rapprochement des surfaces qui pourrait améliorer la base OSM ?
Et qui rendrait le travail plus simple pour ta moulinette.



_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Hauteur et nombre d'étages des bâtiments

Pieren
In reply to this post by Vincent Frison
2015-04-02 11:13 GMT+02:00 Vincent Frison <[hidden email]>:
 
Personnellement j'aimerais bien qu'on prenne également la tranche des 80%->90% car il faut bien voir que le découpage d'OSM est vraiment grossier par rapport à celui d'OpenDataParis et qu'il y a forcément des différences de surfaces assez importantes. Si on se dit que ma zone de test dans le 12e arrondissement est assez représentative (on aura à peu près les mêmes pourcentages sur l'ensemble de Paris) et qu'on accepte cette tranche de 80%->90% cela permettrait de mettre à jour plus de la moitié des immeubles parisiens (39 + 13 = 52%). Mais je comprends tout à fait que cela puisse vous gêner et que vous préfériez ne rien mettre à jour plutôt que de mettre à jour des données "fausses" (même si pour moi elles ne sont pas fausses mais juste légèrement simplistes en raison des données existantes ;p).

Le surfacique des "building" viennent du cadastre. Mais on sait tous que le cadastre a son propre découpage qui contient souvent des artifices/erreurs/fantaisies avec des polygones séparés qui ne sont pas des bâtiments séparés mais au mieux des pièces ou pire, des balcons ou des cheminées (pour les plus petites). C'est pourquoi après l'import du bâti sur Paris, j'ai fusionné de nombreux polygones pour que le tag "building" s'applique vraiment à la surface du building et non à une partie seule (mais pas dans tous les arrondissements). De plus, de nombreuses cours intérieures ont souvent manqué pendant l'import (qui n'est pas de mon fait), ce qui peut aussi expliquer les différences avec les données de la ville.

 

Voila j'attends vos retours avant de me lancer mon programme sur le serveur live.


Avant de passer au vrai import de masse, il faut créer une page wiki décrivant le processus, résumer l'action dans un mail envoyé à la liste [hidden email] avec si possible un échantillon de fichier xml pour que les autres puissent juger de ce qui sera modifié. Il faut chercher "imports" dans le wiki pour trouver la procédure à suivre. Le risque sinon est d'avoir un revert automatique du DWG si tu passes dans leur radar.

Sinon, tu pourrait commencer plus petit, avec un quartier assez caractéristique des problèmes rencontrés. Plus besoin de passer par la procédure officielle. Et d'avantage de gens pourront juger du résultat.
De plus, il serait intéressant de publier ton script pour que d'autres puissent réitérer l'opération plus tard, sur la même zone ou ailleurs. Celui-ci devrait aussi d'ailleurs signaler les cas qui ont un écart trop grand entre les données de Paris et les valeurs déjà dans OSM (quand c'est le cas). Là aussi, dans l'optique de vérifier l'existant manuellement (les anciennes contributions peuvent être fausses, altérées ou obsolètes) et d'exécutions du même script plus-tard avec des données plus fraiches.

Pieren

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Hauteur et nombre d'étages des bâtiments

Vincent Frison
Le 2 avril 2015 16:00, Pieren <[hidden email]> a écrit :
2015-04-02 11:13 GMT+02:00 Vincent Frison <[hidden email]>:
 
Personnellement j'aimerais bien qu'on prenne également la tranche des 80%->90% car il faut bien voir que le découpage d'OSM est vraiment grossier par rapport à celui d'OpenDataParis et qu'il y a forcément des différences de surfaces assez importantes. Si on se dit que ma zone de test dans le 12e arrondissement est assez représentative (on aura à peu près les mêmes pourcentages sur l'ensemble de Paris) et qu'on accepte cette tranche de 80%->90% cela permettrait de mettre à jour plus de la moitié des immeubles parisiens (39 + 13 = 52%). Mais je comprends tout à fait que cela puisse vous gêner et que vous préfériez ne rien mettre à jour plutôt que de mettre à jour des données "fausses" (même si pour moi elles ne sont pas fausses mais juste légèrement simplistes en raison des données existantes ;p).

Le surfacique des "building" viennent du cadastre. Mais on sait tous que le cadastre a son propre découpage qui contient souvent des artifices/erreurs/fantaisies avec des polygones séparés qui ne sont pas des bâtiments séparés mais au mieux des pièces ou pire, des balcons ou des cheminées (pour les plus petites). C'est pourquoi après l'import du bâti sur Paris, j'ai fusionné de nombreux polygones pour que le tag "building" s'applique vraiment à la surface du building et non à une partie seule (mais pas dans tous les arrondissements). De plus, de nombreuses cours intérieures ont souvent manqué pendant l'import (qui n'est pas de mon fait), ce qui peut aussi expliquer les différences avec les données de la ville.

Tout à fait, c'est typiquement ce genre de "simplifications" qui causent de nombreuses différences au niveau des surfaces et dans le cadre de mon import ça me pose évidemment un souci. Mais soyons bien clair, je trouve que le travail accompli pour importer le cadastre est tout bonnement magnifique, la valeur ajoutée à OSM est tellement énorme... et je ne voudrais surtout pas paraître pour le mec qui crache dans la soupe qui nourrit son programme ;)
 
Voila j'attends vos retours avant de me lancer mon programme sur le serveur live.

Avant de passer au vrai import de masse, il faut créer une page wiki décrivant le processus, résumer l'action dans un mail envoyé à la liste [hidden email] avec si possible un échantillon de fichier xml pour que les autres puissent juger de ce qui sera modifié. Il faut chercher "imports" dans le wiki pour trouver la procédure à suivre. Le risque sinon est d'avoir un revert automatique du DWG si tu passes dans leur radar.

Sinon, tu pourrait commencer plus petit, avec un quartier assez caractéristique des problèmes rencontrés. Plus besoin de passer par la procédure officielle. Et d'avantage de gens pourront juger du résultat.

Ok je vais essayer de faire tout ça..
 
De plus, il serait intéressant de publier ton script pour que d'autres puissent réitérer l'opération plus tard, sur la même zone ou ailleurs. Celui-ci devrait aussi d'ailleurs signaler les cas qui ont un écart trop grand entre les données de Paris et les valeurs déjà dans OSM (quand c'est le cas). Là aussi, dans l'optique de vérifier l'existant manuellement (les anciennes contributions peuvent être fausses, altérées ou obsolètes) et d'exécutions du même script plus-tard avec des données plus fraiches.

Mais carrément, j'ai déjà un petit projet GitHub : https://github.com/vince-from-nice/osmaxil


_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Hauteur et nombre d'étages des bâtiments

Vincent Frison
Le 2 avril 2015 12:28, Brice MALLET <[hidden email]> a écrit :
A mon avis, il serait possible d'éprouver ton programme d'import, en acceptant jusqu'à  80 %, en générant un import sur une zone clairement délimité, afin de pouvoir juger sur pièces.

En comparant avec cadastre, openstreetview, terrain, ... chacun pourra juger du degré d'approximation tolérable à son sens.

Tout à fait, chacun peut déjà juger du résultat lorsque le score minimum est 80% puisque c'est cette valeur que j'ai utilisé sur ma zone de test (qui est pour rappel entre Bastille, Gare de Lyon et Nation). Par contre c'est sur le serveur de test et non de prod donc le mieux pour le visualiser c'est avec JOSM je pense (il faut juste changer l'URL de l'API dans les préférences de JOSM pour faire pointer vers http://api06.dev.openstreetmap.org/api)
 
Le 2 avril 2015 13:02, althio <[hidden email]> a écrit :
2015-04-02 11:13 GMT+02:00 Vincent Frison <[hidden email]>:
le découpage d'OSM est vraiment grossier par rapport à celui d'OpenDataParis et qu'il y a forcément des différences de surfaces assez importantes.

Tu veux dire que la base d'opendata.paris.fr est meilleure et pourrait être une source pour le bâti en surface au sol, sans même parler du volume ? A rajouter en plus du cadastre, imageries, ... ?

Si c'est le cas, c'est un travail préliminaire de rapprochement des surfaces qui pourrait améliorer la base OSM ?
Et qui rendrait le travail plus simple pour ta moulinette.

Clairement ma moulinette serait plus simple, et surtout elle aurait de biens meilleures résultats puisque presque tout les bâtiments "matcheraient" à 100%. Mais je doute que Pieren ait envie de refaire une moulinette annulant sa simplification. Déjà que simplifier devait être bien compliqué et mais maintenant faire l'inverse le serait encore plus !
 
Le 2 avril 2015 23:11, Vincent Frison <[hidden email]> a écrit :
Le 2 avril 2015 16:00, Pieren <[hidden email]> a écrit : 
De plus, il serait intéressant de publier ton script pour que d'autres puissent réitérer l'opération plus tard, sur la même zone ou ailleurs. Celui-ci devrait aussi d'ailleurs signaler les cas qui ont un écart trop grand entre les données de Paris et les valeurs déjà dans OSM (quand c'est le cas). Là aussi, dans l'optique de vérifier l'existant manuellement (les anciennes contributions peuvent être fausses, altérées ou obsolètes) et d'exécutions du même script plus-tard avec des données plus fraiches.

Mais carrément, j'ai déjà un petit projet GitHub : https://github.com/vince-from-nice/osmaxil

J'ai lancé le programme sur l'ensemble de Paris pour avoir des stats réelles (c'était sur le serveur live et non plus de test mais en ayant désactivé la phase écriture) :

2015-04-11 23:46:29  INFO === Statistics ===
2015-04-11 23:46:29  INFO *** Statistics with the old matching method ***
2015-04-11 23:46:29  INFO Number of matched elements: 86728
2015-04-11 23:46:29  INFO Number of updatable elements: 84907
2015-04-11 23:46:29  INFO Number of updated elements: 0
2015-04-11 23:46:29  INFO Repartition by matching scores:
2015-04-11 23:46:29  INFO - between 0% and 10% : 1647 (1%) elements including 0 that have been updated (1597 were updatable)
2015-04-11 23:46:29  INFO - between 10% and 20% : 1567 (1%) elements including 0 that have been updated (1512 were updatable)
2015-04-11 23:46:29  INFO - between 20% and 30% : 3490 (4%) elements including 0 that have been updated (3374 were updatable)
2015-04-11 23:46:29  INFO - between 30% and 40% : 5768 (6%) elements including 0 that have been updated (5630 were updatable)
2015-04-11 23:46:29  INFO - between 40% and 50% : 8591 (9%) elements including 0 that have been updated (8426 were updatable)
2015-04-11 23:46:29  INFO - between 50% and 60% : 8813 (10%) elements including 0 that have been updated (8635 were updatable)
2015-04-11 23:46:29  INFO - between 60% and 70% : 7198 (8%) elements including 0 that have been updated (7071 were updatable)
2015-04-11 23:46:29  INFO - between 70% and 80% : 7161 (8%) elements including 0 that have been updated (7033 were updatable)
2015-04-11 23:46:29  INFO - between 80% and 90% : 10916 (12%) elements including 0 that have been updated (10719 were updatable)
2015-04-11 23:46:29  INFO - between 90% and 100% : 31577 (36%) elements including 0 that have been updated (30910 were updatable)
2015-04-11 23:46:29  INFO *** Statistics with the new matching method ***
2015-04-11 23:46:29  INFO * Statistics for the updatable tag building:levels
2015-04-11 23:46:29  INFO Number of matched elements: 86050
2015-04-11 23:46:29  INFO Number of updatable elements: 84253
2015-04-11 23:46:29  INFO Number of updated elements: 0
2015-04-11 23:46:29  INFO Repartition by matching scores:
2015-04-11 23:46:29  INFO - between 0% and 10% : 1482 (1%) elements including 0 that have been updated (1436 were updatable)
2015-04-11 23:46:29  INFO - between 10% and 20% : 702 (0%) elements including 0 that have been updated (678 were updatable)
2015-04-11 23:46:29  INFO - between 20% and 30% : 1368 (1%) elements including 0 that have been updated (1309 were updatable)
2015-04-11 23:46:29  INFO - between 30% and 40% : 3561 (4%) elements including 0 that have been updated (3464 were updatable)
2015-04-11 23:46:29  INFO - between 40% and 50% : 6755 (7%) elements including 0 that have been updated (6598 were updatable)
2015-04-11 23:46:29  INFO - between 50% and 60% : 7819 (9%) elements including 0 that have been updated (7656 were updatable)
2015-04-11 23:46:29  INFO - between 60% and 70% : 7064 (8%) elements including 0 that have been updated (6946 were updatable)
2015-04-11 23:46:29  INFO - between 70% and 80% : 7952 (9%) elements including 0 that have been updated (7807 were updatable)
2015-04-11 23:46:29  INFO - between 80% and 90% : 12900 (14%) elements including 0 that have been updated (12677 were updatable)
2015-04-11 23:46:29  INFO - between 90% and 100% : 36447 (42%) elements including 0 that have been updated (35682 were updatable)

C'est assez équivalent aux stats de ma zone de tests : 
- avec un score minimum de 80% => environ 56% d'immeubles mis à jour
- avec un score minimum de 50% => environ 82% d'immeubles mis à jour

Il faudrait maintenant décider de ce score minimum. 

En raison des simplifications abordées un peu plus haut dans ce thread je pense sincèrement qu'il ne faudrait pas le mettre trop haut. Personnellement je le mettrais carrément à 50% car pour moi si plus de la moitié de la surface d'un immeuble OSM englobe un bâtiment possédant X étage, il n'y a rien de choquant de tagger l'ensemble de l'immeuble avec X étages. Mais comme j'ai déjà dis je comprend aussi que cela puisse gêner... donc peut-être que 80% serait un bon compromis ?

Il faut aussi se dire que les moteurs de rendu 3D sont obligés d'appliquer une hauteur arbitraire aux immeuble n'ayant pas d'information de hauteur (ie. sans tag height ou building:levels). Et qu'à priori il vaut mieux avoir une valeur qui correspond au moins à une partie de la réalité du bâtiment plutôt qu'une valeur complètement arbitraire...

++ Vincent.

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Hauteur et nombre d'étages des bâtiments

FrViPofm
Le 13/04/2015 16:00, Vincent Frison a écrit :


Il faut aussi se dire que les moteurs de rendu 3D sont obligés d'appliquer une hauteur arbitraire aux immeuble n'ayant pas d'information de hauteur (ie. sans tag height ou building:levels). Et qu'à priori il vaut mieux avoir une valeur qui correspond au moins à une partie de la réalité du bâtiment plutôt qu'une valeur complètement arbitraire...
Ça, ça se discute !
Que le moteur de rendu 3D prenne une hauteur arbitraire, c'est son problème. Et ça ne vaut que pour ce moteur de rendu.

Mettre une donnée à moitié juste dans OSM, c'est mettre une donnée à moitié fausse !
Et c'est faire croire à tout le monde qu'elle est juste.

Alors que l'absence de donnée n'est pas une erreur mais une absence.

À mon avis, ce qui frôle les 80 %, c'est OK. Mais descendre à 50, c'est faire un sacré pari.

La donnée externe ne va pas disparaître demain ?
Quand on trouvera d'autres éléments pour une heuristique, elle sera encore la ?
Alors patientons.

Si c'était un building:part, ce serait moins faux !
--
FrViPofm

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Hauteur et nombre d'étages des bâtiments

dHuy Pierre
@Vincent Pottier: exactement ce que je défendais plus haut mais je me croyais seul :p



Le Lundi 13 avril 2015 20h50, Vincent Pottier <[hidden email]> a écrit :


Le 13/04/2015 16:00, Vincent Frison a écrit :


Il faut aussi se dire que les moteurs de rendu 3D sont obligés d'appliquer une hauteur arbitraire aux immeuble n'ayant pas d'information de hauteur (ie. sans tag height ou building:levels). Et qu'à priori il vaut mieux avoir une valeur qui correspond au moins à une partie de la réalité du bâtiment plutôt qu'une valeur complètement arbitraire...

Ça, ça se discute !
Que le moteur de rendu 3D prenne une hauteur arbitraire, c'est son problème. Et ça ne vaut que pour ce moteur de rendu.

Mettre une donnée à moitié juste dans OSM, c'est mettre une donnée à moitié fausse !
Et c'est faire croire à tout le monde qu'elle est juste.

Alors que l'absence de donnée n'est pas une erreur mais une absence.

À mon avis, ce qui frôle les 80 %, c'est OK. Mais descendre à 50, c'est faire un sacré pari.

La donnée externe ne va pas disparaître demain ?
Quand on trouvera d'autres éléments pour une heuristique, elle sera encore la ?
Alors patientons.

Si c'était un building:part, ce serait moins faux !
--
FrViPofm


_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr



_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Hauteur et nombre d'étages des bâtiments

Vincent Frison
In reply to this post by FrViPofm

Le 13 avril 2015 20:50, Vincent Pottier <[hidden email]> a écrit :
Le 13/04/2015 16:00, Vincent Frison a écrit :
Il faut aussi se dire que les moteurs de rendu 3D sont obligés d'appliquer une hauteur arbitraire aux immeuble n'ayant pas d'information de hauteur (ie. sans tag height ou building:levels). Et qu'à priori il vaut mieux avoir une valeur qui correspond au moins à une partie de la réalité du bâtiment plutôt qu'une valeur complètement arbitraire...
Ça, ça se discute !
Que le moteur de rendu 3D prenne une hauteur arbitraire, c'est son problème. Et ça ne vaut que pour ce moteur de rendu.

Je ne connais pas de moteurs 3D qui font autrement.. l'unique alternative serait de ne rien n'afficher du tout, mais bon visuellement ça n'est pas vraiment acceptable.. 
 
À mon avis, ce qui frôle les 80 %, c'est OK. Mais descendre à 50, c'est faire un sacré pari.

Ok, restons sur 80% comme score minimal alors..

J'avoue que je suis un peu déçu du résultat car même si avec 80% comme score min. ça couvre tout de même plus de la moitié des immeubles parisiens, finalement ça correspond bien surtout avec les petits immeubles. Avec les gros bâtiments ou grosses résidences il y a eu malheureusement trop de fusions de sous-bâtiments. Or c'est justement les grosses structures qui sont les plus visibles...

La donnée externe ne va pas disparaître demain ?
Quand on trouvera d'autres éléments pour une heuristique, elle sera encore la ?
Alors patientons.

Hmm quel genre d'heuristiques ? A priori avec le découpage actuel du cadastre parisien dans OSM on ne peut pas vraiment faire mieux, la seule solution pour améliorer le truc serait un redécoupage du cadastre mais bon... 
 
Si c'était un building:part, ce serait moins faux !

En fait mon programme regarde tous les bâtiments, qu'ils soient avec ou sans le tag building:part.


_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Hauteur et nombre d'étages des bâtiments

FrViPofm
Le 13/04/2015 22:50, Vincent Frison a écrit :

 
Si c'était un building:part, ce serait moins faux !

En fait mon programme regarde tous les bâtiments, qu'ils soient avec ou sans le tag building:part.


Et une modif pour la génération de fichiers avec des building:part pour ce qui est entre 50 et 80% en vue d'un import manuel, comme pour le cadastre avec les buildingq, c'est faisable ?
--
FrViPofm

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Hauteur et nombre d'étages des bâtiments

Vincent Frison
L'idée de Vincent est intéressante, en effet pour les buildings pour lesquels la correspondance serait trop faible je pourrais générer un fichier XML proposant des ajouts d'éléments building:parts. Ces fichiers seraient ensuite à merger manuellement avec les bâtiments existants. 

Cela ne sera pas super simple, parmi les nombreuses difficultés il faudra notamment régler un léger décalage de quelques mètres entre les bâtiments ODP et ceux existant dans OSM (et visiblement ce décalage est variable). Or le building OSM, qui ferait office de building "principal" est censé englober parfaitement les différents éléments building:part si j'ai bien compris. D'ailleurs ça me parait plus logique si le building englobant est une relation plutôt qu'un way mais d'après la page Wiki (http://wiki.openstreetmap.org/wiki/Key:building:part) ça peut être une relation OU un way.

Bref ça serait un travail de longue haleine et en attendant je compte déjà lancer mon programme dans sa forme actuelle, c'est à dire qui rajoute simplement des tags building:levels aux buildings existant seulement s'ils ont un matching score supérieur à 80% (et s'il n'ont pas un tag building:levels déjà présent bien sûr).

Sinon Pieren en regardant cadastre.gouv.fr je suis en train de réaliser qu'en fait la différence de précision du découpage des bâtiments entre ceux d'OSM et ceux d'ODP ne viendrait pas de tes "simplifications" (à vrai dire j'en vois pas dans le 12e) mais tout simplement du fait que le découpage du cadastre est *à la base* beaucoup moins précis que celui d'ODP ! 

Pour comparaison avec celui d'OSM (et donc du cadastre) : https://www.openstreetmap.org/#map=19/48.84589/2.39445

Du coup je pense que ça serait une grosse valeur ajoutée si on pouvait affiner le découpage en rajoutant tous ces building:parts. Surtout en sachant qu'on aura forcément la hauteur pour chacun des building:parts, cela permettra d'avoir une modélisation 3D de Paris bien réaliste.

 

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Hauteur et nombre d'étages des bâtiments

verdy_p


Le 18 avril 2015 14:26, Vincent Frison <[hidden email]> a écrit :
L'idée de Vincent est intéressante, en effet pour les buildings pour lesquels la correspondance serait trop faible je pourrais générer un fichier XML proposant des ajouts d'éléments building:parts. Ces fichiers seraient ensuite à merger manuellement avec les bâtiments existants. 

Cela ne sera pas super simple, parmi les nombreuses difficultés il faudra notamment régler un léger décalage de quelques mètres entre les bâtiments ODP et ceux existant dans OSM (et visiblement ce décalage est variable). Or le building OSM, qui ferait office de building "principal" est censé englober parfaitement les différents éléments building:part si j'ai bien compris.

Pas forcément, que fais tu des batiments dont la partie supérieure passe au dessus de la chaussée: au sol il y a plusieurs parties, mais aux étages le polygone est plus grand, puis ensuite peut avoir à nouveau des étages plus petits.

Chose courante également, le long de la rue il y a souvent un passage couvert par le bâtiment situé dessus (et ce ne sont pas seulement des balcons: la partie intérieure en rez de chaussée fait partie de la voirie publique pour former son trottoir, ou une partie essentielle, couverte par le bâtiment en surplomb (et il n'y a pas non plus forcément de poteaux de soutien posé entre ce trottoir couvert et la partie découverte de la rue, car le surplomb a son plancher suspendu au dessus et ne repose pas sur son extrémité mais sur des porteurs à l'intérieur).
 
D'ailleurs ça me parait plus logique si le building englobant est une relation plutôt qu'un way mais d'après la page Wiki (http://wiki.openstreetmap.org/wiki/Key:building:part) ça peut être une relation OU un way.

Avec une relation effectivement, on peut regrouper les différentes parties car ce regroupement n'est pas simple dès que ce n'est plus une simple tour ou pyarmide, dont la base a le plus large périmètre.

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Hauteur et nombre d'étages des bâtiments

Vincent Frison
Effectivement on peut avoir des buildings:parts qui peuvent dépasser. Mais je lancerai bientôt un nouveau sujet du discussion pour éclaircir tout ça et parler plus globalement de ce qu'on pourrait faire pour avoir un meilleur découpage des bâtiments que celui existant.

En attendant j'ai donc lancé mon programme d'import sur le serveur live (avec un score minimal de 80%) et voici quelques statistiques qui correspondent à celles que j'avais déjà envoyés : 

Total of loaded ODP imports: 352293
Total of matched ODP imports: 293527

Total of matched OSM buildings: 86723
Total of updated OSM buildings: 49004

Donc voila un peu plus de la moitié des immeubles parisiens ont donc maintenant leur nombre d'étage réel :)

Le souci c'est que ça a surtout bien marché pour les petits immeubles, pour les "gros" immeubles ça ne pouvait bien marcher à cause du découpage. A voir donc ce que l'on pourrait faire pour améliorer ceci...

Pour info j'ai créé sur le Wiki une page dédiée à cette import : http://wiki.openstreetmap.org/wiki/Paris,_France/Buildings_Heights_Import
J'ai aussi rajouté un petit paragraphe dans la page dédié à Paris : http://wiki.openstreetmap.org/wiki/Paris#Buildings_heights_.28source.3Ddata.paris.fr.29

Sinon je pensais également relancer les gars de PSS pour essayer d'avoir leur accord. Je rappelle que c'est une base de données de plus de 40 000 immeubles répartis sur toute la France. Mais sans parler des problèmes de licence c'est pas sûr que ça soit jouable techniquement car dans leur BD il n'y a pas les formes des immeubles mais juste leurs coordonnées (correspondant au centre des immeubles). Je ne pourrai donc plus calculer des "matching scores" basés sur les surfaces comme c'était le cas avec OpenDataParis.

Le 18 avril 2015 16:05, Philippe Verdy <[hidden email]> a écrit :


Le 18 avril 2015 14:26, Vincent Frison <[hidden email]> a écrit :
L'idée de Vincent est intéressante, en effet pour les buildings pour lesquels la correspondance serait trop faible je pourrais générer un fichier XML proposant des ajouts d'éléments building:parts. Ces fichiers seraient ensuite à merger manuellement avec les bâtiments existants. 

Cela ne sera pas super simple, parmi les nombreuses difficultés il faudra notamment régler un léger décalage de quelques mètres entre les bâtiments ODP et ceux existant dans OSM (et visiblement ce décalage est variable). Or le building OSM, qui ferait office de building "principal" est censé englober parfaitement les différents éléments building:part si j'ai bien compris.

Pas forcément, que fais tu des batiments dont la partie supérieure passe au dessus de la chaussée: au sol il y a plusieurs parties, mais aux étages le polygone est plus grand, puis ensuite peut avoir à nouveau des étages plus petits.

Chose courante également, le long de la rue il y a souvent un passage couvert par le bâtiment situé dessus (et ce ne sont pas seulement des balcons: la partie intérieure en rez de chaussée fait partie de la voirie publique pour former son trottoir, ou une partie essentielle, couverte par le bâtiment en surplomb (et il n'y a pas non plus forcément de poteaux de soutien posé entre ce trottoir couvert et la partie découverte de la rue, car le surplomb a son plancher suspendu au dessus et ne repose pas sur son extrémité mais sur des porteurs à l'intérieur).
 
D'ailleurs ça me parait plus logique si le building englobant est une relation plutôt qu'un way mais d'après la page Wiki (http://wiki.openstreetmap.org/wiki/Key:building:part) ça peut être une relation OU un way.

Avec une relation effectivement, on peut regrouper les différentes parties car ce regroupement n'est pas simple dès que ce n'est plus une simple tour ou pyarmide, dont la base a le plus large périmètre.

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr



_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Hauteur et nombre d'étages des bâtiments

David Crochet
Bonjour

Le 22/04/2015 14:32, Vincent Frison a écrit :
> Pour info j'ai créé sur le Wiki une page dédiée à cette import :
> http://wiki.openstreetmap.org/wiki/Paris,_France/Buildings_Heights_Import
> J'ai aussi rajouté un petit paragraphe dans la page dédié à Paris :
> http://wiki.openstreetmap.org/wiki/Paris#Buildings_heights_.28source.3Ddata.paris.fr.29

Peut-être une annonce sur le OSM-Weekly anglophone et francophone ?

Cordialement

--
David Crochet

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Hauteur et nombre d'étages des bâtiments

Vincent Frison
Le 22 avril 2015 18:34, David Crochet <[hidden email]> a écrit :
Bonjour

Le 22/04/2015 14:32, Vincent Frison a écrit :
Pour info j'ai créé sur le Wiki une page dédiée à cette import :
http://wiki.openstreetmap.org/wiki/Paris,_France/Buildings_Heights_Import
J'ai aussi rajouté un petit paragraphe dans la page dédié à Paris :
http://wiki.openstreetmap.org/wiki/Paris#Buildings_heights_.28source.3Ddata.paris.fr.29

Peut-être une annonce sur le OSM-Weekly anglophone et francophone ?

Pourquoi pas :)

J'ai laissé un message ici : http://www.weeklyosm.eu/fr/contact


_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
12