Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
2015-01-24 10:18 GMT+01:00 Christian Quest cqu...@openstreetmap.fr: C'est la géométrie qu'on ne peut pas reprendre en tant que telle des PDF car elle s'appuie sur une base IGN non libre. Vu qu'on ne la reprend pas, je ne vois pas où serait le problème. Je ne sais pas si ça a déjà été relevé sur cette liste mais la base IRIS est maintenant libérée en LO/OL par l'IGN: http://professionnels.ign.fr/contoursiris (merci à http://ecrans.liberation.fr/ecrans/2015/04/28/un-decoupage-plus-precis-des-communes-en-licence-libre_1273735) Pieren PS: notez que je suis aussi contre leur import dans OSM mais que ça peut servir à contrôler certaines de nos limites communales. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Les IRIS nouvellement disponibles sont basés sur GEOFLA (2010). Les limites internes aux communes ne sont pas trop dégradées, pour le reste c'est variable. Donc pas d'import... car la qualité n'est pas vraiment au rendez-vous. Le 28/04/2015 13:44, Pieren a écrit : 2015-01-24 10:18 GMT+01:00 Christian Quest cqu...@openstreetmap.fr: C'est la géométrie qu'on ne peut pas reprendre en tant que telle des PDF car elle s'appuie sur une base IGN non libre. Vu qu'on ne la reprend pas, je ne vois pas où serait le problème. Je ne sais pas si ça a déjà été relevé sur cette liste mais la base IRIS est maintenant libérée en LO/OL par l'IGN: http://professionnels.ign.fr/contoursiris (merci à http://ecrans.liberation.fr/ecrans/2015/04/28/un-decoupage-plus-precis-des-communes-en-licence-libre_1273735) Pieren PS: notez que je suis aussi contre leur import dans OSM mais que ça peut servir à contrôler certaines de nos limites communales. ___ 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] Zonages statistiques Ilots et IRIS
Bonsoir à tous, En tout cas, je confirme les dires de Christian, il y a à boire et à manger dans ces données. Pour avoir fait le test ici sur la commune, les limites des IRIS sont extrapolées (je ne sais pas sous quelles formes tellement c'est variable) et le calage avec l'orthophoto (tant celle de l'IGN que celle des campagnes successives de l'aglo) ou les données routières sont approximatives... A priori si l'on veut travailler plus finement, il faut (re)prendre la couche à la main afin de séparer clairement les ilots d'habitation par exemple (en ce basant sur l'axe médian de la chaussée par exemple). Pour mon cas, j'ai des écarts de pratiquement 20 m avec certaines rues qui portent dans ce cas la confusion si l'on se lance dans un croisement avec des données cadastrales (on englobe ainsi certaines habitations dans le mauvais IRIS) ! Par contre si quelqu'un a une idée de la méthode qu'ils ont employé pour procéder à la simplification, ca (ne) m'intéresse (pas) ! J'ai ma petite idée la-dessus, à l'image des erreurs que l'on peut retrouver sur le RIL : quelques fois c'est pile-poil, dans d'autres cas l'erreur est uniformément rapportée. Cem CARFIL DSI@DammarieLesLys -Message d'origine- De : Christian Quest [mailto:cqu...@openstreetmap.fr] Envoyé : mardi 28 avril 2015 18:56 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS Les IRIS nouvellement disponibles sont basés sur GEOFLA (2010). Les limites internes aux communes ne sont pas trop dégradées, pour le reste c'est variable. Donc pas d'import... car la qualité n'est pas vraiment au rendez-vous. Le 28/04/2015 13:44, Pieren a écrit : 2015-01-24 10:18 GMT+01:00 Christian Quest cqu...@openstreetmap.fr: C'est la géométrie qu'on ne peut pas reprendre en tant que telle des PDF car elle s'appuie sur une base IGN non libre. Vu qu'on ne la reprend pas, je ne vois pas où serait le problème. Je ne sais pas si ça a déjà été relevé sur cette liste mais la base IRIS est maintenant libérée en LO/OL par l'IGN: http://professionnels.ign.fr/contoursiris (merci à http://ecrans.liberation.fr/ecrans/2015/04/28/un-decoupage-plus-precis -des-communes-en-licence-libre_1273735) Pieren PS: notez que je suis aussi contre leur import dans OSM mais que ça peut servir à contrôler certaines de nos limites communales. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Il me semble quand même que les IRIS ne sont pas soumis au secret statistique, contrairement aux îlots et districts qui les divisent kors du recensement. Le grand public est exposé directement au numéro d'IRIS aussi lors du recensement. Le secret statistique peut en revanche s'appliquer aux données parcellaires avec très peu ou un seul répondant possible pour cet IRIS, et l'INSEE publiera alors des données agrégées en utilisant des IRIS de regroupement et en traitants les IRIS unitiaires comme des ilots pour la donnée source. De fait certaines données sont disponibles par IRIS unitaire, d'autres uniquement par IRIS de regroupement (qui dans les données détaillées d'une commune peuvent être listés sous une ligne autres; il y a sans doute un code prédéfini pour ces autres IRIS regroupés, tel que ; à moins que le regroupement d'IRIS pour la donnée aboutit à la commune entière avec un code IRIS ; ou à regrouper plusieurs petites communes rurales avec un pseudo-code commune dans le département et un IRIS nul) Mais comme ces conditions de secret sont évaluées jeu de données par jeu, les IRIS peuvent rester non regroupés pour plein de données et dès lors publiés avec leurs frontières et numéro, même si toutes les données ne sont pas disponibles publiquement à ce niveau (mais peut-être encore de façon réservée pour les communes ou l'administration fiscale ou ltout commanditaire des données qui a obtenu un avis favorable de la CNL sur la collecte et l'utilisation de données personnelles détaillées et identifiables; ou encore le secret des contrats commerciaux et des affaires pour les données des entreprises et organisations publiques et privées). Note : dans les DOM le recensement collecte aussi les types d'habitats provisoires ou de fortune (baraques de bidonvilles, cases traditonnelles, campements sauvages...). Et qu'on voit facilement aussi dans leur cadastre et sur toutes les photos aériennes. Mais bizarrement pas en métropole (où ils seraient sensés ne pas exister ? Alors que certains perdurent pendant des années et sont reconstruits rapidement après les démolitions... ce qui peut pourtant être utile aux communes pour assurer un service minimum, tel que la collecte des ordures, la sécurité publique, la salubrité et la santé publique, l'accès à l'eau potable, ou ou aux opérateurs de réseaux, les besoins daccuil en milieu scolaire, les prestations sociales... Comment dimensionner ces services et obtenir des financements par l'Etat si on oublie ces populations auxquelles la loi garantie des droits et impose aux collectivités et aux délégatares de service public de les servir ? Alors même que les collectivités locales n'ont pas elles-même le pouvoir de les expulser, les démolir mais devront reloger les occupants expulsés...) Depuis les années 1970 il n'y avait plus de bidonvilles en métropole, mais ils sont de retour. Et je me demande si l'INSEE va recenser aussi les squats, ou juste les propriétaires qui indiquent n'héberger personne (pourtant se lon la loi ils sont locataires après 2 semaines passés dans les lieux ce qui leur donne une adresse pour les inscriptions à l'école, les services sociaux, les listes électorales quand ils sont de nationalité française ou européenne). En revanche l'INSEE prospecte bien dans les lieux d'accueil associatifs et communautaires, même provisoires, mais ces leiux ne voient pas (ou rarement) tout le monde présent sur les communes. Dans certains lieux ça doit être délicat pour les agents recenseurs de s'y rendre (en tout cas pas seuls) : la police ou certaines assos reconnues peuvent-elles faire ces prospections en obtenant une habilitation pour certains de leurs agents; à la demande de l'INSEE une fois les lieux identifiés par les agents classiques qui font du porte à porte dans les quartiers et villages ? Le 24 janvier 2015 07:40, Cyrille Giquello cyrill...@gmail.com a écrit : Le 20 janvier 2015 19:25, Philippe Verdy verd...@wanadoo.fr a écrit : Franchement; si des communes entières sont des IRIS, pas la peine d'ajouter une relation supplémentaire, il suffira juste de les marquer avec un tag supplémentaire tel que statistical=FR:IRIS. Du coup ça me fait penser au problème des GR avec la FFRP. Les conditions de réutilisations des contours IRIS mis à dispo par INSEE interdisent leur représentation autre que via les PDF fournis, interdiction d'en faire une représentation vectorielle. Du coup ajouter le tag IRIS revient à en faire une représentation vectorielle, qui est donc interdite. Donc, d'après ma compréhension, quelque soit la méthode, nous n'avons pas le droit de représenter les contours IRIS autre que pour un usage privé. Cyrille. -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Le 24/01/2015 07:40, Cyrille Giquello a écrit : Le 20 janvier 2015 19:25, Philippe Verdy verd...@wanadoo.fr a écrit : Franchement; si des communes entières sont des IRIS, pas la peine d'ajouter une relation supplémentaire, il suffira juste de les marquer avec un tag supplémentaire tel que statistical=FR:IRIS. Les IRIS sont un découpage SUB communal des communes de plus de 1 habitants. Il n'y a donc pas d'IRIS qui corresponde à un contour de commune complet. Du coup ça me fait penser au problème des GR avec la FFRP. Les conditions de réutilisations des contours IRIS mis à dispo par INSEE interdisent leur représentation autre que via les PDF fournis, interdiction d'en faire une représentation vectorielle. Du coup ajouter le tag IRIS revient à en faire une représentation vectorielle, qui est donc interdite. Donc, d'après ma compréhension, quelque soit la méthode, nous n'avons pas le droit de représenter les contours IRIS autre que pour un usage privé. C'est la géométrie qu'on ne peut pas reprendre en tant que telle des PDF car elle s'appuie sur une base IGN non libre. Vu qu'on ne la reprend pas, je ne vois pas où serait le problème. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Le 24 janvier 2015 10:18, Christian Quest cqu...@openstreetmap.fr a écrit : Le 24/01/2015 07:40, Cyrille Giquello a écrit : Le 20 janvier 2015 19:25, Philippe Verdy verd...@wanadoo.fr a écrit : Franchement; si des communes entières sont des IRIS, pas la peine d'ajouter une relation supplémentaire, il suffira juste de les marquer avec un tag supplémentaire tel que statistical=FR:IRIS. Les IRIS sont un découpage SUB communal des communes de plus de 1 habitants. Il n'y a donc pas d'IRIS qui corresponde à un contour de commune complet. Tu confonds. Seules les communes de plus de 1 habitants sont découpées en plusieurs IRIS. Mais les autres communes non découpées sont un IRIS en elles-mêmes. Et sont traitées comme telles dans les statistiques de l'INSEE par IRIS, qui incluent aussi celles des communes non découpées. (dans certains cas l'INSEE crée des IRIS pour regrouper plusieurs petites communes dont les statistiques individuelles ne sont pas publiables, elle les appelle alors district). Les îlots snt fait pour étudier des zones plus fines (et éventuellement revoir le découpage des IRIS avant publication des statistiques; notamment celles du recensement, mais aussi les études économiques sur une commune importante; ou l'étude de la répartition des cantons et circonscriptions électorales, ce qui sera décidé par les commissions des assemblées et soumis à décret de l'Etat; les commies, révisent alors leur carte électorale et préparent les listes électorales en reprenant la liste de leurs inscrits en fonction de leurs adresses). Si tu habites une petite commune recensée cette année, regarde le formulaire remis par l'agent recenseur (cependant le recensé ne sait pas si sa zone est un IRIS pour la commune entière, un district ou un îlot). Il n'y a rien pour indiquer commune, il est juste marqué IRIS, ilot ou district pour le numéro à 4 chiffres à entrer. Les autres éléments: (département et commune) ne sont pas saisis pour entrer dans le questionnaire, ils sont déjà créés dans code d'accès fourni avec le mot de passe pour le web. mais le formulaire inclut de confirmer l'adresse (dans ce cas seule la commune est présaisie pour l'adresse principale mais peut être encore corrigée; et ce n'est pas présaisi pour les résidences secondaires ou si le sondé sur place n'est pas au moment du recensement à son adresse principale du 1er janvier, qui est celle qui est demandée). Des IRIS peuvent apparaitre ou disparaitre ou être redécoupés après chaque recensement d'une commune (il y a des seuils et plafonds, si la population recensée a augmenté et dépasse les 1 habitants, elle sera découpée, si la population a diminué et certains ou tous ses IRIS passe en dessous du seuil, ses IRIS seront fusionnés et persisteront sous forme d'îlots dont les données privatives facilement identifiables ne seront plus publiées de façon détaillée mais agrégée; par exemple les activités professionelles, l'emploi ou les nationalités). L'IRIS n'est pas un découpage territorial, c'est la plus petite entité géographique sur laquelle des statistiques peuvent être publiées concernant la population ou les études économiques. Les autres entités servent pour le découpage électoral et dans ce cas les IRIS sont remplacés par les circonscriptions ou secteurs électoraux pour former les listes électorales (mais ces secteurs sont aussi assez grands pour le secret statistique sans dépasser les limites de la collectivité territoriale où sont élus les représentants (par exempme les municipales dans une toute petite commune rurale d'une centaine d'habitants ont encore une liste électorale unique pour la commune, sans regroupement, même si les listes d'électeurs tombent à une poignée). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Le 20 janvier 2015 19:25, Philippe Verdy verd...@wanadoo.fr a écrit : Franchement; si des communes entières sont des IRIS, pas la peine d'ajouter une relation supplémentaire, il suffira juste de les marquer avec un tag supplémentaire tel que statistical=FR:IRIS. Du coup ça me fait penser au problème des GR avec la FFRP. Les conditions de réutilisations des contours IRIS mis à dispo par INSEE interdisent leur représentation autre que via les PDF fournis, interdiction d'en faire une représentation vectorielle. Du coup ajouter le tag IRIS revient à en faire une représentation vectorielle, qui est donc interdite. Donc, d'après ma compréhension, quelque soit la méthode, nous n'avons pas le droit de représenter les contours IRIS autre que pour un usage privé. Cyrille. -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Le 20 janvier 2015 21:35, Christian Quest cqu...@openstreetmap.fr a écrit : Mon petit doigt me dit qu'en principe les nouveaux IRIS devraient arriver en opendata dans un avenir proche... sans avoir vu à quoi ce jeu de données pourrait ressembler. Mince je viens tout juste d'acheter les contours d'Indre-et-Loire ! -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Pour le recensement de population l'INSEE a aussi des découpages plus fins que les seuls IRIS. Les formulaires papiers fournis indiquent IRIS, îlot ou district (numéro à 4 chiffres; les ilots et districts sont dans des tranches de numéros à part); avec aussi 3 chiffres pour l'habitation (nommée rang A) et 3 chiffres pour le numéro de logement, porte, appartement (rang L). Ce sont ces trois numéros qu'on doit indiquer sur le formulaire web du recensement que les agents de l'INSEE incitent à utiliser si on peut (le formulaire papier indique un code d'accès et un mot de passe pour accéder au formulaire web du questionnaire). Les données des numéros rang A et rang L sont gardées secrètes, mais les numéros IRIS, îlot ou district ne sont aussi partiellement (seuls les IRIS sont publiés; certains pouvant être requalifiés en îlot ou districts et leur données alors tenues secrètes après validation du secret imposé par la loi et dns ce cas l'INSEE crée un nouvel IRIS de regroupement). Le recensement de la population a lieu en ce moment depuis début janvier jusqu'au 14 février en France métropolitaine et Guyane et le 28 février à la Réunion pour les communes de moins de 1 habitants. Ou jusqu'au 21 février dans les communes de plus de 1 habitants en France métropolitaine, dans les Antilles et en Guyane, ou le 7 mars à la Réunion. Tout le monde n'est pas sondé, c'est par tirage au sort dans les communes concernées; et même si répondre est normalement un devoir civique (pour ceux qui ont reçu l'avis de passage prochain d'un agent recenseur qui présente sa carte et doit vous remettre le document papier officiel contenant les identifiants web à utiliser sur le site officiel www.le-recensement-et-moi.fr). Je lai fait aujourd'hui, suite au passage de l'agent qui avait été annoncé par courrier la semaine dernière : j'ai répondu sur le web (ce qui évite à l'agent de repasser, il est informé par SMS des questionnaires qui ont été répondus sur le web; ça lui permet d'organiser son planning de visites et voir si les objectifs suffisants ont été atteints sur chaque secteur ou s'il faudra qu'il prospecte en février d'autres adresses au hasard des présents pour améliorer leur couverture). On n'est pas obligé de répondre sur le web soi-même : l'agent a aussi une tablette permettant de se connecter par internet mobile et sinon dispose de formulaires de réponse sur papier qui'il complétera avec les sondés qui n'ont pas d'internet ni de couvetture internet mobile utilisable par l'agent recenseur. Si on oublie de répondre sur le web, l'agent repassera dans le mois. Les questions posées sur le formulaire web sont d'abord sur le type de logement (individuel ou collectif), la confirmation des adresses postales, quelques équipements (surface totale habitable, type de chauffage, et de salle d'eau) le statut de celui qui répond (propriétaire ou locataire), et la liste des occupants ; puis un questionnaire sur chaque personne (nom, prénom, année et lieu de naissance, nationalité, emploi ou études possession d'un véhicule, et si on fait des études le lieu de l'établissement, et les hébergements secondaires, y compris chez un parent à titre gratuit; ainsiq que le type de liens de parenté ou autre entre les occupants). En ligne par tirage au sort on peut vous proposer d'autres questions sur les équipements individuels, mais rien sur les revenus ou prix des logements et équipements. Les hôtels et campings sont aussi sondés, de même que les logements militaires, hôpitaux, maisons médicalisées et maisons de retraites. Ainsi que les entreprises et administrations qui pourraient avoir des logements pour leurs employés. Le 22 janvier 2015 08:05, Christian Quest cqu...@openstreetmap.fr a écrit : Le 22/01/2015 01:31, Jérôme Amagat a écrit : Je suis plutôt d'accord mais moi je trouve que ça serait plus simple d'avoir un filaire différent pour les frontière (donc réutiliser les ways pour limite de quartier, limite des IRIS, canton électoral, etc) et un autre pour les rue. Le mieux serai même de ne pas réutiliser les node ou au minimum, ça permettrait d'avoir des couches differentes : des nodes et des way pour les routes et reseau filaire, un autre pour les frontière et pourquoi pas un autre pour les landuse surfacique et pour les bâtiment. Pas de modification de truc completement diferent sans le vouloir et simplification de l'affichage en affichant que les couches. Quand la définition même de la frontière est faite par le voirie elle même, ça me semble normal de n'avoir qu'un objet géométrique et pas deux. Ca permet de verifier la cohérence de la définition de la frontière en regardant quels sont les tronçons utilisés pour la définir. Si on utilise des objets géométriques différents ça sera beaucoup plus compliqué et ça pose un autre problème: les incohérences topologiques. Sur le cas des IRIS on peut ainsi se retrouver avec des points d'adresse flottant de part et d'autre de la limite de l'IRIS. C'est
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Le 21 janvier 2015 09:22, Romain MEHUT romain.me...@gmail.com a écrit : Bonjour, Le 21 janvier 2015 08:45, Christian Quest cqu...@openstreetmap.fr a écrit : Il y a des cas où les limites sont portées par le même élément (limite de quartier, limite des IRIS, canton électoral, etc) et des cas où les limites sont certes proches, mais réellement distinctes (cas typique des limites administratives). Dans le premier cas, il me semble préférable et souhaitable d'utiliser le filaire existant pour définir le multipolygone, et dans le second il faut avoir des filaires séparés pour qu'un changement de géométrie n'impacte pas la limite. +1 Je suis plutôt d'accord mais moi je trouve que ça serait plus simple d'avoir un filaire différent pour les frontière (donc réutiliser les ways pour limite de quartier, limite des IRIS, canton électoral, etc) et un autre pour les rue. Le mieux serai même de ne pas réutiliser les node ou au minimum, ça permettrait d'avoir des couches differentes : des nodes et des way pour les routes et reseau filaire, un autre pour les frontière et pourquoi pas un autre pour les landuse surfacique et pour les bâtiment. Pas de modification de truc completement diferent sans le vouloir et simplification de l'affichage en affichant que les couches. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Des que tu partages les noeuds, toute modif sur les ways touchera aux noeuds des deux couches; bref la séparation des ways n'a pas de sens avec le partage de noeuds ! Soit on partage tout, soit rien et dans ce cas il faudra aussi séparer les noeuds : mais où les placer alors... tu veux aussi des noeuds superposés ? C'est encore plus infernal pour les sélections et même géométriquement cela n'a pasu de sens si on ne les superpose pas et qu'on les écarte un peu de façon arbitraire. Désolé mais OSM ne connait pas les couches, il met tout dans la même base, les couches ne faisant pas partie de son modèle (on n'a des couches que dans les éditeurs comme JOSM mais temporairement; car au final on doit fusionner avec le modèle actuel ! Si les noeuds sont fusionnés il n'y a strictement aucune raison de ne pas fusionner aussi ces mêmes chemins qui les relient entre eux ! Le 22 janvier 2015 01:31, Jérôme Amagat jerome.ama...@gmail.com a écrit : Le 21 janvier 2015 09:22, Romain MEHUT romain.me...@gmail.com a écrit : Bonjour, Le 21 janvier 2015 08:45, Christian Quest cqu...@openstreetmap.fr a écrit : Il y a des cas où les limites sont portées par le même élément (limite de quartier, limite des IRIS, canton électoral, etc) et des cas où les limites sont certes proches, mais réellement distinctes (cas typique des limites administratives). Dans le premier cas, il me semble préférable et souhaitable d'utiliser le filaire existant pour définir le multipolygone, et dans le second il faut avoir des filaires séparés pour qu'un changement de géométrie n'impacte pas la limite. +1 Je suis plutôt d'accord mais moi je trouve que ça serait plus simple d'avoir un filaire différent pour les frontière (donc réutiliser les ways pour limite de quartier, limite des IRIS, canton électoral, etc) et un autre pour les rue. Le mieux serai même de ne pas réutiliser les node ou au minimum, ça permettrait d'avoir des couches differentes : des nodes et des way pour les routes et reseau filaire, un autre pour les frontière et pourquoi pas un autre pour les landuse surfacique et pour les bâtiment. Pas de modification de truc completement diferent sans le vouloir et simplification de l'affichage en affichant que les couches. ___ 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] Zonages statistiques Ilots et IRIS
Le 22/01/2015 01:31, Jérôme Amagat a écrit : Je suis plutôt d'accord mais moi je trouve que ça serait plus simple d'avoir un filaire différent pour les frontière (donc réutiliser les ways pour limite de quartier, limite des IRIS, canton électoral, etc) et un autre pour les rue. Le mieux serai même de ne pas réutiliser les node ou au minimum, ça permettrait d'avoir des couches differentes : des nodes et des way pour les routes et reseau filaire, un autre pour les frontière et pourquoi pas un autre pour les landuse surfacique et pour les bâtiment. Pas de modification de truc completement diferent sans le vouloir et simplification de l'affichage en affichant que les couches. Quand la définition même de la frontière est faite par le voirie elle même, ça me semble normal de n'avoir qu'un objet géométrique et pas deux. Ca permet de verifier la cohérence de la définition de la frontière en regardant quels sont les tronçons utilisés pour la définir. Si on utilise des objets géométriques différents ça sera beaucoup plus compliqué et ça pose un autre problème: les incohérences topologiques. Sur le cas des IRIS on peut ainsi se retrouver avec des points d'adresse flottant de part et d'autre de la limite de l'IRIS. C'est ce qui arrive avec les données SIG habituelles et leurs couches séparées qui n'aident pas à maintenir cette cohérence. Le risque d'hyper-tronçonnage du filaire de voirie ne provient pas trop des frontières, mais plutôt de la nécessité de les découper pour les décrire dans le détail (telle portion avec tel type de stationnement, telle autre avec des trottoirs, le nombre de voies changeant, etc). -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Le 20 janv. 2015 à 21:35, Christian Quest cqu...@openstreetmap.fr a écrit : Mon petit doigt me dit qu'en principe les nouveaux IRIS devraient arriver en opendata dans un avenir proche… Tu parles des Îlots regroupés pour l'information statistique http://fr.wikipedia.org/w/index.php?title=%C3%8Elots_regroup%C3%A9s_pour_l'information_statistique ? ;-) Quel peut-être l’intérêt pour OSM et les citoyens lambdas ? — Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
De nombreuses stats de l'INSEE sont publiées à l'IRIS. Sur une ville important avec différents quartiers, ça permet de mieux comprendre les différences entre quartiers. Le 21 janvier 2015 09:06, Yves Pratter yves.prat...@gmail.com a écrit : Le 20 janv. 2015 à 21:35, Christian Quest cqu...@openstreetmap.fr a écrit : Mon petit doigt me dit qu'en principe les nouveaux IRIS devraient arriver en opendata dans un avenir proche... Tu parles des Îlots regroupés pour l'information statistique http://fr.wikipedia.org/w/index.php?title=%C3%8Elots_regroup%C3%A9s_pour_l'information_statistique ? ;-) Quel peut-être l'intérêt pour OSM et les citoyens lambdas ? -- Yves ___ 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] Zonages statistiques Ilots et IRIS
Bonjour, Le 21 janvier 2015 08:45, Christian Quest cqu...@openstreetmap.fr a écrit : Il y a des cas où les limites sont portées par le même élément (limite de quartier, limite des IRIS, canton électoral, etc) et des cas où les limites sont certes proches, mais réellement distinctes (cas typique des limites administratives). Dans le premier cas, il me semble préférable et souhaitable d'utiliser le filaire existant pour définir le multipolygone, et dans le second il faut avoir des filaires séparés pour qu'un changement de géométrie n'impacte pas la limite. +1 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Le 21 janv. 2015 à 09:23, Christian Quest cqu...@openstreetmap.fr a écrit : De nombreuses stats de l'INSEE sont publiées à l'IRIS. Sur une ville important avec différents quartiers, ça permet de mieux comprendre les différences entre quartiers. Merci :-)___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Les ways dont tu parles étaient déjà découpés. Les cantons ajoutent raremetn de découpes aux rues si ce n'est à des croisements de rues qui sont aussi très souvent aussi des découpes pour les lignes de transport. Le nombre de membres dans les deux relations empruntant les mêmes ways ne change pas la complexité vu qu'on a déjà des multipolygones avec des chemins découpés. En revanche je réfute ton apriori plus de chance d'être détruite quand l'omission d'un petit way préserve la quasi totalité des autres et permet de reconsituer facilement la relation sans ambiguité (et d'autant plus facilement que c'est sourcé par les décrets. Si la rue bouge (réaménagement) les cantons continuent de suivre le nouvel axe déplacé : les cantons séparent des habitations parce qu'ils séparent les lieux de résidence des habitants et électeurs qui ne sont jamais inscrits au milieu de la voi publique leur adresse privative. C'est justemetn la superpostion des tracés qui pose des problèmes sérieux d'intégrité, et qui complique les sélections multiples quand les objets se superposent alors qu'il est facile d'ouvrir une relation pour sélectionner un intervalle de membres, et aussi s'assurer que l'ensemble de l'objet est chargé et sans trous invisibles. Le 21 janvier 2015 01:12, Jérôme Amagat jerome.ama...@gmail.com a écrit : Le 20 janvier 2015 22:00, Romain MEHUT romain.me...@gmail.com a écrit : Bonsoir, Le 20 janvier 2015 20:02, Philippe Verdy verd...@wanadoo.fr a écrit : Bref les ways superposés sont une plaie ils compliquent encore plus la tache pour ceux qui veulent modifier autour. Il est difficile de sélectionner le bon chemin surtout quand on doit faire des sélections multiples. +1. D'ailleurs j'ai modifié pour cette raison les cantons de Nancy cf. http://www.openstreetmap.org/changeset/28291169 Romain Je suis d'accord pour les selections multiples, les ways superposer les complique mais pour des sélections simple c'est pas très compliqué. Exemple pour le Canton Nancy-1: Avant,(c'est moi qui ai créé la relation), 3 ways : 1 way qui est une partie de la frontière de la commune et 2 ways créé pour les cantons de Nancy (1 sert aussi pour nancy 2 et l'autre pour nancy 3) Après, 72 ways : toutes les parties superposées avec des highways ont été remplacé par des highways. pour cela il a surement fallu coupé des highway et des rond point pour avoir que le morceau voulu. il reste quand même 9 ways de 2 ou 3 nœuds boundary=political pour faire la jonction entre des highway. ça fait 72 way pour 13.7 km (71 pour 9.3 km si on enlève le way frontière de commune.) Donc pour moi, ça veut dire qu'on à compliqué les highway avec de nouvelles découpes (il n'y a pas déjà assez de tag donnant de bonnes raisons de le faire), la relation est beaucoup plus compliquer (avant : beaucoup moins d’élément et que des boundary) donc plus de chance d’être détruite. En échange, c'est plus facile de faire des sélections multiples. Ici c'est pou un canton, ou la frontière est plus ou moins lié a la rue, mais pour des frontières de communes, ça veut dire que si on déplace la rue, le chemin ou la rivière la frontière est déplacer aussi. Moi, pour les landuse après m'y être déjà frotter, je ne touche plus au landuse qui on été modifié pour ne plus avoir de way superposé, trop compliqué. ___ 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
[OSM-talk-fr] Zonages statistiques Ilots et IRIS
Bonjour, L'APUR libère des données qui sont parfois évoquées ici, souvent pour regretter leur caractère non libre, car s'appuyant sur des géométries de l'IGN. Il s'agit des les limites statistiques infracommunales Îlots et IRIS : http://www.apur.org/article/donnees-disponibles-open-data Les données Îlot ne sont pas (au moins en diffusion INSEE) promises à grand avenir : http://www.insee.fr/fr/methodes/default.asp?page=definitions/ilot.htm donc les intégrer dans OSM se discute. Proposer en revanche un fond IRIS [1] national et libre aurait de l'allure, et des consommateurs. Les données de l'APUR sont un matériau pertinent, sur Paris et petite couronne, pour alimenter cette démarche. Il faudrait à cette occasion établir un schéma de tags, à base de boundary=census ou boundary=statistical, non documentés pour l'instant. vincent [1] : http://www.insee.fr/fr/methodes/default.asp?page=definitions/iris.htm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Ça va quand même être difficile de faire ça sans rien ajouter dans OSM. Certaines limites n'existent simplement pas dans la zone où je regarde (ma commune). J'ai précisément une limite qui semble être la voie ferrée et comme les rails sont multiples, je serais tenté de placer une limite boundary filaire pour clore ma surface constituée jusque là de boundary=admin et de highway. Mais la question vaut d'être posée ! Dans OSM, ou pas ? A+ Marc Sibert m...@sibert.fr Le 20 janvier 2015 17:36, JB jb...@mailoo.org a écrit : On parle bien de « couche » comme dans « pas dans la base principale d'OSM » ? (Si oui, j'approuve, si non, je me demande qui va entretenir ça et comment les nouveaux contributeurs vont encore se prendre ça dans la figure…) JB. Le 20/01/2015 17:24, Damouns a écrit : Quand je vois que les nouveaux cantons ne sont pas encore tous saisis je crains un peu que cette nouvelle idée ne soit jamais terminée... Mais c'est effectivement une couche qui serait utile. Le 20 janvier 2015 17:21, Marc SIBERT m...@sibert.fr a écrit : Bonjour, Il faudrait aussi se limiter à un modèle contour/surface pour simplifier la création et l'usage (si c'est possible en même temps) et sans ajouter trop de surcharge à la carte (les relations pour ça c'est bien, mais plus difficile à maintenir il est vrai). Il faut voir qu'une majorité des IRIS correspondent aux communes et qu'il est facile de copier les relations administratives existantes pour en faire des surfaces census. A+ Marc Sibert m...@sibert.fr Le 20 janvier 2015 14:51, Vincent de Château-Thierry osm.v...@free.fr a écrit : Bonjour, L'APUR libère des données qui sont parfois évoquées ici, souvent pour regretter leur caractère non libre, car s'appuyant sur des géométries de l'IGN. Il s'agit des les limites statistiques infracommunales Îlots et IRIS : http://www.apur.org/article/donnees-disponibles-open-data Les données Îlot ne sont pas (au moins en diffusion INSEE) promises à grand avenir : http://www.insee.fr/fr/methodes/default.asp?page=definitions/ilot.htm donc les intégrer dans OSM se discute. Proposer en revanche un fond IRIS [1] national et libre aurait de l'allure, et des consommateurs. Les données de l'APUR sont un matériau pertinent, sur Paris et petite couronne, pour alimenter cette démarche. Il faudrait à cette occasion établir un schéma de tags, à base de boundary=census ou boundary=statistical, non documentés pour l'instant. vincent [1] : http://www.insee.fr/fr/methodes/default.asp?page=definitions/iris.htm ___ 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 listTalk-fr@openstreetmap.orghttps://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] Zonages statistiques Ilots et IRIS
Bonjour, Il faudrait aussi se limiter à un modèle contour/surface pour simplifier la création et l'usage (si c'est possible en même temps) et sans ajouter trop de surcharge à la carte (les relations pour ça c'est bien, mais plus difficile à maintenir il est vrai). Il faut voir qu'une majorité des IRIS correspondent aux communes et qu'il est facile de copier les relations administratives existantes pour en faire des surfaces census. A+ Marc Sibert m...@sibert.fr Le 20 janvier 2015 14:51, Vincent de Château-Thierry osm.v...@free.fr a écrit : Bonjour, L'APUR libère des données qui sont parfois évoquées ici, souvent pour regretter leur caractère non libre, car s'appuyant sur des géométries de l'IGN. Il s'agit des les limites statistiques infracommunales Îlots et IRIS : http://www.apur.org/article/donnees-disponibles-open-data Les données Îlot ne sont pas (au moins en diffusion INSEE) promises à grand avenir : http://www.insee.fr/fr/methodes/default.asp?page=definitions/ilot.htm donc les intégrer dans OSM se discute. Proposer en revanche un fond IRIS [1] national et libre aurait de l'allure, et des consommateurs. Les données de l'APUR sont un matériau pertinent, sur Paris et petite couronne, pour alimenter cette démarche. Il faudrait à cette occasion établir un schéma de tags, à base de boundary=census ou boundary=statistical, non documentés pour l'instant. vincent [1] : http://www.insee.fr/fr/methodes/default.asp?page=definitions/iris.htm ___ 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] Zonages statistiques Ilots et IRIS
On parle bien de « couche » comme dans « pas dans la base principale d'OSM » ? (Si oui, j'approuve, si non, je me demande qui va entretenir ça et comment les nouveaux contributeurs vont encore se prendre ça dans la figure…) JB. Le 20/01/2015 17:24, Damouns a écrit : Quand je vois que les nouveaux cantons ne sont pas encore tous saisis je crains un peu que cette nouvelle idée ne soit jamais terminée... Mais c'est effectivement une couche qui serait utile. Le 20 janvier 2015 17:21, Marc SIBERT m...@sibert.fr mailto:m...@sibert.fr a écrit : Bonjour, Il faudrait aussi se limiter à un modèle contour/surface pour simplifier la création et l'usage (si c'est possible en même temps) et sans ajouter trop de surcharge à la carte (les relations pour ça c'est bien, mais plus difficile à maintenir il est vrai). Il faut voir qu'une majorité des IRIS correspondent aux communes et qu'il est facile de copier les relations administratives existantes pour en faire des surfaces census. A+ Marc Sibert m...@sibert.fr mailto:m...@sibert.fr Le 20 janvier 2015 14:51, Vincent de Château-Thierry osm.v...@free.fr mailto:osm.v...@free.fr a écrit : Bonjour, L'APUR libère des données qui sont parfois évoquées ici, souvent pour regretter leur caractère non libre, car s'appuyant sur des géométries de l'IGN. Il s'agit des les limites statistiques infracommunales Îlots et IRIS : http://www.apur.org/article/donnees-disponibles-open-data Les données Îlot ne sont pas (au moins en diffusion INSEE) promises à grand avenir : http://www.insee.fr/fr/methodes/default.asp?page=definitions/ilot.htm donc les intégrer dans OSM se discute. Proposer en revanche un fond IRIS [1] national et libre aurait de l'allure, et des consommateurs. Les données de l'APUR sont un matériau pertinent, sur Paris et petite couronne, pour alimenter cette démarche. Il faudrait à cette occasion établir un schéma de tags, à base de boundary=census ou boundary=statistical, non documentés pour l'instant. vincent [1] : http://www.insee.fr/fr/methodes/default.asp?page=definitions/iris.htm ___ 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 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Franchement; si des communes entières sont des IRIS, pas la peine d'ajouter une relation supplémentaire, il suffira juste de les marquer avec un tag supplémentaire tel que statistical=FR:IRIS. On ne créera alors des relations QUE pour les IRIS infracommunaux (dans les communes de plus de 5000 habitants à la date où l'INSEE les a définis initialement pour une année légale ou l'année suivante le temps pour l'INSEE de faire l'étude) de type boundary=statistical avec aussi le même tag précédent. Le 20 janvier 2015 17:21, Marc SIBERT m...@sibert.fr a écrit : Bonjour, Il faudrait aussi se limiter à un modèle contour/surface pour simplifier la création et l'usage (si c'est possible en même temps) et sans ajouter trop de surcharge à la carte (les relations pour ça c'est bien, mais plus difficile à maintenir il est vrai). Il faut voir qu'une majorité des IRIS correspondent aux communes et qu'il est facile de copier les relations administratives existantes pour en faire des surfaces census. A+ Marc Sibert m...@sibert.fr Le 20 janvier 2015 14:51, Vincent de Château-Thierry osm.v...@free.fr a écrit : Bonjour, L'APUR libère des données qui sont parfois évoquées ici, souvent pour regretter leur caractère non libre, car s'appuyant sur des géométries de l'IGN. Il s'agit des les limites statistiques infracommunales Îlots et IRIS : http://www.apur.org/article/donnees-disponibles-open-data Les données Îlot ne sont pas (au moins en diffusion INSEE) promises à grand avenir : http://www.insee.fr/fr/methodes/default.asp?page=definitions/ilot.htm donc les intégrer dans OSM se discute. Proposer en revanche un fond IRIS [1] national et libre aurait de l'allure, et des consommateurs. Les données de l'APUR sont un matériau pertinent, sur Paris et petite couronne, pour alimenter cette démarche. Il faudrait à cette occasion établir un schéma de tags, à base de boundary=census ou boundary=statistical, non documentés pour l'instant. vincent [1] : http://www.insee.fr/fr/methodes/default.asp?page=definitions/iris.htm ___ 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] Zonages statistiques Ilots et IRIS
C'est pas terminé uniquement parce qu'il manque de monde pour le faire (et les cas compliqués, ceux des communes découpées) sont en voie d'achèvement et certaines régions sont déjà complètes. Il y a toutes les données nécessaires sur la page wiki qui mentionne les arrêtés. De nombreux cantons peuvent être ajoutés uniquement à partir de la liste de communes entières. Il y a deux ans un bot l'avait fait déjà pour tous les cantons ancienne génération ne comprenant aucune commune découpée (et dont les communes étaient entièrement tracées, ce qui n'était pas encore le cas de communes en Basse-Normandie ou en Corse et quelques espaces ruraux négligés par les contributeurs). Note: les cantons actuels devraient être gardés quelques temps encore même après mars. Il y a encore trop de références à ceux-ci dans les textes légaux. Il faudra juste changer leurs tags actuels en: disused:boundary=political disused:political_division=canton et leur ajouter end_date=2015-02 (ceci peut être fait par bot; même maintenant) Avant d'enlever le préfixe planned: en mars pour les actuels planned;boundary=* planned;political_division=* Note: planned:ref=* restera encore jusqu'à ce que l'INSEE codifie réellement l'année prochaine. Le 20 janvier 2015 17:24, Damouns damo...@gmail.com a écrit : Quand je vois que les nouveaux cantons ne sont pas encore tous saisis je crains un peu que cette nouvelle idée ne soit jamais terminée... Mais c'est effectivement une couche qui serait utile. Le 20 janvier 2015 17:21, Marc SIBERT m...@sibert.fr a écrit : Bonjour, Il faudrait aussi se limiter à un modèle contour/surface pour simplifier la création et l'usage (si c'est possible en même temps) et sans ajouter trop de surcharge à la carte (les relations pour ça c'est bien, mais plus difficile à maintenir il est vrai). Il faut voir qu'une majorité des IRIS correspondent aux communes et qu'il est facile de copier les relations administratives existantes pour en faire des surfaces census. A+ Marc Sibert m...@sibert.fr Le 20 janvier 2015 14:51, Vincent de Château-Thierry osm.v...@free.fr a écrit : Bonjour, L'APUR libère des données qui sont parfois évoquées ici, souvent pour regretter leur caractère non libre, car s'appuyant sur des géométries de l'IGN. Il s'agit des les limites statistiques infracommunales Îlots et IRIS : http://www.apur.org/article/donnees-disponibles-open-data Les données Îlot ne sont pas (au moins en diffusion INSEE) promises à grand avenir : http://www.insee.fr/fr/methodes/default.asp?page=definitions/ilot.htm donc les intégrer dans OSM se discute. Proposer en revanche un fond IRIS [1] national et libre aurait de l'allure, et des consommateurs. Les données de l'APUR sont un matériau pertinent, sur Paris et petite couronne, pour alimenter cette démarche. Il faudrait à cette occasion établir un schéma de tags, à base de boundary=census ou boundary=statistical, non documentés pour l'instant. vincent [1] : http://www.insee.fr/fr/methodes/default.asp?page=definitions/iris.htm ___ 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Ça dépend de la complexité de ce découpage. Les ways superposés sur de nombreuses rues sont de toute façon cassés aussi par les modifs sur les rues, d'autant plus facilement et rendent souvent même la modif des rues compliquées. Note: la prévision de tracé des rues est importante, mais pas celles des cantons qui se contentent juste de séparer les zones habitées/ Il est rare qu'une rue même soit réaménagée de sorte que le canton soit légalement modifié. Prenons l'exemple d'un carrefour réaménagé en rond-point: la modif consiste souvent à tracer un cercle; découper les rues qui avant se croisaient, puis virer les segments. L'auteur va accepter le changement des relations cantonales ou des circonscriptions mais omet de retracer un segment de jonction gardant l'intégrité des cantons ou circonscription. Normalement il n'aurait pas du supprimer ces chemins et leurs noeuds mais ils ne font tout de même et ce n'est pas parce qu'il y avait deux ways superposés que ça les arrête ! Bref les ways superposés sont une plaie ils compliquent encore plus la tache pour ceux qui veulent modifier autour. Il est difficile de sélectionner le bon chemin surtout quand on doit faire des sélections multiples. Astuce : pour les sélections multiples dans JOSM, je m'en sors parfois en créant une relation **temporaire** pour accumuler des objets et permettre de travailler sur la liste. Cette relation n'est pas toujours enregistrée (le dialogue de création reste ouvert, mais à la fin quand je n'ai plus besoin de cette liste, j'annule sans enregistrer) ou bien il sera supprimé avant l'envoi; mais dans ce cas si l'objet est validé localement, ou en cas de besoin d'un envoi intermédiaire, je met dessus un tag explicite repérable comme type=!DELETEME qui, grâce au point d'exclamation en premier caractère, sera affichée en tête de la liste des relations, pour la trouver facilement en cas d'oubli; le dialogue d'envoi des données devrait afficher cette relation tout en haut, il peut arriver qu'on ait besoin aussi de tels objets le temps de résoudre une série de conflits d'édition pour y accumuler des objets dépendants restant à vérifier; ce genre de relation temporaire peut aussi être utile quand on manque de mémoire pour charger tous les objets dépendants et travailler de façon incrémentale, ils signaleront aux autres qu'il y a un travail en cours). Je préfère indiquer explicitement qu'une rue est aussi une frontière politique, pour que les modificateurs s'en aperçoivent avant de virer des chemins ou leurs nœuds. Ces tags mettent des alertes qui leur évite d'oublier de regarder les autres relations (l'omission est beaucoup trop facile par les auteurs utilisant iD, qui en plus ne sait pas conserver l'ordre de succession des éléments, il supprime mais n'ajoute qu'en fin de liste des membres, il ne gère pas du tout leur ordre relatif; même si cet ordre n'est à priori pas significatif pour les boundary, mais très utile pourtant pour réparer et trouver les trous) Le 20 janvier 2015 19:28, Jérôme Amagat jerome.ama...@gmail.com a écrit : Pas grand chose à voir avec ces nouvelles données en particulier mais avec les relations boundary : Quelles way mettre dans ces relations? Je sais pas si il y a une bonne façon de faire. Moi je préfère (j'ai ajouter des nouveaux cantons) utiliser les way qui sont déjà des boundary (limite des anciens cantons et des communes surtout) et créer des way boundary=political pour tout le reste. ces way utilise beaucoup les node des way highway mais je ne mets pas ces way highway dans la relation. Je pense que comme ça il y a moins de chance de casser la relation dans le futur (surtout en supprimant,coupant ou fusionnant des highway) et c'est plus facile à maintenir et à comprendre pour les autres contributeurs (beaucoup moins de way dans la relation) et on mélange moins des choses qui n'ont pas grand chose a voir (frontière et route). Pour ce qui est de ces données, pas vraiment d'avis (ça n'a plus l'air de servir a grand chose?). Mais si vous voulez tracer des frontières il reste un peu moins de 1000 cantons a ajouter dont environ 250 avec une frontière à tracer à l’intérieur d'une commune. ___ 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] Zonages statistiques Ilots et IRIS
Pas grand chose à voir avec ces nouvelles données en particulier mais avec les relations boundary : Quelles way mettre dans ces relations? Je sais pas si il y a une bonne façon de faire. Moi je préfère (j'ai ajouter des nouveaux cantons) utiliser les way qui sont déjà des boundary (limite des anciens cantons et des communes surtout) et créer des way boundary=political pour tout le reste. ces way utilise beaucoup les node des way highway mais je ne mets pas ces way highway dans la relation. Je pense que comme ça il y a moins de chance de casser la relation dans le futur (surtout en supprimant,coupant ou fusionnant des highway) et c'est plus facile à maintenir et à comprendre pour les autres contributeurs (beaucoup moins de way dans la relation) et on mélange moins des choses qui n'ont pas grand chose a voir (frontière et route). Pour ce qui est de ces données, pas vraiment d'avis (ça n'a plus l'air de servir a grand chose?). Mais si vous voulez tracer des frontières il reste un peu moins de 1000 cantons a ajouter dont environ 250 avec une frontière à tracer à l’intérieur d'une commune. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Quand je vois que les nouveaux cantons ne sont pas encore tous saisis je crains un peu que cette nouvelle idée ne soit jamais terminée... Mais c'est effectivement une couche qui serait utile. Le 20 janvier 2015 17:21, Marc SIBERT m...@sibert.fr a écrit : Bonjour, Il faudrait aussi se limiter à un modèle contour/surface pour simplifier la création et l'usage (si c'est possible en même temps) et sans ajouter trop de surcharge à la carte (les relations pour ça c'est bien, mais plus difficile à maintenir il est vrai). Il faut voir qu'une majorité des IRIS correspondent aux communes et qu'il est facile de copier les relations administratives existantes pour en faire des surfaces census. A+ Marc Sibert m...@sibert.fr Le 20 janvier 2015 14:51, Vincent de Château-Thierry osm.v...@free.fr a écrit : Bonjour, L'APUR libère des données qui sont parfois évoquées ici, souvent pour regretter leur caractère non libre, car s'appuyant sur des géométries de l'IGN. Il s'agit des les limites statistiques infracommunales Îlots et IRIS : http://www.apur.org/article/donnees-disponibles-open-data Les données Îlot ne sont pas (au moins en diffusion INSEE) promises à grand avenir : http://www.insee.fr/fr/methodes/default.asp?page=definitions/ilot.htm donc les intégrer dans OSM se discute. Proposer en revanche un fond IRIS [1] national et libre aurait de l'allure, et des consommateurs. Les données de l'APUR sont un matériau pertinent, sur Paris et petite couronne, pour alimenter cette démarche. Il faudrait à cette occasion établir un schéma de tags, à base de boundary=census ou boundary=statistical, non documentés pour l'instant. vincent [1] : http://www.insee.fr/fr/methodes/default.asp?page=definitions/iris.htm ___ 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] Zonages statistiques Ilots et IRIS
On est d'accord... Les superpositions de ways c'est juste pour des petits objets de nature similaire, susceptibles d'être modifiés facilement et localement (par exemple deux bâtiments accolés avec une géométrie relativement simple; mais pas non plus tout un château; d'autant plus que les batiments compelxes nécessitent déjà des multipolygones pour les enclaves et les diverses surfaces incluses). Dès qu'on dépasse les 20 mètres de rayon, on a déjà des problèmes de sélection on a vite des objets à tracer dedans. Lavantage de multipolygones est de rendre les objets facilement éditables localement et il est plus facile de les enrichir en détails locaux. Certes pour les débutants c'est déroutant de travailler sur les multipolygnes mais les débutants sont tout autant déroutés sur le fait de travailler sur des objets de toute façon déjà complexes par eux-mêmes; et sont encore plus déroutés par les moyens de sélectionner des objets quand ils sont superposés (et c'est encore plus difficile d'ailleurs dans iD que dans JOSM !) Certes il y a le risque d'un multipolygne soit localement brisé mais justement cette brisure restera locale et plus facile à reconstiter. Mais quand les débutants tombent sur des objets superposés ils ne se rendent pas compte du tout de l'objet qu'il modifient. Les multipolygones il faut s'y faire, d'autant plus qu'OSM (contrairement aux systèmes GIS standards) mélange tout dans sa base sans la gérer en couches indépendantes. Ca s'apprend, mais les débutants commencent d'aord par des modifs sur des objets de petite taille et sans inclusions. Quand ils ont besoin de travailler sur des objets plus gros, ils passent à autre chose qu'iD et apprennent à se servir de JOSM. Le 20 janvier 2015 22:00, Romain MEHUT romain.me...@gmail.com a écrit : Bonsoir, Le 20 janvier 2015 20:02, Philippe Verdy verd...@wanadoo.fr a écrit : Bref les ways superposés sont une plaie ils compliquent encore plus la tache pour ceux qui veulent modifier autour. Il est difficile de sélectionner le bon chemin surtout quand on doit faire des sélections multiples. +1. D'ailleurs j'ai modifié pour cette raison les cantons de Nancy cf. http://www.openstreetmap.org/changeset/28291169 Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Ah! si OSM permettait de travailler sur une base à couches séparées ou sur plusieurs bases séparées, on pourrait charger une zone avec toutes ses couches, et utiliser le sélecteur de calques ! Et bien des problèmes d'intégration (et même de versionnement) seraient évités. Autrement dit une base OpenGIS standard directement, comme sur les systèmes commerciaux et des administrations. Et pour chaque claque un jeu de tags bien mieux défini et plus cohérent. LEs jeux de données étant plus simples, meˆme les débutants seraient moins intimidés puisque la casse serait immédiatement visible et bien plus facilement repérable et réparable. On éviterait aussi pas mals de conflits d'édition que les débutants ne savent pas du tout gérer correctement (ils abandonnent vite en cours de route et laissent les autres réparer). Plus la base se densifie et moins elle est accessible aux débutants. OSM devient un système pour spécialistes et de plus en plus fermé, dont le nombre de contributeurs se réduit de plus en plus et où tout nouveau jeu de données est de plus en plus difficile à intégrer. LA bonne volonté des débuts ne suffit plus et assez vite on va être confronté à des abandons et au manque de nouveaux contributeurs qui ne comprendront plus rien sur la façon de commencer sur des choses simples. La base pourrait aussi être distribuée (avec des serveurs séparés pour des jeux de couches différentes ou des versions historisées, datées, vérifiées, validées et stabilisées sans aucune casse ultérieure). Les performances des serveurs seraient aussi bien meilleures. Tôt ou tard on y viendra: la base changera de format et on va devoir la migrer vers un système plus accessible et plus stable (et plus facile aussi à rescaler vers des jeux de données et usages plus nombreux). Il est tout à fait possible même d'avoir une interface de requêtes permettant d'interroger un nombre indéfini de bases de données, lesquelles retourneront des jeux de calques séparés répondant à la requête. D'ailleurs le W3C prépare un système d''interopéraiblité permettant d'interconnecter des bases multiples; gérées séparément et sans nécessiter de travail de préparation/fusion (une grosse perte de temps gaspillée dans OSM). Le 20 janvier 2015 22:13, Vincent de Château-Thierry v...@laposte.net a écrit : Le 20/01/2015 18:22, Marc SIBERT a écrit : Ça va quand même être difficile de faire ça sans rien ajouter dans OSM. Certaines limites n'existent simplement pas dans la zone où je regarde (ma commune). J'ai précisément une limite qui semble être la voie ferrée et comme les rails sont multiples, je serais tenté de placer une limite boundary filaire pour clore ma surface constituée jusque là de boundary=admin et de highway. Mais la question vaut d'être posée ! Dans OSM, ou pas ? En effet, quel peut être l'intérêt d'un zonage (un de plus !) directement dans OSM ? Petit préambule : il existe un produit, commercialisé par l'IGN, qui détaille les contours d'IRIS avec une précision géométrique semblable à celle qu'on manipule dans OSM. Je vous laisse voir les tarifs de 2012 p10 de ce doc : http://professionnels.ign.fr/sites/default/files/Bar%C3% A8me%20des%20licences%20d%27utilisation%20des%20produits%202012.pdf Un autre produit est proposé par ESRI France : http://esrifrance.fr/iso_album/DP_FranceIRIS_V1.1.pdf Ces mentions pour indiquer que le contenu IRIS est suffisamment utilisé pour disposer d'un marché. Je parlais volontairement de consommateurs au début de ce fil. À partir de là, proposer des contours IRIS issus d'OSM, c'est potentiellement répondre à un besoin. La problématique ici n'est pas différente des autres thématiques de la base, comme par exemple les limites communales : https://www.data.gouv.fr/fr/datasets/decoupage-administratif-communal- francais-issu-d-openstreetmap/ Par nature, les limites d'IRIS s'appuient sur des éléments physiques : cours d'eau, axes de voirie, voies ferrées. Proposer une couche intégrée dans OSM, c'est offrir un jeu de données cohérent, en terme de géométrie. Si les IRIS sont libérés prochainement, ça facilitera le travail d'intégration, mais ne changera pas la plus-value de cohérence géométrique liée à une intégration dans OSM. À l'inverse, oui bien sûr, ça constitue une couche de relations supplémentaire, qui plus est en milieu urbain, dense en informations. On n'échappera pas à de la casse de relations de temps en temps. C'est le lot (quotidien) pour les limites communales. Mais, comme pour ces dernières, s'il y a un besoin, et des consommateurs, il y aura toujours de la motivation pour assurer la maintenance, j'en suis convaincu. 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] Zonages statistiques Ilots et IRIS
Le 20 janvier 2015 22:00, Romain MEHUT romain.me...@gmail.com a écrit : Bonsoir, Le 20 janvier 2015 20:02, Philippe Verdy verd...@wanadoo.fr a écrit : Bref les ways superposés sont une plaie ils compliquent encore plus la tache pour ceux qui veulent modifier autour. Il est difficile de sélectionner le bon chemin surtout quand on doit faire des sélections multiples. +1. D'ailleurs j'ai modifié pour cette raison les cantons de Nancy cf. http://www.openstreetmap.org/changeset/28291169 Romain Je suis d'accord pour les selections multiples, les ways superposer les complique mais pour des sélections simple c'est pas très compliqué. Exemple pour le Canton Nancy-1: Avant,(c'est moi qui ai créé la relation), 3 ways : 1 way qui est une partie de la frontière de la commune et 2 ways créé pour les cantons de Nancy (1 sert aussi pour nancy 2 et l'autre pour nancy 3) Après, 72 ways : toutes les parties superposées avec des highways ont été remplacé par des highways. pour cela il a surement fallu coupé des highway et des rond point pour avoir que le morceau voulu. il reste quand même 9 ways de 2 ou 3 nœuds boundary=political pour faire la jonction entre des highway. ça fait 72 way pour 13.7 km (71 pour 9.3 km si on enlève le way frontière de commune.) Donc pour moi, ça veut dire qu'on à compliqué les highway avec de nouvelles découpes (il n'y a pas déjà assez de tag donnant de bonnes raisons de le faire), la relation est beaucoup plus compliquer (avant : beaucoup moins d’élément et que des boundary) donc plus de chance d’être détruite. En échange, c'est plus facile de faire des sélections multiples. Ici c'est pou un canton, ou la frontière est plus ou moins lié a la rue, mais pour des frontières de communes, ça veut dire que si on déplace la rue, le chemin ou la rivière la frontière est déplacer aussi. Moi, pour les landuse après m'y être déjà frotter, je ne touche plus au landuse qui on été modifié pour ne plus avoir de way superposé, trop compliqué. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Le 20/01/2015 18:22, Marc SIBERT a écrit : Ça va quand même être difficile de faire ça sans rien ajouter dans OSM. Certaines limites n'existent simplement pas dans la zone où je regarde (ma commune). J'ai précisément une limite qui semble être la voie ferrée et comme les rails sont multiples, je serais tenté de placer une limite boundary filaire pour clore ma surface constituée jusque là de boundary=admin et de highway. Mais la question vaut d'être posée ! Dans OSM, ou pas ? En effet, quel peut être l'intérêt d'un zonage (un de plus !) directement dans OSM ? Petit préambule : il existe un produit, commercialisé par l'IGN, qui détaille les contours d'IRIS avec une précision géométrique semblable à celle qu'on manipule dans OSM. Je vous laisse voir les tarifs de 2012 p10 de ce doc : http://professionnels.ign.fr/sites/default/files/Bar%C3%A8me%20des%20licences%20d%27utilisation%20des%20produits%202012.pdf Un autre produit est proposé par ESRI France : http://esrifrance.fr/iso_album/DP_FranceIRIS_V1.1.pdf Ces mentions pour indiquer que le contenu IRIS est suffisamment utilisé pour disposer d'un marché. Je parlais volontairement de consommateurs au début de ce fil. À partir de là, proposer des contours IRIS issus d'OSM, c'est potentiellement répondre à un besoin. La problématique ici n'est pas différente des autres thématiques de la base, comme par exemple les limites communales : https://www.data.gouv.fr/fr/datasets/decoupage-administratif-communal-francais-issu-d-openstreetmap/ Par nature, les limites d'IRIS s'appuient sur des éléments physiques : cours d'eau, axes de voirie, voies ferrées. Proposer une couche intégrée dans OSM, c'est offrir un jeu de données cohérent, en terme de géométrie. Si les IRIS sont libérés prochainement, ça facilitera le travail d'intégration, mais ne changera pas la plus-value de cohérence géométrique liée à une intégration dans OSM. À l'inverse, oui bien sûr, ça constitue une couche de relations supplémentaire, qui plus est en milieu urbain, dense en informations. On n'échappera pas à de la casse de relations de temps en temps. C'est le lot (quotidien) pour les limites communales. Mais, comme pour ces dernières, s'il y a un besoin, et des consommateurs, il y aura toujours de la motivation pour assurer la maintenance, j'en suis convaincu. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Bonsoir, Le 20 janvier 2015 20:02, Philippe Verdy verd...@wanadoo.fr a écrit : Bref les ways superposés sont une plaie ils compliquent encore plus la tache pour ceux qui veulent modifier autour. Il est difficile de sélectionner le bon chemin surtout quand on doit faire des sélections multiples. +1. D'ailleurs j'ai modifié pour cette raison les cantons de Nancy cf. http://www.openstreetmap.org/changeset/28291169 Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Tu oublies de dire quelle valeur tu as utilisée pour boundary=* si ce n'est pas administrative (statistical?), ou s'il y a cohérence avec d'autres entités comparables et quel autre tag indique le type de subdivision statistique. Tu n'indiques pas non plus dans quelle ville tu l'as fait. J'espère au moins que tu ne les as pas juste taguées en admin_level=10 ou autre valeur puisque ce ne sont pas non plus des quartiers à proprement parler : Ces entités obéissent aussi en taille minimale à des règles légales de secret statistique, l'INSEE pouvant aussi regrouper plusieurs IRIS ensemble pour certaines données dont l'anonymat doit être préservé, comme il le fait depuis longtemps pour des données comparables carroyées: ces îlots géographiques peuvent dont changer à tout moment d'une année à l'autre voire plusieurs fois selon les jeux de données statistiques, et ne correspondent à aucune entité administrative légale (laquelle est stable et rendue publique par lois, décrets ou arrêtés publiés dans un des journaux officiels, ce qui n'est pas le cas des IRIS dont l'INSEE se sert uniquement comme outil pour ses études pas toutes publiques non plus) ! Le 20 janvier 2015 21:35, Christian Quest cqu...@openstreetmap.fr a écrit : J'ai modélisé les IRIS sur ma commune depuis pas mal de temps... c'est une frontière comme une autre (type=boundary) mais pas administrative. Mon petit doigt me dit qu'en principe les nouveaux IRIS devraient arriver en opendata dans un avenir proche... sans avoir vu à quoi ce jeu de données pourrait ressembler. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
Le 21 janvier 2015 01:12, Jérôme Amagat jerome.ama...@gmail.com a écrit : Je suis d'accord pour les selections multiples, les ways superposer les complique mais pour des sélections simple c'est pas très compliqué. Exemple pour le Canton Nancy-1: Avant,(c'est moi qui ai créé la relation), 3 ways : 1 way qui est une partie de la frontière de la commune et 2 ways créé pour les cantons de Nancy (1 sert aussi pour nancy 2 et l'autre pour nancy 3) Après, 72 ways : toutes les parties superposées avec des highways ont été remplacé par des highways. pour cela il a surement fallu coupé des highway et des rond point pour avoir que le morceau voulu. il reste quand même 9 ways de 2 ou 3 noeuds boundary=political pour faire la jonction entre des highway. ça fait 72 way pour 13.7 km (71 pour 9.3 km si on enlève le way frontière de commune.) Donc pour moi, ça veut dire qu'on à compliqué les highway avec de nouvelles découpes (il n'y a pas déjà assez de tag donnant de bonnes raisons de le faire), la relation est beaucoup plus compliquer (avant : beaucoup moins d'élément et que des boundary) donc plus de chance d'être détruite. En échange, c'est plus facile de faire des sélections multiples. Ici c'est pou un canton, ou la frontière est plus ou moins lié a la rue, mais pour des frontières de communes, ça veut dire que si on déplace la rue, le chemin ou la rivière la frontière est déplacer aussi. Moi, pour les landuse après m'y être déjà frotter, je ne touche plus au landuse qui on été modifié pour ne plus avoir de way superposé, trop compliqué. Il y a des cas où les limites sont portées par le même élément (limite de quartier, limite des IRIS, canton électoral, etc) et des cas où les limites sont certes proches, mais réellement distinctes (cas typique des limites administratives). Dans le premier cas, il me semble préférable et souhaitable d'utiliser le filaire existant pour définir le multipolygone, et dans le second il faut avoir des filaires séparés pour qu'un changement de géométrie n'impacte pas la limite. Si l'on traçait des géométries distinctes pour chaque limite on aurait un plat de nouille ingérable (cas fréquent de nombreuses limites passant au même endroit) et il faut préférer autant que possible la réutilisation du filaire. Le risque c'est d'avoir des multipolygones cassés, mais on peut avoir des outils pour les détecter automatiquement et améliorer leur maintenance. J'ai d'ailleurs l'impression qu'on en a moins (ou alors les réparateurs sont super efficaces). -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS
J'ai modélisé les IRIS sur ma commune depuis pas mal de temps... c'est une frontière comme une autre (type=boundary) mais pas administrative. Mon petit doigt me dit qu'en principe les nouveaux IRIS devraient arriver en opendata dans un avenir proche... sans avoir vu à quoi ce jeu de données pourrait ressembler. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
