[OSM-talk-fr] référence insee

[hpmt]

Je cherche une référence insee à inclure dans la relation de niveau 7.
il semble bien que dans banana-split (banatic pour les intimes) c'est le 
numéro siren de l'EPIC qui est utilisé comme identificateur.


On peut donc mettre dans la relation :
ref:insee=243100633
pour le sicoval, par exemple ?
sachant que les siren sont attribués par l'insee, d'une part, et que 
nous sommes dans une ère de grands basculements dans les référencements, 
d'autre part ?



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] référence insee

[alexis gayte]

pourquoi pas le siret pour référencer un entreprise geographiquement ?
du coup plus d'insee ... ref:siret peut etre ?



Le 11 janvier 2011 12:27, hpmt  a écrit :

> Je cherche une référence insee à inclure dans la relation de niveau 7.
> il semble bien que dans banana-split (banatic pour les intimes) c'est le
> numéro siren de l'EPIC qui est utilisé comme identificateur.
>
> On peut donc mettre dans la relation :
> ref:insee=243100633
> pour le sicoval, par exemple ?
> sachant que les siren sont attribués par l'insee, d'une part, et que nous
> sommes dans une ère de grands basculements dans les référencements, d'autre
> part ?
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Cordialement,
alexis GAYTE
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] référence insee

[hpmt]

alexis gayte a écrit , Le 11/01/2011 13:28:

pourquoi pas le siret pour référencer un entreprise geographiquement ?

parce qu'une entreprise, ce n'est pas un boundary=administrative.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] référence insee

[Damouns]

À ce sujet voir dans le wiki [1] qui propose : pour les EPCI, en ref=*
"le code attribué par l'INSEE à l'EPCI, qui est son numéro de SIRET"
(c'est moi qui l'ai mis, je crois, d'ailleurs).

Toutefois, il se trouve que le SIREN fait 9 chiffres et le SIRET 14
chiffres (SIREN + 5) donc si BANATIC identifie les EPCI avec 9
chiffres c'est le SIREN. Donc je modifie le wiki pour indiquer SIREN.

Damouns

[1] 
http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Tracer_les_limites_administratives#En_proposition_:_.C3.89tablissements_publics_de_coop.C3.A9ration_intercommunale

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] référence insee

[alexis gayte]

autant pour moi j'ai confondu EPIC et EPCI

cela dit
une petit recherche sur gogo

> Forme Juridique : *EPCI* - *SIRET* : 248 714 602 00013
> apib-limousin





Le 11 janvier 2011 16:41, Damouns  a écrit :

> À ce sujet voir dans le wiki [1] qui propose : pour les EPCI, en ref=*
> "le code attribué par l'INSEE à l'EPCI, qui est son numéro de SIRET"
> (c'est moi qui l'ai mis, je crois, d'ailleurs).
>
> Toutefois, il se trouve que le SIREN fait 9 chiffres et le SIRET 14
> chiffres (SIREN + 5) donc si BANATIC identifie les EPCI avec 9
> chiffres c'est le SIREN. Donc je modifie le wiki pour indiquer SIREN.
>
> Damouns
>
> [1]
> http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Tracer_les_limites_administratives#En_proposition_:_.C3.89tablissements_publics_de_coop.C3.A9ration_intercommunale
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Cordialement,
alexis GAYTE
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] référence insee

[Vincent Privat]

Bonsoir,

Je me suis prêté au jeu de modéliser un EPCI en testant chez moi:

http://www.openstreetmap.org/browse/relation/1371362

Vu que je suis encore débutant sur OSM, j'ai une question sur la manip de
JOSM: Ya-t-il un moyen de réoordonner simplement les membres d'une boundary
pour vérfier qu'ils soient dans l'ordre et qu'ils forment bien une boucle ?
Pour l'instant je réorganise à la main jusqu'à ce que la boucle apparaisse
dans l'éditeur de relations. Si ça ne pose pas de souci à l'échelle au
niveau 8, c'est déjà bien plus galère au niveau 7, j'ose pas imaginer au
dessus !

Pour la documentation, j'ai lu la page du wiki:
http://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_les_limites_administratives/Mise_au_point_du_modele_des_EPCI
et j'ai retrouvé l'identifiant INSEE ici:
http://www.insee.fr/fr/methodes/zonages/EPCI.zip

Pour la ref, pas de souci, c'est bien le SIREN à 9 chiffres :)

Par contre en lisant la page du wiki, je serai plutôt partisan de la
proposition n°2 ("utiliser boundary=local_authority") pour les raisons
suivantes:
- Pour moi un EPCI, même s'il a tout à fait sa place dans OSM, n'est pas une
entité "administrative" dans la mesure où toutes les communes ne font pas
toutes partie d'un EPCI, il n'y a donc pas couverture totale du territoire.
- Ça permet de renseigner le type d'EPCI, pas toujours déductible du nom.
- Ça permettrait de libérer l'utilisation du niveau 7 qui apparemment, fait
débat (surtout entre EPCI, canton et arrondissement de département à
priori).

Par contre il manque le lien EPCI->communes qu'on a pas facilement,
j'aimerais bien les voir apparaitre dans la relation, surtout dans le cas où
une commune ne participe pas à la frontière extérieure de l'EPCI, mais du
coup je ne sais pas trop avec quel rôle on peut faire ça ? "subarea" de la
proposition n°1 peut-être ?

Est-ce qu'on peut comme ça, choisir telle ou telle solution, ou bien le
niveau 7 est réellement la règle à utiliser ?

Merci d'avance pour vos éclaircissements :)

Vincent

Le 11 janvier 2011 20:43, alexis gayte  a écrit :

> autant pour moi j'ai confondu EPIC et EPCI
>
> cela dit
> une petit recherche sur gogo
>
> > Forme Juridique : *EPCI* - *SIRET* : 248 714 602 00013
> > apib-limousin
>
>
>
>
>
> Le 11 janvier 2011 16:41, Damouns  a écrit :
>
> À ce sujet voir dans le wiki [1] qui propose : pour les EPCI, en ref=*
>> "le code attribué par l'INSEE à l'EPCI, qui est son numéro de SIRET"
>> (c'est moi qui l'ai mis, je crois, d'ailleurs).
>>
>> Toutefois, il se trouve que le SIREN fait 9 chiffres et le SIRET 14
>> chiffres (SIREN + 5) donc si BANATIC identifie les EPCI avec 9
>> chiffres c'est le SIREN. Donc je modifie le wiki pour indiquer SIREN.
>>
>> Damouns
>>
>> [1]
>> http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Tracer_les_limites_administratives#En_proposition_:_.C3.89tablissements_publics_de_coop.C3.A9ration_intercommunale
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> --
> Cordialement,
> alexis GAYTE
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] référence insee

[Eric SIBERT]

Vu que je suis encore débutant sur OSM, j'ai une question sur la manip
de JOSM: Ya-t-il un moyen de réoordonner simplement les membres d'une
boundary pour vérfier qu'ils soient dans l'ordre et qu'ils forment bien
une boucle ?


Oui, dans la fenêtre de modification de relation, le bouton vers le bas, 
à gauche avec les lettres A..Z.


--
Éric

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] référence insee

[Vincent de Chateau-Thierry]

Bonsoir,

Le 11/01/2011 23:33, Vincent Privat a écrit :

Bonsoir,

Je me suis prêté au jeu de modéliser un EPCI en testant chez moi:

http://www.openstreetmap.org/browse/relation/1371362

Vu que je suis encore débutant sur OSM, j'ai une question sur la manip
de JOSM: Ya-t-il un moyen de réoordonner simplement les membres d'une
boundary pour vérfier qu'ils soient dans l'ordre et qu'ils forment bien
une boucle ? Pour l'instant je réorganise à la main jusqu'à ce que la
boucle apparaisse dans l'éditeur de relations. Si ça ne pose pas de
souci à l'échelle au niveau 8, c'est déjà bien plus galère au niveau 7,
j'ose pas imaginer au dessus !

Pour la documentation, j'ai lu la page du wiki:
http://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_les_limites_administratives/Mise_au_point_du_modele_des_EPCI
et j'ai retrouvé l'identifiant INSEE ici:
http://www.insee.fr/fr/methodes/zonages/EPCI.zip

Pour la ref, pas de souci, c'est bien le SIREN à 9 chiffres :)

Par contre en lisant la page du wiki, je serai plutôt partisan de la
proposition n°2 ("utiliser boundary=local_authority") pour les raisons
suivantes:
- Pour moi un EPCI, même s'il a tout à fait sa place dans OSM, n'est pas
une entité "administrative" dans la mesure où toutes les communes ne
font pas toutes partie d'un EPCI, il n'y a donc pas couverture totale du
territoire.
- Ça permet de renseigner le type d'EPCI, pas toujours déductible du nom.
- Ça permettrait de libérer l'utilisation du niveau 7 qui apparemment,
fait débat (surtout entre EPCI, canton et arrondissement de département
à priori).

Par contre il manque le lien EPCI->communes qu'on a pas facilement,
j'aimerais bien les voir apparaitre dans la relation, surtout dans le
cas où une commune ne participe pas à la frontière extérieure de l'EPCI,
mais du coup je ne sais pas trop avec quel rôle on peut faire ça ?
"subarea" de la proposition n°1 peut-être ?

Est-ce qu'on peut comme ça, choisir telle ou telle solution, ou bien le
niveau 7 est réellement la règle à utiliser ?

Merci d'avance pour vos éclaircissements :)



La page que tu cites est une tentative non aboutie de synthèse de 
discussions qui ont eu lieu ici en septembre dernier. Ce que je 
souhaitais (et je souhaite toujours), c'est qu'on puisse disposer du 
niveau 7 d'admin_level pour les arrondissements (les territoires des 
sous-préfectures). En cascade, cela impacte les EPCI qui aujourd'hui 
"squattent" ce niveau administratif, et qu'il faut donc tagguer autrement.
Pour rappel, en modélisant en admin_level=7 des EPCI, on ne peut pas 
respecter cette règle :

http://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_les_limites_administratives#Way_appartenant_.C3.A0_plusieurs_niveaux_administratifs
vu qu'un EPCI peut regrouper des communes de départements différents.

Pour la proposition boundary=local_authority, c'est bien donc 
aujourd'hui une proposition et pas autre chose, elle n'est pas 
utilisable en l'état (pas de consensus dessus). Si certains ont un avis 
dessus, voire d'autres suggestions, ne pas hésiter à l'exprimer :-)


Pour le lien EPCI <=> communes, c'est vrai qu'il n'est pas présent dans 
la relation, vu que c'est une relation qui définit une frontière 
(boundary) et non une surface (region, area...). C'est le même principe 
pour par exemple connaître l'appartenance d'une commune à un département 
ou une région : la relation qui définit le département ou la région se 
contente de lister les ways qui composent la limite extérieure du 
territoire, sans mention de communes constituantes, à part la commune 
chef-lieu, avec le role admin_centre.


Garder la logique de boundary (plutôt que region) pour les EPCI rend par 
ailleurs très simple la transition des tags boundary=administrative et 
admin_level=7 vers un nouveau modèle de tags, puisque la manière de 
construire la relation ne change pas. Il "suffit" juste de se mettre 
d'accord sur ces nouveaux tags...


vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] référence insee

[Vincent Pottier]

Le 12/01/2011 00:12, Vincent de Chateau-Thierry a écrit :

Bonsoir,


Pour le lien EPCI <=> communes, c'est vrai qu'il n'est pas présent 
dans la relation, vu que c'est une relation qui définit une frontière 
(boundary) et non une surface (region, area...). C'est le même 
principe pour par exemple connaître l'appartenance d'une commune à un 
département ou une région : la relation qui définit le département ou 
la région se contente de lister les ways qui composent la limite 
extérieure du territoire, sans mention de communes constituantes, à 
part la commune chef-lieu, avec le role admin_centre.

Pour le coup, ça, ça se calcule facilement. Même moi je sais faire !

SELECT * FROM france_polygon AS commune
JOIN france_polygon AS epci
ON ST_WITHIN(commune.way, epci.way)
WHERE epci."ref:INSEE"='theRef'
AND commune.admin_level='8'

--
FrViPofm

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] référence insee

[sylvain]

Selon Vincent Privat :

> Vu que je suis encore débutant sur OSM, j'ai une question sur la manip de
> JOSM: Ya-t-il un moyen de réoordonner simplement les membres d'une boundary
> pour vérfier qu'ils soient dans l'ordre et qu'ils forment bien une boucle ?

j'ose pas dire que j'ai moi aussi ré-ordonné les membres à la main pendant
longtemps avant de découvrir simplement qu'une des icones à gauche dans
l'éditeur de relation est justement faite pour ça...


--
sly

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] référence insee

[Vincent Privat]

Je me suis senti un peu bête en lisant la réponse ^^
Je sais pas pourquoi, mais j'imaginais que ça triait par ordre alphabétique,
sans ayant eu la curiosité de vérifier :)
Pour le candidat idéal du level 7, j'avoue que je voterai aussi pour
l'arrondissement. C'est dommage de ne pas les avoir, là :(
Merci pour vos réponses en tout cas !

Le 12 janvier 2011 01:06,  a écrit :

> Selon Vincent Privat :
>
> > Vu que je suis encore débutant sur OSM, j'ai une question sur la manip de
> > JOSM: Ya-t-il un moyen de réoordonner simplement les membres d'une
> boundary
> > pour vérfier qu'ils soient dans l'ordre et qu'ils forment bien une boucle
> ?
>
> j'ose pas dire que j'ai moi aussi ré-ordonné les membres à la main pendant
> longtemps avant de découvrir simplement qu'une des icones à gauche dans
> l'éditeur de relation est justement faite pour ça...
>
>
> --
> sly
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] référence insee

[Vincent de Chateau-Thierry]

Bonjour,

> De : "Vincent Privat" 
>
> Pour le candidat idéal du level 7, j'avoue que je voterai aussi pour
> l'arrondissement. C'est dommage de ne pas les avoir, là :(

Bien, on est 2 alors, c'est un début :-)

Sur cette page du site de l'INSEE :
http://www.insee.fr/fr/methodes/nomenclatures/cog/telechargement.asp

on trouve la liste des arrondissements, et la liste des communes avec entre 
autre leur
appartenance à un arrondissement. Donc tout ce qu'il faut pour avoir un 
référentiel des
arrondissements à transcrire en base le moment venu. Mais pour avancer, il faut 
un minimum
de consensus, et donc de retour sur les propositions pour les EPCI [1].

vincent

[1] (mon webmail casse les liens sur 2 lignes) : 
http://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_les_limites_administratives/Mi
se_au_point_du_modele_des_EPCI#Propositions

Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] référence insee

[Guillaume Allegre]

Le mer. 12 janv. 2011 à 09:45 +0100, Vincent de Chateau-Thierry a ecrit :
> 
> Bonjour,
> 
> > De : "Vincent Privat" 
> >
> > Pour le candidat idéal du level 7, j'avoue que je voterai aussi pour
> > l'arrondissement. C'est dommage de ne pas les avoir, là :(
> 
> Bien, on est 2 alors, c'est un début :-)
> 
> Sur cette page du site de l'INSEE :
> http://www.insee.fr/fr/methodes/nomenclatures/cog/telechargement.asp
> 
> on trouve la liste des arrondissements, et la liste des communes avec entre 
> autre leur
> appartenance à un arrondissement. Donc tout ce qu'il faut pour avoir un 
> référentiel des
> arrondissements à transcrire en base le moment venu. Mais pour avancer, il 
> faut un minimum
> de consensus, et donc de retour sur les propositions pour les EPCI [1].

Je suppose que ça a été évoqué, mais je n'en vois pas trace sur le wiki : 
pour les EPCI, qui sont forcément des regroupements de communes (ie pas de 
découpage intra-communal), pourquoi s'embêter à redescendre au niveau des 
frontières, 
alors qu'il suffirait de les déclarer
comme des relations regroupant des relations-communes ?



-- 
 ° /\Guillaume AllègreMembre de l'April
  /~~\/\   allegre.guilla...@free.fr  Promouvoir et défendre le logiciel libre
 /   /~~\tél. 04.76.63.26.99  http://www.april.org

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] référence insee

[Vincent de Chateau-Thierry]

Bonjour,

> De : "Guillaume Allegre" 
> 
> Je suppose que ça a été évoqué, mais je n'en vois pas trace sur le wiki : 
> pour les EPCI, qui sont forcément des regroupements de communes (ie pas de 
> découpage intra-communal), pourquoi s'embêter à redescendre au niveau des 
> frontières, 
> alors qu'il suffirait de les déclarer
> comme des relations regroupant des relations-communes ?
> 

De mon point de vue c'est avant tout une histoire de cohérence de modèle. Si, 
comme on a
commencé à le faire, on modélise les regroupements de communes que sont les 
département,
ou les régions, au travers de leur frontière, pourquoi modéliser autrement les 
EPCIs,
autres regroupements de communes ? D'autres arguments (mineurs) : ça permet de 
définir le
contour d'un EPCI sans forcément disposer de toutes les limites administratives 
des
communes, et la conversion depuis le modèle actuel(admin_level=7) est facilitée 
puisque
les membres de la relation restent les mêmes ways qu'actuellement, seuls 
quelques tags
changent.

vincent

Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] référence insee

[Vincent Pottier]

Le 13/01/2011 14:21, sly (sylvain letuffe) a écrit :

Il s'agit du débat régulier entre le modèle surfacique et le modèle frontière
pour la représentation des entités administratives.

Puisque, le cas que tu présentes : "une epci est formée d'un regroupement de
communes" et exactement le même qu'un département qui est le regroupement de
communes, une région regroupement de département, et la france, un
regroupement de régions.

J'ai la flemme de retrouver le débat dans les archives, mais je me souviens
que la conclusion est la suivante :
Chaque modèle a ses avantages et inconvénients, mais rien n'a pû être avancé
pour trancher en la faveur de l'un ou de l'autre de façon radicale. Il en
ressort un statu quo où nous continuons sur le modèle frontière pour des
raisons d'homogénéité avec ce qui est déjà en place.

Pour faire avancer le shmilblik,
Même si on ne mappe pas pour...
Quel est le traitement par osm2psql d'une relation dont les membres 
seraient les relations communes actuelles ?

On se retrouverait avec un bon polygone bien valide ?
(Parce que dans l'état actuel de la base, beaucoup de polygones 
pourraient se retrouver ici : http://osm.org/go/0BOdZeu@Y-- )

--
FrViPofm

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] référence insee

[Vincent Pottier]

Le 13/01/2011 14:46, sly (sylvain letuffe) a écrit :

On jeudi 13 janvier 2011, Vincent Pottier wrote:

Pour faire avancer le shmilblik,
Même si on ne mappe pas pour...
Quel est le traitement par osm2psql d'une relation dont les membres
seraient les relations communes actuelles ?

ça ne marcherait pas, mais tu l'as dis : "on ne mappe pas pour X"

Il est cependant envisageable de coder un programme pour déterminer
la "bordure extérieure" et construire le bon polygone.
Bon, alors je ne suis pas favorable à la relation qui contient les 
relations communes...
Avant que le programme qui va bien soit intégré à osm2pgsql, ou que 
j'arrive à l'implémenter sur ma machine...


Les utilisateurs de postGIS, Qgis, osmose et autres seront handicapés 
par cette méthode.

--
FrViPofm

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] référence insee

[Vincent de Chateau-Thierry]

> De : "Vincent Pottier" 
> Le 13/01/2011 14:46, sly (sylvain letuffe) a écrit :
> > On jeudi 13 janvier 2011, Vincent Pottier wrote:
> >> Pour faire avancer le shmilblik,
> >> Même si on ne mappe pas pour...
> >> Quel est le traitement par osm2psql d'une relation dont les membres
> >> seraient les relations communes actuelles ?
> > ça ne marcherait pas, mais tu l'as dis : "on ne mappe pas pour X"
> >
> > Il est cependant envisageable de coder un programme pour déterminer
> > la "bordure extérieure" et construire le bon polygone.
> Bon, alors je ne suis pas favorable à la relation qui contient les 
> relations communes...
> Avant que le programme qui va bien soit intégré à osm2pgsql, ou que 
> j'arrive à l'implémenter sur ma machine...
> 
> Les utilisateurs de postGIS, Qgis, osmose et autres seront handicapés 
> par cette méthode.

Il y a la complexité pour les outils (relations récursives) et aussi la
complexité pour ceux qui doivent saisir en base ces relations. Le côté gigogne
est parfait pour se perdre dans les imbrications. Bref, sur ces aspects, une 
enfilade
de ways 'limites' est plus facile à appréhender en l'état des outils comme JOSM.

Et puis, mine de rien, si on basculait en modèle 'somme de surfaces', on aurait 
les
constructions suivantes :
- les départements sont les sommes des surfaces des communes
- les régions sont les sommes des surfaces des départements
- la France est la somme des surfaces des régions.
Avec ce modèle, la métropole se réduirait aujourd'hui à l'Alsace, seule 
région
complète en terme de surfaces communales. 
Donc le modèle par somme de surface, peut-être, mais seulement le jour où notre
carto des limites sera complète. Avant cela, le modèle par frontières reste 
plus 
efficace.

vincent


Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] référence insee

[Vincent Privat]

Petit déterrage de topic sur les EPCI.

D'une part, pour dire que j'ai trouvé une source plus récente que l'INSEE
(qui ne liste les EPCI qu'au 1er janvier 2009).
Ici la liste est au 1er janvier 2010, et en plus fait un résumé des
créations/fusions récentes d'EPCI, pratique:
http://www.dgcl.interieur.gouv.fr/sections/a_votre_service/statistiques/intercommunalite/epci_a_fiscalite_pro/liste_et_composition5985/view
Vu la date de mise en ligne (23/02/2010), on peut espérer la mise à jour
2011 pour bientôt :)

D'autre part, que pensez-vous d'un outil de suivi du style "etat-epci",
similaire au suivi des communes (
http://beta.letuffe.org/cron/etat-communes/communes.csv.txt) ?

Vincent

Le 13 janvier 2011 15:37, Vincent de Chateau-Thierry  a
écrit :

>
>
> > De : "Vincent Pottier"
> > Le 13/01/2011 14:46, sly (sylvain letuffe) a écrit :
> > > On jeudi 13 janvier 2011, Vincent Pottier wrote:
> > >> Pour faire avancer le shmilblik,
> > >> Même si on ne mappe pas pour...
> > >> Quel est le traitement par osm2psql d'une relation dont les membres
> > >> seraient les relations communes actuelles ?
> > > ça ne marcherait pas, mais tu l'as dis : "on ne mappe pas pour X"
> > >
> > > Il est cependant envisageable de coder un programme pour déterminer
> > > la "bordure extérieure" et construire le bon polygone.
> > Bon, alors je ne suis pas favorable à la relation qui contient les
> > relations communes...
> > Avant que le programme qui va bien soit intégré à osm2pgsql, ou que
> > j'arrive à l'implémenter sur ma machine...
> >
> > Les utilisateurs de postGIS, Qgis, osmose et autres seront handicapés
> > par cette méthode.
>
> Il y a la complexité pour les outils (relations récursives) et aussi la
> complexité pour ceux qui doivent saisir en base ces relations. Le côté
> gigogne
> est parfait pour se perdre dans les imbrications. Bref, sur ces aspects,
> une enfilade
> de ways 'limites' est plus facile à appréhender en l'état des outils comme
> JOSM.
>
> Et puis, mine de rien, si on basculait en modèle 'somme de surfaces', on
> aurait les
> constructions suivantes :
> - les départements sont les sommes des surfaces des communes
> - les régions sont les sommes des surfaces des départements
> - la France est la somme des surfaces des régions.
> Avec ce modèle, la métropole se réduirait aujourd'hui à l'Alsace, seule
> région
> complète en terme de surfaces communales.
> Donc le modèle par somme de surface, peut-être, mais seulement le jour où
> notre
> carto des limites sera complète. Avant cela, le modèle par frontières reste
> plus
> efficace.
>
> vincent
>
>
> Une messagerie gratuite, garantie à vie et des services en plus, ça vous
> tente ?
> Je crée ma boîte mail www.laposte.net
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] référence insee

[sylvain letuffe]

Le dimanche 23 janvier 2011 17:20:29, Vincent Privat a écrit :
> Petit déterrage de topic sur les EPCI.
> 
> D'une part, pour dire que j'ai trouvé une source plus récente que l'INSEE
> (qui ne liste les EPCI qu'au 1er janvier 2009).
> Ici la liste est au 1er janvier 2010, et en plus fait un résumé des
> créations/fusions récentes d'EPCI, pratique:
> http://www.dgcl.interieur.gouv.fr/sections/a_votre_service/statistiques/int
> ercommunalite/epci_a_fiscalite_pro/liste_et_composition5985/view Vu la date
> de mise en ligne (23/02/2010), on peut espérer la mise à jour 2011 pour
> bientôt :)
> 
> D'autre part, que pensez-vous d'un outil de suivi du style "etat-epci",
> similaire au suivi des communes (
> http://beta.letuffe.org/cron/etat-communes/communes.csv.txt) ?

A l'aide des fichiers précédemment cités, je dois pouvoir adapter, pour pas 
trop cher, mon bidule des communes à celui des EPCI.
(utilisant une clef genre le siren pour faire le rapprochement entre la base 
osm et celle que tu as indiqué)

Mais il est peut-etre possible de faire plus automatique que ça. Le deuxième 
fichier du lien que tu donnes liste les communes appartenant à une EPCI, si ce 
fichier est librement utilisable au regard de la licence OSM, et que les 
communes en question sont déjà dans OSM, on peut alors imaginer importer 
automatiquement les EPCI.

--
sly


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] référence insee

[Vincent Privat]

J'ai trouvé encore mieux en farfouillant:
http://www.banatic.interieur.gouv.fr/Banatic2/index.htm
Données actualisées tous les 3 mois ! Et ya même des cartes très bien faites
:)
Pour un import auto lorsqu'on a les communes, effectivement ça se fait :)
Concernant la licence de données, les infos légales sont les suivantes:

*Téléchargement des données
Les données téléchargeables sur ce site sont des données publiques qui
peuvent être réutilisées en tout ou en partie au sein du système
d'information de l'utilisateur. Ce dernier s'engage à ne pas réutiliser ces
données à des fins commerciales ou publicitaires et à explicitement
mentionner la source des données qu'il utilise, à savoir "Source : Ministère
de l'Intérieur - DGCL".*

Avis des spécialistes ? Faut demander confirmation mais j'aurais tendance à
dire que c'est bon non ?

Le 23 janvier 2011 19:25, sylvain letuffe  a écrit :

> Le dimanche 23 janvier 2011 17:20:29, Vincent Privat a écrit :
> > Petit déterrage de topic sur les EPCI.
> >
> > D'une part, pour dire que j'ai trouvé une source plus récente que l'INSEE
> > (qui ne liste les EPCI qu'au 1er janvier 2009).
> > Ici la liste est au 1er janvier 2010, et en plus fait un résumé des
> > créations/fusions récentes d'EPCI, pratique:
> >
> http://www.dgcl.interieur.gouv.fr/sections/a_votre_service/statistiques/int
> > ercommunalite/epci_a_fiscalite_pro/liste_et_composition5985/view Vu la
> date
> > de mise en ligne (23/02/2010), on peut espérer la mise à jour 2011 pour
> > bientôt :)
> >
> > D'autre part, que pensez-vous d'un outil de suivi du style "etat-epci",
> > similaire au suivi des communes (
> > http://beta.letuffe.org/cron/etat-communes/communes.csv.txt) ?
>
> A l'aide des fichiers précédemment cités, je dois pouvoir adapter, pour pas
> trop cher, mon bidule des communes à celui des EPCI.
> (utilisant une clef genre le siren pour faire le rapprochement entre la
> base
> osm et celle que tu as indiqué)
>
> Mais il est peut-etre possible de faire plus automatique que ça. Le
> deuxième
> fichier du lien que tu donnes liste les communes appartenant à une EPCI, si
> ce
> fichier est librement utilisable au regard de la licence OSM, et que les
> communes en question sont déjà dans OSM, on peut alors imaginer importer
> automatiquement les EPCI.
>
> --
> sly
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] référence insee

[Vincent de Chateau-Thierry]

Bonsoir,

Le 23/01/2011 22:07, Vincent Privat a écrit :

J'ai trouvé encore mieux en farfouillant:
http://www.banatic.interieur.gouv.fr/Banatic2/index.htm
Données actualisées tous les 3 mois ! Et ya même des cartes très bien
faites :)
Pour un import auto lorsqu'on a les communes, effectivement ça se fait
:) Concernant la licence de données, les infos légales sont les suivantes:

/_Téléchargement des données_
Les données téléchargeables sur ce site sont des données publiques qui
peuvent être réutilisées en tout ou en partie au sein du système
d'information de l'utilisateur. Ce dernier s'engage à ne pas réutiliser
ces données à des fins commerciales ou publicitaires et à explicitement
mentionner la source des données qu'il utilise, à savoir "Source :
Ministère de l'Intérieur - DGCL"./

Avis des spécialistes ? Faut demander confirmation mais j'aurais
tendance à dire que c'est bon non ?



"Ce dernier s'engage à ne pas réutiliser ces données à des fins 
commerciales" signifie pour nous "pas d'usage possible dans OSM".

Cependant on trouve sur le site de l'INSEE ici :
http://www.insee.fr/fr/methodes/default.asp?page=zonages/intercommunalite.htm
un fichier Excel à télécharger avec la liste des communes et leur 
appartenance à un EPCI. En cliquant en bas de page sur "Mentions légales 
et crédits", on peut lire :
"Les publications et données mises à disposition sur le présent site 
sont consultables et téléchargeables gratuitement ; sauf spécification 
contraire, elles peuvent être réutilisées, y compris à des fins 
commerciales [...]".
Je n'ai rien vue de particulier dans le fichier Excel concernant la 
licence, j'ai tendance à penser que les infos qu'il donne sont 
compatibles avec une réutilisation dans OSM.


Le point à régler alors, avant un import (automatique ou pas d'ailleurs) 
c'est "comment tagguer un EPCI ?". En considérant qu'on garde la 
modélisation en "boundary=*" (cf. le début de ce fil), il est possible 
d'utiliser le modèle que je proposais ici :

http://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_les_limites_administratives/Mise_au_point_du_modele_des_EPCI#Proposition_n.C2.B02_.E2.80.93_utiliser_boundary.3Dlocal_authority_-
mais encore une fois, ça n'est qu'une proposition.

vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] référence insee

[Thomas Petillon]

Le 23/01/2011 23:31, Vincent de Chateau-Thierry a écrit :
Le point à régler alors, avant un import (automatique ou pas 
d'ailleurs) c'est "comment tagguer un EPCI ?".

Bonsoir,

Justement sur ce point, je me demandais comment il valait mieux taguer 
les noms des EPCIs. On a donc les communautés urbaines, les communauté 
d'agglomération et les communautés de communes, plus les cinq syndicats 
d'agglomération nouvelle restants. (Si on ne parle bien ici que des EPCI 
à fiscalité propre.)


La plupart des EPCIs sont nommés selon le schéma « [CU|CA|CC] de X » 
mais un nombre non négligeable ont des noms qui ne reprennent pas le 
type d'EPCI, et ce pour les trois types. Par exemple on a « Nantes 
Métropole » (CU), « Quimper Communauté » (CA) et « Poher Communauté » 
(CC). Si pour ces EPCIs on ne met pas le type dans le nom il n'est pas 
rentré dans la base, si on le met ça ne respecte pas le nom usuel.


Du coup on a plusieurs solutions :

   * Mettre juste le nom habituel, i.e. « Quimper Communauté » ou «
 Communauté de Communes de Concarneau Cornouaille ». Inconvénient
 le type d'EPCI n'est pas toujours déductible.
   * Mettre le nom habituel et préciser avec un autre tag le type, par
 exemple « epci=cu », « epci=ca » et « epci=cc ». Inconvénient on a
 une redondance pour la plupart des EPCIs entre le nom et ce tag.
   * Ne pas mettre le type d'EPCI dans le nom, i.e. « Quimper
 Communauté » (pas de changements) mais « Concarneau Cornouaille »,
 et mettre le tag indiquant le type d'EPCI. Ici on considère que le
 type ne fait pas réellement partie du nom. (Comme dans « Ville de
 Quimper » ou « Département du Finistère ».) Les EPCIs ne sont pas
 constants dans leur utilisation du type dans leurs noms. En
 regardant sur leurs sites web on voit beaucoup de « Pays de X », «
 X - Communauté de communes », avec aussi des « Communauté de
 communes de X ». Avec cette méthode on élimine des ambigüités de
 nommage, au risque de ne pas toujours coller avec le nom
 couramment utilisé par l'EPCI dans sa communication. (Mais encore
 faut-il que ce soit toujours le même donc.)

Pour l'instant dans OSM, on retrouve les deux types de nommages, suivant 
la personne qui a entré la relation dans la base. Personnellement je ne 
vois pas trop quel schéma de nommage pourrait être le mieux, mais dans 
tous les cas je pense qu'un tag indiquant le type pourrait être intéressant.


(Bien sûr tout ça c'est sans tenir compte du fait que beaucoup d'EPCI 
ont des noms comme créés par des publicitaires, qui font très 
artificiels et sonnent comme des produits qu'il faut vendre le plus 
possible, quand ils ne sont pas carrément historiquement ou 
géographiquement faux. Mais contre ça on ne peut pas grand chose, et on 
est là pour décrire la réalité du terrain, qu'elle soit jolie ou non. :| )


Thomas.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] référence insee

[Vincent de Chateau-Thierry]

Bonjour,

> De : "Thomas Petillon" 
> Le 23/01/2011 23:31, Vincent de Chateau-Thierry a écrit :
> > Le point à régler alors, avant un import (automatique ou pas 
> > d'ailleurs) c'est "comment tagguer un EPCI ?".
> Bonsoir,
> 
> Justement sur ce point, je me demandais comment il valait mieux taguer 
> les noms des EPCIs. On a donc les communautés urbaines, les communauté 
> d'agglomération et les communautés de communes, plus les cinq syndicats 
> d'agglomération nouvelle restants. (Si on ne parle bien ici que des EPCI 
> à fiscalité propre.)
> 
> La plupart des EPCIs sont nommés selon le schéma « [CU|CA|CC] de X » 
> mais un nombre non négligeable ont des noms qui ne reprennent pas le 
> type d'EPCI, et ce pour les trois types. Par exemple on a « Nantes 
> Métropole » (CU), « Quimper Communauté » (CA) et « Poher Communauté » 
> (CC). Si pour ces EPCIs on ne met pas le type dans le nom il n'est pas 
> rentré dans la base, si on le met ça ne respecte pas le nom usuel.
> 
> Du coup on a plusieurs solutions :
> 
> * Mettre juste le nom habituel, i.e. « Quimper Communauté » ou «
> Communauté de Communes de Concarneau Cornouaille ». Inconvénient
> le type d'EPCI n'est pas toujours déductible.
> * Mettre le nom habituel et préciser avec un autre tag le type, par
> exemple « epci=cu », « epci=ca » et « epci=cc ». Inconvénient on a
> une redondance pour la plupart des EPCIs entre le nom et ce tag.
> * Ne pas mettre le type d'EPCI dans le nom, i.e. « Quimper
> Communauté » (pas de changements) mais « Concarneau Cornouaille »,
> et mettre le tag indiquant le type d'EPCI. Ici on considère que le
> type ne fait pas réellement partie du nom. (Comme dans « Ville de
> Quimper » ou « Département du Finistère ».) Les EPCIs ne sont pas
> constants dans leur utilisation du type dans leurs noms. En
> regardant sur leurs sites web on voit beaucoup de « Pays de X », «
> X - Communauté de communes », avec aussi des « Communauté de
> communes de X ». Avec cette méthode on élimine des ambigüités de
> nommage, au risque de ne pas toujours coller avec le nom
> couramment utilisé par l'EPCI dans sa communication. (Mais encore
> faut-il que ce soit toujours le même donc.)
> 
> Pour l'instant dans OSM, on retrouve les deux types de nommages, suivant 
> la personne qui a entré la relation dans la base. Personnellement je ne 
> vois pas trop quel schéma de nommage pourrait être le mieux, mais dans 
> tous les cas je pense qu'un tag indiquant le type pourrait être intéressant.
> 

Je vois une autre possibilité (en fait celle déjà sur le wiki) qui est de 
donner 
pour name=* le nom indiqué par l'INSEE dans le référentiel des EPCIs, en 
remplaçant
les abbréviations (CA, CU, CC, SAN) par les mots complets. C'est verbeux mais 
puisé à une seule source (qui doit faire référence sur le sujet, j'imagine) 
et peut éviter des ambiguïtés lorsque l'EPCI a le même nom que la ville 
principale :
CU d'Arras, CU d'Alençon par ex.
On pourrait aussi faire figurer dans un autre tag l'acronyme, qui tient parfois 
lieu 
de nom d'usage, et aussi, a priori dans le alt_name=* le nom sans les termes 
CA, CU,
ce qui revient à ta 3e proposition.

Comme tu l'évoque en 2e, un tag dédié au type me semble essentiel, à l'image du
school:FR=*, toujours dans l'idée d'une typologie non déduite du nom mais 
explicitée,
et stockée à un endroit dédié.

Reste à qualifier l'EPCI avec le boundary=* (on avance !). S'il y a des 
objections au 
"boundary=local_authority" déjà proposé (mais peu discuté), ce serait bien de 
les lire. 

vincent


Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] référence insee

[Thomas Petillon]

Bonjour,

2011/1/24 Vincent de Chateau-Thierry 

>
> Bonjour,
>
> Je vois une autre possibilité (en fait celle déjà sur le wiki) qui est de
> donner
> pour name=* le nom indiqué par l'INSEE dans le référentiel des EPCIs, en
> remplaçant
> les abbréviations (CA, CU, CC, SAN) par les mots complets. C'est verbeux
> mais
> puisé à une seule source (qui doit faire référence sur le sujet, j'imagine)
> et peut éviter des ambiguïtés lorsque l'EPCI a le même nom que la ville
> principale :
> CU d'Arras, CU d'Alençon par ex.
> On pourrait aussi faire figurer dans un autre tag l'acronyme, qui tient
> parfois lieu
> de nom d'usage, et aussi, a priori dans le alt_name=* le nom sans les
> termes CA, CU,
> ce qui revient à ta 3e proposition.
>

Oui, c'est vrai que se baser sur une base uniqueet à priori officiel, c'est
pas plus mal.
Il y a aussi la possibilité de mettre le nom usuel dans name et le nom de la
base de l'INSEE dans official_name. (Mais qui s'il est présent sur le wiki
n'est pas très utilisé avec ~4 000 utilisations dans le monde.)


>
> Comme tu l'évoque en 2e, un tag dédié au type me semble essentiel, à
> l'image du
> school:FR=*, toujours dans l'idée d'une typologie non déduite du nom mais
> explicitée,
> et stockée à un endroit dédié.
>

En fait ce point était déjà dans la page du wiki, mais je ne l'avais pas vu.


>
> Reste à qualifier l'EPCI avec le boundary=* (on avance !). S'il y a des
> objections au
> "boundary=local_authority" déjà proposé (mais peu discuté), ce serait bien
> de les lire.
>

Pas d'objections de ma part. Un admin_level pose des problèmes, notamment
parce que les EPCIs ne s'insèrent pas dans les inclusions successives
régions > départements > communes. Mais c'est vrai que dans la pratique
c'est le niveau entre la commune et le département, donc c'est pas
complètement faux non plus.

(Et au passage, considérer les arrondissements de département comme des
admin_levels me semble pas complètement juste non plus, ce sont plus des
découpages internes au fonctionnement des divers organes de l'état. Pour
citer Wikipédia : « Contrairement aux régions, aux départements et aux
communes, les arrondissements départementaux ne possèdent pas le statut de
personne morale de droit public. Ils n'ont par ailleurs pas de nom propre et
sont désignés par le nom de la ville siège de la sous-préfecture. Toujours à
la différence de ces divisions territoriales, les arrondissements ne sont
pas gérés par des personnes élues, mais désignées par la présidence de la
République française. »)

Thomas.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] référence insee

[Vincent Pottier]

Le 24/01/2011 09:46, Vincent de Chateau-Thierry a écrit :

Bonjour,

Reste à qualifier l'EPCI avec le boundary=* (on avance !). S'il y a des 
objections au
"boundary=local_authority" déjà proposé (mais peu discuté), ce serait bien de 
les lire.

Nihil obstat (rien n'empêche)
--
FrViPofm

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] référence insee

[hpmt]

Vincent Privat a écrit , Le 23/01/2011 22:07:

J'ai trouvé encore mieux en farfouillant:
http://www.banatic.interieur.gouv.fr/Banatic2/index.htm
Données actualisées tous les 3 mois ! Et ya même des cartes très bien
faites :)


Trop marrant !
C'est le site que je citais dans le tout premier message de ce fil !
Les redécouvertes sont toujours plus juteuses, non ?
Où alors, personne n'a soupçonné que mon "banatic" voulait dire quelque 
chose ?

:>)

Hélène


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] référence insee

[Vincent de Chateau-Thierry]

Bonsoir,

Le 24/01/2011 12:05, Thomas Petillon a écrit :
>
> Pas d'objections de ma part. Un admin_level pose des problèmes,
> notamment parce que les EPCIs ne s'insèrent pas dans les inclusions
> successives régions > départements > communes. Mais c'est vrai que
> dans la pratique c'est le niveau entre la commune et le département,
> donc c'est pas complètement faux non plus.
>
> (Et au passage, considérer les arrondissements de département comme
> des admin_levels me semble pas complètement juste non plus, ce sont
> plus des découpages internes au fonctionnement des divers organes de
> l'état. Pour citer Wikipédia : « Contrairement aux régions, aux
> départements et aux  communes, les arrondissements départementaux ne
> possèdent pas le statut de personne morale de droit public. Ils n'ont 
> par ailleurs pas de nom propre et sont désignés par le nom de la

> ville siège de la sous-préfecture. Toujours à la différence de ces
> divisions territoriales, les arrondissements ne sont pas gérés par
> des personnes élues, mais désignées par la présidence de la
> République française. »)
>
> Thomas.

Merci Thomas. J'ai il est vrai plus l'aspect "imbrication / pyramide" en 
tête pour motiver l'attribution de l'admin_level=7 aux arrondissements. 
Sur la foi de l'article que tu cites, il serait au passage pertinent de 
ne pas attribuer de name=* aux arrondissements, mais leur ref:INSEE=* et 
l'admin_centre=*.


Le 24/01/2011 14:45, Vincent Pottier a écrit :


Le 24/01/2011 09:46, Vincent de Chateau-Thierry a écrit :

Bonjour,

Reste à qualifier l'EPCI avec le boundary=* (on avance !). S'il y a
des objections au
"boundary=local_authority" déjà proposé (mais peu discuté), ce serait
bien de les lire.

Nihil obstat (rien n'empêche)
--
FrViPofm



Et si en plus Vincent donne son Imprimatur, alors là  :-)

Ce que je vous propose pour la suite, compte tenu des retours :
- documenter sur le wiki (de façon plus propre qu'aujourd'hui) la 
modélisation des EPCIs, a priori sur cette page :

http://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_les_limites_administratives
où le sujet est déja évoqué,
- documenter la nouvelle modélisation des arrondissements sur la même page,
- voir avec Sly (allo Sylvain ?) pour une prise en compte des EPCIs dans 
le rendu des découpages sur beta.letuffe.org
- une fois ces points validés, convertir les EPCIs déjà dans OSM vers la 
nouvelle modélisation


Ca ne sera pas fait (si c'est par moi) dans la minute, mais dans les 
jours à venir. Si d'autres initient la démarche, merci de se manifester 
par ici.


vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Référence INSEE des communes et points "admin_centre" : chantiers terminés

[Vincent de Chateau-Thierry]

  
  
Bonjour,
C'en est terminé des deux chantiers PlaceMaker
  autour du rôle admin_centre dans les relations
administratives communales
[1] et de l'ajout du code INSEE pour les communes en
étant dépourvues [2].
Dans le premier cas, ça signifie que notre manière de
représenter une commune à l'aide d'une
  relation est (à ce jour) homogène sur les 32.000 et
  quelques communes déjà couvertes.
  Dans le second, cela aboutit
normalement à ce que toutes les communes référencées
par l'INSEE aient leur
identifiant présent dans OSM, soit
  sur la relation, soit sur un node, soit (souvent)
  sur les deux.
  
  Merci aux contributeurs qui y sont
allé de leurs clics et de leur temps !
  
  vincent

[1] :
  http://osm.vdct.free.fr/admin_centre/index.html
  [2] :
http://osm.vdct.free.fr/ref_insee/index.html

  


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Référence INSEE des communes et points "admin_centre" : chantiers terminés

[Black Myst]

Le 23 février 2013 14:52, Vincent de Chateau-Thierry  a
écrit :

>  Bonjour,
> C'en est terminé des deux chantiers PlaceMaker autour du rôle
> admin_centre dans les relations administratives communales [1] et de
> l'ajout du code INSEE pour les communes en étant dépourvues [2].
>
Cool,

Ca fait toujours plaisir de voir un sujet complété. ;-)

Black Myst
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Référence INSEE des communes et points "admin_centre" : chantiers terminés

[Christian Quest]

Très bonne nouvelle !

Il n'y a plus qu'à faire un petit script de suivi pour voir ce qui pourrait
être modifié et nous faire revenir en arrière.


Le 23 février 2013 18:49, Black Myst  a écrit :

> Le 23 février 2013 14:52, Vincent de Chateau-Thierry  a
> écrit :
>
>>  Bonjour,
>> C'en est terminé des deux chantiers PlaceMaker autour du rôle
>> admin_centre dans les relations administratives communales [1] et de
>> l'ajout du code INSEE pour les communes en étant dépourvues [2].
>>
> Cool,
>
> Ca fait toujours plaisir de voir un sujet complété. ;-)
>
> Black Myst
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Christian Quest - OpenStreetMap France
Week-end "SOTM-FR" à Lyon, les 23-24 février prochains:
http://openstreetmap.fr/sotmfr2013
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Référence INSEE des communes et points "admin_centre" : chantiers terminés

[thevenon . julien]

Salut,

Je vois pouvoir m en charger avec SODA. Je n ai suivi le projet que de loin, qu 
est ce qu il faut verifier exactement ?

Julien


- Mail original -
De: "Christian Quest" 
À: "Discussions sur OSM en français" 
Envoyé: Dimanche 24 Février 2013 07:52:28
Objet: Re: [OSM-talk-fr]    Référence INSEE des communes et points 
"admin_centre" : chantiers terminés


Très bonne nouvelle ! 


Il n'y a plus qu'à faire un petit script de suivi pour voir ce qui pourrait 
être modifié et nous faire revenir en arrière. 



Le 23 février 2013 18:49, Black Myst < black.m...@free.fr > a écrit : 



Le 23 février 2013 14:52, Vincent de Chateau-Thierry < v...@laposte.net > a 
écrit : 





Bonjour, 
C'en est terminé des deux chantiers PlaceMaker autour d u rôle admin_centre 
dans les relations admi nistrativ es communales [1] et de l'ajout du code INSEE 
pour les communes en étant dépourv ues [2] . 
Cool, 


Ca fait toujours plaisir de voir un sujet complété. ;-) 


Black Myst 
___ 
Talk-fr mailing list 
Talk-fr@openstreetmap.org 
http://lists.openstreetmap.org/listinfo/talk-fr 





-- 
Christian Quest - OpenStreetMap France 
Week-end "SOTM-FR" à Lyon, les 23-24 février prochains: 
http://openstreetmap.fr/sotmfr2013 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Référence INSEE des communes et points "admin_centre" : chantiers terminés

[Vincent de Chateau-Thierry]

Bonjour,

> De : thevenon.jul...@free.fr
> 
> Je vois pouvoir m en charger avec SODA. Je n ai suivi le projet que de loin, 
> qu est ce 
qu il faut verifier exactement ?
> 

Pour la partie "admin_centre" : une relation décrite au moins par les tags
"boundary=administrative" et "admin_level=8" doit avoir un membre avec comme 
rôle 
'admin_centre'. 

Pour le sujet "ref:INSEE" : il s'agit de contrôler qu'aucune référence INSEE 
des communes
actuelles ne manque dans OSM, dans le tag ref:INSEE. Pour ce sujet il y a un 
point à
établir : avoir une liste des codes INSEE à jour, d'étendue France. Sur le site 
de
l'INSEE, les mises à jour se terminent au 01/01/2012, donc pas de trace des 
fusions ou
rétablissements opérées depuis. OSM peut donc se retrouver en avance 
localement...

vincent

Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Référence INSEE des communes et points "admin_centre" : chantiers terminés

[Francescu GAROBY]

Il faudrait aussi vérifier que le 'ref:INSEE' du node 'admin_centre' est
équivalent à celui de la relation, pour détecter les fautes de frappe,
erreurs d'inattention ou fusion de communes (si le node date d'avant la
fusion et que la relation date d'après).

Francescu


Le 25 février 2013 14:26, Vincent de Chateau-Thierry  a
écrit :

> Bonjour,
>
> > De : thevenon.jul...@free.fr
> >
> > Je vois pouvoir m en charger avec SODA. Je n ai suivi le projet que de
> loin, qu est ce
> qu il faut verifier exactement ?
> >
>
> Pour la partie "admin_centre" : une relation décrite au moins par les tags
> "boundary=administrative" et "admin_level=8" doit avoir un membre avec
> comme rôle
> 'admin_centre'.
>
> Pour le sujet "ref:INSEE" : il s'agit de contrôler qu'aucune référence
> INSEE des communes
> actuelles ne manque dans OSM, dans le tag ref:INSEE. Pour ce sujet il y a
> un point à
> établir : avoir une liste des codes INSEE à jour, d'étendue France. Sur le
> site de
> l'INSEE, les mises à jour se terminent au 01/01/2012, donc pas de trace
> des fusions ou
> rétablissements opérées depuis. OSM peut donc se retrouver en avance
> localement...
>
> vincent
>
> Une messagerie gratuite, garantie à vie et des services en plus, ça vous
> tente ?
> Je crée ma boîte mail www.laposte.net
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Cordialement,
Francescu GAROBY
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Référence INSEE des communes et points "admin_centre" : chantiers terminés

[Vincent de Chateau-Thierry]

> De : "Francescu GAROBY" 
>
> Il faudrait aussi vérifier que le 'ref:INSEE' du node 'admin_centre' est
> équivalent à celui de la relation, pour détecter les fautes de frappe,
> erreurs d'inattention ou fusion de communes (si le node date d'avant la
> fusion et que la relation date d'après).
> 

Oui. Je pense que pour ça Osmose est déjà équipé : si l'analyse n'existe pas 
déjà, elle
est à portée de main.

vincent

Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Référence INSEE pour quelques communes (était : Mise à jour pour l'intégration des bureaux de poste)

[Vincent de Chateau-Thierry]

Bonsoir,

Le 12/02/2013 16:51, sly (sylvain letuffe) a écrit :

On mardi 12 février 2013, Vincent de Chateau-Thierry wrote:

Ça, c'est si on décide que toutes les communes doivent avoir un ref:INSEE
sans attendre le tracé de leurs limites.


Je croyais que c'était le cas : si les limites sont là, ce sont elles qui
portent le ref:INSEE
Si elles ne sont pas là, c'est pour l'instant un noeud simple qui le porte.

Modèle classique pour les shop par exemple où on recommande d'ajouter les tags
à l'emprise du bâtiment si possible, mais sinon, un noeud reste tout à fait
acceptable pointant approximativement le centre du magasin


alors pourquoi pas. Mais il y a un côté fastidieux + jetable à considérer.


Fastidieux, oui, mais jetable, pas tant : le boulot n'est pas tant dans la
recherche du ref:INSEE mais plutôt de savoir où se trouve la mairie de la
commune pour pointer le admin_centre, qui lui, restera, même après. Seule la
ref:INSEE pourra en être retiré (ou pas, on est plus à un doublon prêt)


Je compte à l'instant 930 communes candidates : sans ref:INSEE ni sur la
relation ni sur un node.

930, c'est pas énorme, un joli projet de la semaine en perspective ;-)




En refaisant les comptes (avec des données à jour !) ce ne sont pas 930 
candidats mais seulement 121, et tous dans le même département : la 
Dordogne.

Ils sont présentés ici :
http://osm.vdct.free.fr/ref_insee/index.html avec quelques explications 
en bas de page sur comment procéder.


vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Référence INSEE pour quelques communes (était : Mise à jour pour l'intégration des bureaux de poste)

[Black Myst]

Le 14 février 2013 21:52, Vincent de Chateau-Thierry  a
écrit :
>
> En refaisant les comptes (avec des données à jour !) ce ne sont pas 930
> candidats mais seulement 121, et tous dans le même département : la
> Dordogne.
> Ils sont présentés ici :
> http://osm.vdct.free.fr/ref_**insee/index.htmlavec
>  quelques explications en bas de page sur comment procéder.
>

Je viens d'en compléter une dizaine.

Il est un peu surprenant de ne pas être centré dans JOSM sur le nouvel
élément.
Sinon, l'option "Marquer comme traité" n'efface pas immédiatement le
message, du coup je pense que j'ai cliqué 20x sur le premier que j'ai
corrigé avant de me rendre compte qu'un changement de zoom le faisait
disparaître.

Cdt
Black Myst
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Référence INSEE pour quelques communes (était : Mise à jour pour l'intégration des bureaux de poste)

[Vincent de Chateau-Thierry]

Bonjour,

> De : "Black Myst" 
> Le 14 février 2013 21:52, Vincent de Chateau-Thierry  a
> écrit :
> >
> > En refaisant les comptes (avec des données à jour !) ce ne sont pas 930
> > candidats mais seulement 121, et tous dans le même département : la
> > Dordogne.
> > Ils sont présentés ici :
> > http://osm.vdct.free.fr/ref_insee/index.html avec quelques explications en 
> > bas de 
page sur comment procéder.
> >
> 
> Je viens d'en compléter une dizaine.

Merci

> Il est un peu surprenant de ne pas être centré dans JOSM sur le nouvel
> élément.
> Sinon, l'option "Marquer comme traité" n'efface pas immédiatement le
> message, du coup je pense que j'ai cliqué 20x sur le premier que j'ai
> corrigé avant de me rendre compte qu'un changement de zoom le faisait
> disparaître.

Merci pour ton retour. Je vais essayer d'améliorer ces 2 points mais le temps 
presse car
la liste des candidats fond :-).

vincent

Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Référence INSEE pour quelques communes (était : Mise à jour pour l'intégration des bureaux de poste)

[Vincent de Chateau-Thierry]

> De : "Vincent de Chateau-Thierry" 
> 
> > De : "Black Myst" 
> 
> > Il est un peu surprenant de ne pas être centré dans JOSM sur le nouvel
> > élément.

Ça devrait mieux se passer désormais. Un petit périmètre de données autour du 
nouveau
node est chargé depuis OSM.

> > Sinon, l'option "Marquer comme traité" n'efface pas immédiatement le
> > message, du coup je pense que j'ai cliqué 20x sur le premier que j'ai
> > corrigé avant de me rendre compte qu'un changement de zoom le faisait
> > disparaître.
Oui, changement de zoom ou bien recliquer sur le n° de département en ayant 
décoché :
"Activer le cadrage par département". Désolé, j'ai pas mieux à l'instant. 

vincent


Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr