Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
Le 22 avril 2015 18:34, David Crochet david.croc...@free.fr 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 Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
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 verd...@wanadoo.fr a écrit : Le 18 avril 2015 14:26, Vincent Frison vincent.fri...@gmail.com 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 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] Hauteur et nombre d'étages des bâtiments
Le 18 avril 2015 14:26, Vincent Frison vincent.fri...@gmail.com 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 Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
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 ! Vous pouvez voir un découpage d'ODP ici par ex : http://opendata.paris.fr/explore/dataset/volumesbatisparis2011/?tab=maplocation=19,48.84598,2.39463 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 Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
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 Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
@Vincent Pottier: exactement ce que je défendais plus haut mais je me croyais seul :p Le Lundi 13 avril 2015 20h50, Vincent Pottier vpott...@gmail.com 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 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] Hauteur et nombre d'étages des bâtiments
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 Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
Le 13 avril 2015 20:50, Vincent Pottier vpott...@gmail.com 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 Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
Le 31 mars 2015 10:52, Vincent Frison vincent.fri...@gmail.com 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 Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
Le 2 avril 2015 16:00, Pieren pier...@gmail.com a écrit : 2015-04-02 11:13 GMT+02:00 Vincent Frison vincent.fri...@gmail.com: 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 impo...@osm.org 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 Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
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 vincent.fri...@gmail.com mailto:vincent.fri...@gmail.com 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.
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
2015-04-02 11:13 GMT+02:00 Vincent Frison vincent.fri...@gmail.com: 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 Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
2015-04-02 11:13 GMT+02:00 Vincent Frison vincent.fri...@gmail.com: 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 impo...@osm.org 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 Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
Le 30 mars 2015 21:24, Vincent Frison vincent.fri...@gmail.com a écrit : Le 30 mars 2015 20:59, erwan salomon r...@gmx.fr 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 Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
Le 26 mars 2015 23:23, Vincent Frison vincent.fri...@gmail.com 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 Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
Le 30 mars 2015 20:59, erwan salomon r...@gmx.fr 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 Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
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 vincent.fri...@gmail.com 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 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] Hauteur et nombre d'étages des bâtiments
Il n'y a qu'un seul bâtiment. Les premiers étages sont cubiques, et au delà du 3e, le reste du bâtiment à la forme d'une église nettement plus étroite que les étages inférieur. Vu de l'extérieur c'est un peu comme si on avait posé une chapelle sur un immeuble de bureau. Suffit de regarder sur gogol maps la représentation 3D est assez fidèle. Le 26 mars 2015 23:23, Vincent Frison vincent.fri...@gmail.com a écrit : Le 25 mars 2015 00:16, dHuy Pierre dh...@yahoo.fr a écrit : Si tu tags le building avec la hauteur la plus faible puis que tu dessine une bloc building:part=yes, building:levels=... Ça permet de dessiner les variétés de hauteur sans créer de nouveaux batiments mais des bouts de batiments. http://wiki.openstreetmap.org/wiki/Simple_3D_Buildings Oui je connaissais bien sûr les building:parts mais encore une fois mon programme n'a pas la prétention de faire du découpage.. Pour ce qui est de l'exemple, je t'invite à regarder l'historique de la zone https://www.openstreetmap.org/way/330517677 avec une logiciel de rendu 3D Arf j'avoue avoir du mal à comprendre la structure de cette église sur l’île Saint-Louis.. un bâtiment avec un bâtiment à l'intérieur de l'église ?? 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... ___ 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] Hauteur et nombre d'étages des bâtiments
Le 25 mars 2015 00:16, dHuy Pierre dh...@yahoo.fr a écrit : Si tu tags le building avec la hauteur la plus faible puis que tu dessine une bloc building:part=yes, building:levels=... Ça permet de dessiner les variétés de hauteur sans créer de nouveaux batiments mais des bouts de batiments. http://wiki.openstreetmap.org/wiki/Simple_3D_Buildings Oui je connaissais bien sûr les building:parts mais encore une fois mon programme n'a pas la prétention de faire du découpage.. Pour ce qui est de l'exemple, je t'invite à regarder l'historique de la zone https://www.openstreetmap.org/way/330517677 avec une logiciel de rendu 3D Arf j'avoue avoir du mal à comprendre la structure de cette église sur l’île Saint-Louis.. un bâtiment avec un bâtiment à l'intérieur de l'église ?? 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... ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
Le 25/03/2015 00:16, dHuy Pierre a écrit : Si tu tags le building avec la hauteur la plus faible puis que tu dessine une bloc building:part=yes, building:levels=... Ça permet de dessiner les variétés de hauteur sans créer de nouveaux batiments mais des bouts de batiments. http://wiki.openstreetmap.org/wiki/Simple_3D_Buildings Pour ce qui est de l'exemple, je t'invite à regarder l'historique de la zone https://www.openstreetmap.org/way/330517677 avec une logiciel de rendu 3D Pour le coup, c'est typiquement le genre d'endroit où le polygone 55314295 pourrait être découpé [1]. À voir l'imagerie aérienne, il semble que l'église ne remplisse que le polygone 330517677, c'est donc sur ce polygone uniquement que devraient être portés les tags amenity=place_of_worship... Il semble par ailleurs que la nef est plus large que celle cartographiée et que le transept nord va jusqu'à la rue. Le polygone 330517677 est taggé avec building:levels=6 . Il y a réellement 6 niveaux dans le bâtiment (dans ce cas, l'église serait à un des étages. J'en doute, mais ça existe ailleurs), ou c'est la hauteur de la nef qui correspond à une hauteur de bâtiment de 6 niveaux (et alors le tag n'est pas exact [2] ) ? [1] Voir http://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dplace_of_worship#Remarques [2] building:levels est une mesure du nombre de niveau hors combles et sous-sols, et non une mesure de hauteur. Voir http://wiki.openstreetmap.org/wiki/FR:Key:building:levels -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
Les building:part c'est très bien quand on découpe les buildings. Je doute qu'on puisse automatiser leur création à partir de géométries différentes (si on les a, ce qui n'est pas forcément le cas). Scripter et automatiser... avec prudence et si c'est pour ajouter une donnée imprécise en collant des fixme, je pense que ça n'est pas souhaitable. Des trucs avec des fixme on en a encore de grosses pelletés alors que ça a été intégré il y a des années (je pense aux points d'eau à Paris). Il n'y a que dans les cas où le rapprochement est quasi parfait (par exemple surface de bâtiment identique à quelques % près) qu'on devrait s'aider d'un automatisme... pour le reste: huile de coude ! Le 25/03/2015 09:56, dHuy Pierre a écrit : Hors-Topic Huhu effectivement, tu me fais remarquer une erreur que j'ai faite à ce moment là. Je visiterai quand je pourrai pour voir. Mais l'objectif était de montrer que si tu te bases sur le dessin de base (modifié par moi) ça risquait de faire disparaitre l'eglise. Sinon je connais bien l'usage de building:levels et la différence avec height :) J'ai fait l'essentiel du travail à la main pour le coup et je n'ai pas fait attention aux tags autour. /Hors-Topic Mais du coup, que penses tu des building:part? Le Mercredi 25 mars 2015 9h47, Vincent Pottier vpott...@gmail.com a écrit : Le 25/03/2015 00:16, dHuy Pierre a écrit : Si tu tags le building avec la hauteur la plus faible puis que tu dessine une bloc building:part=yes, building:levels=... Ça permet de dessiner les variétés de hauteur sans créer de nouveaux batiments mais des bouts de batiments. http://wiki.openstreetmap.org/wiki/Simple_3D_Buildings Pour ce qui est de l'exemple, je t'invite à regarder l'historique de la zone https://www.openstreetmap.org/way/330517677 avec une logiciel de rendu 3D Pour le coup, c'est typiquement le genre d'endroit où le polygone 55314295 pourrait être découpé [1]. À voir l'imagerie aérienne, il semble que l'église ne remplisse que le polygone 330517677, c'est donc sur ce polygone uniquement que devraient être portés les tags amenity=place_of_worship... Il semble par ailleurs que la nef est plus large que celle cartographiée et que le transept nord va jusqu'à la rue. Le polygone 330517677 est taggé avec building:levels=6 . Il y a réellement 6 niveaux dans le bâtiment (dans ce cas, l'église serait à un des étages. J'en doute, mais ça existe ailleurs), ou c'est la hauteur de la nef qui correspond à une hauteur de bâtiment de 6 niveaux (et alors le tag n'est pas exact [2] ) ? [1] Voir http://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dplace_of_worship#Remarques [2] building:levels est une mesure du nombre de niveau hors combles et sous-sols, et non une mesure de hauteur. Voir http://wiki.openstreetmap.org/wiki/FR:Key:building:levels -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto: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 -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
Hors-TopicHuhu effectivement, tu me fais remarquer une erreur que j'ai faite à ce moment là. Je visiterai quand je pourrai pour voir. Mais l'objectif était de montrer que si tu te bases sur le dessin de base (modifié par moi) ça risquait de faire disparaitre l'eglise.Sinon je connais bien l'usage de building:levels et la différence avec height :) J'ai fait l'essentiel du travail à la main pour le coup et je n'ai pas fait attention aux tags autour./Hors-TopicMais du coup, que penses tu des building:part? Le Mercredi 25 mars 2015 9h47, Vincent Pottier vpott...@gmail.com a écrit : Le 25/03/2015 00:16, dHuy Pierre a écrit : Si tu tags le building avec la hauteur la plus faible puis que tu dessine une bloc building:part=yes, building:levels=... Ça permet de dessiner les variétés de hauteur sans créer de nouveaux batiments mais des bouts de batiments. http://wiki.openstreetmap.org/wiki/Simple_3D_Buildings Pour ce qui est de l'exemple, je t'invite à regarder l'historique de la zone https://www.openstreetmap.org/way/330517677 avec une logiciel de rendu 3D Pour le coup, c'est typiquement le genre d'endroit où le polygone 55314295 pourrait être découpé [1]. À voir l'imagerie aérienne, il semble que l'église ne remplisse que le polygone 330517677, c'est donc sur ce polygone uniquement que devraient être portés les tags amenity=place_of_worship... Il semble par ailleurs que la nef est plus large que celle cartographiée et que le transept nord va jusqu'à la rue. Le polygone 330517677 est taggé avec building:levels=6 . Il y a réellement 6 niveaux dans le bâtiment (dans ce cas, l'église serait à un des étages. J'en doute, mais ça existe ailleurs), ou c'est la hauteur de la nef qui correspond à une hauteur de bâtiment de 6 niveaux (et alors le tag n'est pas exact [2] ) ? [1] Voirhttp://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dplace_of_worship#Remarques [2] building:levels est une mesure du nombre de niveau hors combles et sous-sols, et non une mesure de hauteur. Voir http://wiki.openstreetmap.org/wiki/FR:Key:building:levels -- FrViPofm ___ 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] Hauteur et nombre d'étages des bâtiments
Le 25/03/2015 09:56, dHuy Pierre a écrit : Hors-Topic Huhu effectivement, tu me fais remarquer une erreur que j'ai faite à ce moment là. Je visiterai quand je pourrai pour voir. Mais l'objectif était de montrer que si tu te bases sur le dessin de base (modifié par moi) ça risquait de faire disparaitre l'eglise. Sinon je connais bien l'usage de building:levels et la différence avec height :) J'ai fait l'essentiel du travail à la main pour le coup et je n'ai pas fait attention aux tags autour. Mille excuses. À regarder de plus près l'imagerie aériene, il semble bien que l'église soit tout le bâtiment taggé comme tel (sauf peut-être le rectangle à l'est qui doit être une sacristie, un presbytère). Je n'avais pas repéré les colatéraux nords et sud. /Hors-Topic Mais du coup, que penses tu des building:part? C'est bien destiné à ça : porter des indications sur des parties de bâtiment. Notamment la hauteur, mais en height, pas en building:levels. Pour le building part central (en croix latine), il faudrait le diviser en deux : un axé ouest-est pour la nef, et un axé nord-sud pour le transept. Voir comment est cartographiée la cathédrale à proximité. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
Le 25/03/2015 10:08, Christian Quest a écrit : Les building:part c'est très bien quand on découpe les buildings. Je doute qu'on puisse automatiser leur création à partir de géométries différentes (si on les a, ce qui n'est pas forcément le cas). Scripter et automatiser... avec prudence et si c'est pour ajouter une donnée imprécise en collant des fixme, je pense que ça n'est pas souhaitable. Des trucs avec des fixme on en a encore de grosses pelletés alors que ça a été intégré il y a des années (je pense aux points d'eau à Paris). Il n'y a que dans les cas où le rapprochement est quasi parfait (par exemple surface de bâtiment identique à quelques % près) qu'on devrait s'aider d'un automatisme... pour le reste: huile de coude ! +1 genre : * Quand correspondance des bâtiments à qq %, travail pour le bot. * Quand variation plus importante ou plusieurs valeurs pour un même polygone OSM, génération de fichier d'intégration. C'était un peu la méthodologie CLC, non ? -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
building:part s'utilise très bien avec minlevel et levels...Pour l'église j'avais fait un travail de pure intégration donc je verrais irl (faut que je fasse un tour pour noter les toitures).Sinon +1 pour l'intégration quand la shape correspond exactement (modulo quelques %) au building. Le Mercredi 25 mars 2015 10h26, Vincent Pottier vpott...@gmail.com a écrit : Le 25/03/2015 10:08, Christian Quest a écrit : Les building:part c'est très bien quand on découpe les buildings. Je doute qu'on puisse automatiser leur création à partir de géométries différentes (si on les a, ce qui n'est pas forcément le cas). Scripter et automatiser... avec prudence et si c'est pour ajouter une donnée imprécise en collant des fixme, je pense que ça n'est pas souhaitable. Des trucs avec des fixme on en a encore de grosses pelletés alors que ça a été intégré il y a des années (je pense aux points d'eau à Paris). Il n'y a que dans les cas où le rapprochement est quasi parfait (par exemple surface de bâtiment identique à quelques % près) qu'on devrait s'aider d'un automatisme... pour le reste: huile de coude ! +1 genre : * Quand correspondance des bâtiments à qq %, travail pour le bot. * Quand variation plus importante ou plusieurs valeurs pour un même polygone OSM, génération de fichier d'intégration. C'était un peu la méthodologie CLC, non ? -- FrViPofm ___ 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] Hauteur et nombre d'étages des bâtiments
Le 24 mars 2015 20:30, dHuy Pierre dh...@yahoo.fr a écrit : Francescu décrit assez bien le type de situation qui m'effraie. Sur l'île St Louis par exemple, il y avait une Eglise imbriqué dans un batiment, l'église était supérieur au reste mais de surface inférieur. Avec ton logiciel ça ferait disparaitre l'eglise... Autre exemple une coupole isolée (ça aussi ça existe sur le terrain). Etc... Hmm je vois pas dans quel cas ça pourrait faire disparaître un bâtiment.. t'aurais un lieu précis à m'indiquer stp ? Plutôt que de t'attaquer au building, pourquoi ne pas utiliser building:part? Il est parfaitement normé et t'éviteras les approximations. Je ne suis pas sûr de bien comprendre.. mais encore une fois mon programme ne crée pas ou ne découpe pas des bâtiments, ça serait une tâche bien plus compliquée... Actuellement le programme lit les bâtiments importés et essaye de les faire correspondre avec des bâtiment existants d'OSM pour éventuellement rajouter un tag un tags levels=* ou height=* (seulement si le bâtiment n'en possède pas encore donc à priori je ne vais pas saccager le travail des cartographes de l'île de la Cité). D'ailleurs Jếrôme tu as remarqué que j'ai fait plusieurs updates avec différents tags levels. C'est parce que je met à jour l'immeuble dès que je trouve un import qui le match géographiquement. Mais si par la suite je tombe sur un nouvel import qui match encore mieux alors je fais une nouvelle mise à jour (mais si vraiment ça pose problème je pourrais me débrouiller pour ne faire qu'une seule mise à jour, celle du meilleur candidat tant qu'à faire ;p). Et comme tu l'as dis rien n'empêche d'autres contributeurs d'améliorer le travail par la suite. D'ailleurs pour reprendre l'idée de Vincent je pourrais rajouter pour faciliter le travail des contributeurs un tag fixme pour les bâtiments trop tendancieux. Je pourrais par exemple poser ce tag dans le cas où le score du meilleur bâtiment importé ne dépasse pas les 80% (ie. parmi les bâtiments d'ODP le meilleur candidat a une surface dont le ratio avec la surface du bâtiment d'OSM est inférieur à 0.8). Sinon attention delta entre osm et la db de l'opendata, un toit/grenier n'est pas considéré comme level sur osm! Oui je rajoute déjà +1 au nombre d'étage puisque OSM compte les étages à l'américaine ;) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
Le 24 mars 2015 23:13, Vincent Frison vincent.fri...@gmail.com a écrit : Le 24 mars 2015 20:30, dHuy Pierre dh...@yahoo.fr a écrit : Francescu décrit assez bien le type de situation qui m'effraie. Sur l'île St Louis par exemple, il y avait une Eglise imbriqué dans un batiment, l'église était supérieur au reste mais de surface inférieur. Avec ton logiciel ça ferait disparaitre l'eglise... Autre exemple une coupole isolée (ça aussi ça existe sur le terrain). Etc... Hmm je vois pas dans quel cas ça pourrait faire disparaître un bâtiment.. t'aurais un lieu précis à m'indiquer stp ? Plutôt que de t'attaquer au building, pourquoi ne pas utiliser building:part? Il est parfaitement normé et t'éviteras les approximations. Je ne suis pas sûr de bien comprendre.. mais encore une fois mon programme ne crée pas ou ne découpe pas des bâtiments, ça serait une tâche bien plus compliquée... Actuellement le programme lit les bâtiments importés et essaye de les faire correspondre avec des bâtiment existants d'OSM pour éventuellement rajouter un tag un tags levels=* ou height=* (seulement si le bâtiment n'en possède pas encore donc à priori je ne vais pas saccager le travail des cartographes de l'île de la Cité). D'ailleurs Jếrôme tu as remarqué que j'ai fait plusieurs updates avec différents tags levels. C'est parce que je met à jour l'immeuble dès que je trouve un import qui le match géographiquement. Mais si par la suite je tombe sur un nouvel import qui match encore mieux alors je fais une nouvelle mise à jour (mais si vraiment ça pose problème je pourrais me débrouiller pour ne faire qu'une seule mise à jour, celle du meilleur candidat tant qu'à faire ;p). Je pense qu'un seul changement par bâtiment c'est mieux, plus facile a comprendre pour quelqu'un regardant l'historique par la suite ou voulant revenir à l'ancienne version. Et comme tu l'as dis rien n'empêche d'autres contributeurs d'améliorer le travail par la suite. D'ailleurs pour reprendre l'idée de Vincent je pourrais rajouter pour faciliter le travail des contributeurs un tag fixme pour les bâtiments trop tendancieux. Je pourrais par exemple poser ce tag dans le cas où le score du meilleur bâtiment importé ne dépasse pas les 80% (ie. parmi les bâtiments d'ODP le meilleur candidat a une surface dont le ratio avec la surface du bâtiment d'OSM est inférieur à 0.8). Sinon attention delta entre osm et la db de l'opendata, un toit/grenier n'est pas considéré comme level sur osm! Oui je rajoute déjà +1 au nombre d'étage puisque OSM compte les étages à l'américaine ;) ___ 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] Hauteur et nombre d'étages des bâtiments
Si tu tags le building avec la hauteur la plus faible puis que tu dessine une bloc building:part=yes, building:levels=... Ça permet de dessiner les variétés de hauteur sans créer de nouveaux batiments mais des bouts de batiments.http://wiki.openstreetmap.org/wiki/Simple_3D_Buildings Pour ce qui est de l'exemple, je t'invite à regarder l'historique de la zone https://www.openstreetmap.org/way/330517677 avec une logiciel de rendu 3D Le Mardi 24 mars 2015 23h13, Vincent Frison vincent.fri...@gmail.com a écrit : Le 24 mars 2015 20:30, dHuy Pierre dh...@yahoo.fr a écrit : Francescu décrit assez bien le type de situation qui m'effraie. Sur l'île St Louis par exemple, il y avait une Eglise imbriqué dans un batiment, l'église était supérieur au reste mais de surface inférieur. Avec ton logiciel ça ferait disparaitre l'eglise... Autre exemple une coupole isolée (ça aussi ça existe sur le terrain). Etc... Hmm je vois pas dans quel cas ça pourrait faire disparaître un bâtiment.. t'aurais un lieu précis à m'indiquer stp ? Plutôt que de t'attaquer au building, pourquoi ne pas utiliser building:part? Il est parfaitement normé et t'éviteras les approximations. Je ne suis pas sûr de bien comprendre.. mais encore une fois mon programme ne crée pas ou ne découpe pas des bâtiments, ça serait une tâche bien plus compliquée... Actuellement le programme lit les bâtiments importés et essaye de les faire correspondre avec des bâtiment existants d'OSM pour éventuellement rajouter un tag un tags levels=* ou height=* (seulement si le bâtiment n'en possède pas encore donc à priori je ne vais pas saccager le travail des cartographes de l'île de la Cité). D'ailleurs Jếrôme tu as remarqué que j'ai fait plusieurs updates avec différents tags levels. C'est parce que je met à jour l'immeuble dès que je trouve un import qui le match géographiquement. Mais si par la suite je tombe sur un nouvel import qui match encore mieux alors je fais une nouvelle mise à jour (mais si vraiment ça pose problème je pourrais me débrouiller pour ne faire qu'une seule mise à jour, celle du meilleur candidat tant qu'à faire ;p). Et comme tu l'as dis rien n'empêche d'autres contributeurs d'améliorer le travail par la suite. D'ailleurs pour reprendre l'idée de Vincent je pourrais rajouter pour faciliter le travail des contributeurs un tag fixme pour les bâtiments trop tendancieux. Je pourrais par exemple poser ce tag dans le cas où le score du meilleur bâtiment importé ne dépasse pas les 80% (ie. parmi les bâtiments d'ODP le meilleur candidat a une surface dont le ratio avec la surface du bâtiment d'OSM est inférieur à 0.8). Sinon attention delta entre osm et la db de l'opendata, un toit/grenier n'est pas considéré comme level sur osm! Oui je rajoute déjà +1 au nombre d'étage puisque OSM compte les étages à l'américaine ;) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
Francescu décrit assez bien le type de situation qui m'effraie. Sur l'île St Louis par exemple, il y avait une Eglise imbriqué dans un batiment, l'église était supérieur au reste mais de surface inférieur. Avec ton logiciel ça ferait disparaitre l'eglise... Autre exemple une coupole isolée (ça aussi ça existe sur le terrain). Etc...Plutôt que de t'attaquer au building, pourquoi ne pas utiliser building:part? Il est parfaitement normé et t'éviteras les approximations.Sinon attention delta entre osm et la db de l'opendata, un toit/grenier n'est pas considéré comme level sur osm! Le Mardi 24 mars 2015 8h39, Francescu GAROBY windu...@gmail.com a écrit : Bonjour,Pour ton exemple de 2 immeubles, l'un de 8 et l'autre de 5 étages, représentés comme un seul bâtiment dans OSM : ne pourrait-on pas imaginer que ton script propose de découper cet immeuble en 2, de façon à ce que la superficie de chacun colle avec ce qu'ODP connaît ?En écrivant ça, je réalise que cela signifierait alors que la coupure ne suivrait pas forcément la réalité (un mur de séparation qui zigzaguerait, par exemple). Mais cela aurait au moins le mérite d'éviter d'avoir 2 immeubles dont l'un est trop haut (si c'est le 8 étages qui est retenu par ton script actuel) ou trop bas (si c'est le 5 étages). Francescu Le 23 mars 2015 21:27, Vincent Frison vincent.fri...@gmail.com a écrit : Le 23 mars 2015 16:21, dHuy Pierre dh...@yahoo.fr a écrit : Inclus-tu les batiments pouvant avoir plusieurs étages? Parce qu'après avoir regarder cette base c'est souvent le cas! Tout dépend ce qu'il y a déjà dans OSM. Mon programme ne rajoute pas ou ne découpe de bâtiment, il rajoute juste des tags sur des bâtiments déjà existants dans OSM. Si un bâtiment a plusieurs étages il y aura à coup sûr plusieurs bâtiments dans la base d'OpenDataParis (ODP) car effectivement cette dernière possède un découpage extrêmement précis des bâtiments (plus de 300 000 volumes bâtis !!), bien plus que le découpage des bâtiments d'OSM. Imaginons un bâtiment de 8 étages collé à un autre de 5 étages. Si il y a déjà un découpage en 2 bâtiments dans OSM, ça va coller nickel. Sinon ça sera une simplification : si OSM n'a qu'a seul bâtiment pour représenter ces 2 immeubles alors il faudra choisir, 5 ou 8 étages. Mais comme je regarde les surfaces et ça sera le bâtiment d'ODP qui aura la surface la plus proche du bâtiment d'OSM qui sera pris en compte. C'est donc une simplification et dans l'idéal il faudrait découper le bâtiment d'OSM en 2 bâtiments mais c'est pas ce que fait mon programme. N'hésitez pas à regarder le résultat sur la zone de test entre Bastille et Nation pour vérifier des cas concrets. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Francescu ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
Bonjour, Pour ton exemple de 2 immeubles, l'un de 8 et l'autre de 5 étages, représentés comme un seul bâtiment dans OSM : ne pourrait-on pas imaginer que ton script propose de découper cet immeuble en 2, de façon à ce que la superficie de chacun colle avec ce qu'ODP connaît ? En écrivant ça, je réalise que cela signifierait alors que la coupure ne suivrait pas forcément la réalité (un mur de séparation qui zigzaguerait, par exemple). Mais cela aurait au moins le mérite d'éviter d'avoir 2 immeubles dont l'un est trop haut (si c'est le 8 étages qui est retenu par ton script actuel) ou trop bas (si c'est le 5 étages). Francescu Le 23 mars 2015 21:27, Vincent Frison vincent.fri...@gmail.com a écrit : Le 23 mars 2015 16:21, dHuy Pierre dh...@yahoo.fr a écrit : Inclus-tu les batiments pouvant avoir plusieurs étages? Parce qu'après avoir regarder cette base c'est souvent le cas! Tout dépend ce qu'il y a déjà dans OSM. Mon programme ne rajoute pas ou ne découpe de bâtiment, il rajoute juste des tags sur des bâtiments déjà existants dans OSM. Si un bâtiment a plusieurs étages il y aura à coup sûr plusieurs bâtiments dans la base d'OpenDataParis (ODP) car effectivement cette dernière possède un découpage extrêmement précis des bâtiments (plus de 300 000 volumes bâtis !!), bien plus que le découpage des bâtiments d'OSM. Imaginons un bâtiment de 8 étages collé à un autre de 5 étages. Si il y a déjà un découpage en 2 bâtiments dans OSM, ça va coller nickel. Sinon ça sera une simplification : si OSM n'a qu'a seul bâtiment pour représenter ces 2 immeubles alors il faudra choisir, 5 ou 8 étages. Mais comme je regarde les surfaces et ça sera le bâtiment d'ODP qui aura la surface la plus proche du bâtiment d'OSM qui sera pris en compte. C'est donc une simplification et dans l'idéal il faudrait découper le bâtiment d'OSM en 2 bâtiments mais c'est pas ce que fait mon programme. N'hésitez pas à regarder le résultat sur la zone de test entre Bastille et Nation pour vérifier des cas concrets. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Francescu ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
Hello, Comme je l'avais indiqué il y a quelques temps sur cette ML j'ai développé un petit programme permettant l'importation de base de données avec des hauteurs d'immeubles (véritable hauteur en mètre ou juste nombre d'étages). A la base c'était pour importer la base de donnée de http://www.pss-archi.eu (environ 40 000 immeubles répartis sur l'ensemble de la France) mais finalement j'ai commencé par les données de http://opendata.paris.fr. Cette dernière BD a l'avantage d'être complètement libre et elle contient 320 000 volumes bâtis parisiens avec leur nombre d'étage. Voici très grossièrement le fonctionnement: du programme - pour faire la correspondance avec les éléments d'OSM je regarde tout simplement si leur polygone contient (fonction ST_Contains de PostGIS) les coordonnées des bâtiments importés - si le bâtiment OSM a déjà un tag de hauteur ou de nombre d'étages je n'y touche pas - s'il y a plusieurs imports qui matchent le même bâtiment OSM c'est celui dont la surface se rapproche le plus du bâtiment OSM qui gagne - si un import match une relation multipolygone : s'il y a un et un seul membre outer (la grosse majorité des cas) je le met à jour, sinon je ne fais rien (pour l'instant) J'ai testé le programme sur la base de test avec une zone couvrant Bastille / Gare de Lyon / Nation et cela se passe plutôt pas mal : environ 2400 immeubles (sur 2500 matchés) ont été mis à jour, soit quasiment tous les immeubles de la zone concernée. Vous pouvez voir le résultat avec JOSM par ex. en le faisant pointer sur http://api06.dev.openstreetmap.org (éventuellement avec le plugin Kenzi3D pour avoir un rendu 3D). Maintenant j'aimerais avoir vos conseils pour la suite : - dans quelle mesure dois je pousser mes tests avant de pouvoir prétendre les appliquer en live ? - quelles précautions à prendre pour pouvoir éventuellement rollbacker mes changements sans trop de complications ? - dois je demander une autorisation spéciale avant de faire des modifications en masse sur le serveur live ? Pour le 2e point j'imagine que ça sera possible dans la mesure où j'aurais des changesets bien définis (ie. avec les mêmes tags source et comment) ainsi qu'un compte utilisateur créé pour l'occasion (différent de mon compte personnel). Merci pour votre aide, Vincent. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
Inclus-tu les batiments pouvant avoir plusieurs étages? Parce qu'après avoir regarder cette base c'est souvent le cas! Le Lundi 23 mars 2015 11h56, Vincent Frison vincent.fri...@gmail.com a écrit : Hello, Comme je l'avais indiqué il y a quelques temps sur cette ML j'ai développé un petit programme permettant l'importation de base de données avec des hauteurs d'immeubles (véritable hauteur en mètre ou juste nombre d'étages). A la base c'était pour importer la base de donnée de http://www.pss-archi.eu (environ 40 000 immeubles répartis sur l'ensemble de la France) mais finalement j'ai commencé par les données de http://opendata.paris.fr. Cette dernière BD a l'avantage d'être complètement libre et elle contient 320 000 volumes bâtis parisiens avec leur nombre d'étage. Voici très grossièrement le fonctionnement: du programme- pour faire la correspondance avec les éléments d'OSM je regarde tout simplement si leur polygone contient (fonction ST_Contains de PostGIS) les coordonnées des bâtiments importés- si le bâtiment OSM a déjà un tag de hauteur ou de nombre d'étages je n'y touche pas- s'il y a plusieurs imports qui matchent le même bâtiment OSM c'est celui dont la surface se rapproche le plus du bâtiment OSM qui gagne- si un import match une relation multipolygone : s'il y a un et un seul membre outer (la grosse majorité des cas) je le met à jour, sinon je ne fais rien (pour l'instant) J'ai testé le programme sur la base de test avec une zone couvrant Bastille / Gare de Lyon / Nation et cela se passe plutôt pas mal : environ 2400 immeubles (sur 2500 matchés) ont été mis à jour, soit quasiment tous les immeubles de la zone concernée.Vous pouvez voir le résultat avec JOSM par ex. en le faisant pointer sur http://api06.dev.openstreetmap.org (éventuellement avec le plugin Kenzi3D pour avoir un rendu 3D). Maintenant j'aimerais avoir vos conseils pour la suite : - dans quelle mesure dois je pousser mes tests avant de pouvoir prétendre les appliquer en live ?- quelles précautions à prendre pour pouvoir éventuellement rollbacker mes changements sans trop de complications ?- dois je demander une autorisation spéciale avant de faire des modifications en masse sur le serveur live ? Pour le 2e point j'imagine que ça sera possible dans la mesure où j'aurais des changesets bien définis (ie. avec les mêmes tags source et comment) ainsi qu'un compte utilisateur créé pour l'occasion (différent de mon compte personnel). Merci pour votre aide, Vincent. ___ 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] Hauteur et nombre d'étages des bâtiments
Le 23/03/2015 21:27, Vincent Frison a écrit : Mon programme ne rajoute pas ou ne découpe de bâtiment, il rajoute juste des tags sur des bâtiments déjà existants dans OSM. Si un bâtiment a plusieurs étages il y aura à coup sûr plusieurs bâtiments dans la base d'OpenDataParis (ODP) car effectivement cette dernière possède un découpage extrêmement précis des bâtiments (plus de 300 000 volumes bâtis !!), bien plus que le découpage des bâtiments d'OSM. Imaginons un bâtiment de 8 étages collé à un autre de 5 étages. Si il y a déjà un découpage en 2 bâtiments dans OSM, ça va coller nickel. Sinon ça sera une simplification : si OSM n'a qu'a seul bâtiment pour représenter ces 2 immeubles alors il faudra choisir, 5 ou 8 étages. Mais comme je regarde les surfaces et ça sera le bâtiment d'ODP qui aura la surface la plus proche du bâtiment d'OSM qui sera pris en compte. C'est donc une simplification et dans l'idéal il faudrait découper le bâtiment d'OSM en 2 bâtiments mais c'est pas ce que fait mon programme. N'hésitez pas à regarder le résultat sur la zone de test entre Bastille et Nation pour vérifier des cas concrets. En enregistrant le résultat de tes programmes, non en base OSM, mais dans des fichiers au format .osm, mis ensuite à disposition, tu rendrais possible plusieurs aspects : - le contrôle a priori, chacun ayant le loisir d'inspecter un fichier _avant_ que ses modifs ne soient en base - la répartition du travail : on peut imaginer un lotissement par pâté de maisons, feuille cadastrale, ou autre segmentation, ce qui ouvre la possibilité d'un travail coordonné comme ça existe déjà sur d'autres sujets - la mise en évidence de divergences entre les bâtis attendus et ceux trouvés dans OSM, comme dans ton exemple ci-dessus. Rien n'oblige à appliquer des tags en cherchant un critère d'affectation à tout prix. Devant une ambiguïté, on peut imaginer un signalement directement dans les fichiers mis à disposition, sous forme de tag fixme par exemple. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
Le 23 mars 2015 16:21, dHuy Pierre dh...@yahoo.fr a écrit : Inclus-tu les batiments pouvant avoir plusieurs étages? Parce qu'après avoir regarder cette base c'est souvent le cas! Tout dépend ce qu'il y a déjà dans OSM. Mon programme ne rajoute pas ou ne découpe de bâtiment, il rajoute juste des tags sur des bâtiments déjà existants dans OSM. Si un bâtiment a plusieurs étages il y aura à coup sûr plusieurs bâtiments dans la base d'OpenDataParis (ODP) car effectivement cette dernière possède un découpage extrêmement précis des bâtiments (plus de 300 000 volumes bâtis !!), bien plus que le découpage des bâtiments d'OSM. Imaginons un bâtiment de 8 étages collé à un autre de 5 étages. Si il y a déjà un découpage en 2 bâtiments dans OSM, ça va coller nickel. Sinon ça sera une simplification : si OSM n'a qu'a seul bâtiment pour représenter ces 2 immeubles alors il faudra choisir, 5 ou 8 étages. Mais comme je regarde les surfaces et ça sera le bâtiment d'ODP qui aura la surface la plus proche du bâtiment d'OSM qui sera pris en compte. C'est donc une simplification et dans l'idéal il faudrait découper le bâtiment d'OSM en 2 bâtiments mais c'est pas ce que fait mon programme. N'hésitez pas à regarder le résultat sur la zone de test entre Bastille et Nation pour vérifier des cas concrets. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
Effectivement, si tu fais ça, ça serait uploader des données erronées si tu le fais directement... C'est un travail minutieux que de cartographier les volumes, ça sert ensuite pour mettre en place une visualisation 3D et une erreur sur ces datas provoquera, une erreur dans la visualisation et réduira conséquemment l'appréciation d'osm pour ce type de données, alors qu'à Paris de nombreux cartographes y travaillent (jette un oeil à Cité).Librement, Le Lundi 23 mars 2015 23h38, Vincent de Château-Thierry v...@laposte.net a écrit : Le 23/03/2015 21:27, Vincent Frison a écrit : Mon programme ne rajoute pas ou ne découpe de bâtiment, il rajoute juste des tags sur des bâtiments déjà existants dans OSM. Si un bâtiment a plusieurs étages il y aura à coup sûr plusieurs bâtiments dans la base d'OpenDataParis (ODP) car effectivement cette dernière possède un découpage extrêmement précis des bâtiments (plus de 300 000 volumes bâtis !!), bien plus que le découpage des bâtiments d'OSM. Imaginons un bâtiment de 8 étages collé à un autre de 5 étages. Si il y a déjà un découpage en 2 bâtiments dans OSM, ça va coller nickel. Sinon ça sera une simplification : si OSM n'a qu'a seul bâtiment pour représenter ces 2 immeubles alors il faudra choisir, 5 ou 8 étages. Mais comme je regarde les surfaces et ça sera le bâtiment d'ODP qui aura la surface la plus proche du bâtiment d'OSM qui sera pris en compte. C'est donc une simplification et dans l'idéal il faudrait découper le bâtiment d'OSM en 2 bâtiments mais c'est pas ce que fait mon programme. N'hésitez pas à regarder le résultat sur la zone de test entre Bastille et Nation pour vérifier des cas concrets. En enregistrant le résultat de tes programmes, non en base OSM, mais dans des fichiers au format .osm, mis ensuite à disposition, tu rendrais possible plusieurs aspects : - le contrôle a priori, chacun ayant le loisir d'inspecter un fichier _avant_ que ses modifs ne soient en base - la répartition du travail : on peut imaginer un lotissement par pâté de maisons, feuille cadastrale, ou autre segmentation, ce qui ouvre la possibilité d'un travail coordonné comme ça existe déjà sur d'autres sujets - la mise en évidence de divergences entre les bâtis attendus et ceux trouvés dans OSM, comme dans ton exemple ci-dessus. Rien n'oblige à appliquer des tags en cherchant un critère d'affectation à tout prix. Devant une ambiguïté, on peut imaginer un signalement directement dans les fichiers mis à disposition, sous forme de tag fixme par exemple. vincent ___ 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] Hauteur et nombre d'étages des bâtiments
ça améliore pas mal les données mais il y a des inexactitudes donc c'est mauvais d’après toi. (réaction que j'ai déjà vu ici sur d'autres types de données). d’après ce qui a été dit il ne touche pas aux bâtiments avec déjà des tags de hauteur et rien n’empêche que d'autres contributeurs n’améliore se qui a déjà été touché par son script. je n'y connais pas grand chose en import mais ce que j'ai compris : - pour l'importation il faut le faire à partir un compte dédié à l'import (un compte normale mais avec sur sa page une description de ce qui est importé.) - vu que c'est sur la France il faut en discuter ici Apres, je suis aller voir les données rapidement là http://api06.dev.openstreetmap.org/api/ (pour ceux qui ne savent pas comme moi il y a quelque minutes, dans josm, préférence, mettre cette adresse comme serveur où se connecter puis charger la zone modifié (une zone couvrant Bastille / Gare de Lyon / Nation)). on voit dans l'historique que tu as fais plusieurs passages qui modifies plusieurs fois les level pour certains building, j'ai pa Le 24 mars 2015 00:24, dHuy Pierre dh...@yahoo.fr a écrit : Effectivement, si tu fais ça, ça serait uploader des données erronées si tu le fais directement... C'est un travail minutieux que de cartographier les volumes, ça sert ensuite pour mettre en place une visualisation 3D et une erreur sur ces datas provoquera, une erreur dans la visualisation et réduira conséquemment l'appréciation d'osm pour ce type de données, alors qu'à Paris de nombreux cartographes y travaillent (jette un oeil à Cité). Librement, Le Lundi 23 mars 2015 23h38, Vincent de Château-Thierry v...@laposte.net a écrit : Le 23/03/2015 21:27, Vincent Frison a écrit : Mon programme ne rajoute pas ou ne découpe de bâtiment, il rajoute juste des tags sur des bâtiments déjà existants dans OSM. Si un bâtiment a plusieurs étages il y aura à coup sûr plusieurs bâtiments dans la base d'OpenDataParis (ODP) car effectivement cette dernière possède un découpage extrêmement précis des bâtiments (plus de 300 000 volumes bâtis !!), bien plus que le découpage des bâtiments d'OSM. Imaginons un bâtiment de 8 étages collé à un autre de 5 étages. Si il y a déjà un découpage en 2 bâtiments dans OSM, ça va coller nickel. Sinon ça sera une simplification : si OSM n'a qu'a seul bâtiment pour représenter ces 2 immeubles alors il faudra choisir, 5 ou 8 étages. Mais comme je regarde les surfaces et ça sera le bâtiment d'ODP qui aura la surface la plus proche du bâtiment d'OSM qui sera pris en compte. C'est donc une simplification et dans l'idéal il faudrait découper le bâtiment d'OSM en 2 bâtiments mais c'est pas ce que fait mon programme. N'hésitez pas à regarder le résultat sur la zone de test entre Bastille et Nation pour vérifier des cas concrets. En enregistrant le résultat de tes programmes, non en base OSM, mais dans des fichiers au format .osm, mis ensuite à disposition, tu rendrais possible plusieurs aspects : - le contrôle a priori, chacun ayant le loisir d'inspecter un fichier _avant_ que ses modifs ne soient en base - la répartition du travail : on peut imaginer un lotissement par pâté de maisons, feuille cadastrale, ou autre segmentation, ce qui ouvre la possibilité d'un travail coordonné comme ça existe déjà sur d'autres sujets - la mise en évidence de divergences entre les bâtis attendus et ceux trouvés dans OSM, comme dans ton exemple ci-dessus. Rien n'oblige à appliquer des tags en cherchant un critère d'affectation à tout prix. Devant une ambiguïté, on peut imaginer un signalement directement dans les fichiers mis à disposition, sous forme de tag fixme par exemple. vincent ___ 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
oups, partie sans la fin de ma phrase : j'ai pas vérifié quel level était le bon dans les données. Le 24 mars 2015 01:40, Jérôme Amagat jerome.ama...@gmail.com a écrit : ça améliore pas mal les données mais il y a des inexactitudes donc c'est mauvais d’après toi. (réaction que j'ai déjà vu ici sur d'autres types de données). d’après ce qui a été dit il ne touche pas aux bâtiments avec déjà des tags de hauteur et rien n’empêche que d'autres contributeurs n’améliore se qui a déjà été touché par son script. je n'y connais pas grand chose en import mais ce que j'ai compris : - pour l'importation il faut le faire à partir un compte dédié à l'import (un compte normale mais avec sur sa page une description de ce qui est importé.) - vu que c'est sur la France il faut en discuter ici Apres, je suis aller voir les données rapidement là http://api06.dev.openstreetmap.org/api/ (pour ceux qui ne savent pas comme moi il y a quelque minutes, dans josm, préférence, mettre cette adresse comme serveur où se connecter puis charger la zone modifié (une zone couvrant Bastille / Gare de Lyon / Nation)). on voit dans l'historique que tu as fais plusieurs passages qui modifies plusieurs fois les level pour certains building, j'ai pa Le 24 mars 2015 00:24, dHuy Pierre dh...@yahoo.fr a écrit : Effectivement, si tu fais ça, ça serait uploader des données erronées si tu le fais directement... C'est un travail minutieux que de cartographier les volumes, ça sert ensuite pour mettre en place une visualisation 3D et une erreur sur ces datas provoquera, une erreur dans la visualisation et réduira conséquemment l'appréciation d'osm pour ce type de données, alors qu'à Paris de nombreux cartographes y travaillent (jette un oeil à Cité). Librement, Le Lundi 23 mars 2015 23h38, Vincent de Château-Thierry v...@laposte.net a écrit : Le 23/03/2015 21:27, Vincent Frison a écrit : Mon programme ne rajoute pas ou ne découpe de bâtiment, il rajoute juste des tags sur des bâtiments déjà existants dans OSM. Si un bâtiment a plusieurs étages il y aura à coup sûr plusieurs bâtiments dans la base d'OpenDataParis (ODP) car effectivement cette dernière possède un découpage extrêmement précis des bâtiments (plus de 300 000 volumes bâtis !!), bien plus que le découpage des bâtiments d'OSM. Imaginons un bâtiment de 8 étages collé à un autre de 5 étages. Si il y a déjà un découpage en 2 bâtiments dans OSM, ça va coller nickel. Sinon ça sera une simplification : si OSM n'a qu'a seul bâtiment pour représenter ces 2 immeubles alors il faudra choisir, 5 ou 8 étages. Mais comme je regarde les surfaces et ça sera le bâtiment d'ODP qui aura la surface la plus proche du bâtiment d'OSM qui sera pris en compte. C'est donc une simplification et dans l'idéal il faudrait découper le bâtiment d'OSM en 2 bâtiments mais c'est pas ce que fait mon programme. N'hésitez pas à regarder le résultat sur la zone de test entre Bastille et Nation pour vérifier des cas concrets. En enregistrant le résultat de tes programmes, non en base OSM, mais dans des fichiers au format .osm, mis ensuite à disposition, tu rendrais possible plusieurs aspects : - le contrôle a priori, chacun ayant le loisir d'inspecter un fichier _avant_ que ses modifs ne soient en base - la répartition du travail : on peut imaginer un lotissement par pâté de maisons, feuille cadastrale, ou autre segmentation, ce qui ouvre la possibilité d'un travail coordonné comme ça existe déjà sur d'autres sujets - la mise en évidence de divergences entre les bâtis attendus et ceux trouvés dans OSM, comme dans ton exemple ci-dessus. Rien n'oblige à appliquer des tags en cherchant un critère d'affectation à tout prix. Devant une ambiguïté, on peut imaginer un signalement directement dans les fichiers mis à disposition, sous forme de tag fixme par exemple. vincent ___ 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
