Re: [OSM-talk-fr] Fichiers bâti cadastral ( était: Restreignons les imports des cours d'eau)
2012/10/3 Christian Quest cqu...@openstreetmap.fr: Il en était ainsi arrivé à la conclusion que la majorité des polygones de bâti faisait dans les 6m2, même pas la taille d'un garage (je vous passe le quart d'heure de délire où je lui ai expliqué que ça me suffisait pour garer ma Smart). Les statistiques et calculs il faut faire attention à ce qu'on fait et ce qu'on en fait pour ne pas leur faire dire n'importe quoi... La segmentation d'un bâtiment est très variable d'une commune à l'autre. Il faut aussi tenir compte des wall=no (qui eux aussi sont parfois segmentés). Il est aussi possible que la segmentation dépende de l'âge du bâti et du nombre d'extensions (je pense en particulier au corps de ferme qui a été abondamment cité comme exemple sur la liste principale) ou des pratiques du CDIF local. Il serait intéressant de faire un ratio polygones/habitants par commune et examiner celles qui en ont le plus. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Fichiers bâti cadastral (était: Restreignons les imports des cours d'eau)
Le 01/10/2012 14:03, Pieren a écrit : Pour finir, il faudrait lancer une réflexion sur le tag source et la taille considérable qu'il prend dans la base de donnée. Ja'i pensé à un tag spécial (source_id par ex.) qui utiliserait une valeur réservée. La valeur réservée serait par exemple un chiffre qui serait renseigné sur une page protégée du site osm.org (http://www.openstreetmap.org/credits). Il serait utilisable pour toutes les sources externes en général. L'ajout de nouvelles valeurs devrait être relativement aisé et ouvert mais pas les modifications sur des valeurs déjà utilisées. Par exemple source_id=22 où 22=cadastre blabla, année 2012. C'est une façon de faire un peu du foreign key sans modifier la structure de la base de donnée mais qui permettrait d'économiser des gigaoctets en disque et bande passante chez beaucoup de monde. Bien-sûr, on ne pourrait empêcher l'altération du tag ou sa suppression comme tous les autres tags mais il serait dans l'historique, ce qui nous fait respecter la clause de la dgfip. Bon, cette idée nécessiterait une discussion à une autre échelle que la notre mais vous en pensez quoi ? J'aime bien cette proposition. Pour l'économie de place dans la base de données, je prônerais l'abandon du tag source au niveau des objets pour ne les laisser qu'au niveau des changesets car la source est une information que l'on associe plus à une contribution qu'à un objet : un objet peut être modifié de multiples fois avec des sources différentes, ce n'est en général pas le cas d'un changeset. -- Benjamin -- View this message in context: http://gis.19327.n5.nabble.com/Fichiers-bati-cadastral-etait-Restreignons-les-imports-des-cours-d-eau-tp5728432p5728739.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Fichiers bâti cadastral (était: Restreignons les imports des cours d'eau)
2012/10/3 Benjamin C. benjamin.chart...@cegetel.net: je prônerais l'abandon du tag source au niveau des objets pour ne les laisser qu'au niveau des changesets car la source est une information que l'on associe plus à une contribution qu'à un objet : un objet peut être modifié de multiples fois avec des sources différentes, ce n'est en général pas le cas d'un changeset. Il y a plusieurs inconvénients à cette méthode: - ça n'est possible que si le changeset n'utilise qu'une seule source. Hors, l'intégration des données bâti supposent souvent l'utilisation d'autres sources (Bing) ou d'anciennes contributions (recopie des tags des anciens bâtiments déjà présents sous une forme ou une autre). - on ne peut pas modifier les tags d'un changeset une fois que celui-ci est fermé. Si on oublie de mettre le source avant l'upload, la seule façon de corriger est de faire un gros revert du changeset complet et de recommencer. - l'attribution disparait dans les modes de redistribution des données OSM actuellement. Que ce soit dans les fichiers planet ou les requêtes API, les tags de changesets ne sont pas inclues directement. Pour les retrouver, il faut entamer une démarche supplémentaire (charger le dump séparé des changesets sur le planet ou faire des requêtes avancées sur l'API) et volontaire dont la plupart des consommateurs de données OSM se passent. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Fichiers bâti cadastral (était: Restreignons les imports des cours d'eau)
Je préfère une source claire à l'aide de tags sur les objets, plutôt que sur les changeset car l'accès est immédiat. Le principe de l'id pour raccourcir la valeur est intéressant mais je pense qu'on devrait plutôt mieux gérer le stockage des tags/valeur dans les différentes bases de données et formats de fichiers (je pense par exemple aux formats .o5m/.o5c qui sont une forme binaire des formats .osm/osc qui gère très bien la redondance d'info mais malheureusement peu utilisé bien qu'aussi compact que le pbf et plus simple à manipuler). Le 3 octobre 2012 10:39, Pieren pier...@gmail.com a écrit : Il y a plusieurs inconvénients à cette méthode: - ça n'est possible que si le changeset n'utilise qu'une seule source. Hors, l'intégration des données bâti supposent souvent l'utilisation d'autres sources (Bing) ou d'anciennes contributions (recopie des tags des anciens bâtiments déjà présents sous une forme ou une autre). - on ne peut pas modifier les tags d'un changeset une fois que celui-ci est fermé. Si on oublie de mettre le source avant l'upload, la seule façon de corriger est de faire un gros revert du changeset complet et de recommencer. - l'attribution disparait dans les modes de redistribution des données OSM actuellement. Que ce soit dans les fichiers planet ou les requêtes API, les tags de changesets ne sont pas inclues directement. Pour les retrouver, il faut entamer une démarche supplémentaire (charger le dump séparé des changesets sur le planet ou faire des requêtes avancées sur l'API) et volontaire dont la plupart des consommateurs de données OSM se passent. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Fichiers bâti cadastral (était: Restreignons les imports des cours d'eau)
Le 03/10/2012 14:46, Christian Quest a écrit : Je préfère une source claire \o/ -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Fichiers bâti cadastral ( était: Restreignons les imports des cours d'eau)
On mercredi 3 octobre 2012, Christian Quest wrote: Je préfère une source claire à l'aide de tags sur les objets, plutôt que sur les changeset car l'accès est immédiat. Je suis de cet avis dans l'état actuel des éditeurs et exports de la base, toutefois, mon avis changerais si les informations du changeset (tags, dont source=* et comment=*) étaient accessible de manière plus simple à l'utilisateur. Il avait été évoqué que, si les tags de tous les changesets, par ordre chronologiques, ayant changé un objet apparaissaient de manière clair dans les éditeurs, genre juste à coté des tags propres à l'objet, Et que des exports disons étendus entre les full historique et les juste maintenant pouvaient exister, fournissant cette information accompagnant les données. Et qu'un format simili osm puise exister dans lequel on puisse indiquer des tags aux changesets de sorte qu'ils ne soient pas oubliés (comme on le fait dans les fichiers bâtis et le tag source redondant) Alors oui, là, le changeset serait le bon endroit, tant en terme de place que de logique pour mettre les infos de sources tout en étant pas une contrainte de plus. Mais pour l'heure, je suis contre. Le principe de l'id pour raccourcir la valeur est intéressant mais je pense qu'on devrait plutôt mieux gérer le stockage des tags/valeur dans les différentes bases de données et formats de fichiers (je pense par exemple aux formats .o5m/.o5c qui sont une forme binaire des formats .osm/osc qui gère très bien la redondance d'info mais malheureusement peu utilisé bien qu'aussi compact que le pbf et plus simple à manipuler). +1 On ne devrait pas perturber la ressource la plus importante (les contributeurs) pour résoudre un problème qui peut l'être de manière technique et complètement transparente pour l'utilisateur. techos avis=le mien L'argument de la taille, récurent est à mon avis un argument de mauvaise foi, ou, tout du moins, majoritairement de mauvaise foi. Je n'ai pas fait de tests, mais les exports en .osm.bz2 dispose d'un algo de compression (bz2) qui sait réduire la taille d'une redondance, idem pour le reste. Donc le dowload plus long n'est à mon avis que minime. En ce qui concerne les bases type osm2pgsql, la place sur disque est sans objet car le tag source est exclue dans la majorité des cas. Seul cette histoire de passage en id 64bit au lieu de 32bit est vrai, mais les conjectures données disent que à 18mois prêt, il aurait de toute façon fallu y passer. Il reste donc le temps de traitement du xml qui peut, peut-être prendre quelques % de plus, mais comme ce traitement n'est lui même que 10% du total, c'est à mon avis peanuts au final. Pour ce qui est du reste, on parle, pour le planète, de taille de l'ordre de 300Go sur disque, et de temps d'import de dizaines d'heures sur de gros serveur. Quand on se prépare à faire ça, les à 3Go pour le cadastre, c'est de la nioniotte et il faudra de toute façon des gros disques et des gros serveur. Celui qui veut vraiment optimiser la taille, pourra toujours factoriser les tags (id relationnel) et puisqu'il le fera, il économisera autant sur les 40 Millions de fois ou les mots residential, unclassified, service, track et footway, ... apparaissent dans la base que pour le source cadastre /techos -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Fichiers bâti cadastral ( était: Restreignons les imports des cours d'eau)
Dans les fichiers XML, le tag source du cadastre pèse en gros trois fois plus qu'un tag normal (environ 107 contre 35 pour un highway=unclassified par ex.). En utilisant le truc du source_id, on pourrait diminuer par 4 la taille du texte (sur XML non compressé, 27 bytes). En mouillant le doigt, on a dans les 35 millions de tags source=cadastre sur la France (contre par exemple 3 millions de highway). Ca ferait un gain de 2.7 Go sur un planet non compressé. Négligeable ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Fichiers bâti cadastral ( était: Restreignons les imports des cours d'eau)
On mercredi 3 octobre 2012, Pieren wrote: Ca ferait un gain de 2.7 Go sur un planet non compressé. Négligeable ? oui ;-) Et pour 2 raisons : - parce que le planet pèse 330Go en non compressé, 2.7Go ne représente donc que 0.8% du total - parce que de toute façon, quasiment personne ne traite le planet non compressé (et que, pour le plaisir des yeux, je vous offre les statistiques sur la différence qu'aurait un fichier alsace.osm.bz2 avec et sans les tags source=cadastre Avec source cadastre : 107434352 octets sans source cadastre : 107315870 octets on économise donc 0.11% d'espace du fichier .osm.bz2 Par extrapolation (flemme de lancer sa sur la france) le fichier france, donc le fichier planet, ferait 3.6Mo de moins si on enlevait tous les tag source du cadastre ça tiendrait presque sur 2 disquettes 3 pouces et demi datant de 1988, mais pas de chance, plus personne n'a de ce type de disquette. Mon ton un tantinet moqueur, ne l'ait pas, c'est juste pour ajouter de la couleur à l'histoire ;-) ) -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Fichiers bâti cadastral ( était: Restreignons les imports des cours d'eau)
Et si on extrapole jusqu'a une completude de l'import? Yves -- Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté. sly (sylvain letuffe) li...@letuffe.org a écrit : On mercredi 3 octobre 2012, Pieren wrote: Ca ferait un gain de 2.7 Go sur un planet non compressé. Négligeable ? oui ;-) Et pour 2 raisons : - parce que le planet pèse 330Go en non compressé, 2.7Go ne représente donc que 0.8% du total - parce que de toute façon, quasiment personne ne traite le planet non compressé (et que, pour le plaisir des yeux, je vous offre les statistiques sur la différence qu'aurait un fichier alsace.osm.bz2 avec et sans les tags source=cadastre Avec source cadastre : 107434352 octets sans source cadastre : 107315870 octets on économise donc 0.11% d'espace du fichier .osm.bz2 Par extrapolation (flemme de lancer sa sur la france) le fichier france, donc le fichier planet, ferait 3.6Mo de moins si on enlevait tous les tag source du cadastre ça tiendrait presque sur 2 disquettes 3 pouces et demi datant de 1988, mais pas de chance, plus personne n'a de ce type de disquette. Mon ton un tantinet moqueur, ne l'ait pas, c'est juste pour ajouter de la couleur à l'histoire ;-) ) -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org _ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Fichiers bâti cadastral ( était: Restreignons les imports des cours d'eau)
On mercredi 3 octobre 2012, Yves wrote: Et si on extrapole jusqu'a une completude de l'import? Yves (de l'import en france de tous les bâtiments par exemple ?) Difficile à dire. Il faudrait connaître, même approximativement, le nombre de bâtiment rendu disponible par le cadastre. Actuellement il y a 29 Million de building=yes dans OSM en france. Rien que ça, j'arrive pas à comprendre comment c'est possible ! 1 bâtiment pour 2 habitants ??? Un test rapidos, à chambéry, commune de type assez urbaine je tombe sur 1 bâtiment pour 5 habitants curienne, commune franchement rurale, 1 bâtiment par habitant !!! Donc, mais là c'est même plus du doigt mouillé en fermant les yeux avec des dès : Supposons le pire, soit 1 bâtiment par habitant, cela va encore être multiplié par 2 par rapport à maintenant -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Fichiers bâti cadastral ( était: Restreignons les imports des cours d'eau)
Le 03/10/2012 19:13, sly (sylvain letuffe) a écrit : Actuellement il y a 29 Million de building=yes dans OSM en france. Rien que ça, j'arrive pas à comprendre comment c'est possible ! 1 bâtiment pour 2 habitants ??? le nombre de bâtiments est fortement impacté par les bâtiments indûment coupés en 2, 3, 4 voire plus par le script de préparation des fichiers .osm. D'où l'intérêt d'un grand nettoyage avant de téléverser sur les serveurs OSM. Pour ma part, au début je n'y prêtais pas attention, maintenant beaucoup plus. Idem d'ailleurs pour les points inutiles ajoutés sur le contour des bâtiments. -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Fichiers bâti cadastral ( était: Restreignons les imports des cours d'eau)
Dans les villes que j'ai importées, la plupart des bâtiments sont séparés correctement : la plupart des buildings coupés en plusieurs morceaux le sont seulement pour séparer les parties avec wall=no. Du coup, toutes les statistiques sur la taille moyenne des bâtiments ne veulent pas dire grand chose. Un meilleur point de départ serait de comptabiliser les building=yes sans wall=no. 2012/10/3 Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net Le 03/10/2012 19:13, sly (sylvain letuffe) a écrit : Actuellement il y a 29 Million de building=yes dans OSM en france. Rien que ça, j'arrive pas à comprendre comment c'est possible ! 1 bâtiment pour 2 habitants ??? le nombre de bâtiments est fortement impacté par les bâtiments indûment coupés en 2, 3, 4 voire plus par le script de préparation des fichiers .osm. D'où l'intérêt d'un grand nettoyage avant de téléverser sur les serveurs OSM. Pour ma part, au début je n'y prêtais pas attention, maintenant beaucoup plus. Idem d'ailleurs pour les points inutiles ajoutés sur le contour des bâtiments. -- Jean-Francois Nifenecker, Bordeaux __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Fichiers bâti cadastral ( était: Restreignons les imports des cours d'eau)
Tu as suivi les discussions sur irc avec pnorman ? Il a sorti un superbe graphique avec un magnifique pic à 6m2 en abscisse... mais ses ordonnées sont plus qu'étrange: nombre de bâtiments / surface ... je ne vois pas l'intérêt d'un tel calcul. Il en était ainsi arrivé à la conclusion que la majorité des polygones de bâti faisait dans les 6m2, même pas la taille d'un garage (je vous passe le quart d'heure de délire où je lui ai expliqué que ça me suffisait pour garer ma Smart). Les statistiques et calculs il faut faire attention à ce qu'on fait et ce qu'on en fait pour ne pas leur faire dire n'importe quoi... Deuxième bilan: la taille médiane d'un polygone de bâti serait de 34m2, 50% sont plus petits, 50% sont plus grands. Le 3 octobre 2012 22:31, Jérome Armau jerar...@gmail.com a écrit : Dans les villes que j'ai importées, la plupart des bâtiments sont séparés correctement : la plupart des buildings coupés en plusieurs morceaux le sont seulement pour séparer les parties avec wall=no. Du coup, toutes les statistiques sur la taille moyenne des bâtiments ne veulent pas dire grand chose. Un meilleur point de départ serait de comptabiliser les building=yes sans wall=no. 2012/10/3 Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net Le 03/10/2012 19:13, sly (sylvain letuffe) a écrit : Actuellement il y a 29 Million de building=yes dans OSM en france. Rien que ça, j'arrive pas à comprendre comment c'est possible ! 1 bâtiment pour 2 habitants ??? le nombre de bâtiments est fortement impacté par les bâtiments indûment coupés en 2, 3, 4 voire plus par le script de préparation des fichiers .osm. D'où l'intérêt d'un grand nettoyage avant de téléverser sur les serveurs OSM. Pour ma part, au début je n'y prêtais pas attention, maintenant beaucoup plus. Idem d'ailleurs pour les points inutiles ajoutés sur le contour des bâtiments. -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Fichiers bâti cadastral (était: Restreignons les imports des cours d'eau)
Le 01/10/2012 14:03, Pieren a écrit : Pour finir, il faudrait lancer une réflexion sur le tag source et la taille considérable qu'il prend dans la base de donnée. Ja'i pensé à un tag spécial (source_id par ex.) qui utiliserait une valeur réservée. La valeur réservée serait par exemple un chiffre qui serait renseigné sur une page protégée du site osm.org (http://www.openstreetmap.org/credits). Il serait utilisable pour toutes les sources externes en général. L'ajout de nouvelles valeurs devrait être relativement aisé et ouvert mais pas les modifications sur des valeurs déjà utilisées. Par exemple source_id=22 où 22=cadastre blabla, année 2012. C'est une façon de faire un peu du foreign key sans modifier la structure de la base de donnée mais qui permettrait d'économiser des gigaoctets en disque et bande passante chez beaucoup de monde. Bien-sûr, on ne pourrait empêcher l'altération du tag ou sa suppression comme tous les autres tags mais il serait dans l'historique, ce qui nous fait respecter la clause de la dgfip. Bon, cette idée nécessiterait une discussion à une autre échelle que la notre mais vous en pensez quoi ? Ça peut être un source_url=http://www.openstreetmap.org/credits#cadastre_2012 Dans le wiki, on peut facilement avoir une structure de données avec les templates. Cette structure peut s'afficher en liste, en tableau, en ce que vous voulez et être analysable par un outil. Et c'est facilement adressable. C'est ce qui est utilisé pour les messages d'erreurs osmose, pour le filtre TagwatchCleaner. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
