Zonages statistiques Ilots et IRIS

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

Zonages statistiques Ilots et IRIS

Vincent de Château-Thierry-2
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Zonages statistiques Ilots et IRIS

Marc SIBERT
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
[hidden email]

Le 20 janvier 2015 14:51, Vincent de Château-Thierry <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr


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

Re: Zonages statistiques Ilots et IRIS

Damouns
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 <[hidden email]> 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
[hidden email]

Le 20 janvier 2015 14:51, Vincent de Château-Thierry <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr


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



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

Re: Zonages statistiques Ilots et IRIS

jbosm
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 <[hidden email]> 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
[hidden email]

Le 20 janvier 2015 14:51, Vincent de Château-Thierry <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr


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




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


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

Re: Zonages statistiques Ilots et IRIS

Marc SIBERT
Ç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
[hidden email]

Le 20 janvier 2015 17:36, JB <[hidden email]> 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 <[hidden email]> 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
[hidden email]

Le 20 janvier 2015 14:51, Vincent de Château-Thierry <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr


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




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


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



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

Re: Zonages statistiques Ilots et IRIS

verdy_p
In reply to this post by Marc SIBERT
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 <[hidden email]> 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
[hidden email]

Le 20 janvier 2015 14:51, Vincent de Château-Thierry <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr


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



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

Re: Zonages statistiques Ilots et IRIS

Jérôme Amagat
In reply to this post by Marc SIBERT
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Zonages statistiques Ilots et IRIS

verdy_p
In reply to this post by Damouns
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]

Le 20 janvier 2015 14:51, Vincent de Château-Thierry <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr


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



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



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

Re: Zonages statistiques Ilots et IRIS

verdy_p
In reply to this post by Jérôme Amagat
Ç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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr



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

Re: Zonages statistiques Ilots et IRIS

cquest
In reply to this post by Jérôme Amagat
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Christian Quest - cquest@openstreetmap.fr
Reply | Threaded
Open this post in threaded view
|

Re: Zonages statistiques Ilots et IRIS

Romain MEHUT-2
In reply to this post by verdy_p
Bonsoir,

Le 20 janvier 2015 20:02, Philippe Verdy <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Zonages statistiques Ilots et IRIS

verdy_p
In reply to this post by cquest
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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr


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

Re: Zonages statistiques Ilots et IRIS

Vincent de Château-Thierry
In reply to this post by Marc SIBERT

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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Zonages statistiques Ilots et IRIS

verdy_p
In reply to this post by Romain MEHUT-2
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.

L"avantage 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 <[hidden email]> a écrit :
Bonsoir,

Le 20 janvier 2015 20:02, Philippe Verdy <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Zonages statistiques Ilots et IRIS

verdy_p
In reply to this post by Vincent de Château-Thierry
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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr


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

Re: Zonages statistiques Ilots et IRIS

Jérôme Amagat
In reply to this post by Romain MEHUT-2


Le 20 janvier 2015 22:00, Romain MEHUT <[hidden email]> a écrit :
Bonsoir,

Le 20 janvier 2015 20:02, Philippe Verdy <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Zonages statistiques Ilots et IRIS

cquest
Le 21 janvier 2015 01:12, Jérôme Amagat <[hidden email]> 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 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é.


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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Christian Quest - cquest@openstreetmap.fr
Reply | Threaded
Open this post in threaded view
|

Re: Zonages statistiques Ilots et IRIS

pyrog
In reply to this post by cquest

Le 20 janv. 2015 à 21:35, Christian Quest <[hidden email]> a écrit :

Mon petit doigt me dit qu'en principe les nouveaux IRIS devraient
arriver en opendata dans un avenir proche…

;-)

Quel peut-être l’intérêt pour OSM et les citoyens lambdas ?

Yves


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

Re: Zonages statistiques Ilots et IRIS

Romain MEHUT-2
In reply to this post by cquest
Bonjour,

Le 21 janvier 2015 08:45, Christian Quest <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Zonages statistiques Ilots et IRIS

cquest
In reply to this post by pyrog
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 <[hidden email]> a écrit :

Le 20 janv. 2015 à 21:35, Christian Quest <[hidden email]> a écrit :

Mon petit doigt me dit qu'en principe les nouveaux IRIS devraient
arriver en opendata dans un avenir proche…

;-)

Quel peut-être l’intérêt pour OSM et les citoyens lambdas ?

Yves


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




--
Christian Quest - OpenStreetMap France

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