Re: [OSM-talk-fr] près de 200 nouvelles communes au 1er jv 2016

2015-12-19 Par sujet Jérôme Amagat 
c'est vrai que border_type c'est pour les frontières alors pourquoi pas
admin_type.

ça pourrait faire pour les communes nouvelles, (comme les autres communes) :
type=boundary
boundary=administrative
admin_level=8
name=*
et
source=* (Arrêté préfectoral)
start_date=2016-01-01

et pour les communes déléguées :
type=boundary
boundary=administrative
admin_level=9
name=*
et
source=* (Arrêté préfectoral)
start_date=2016-01-01
admin_type:FR=commune déléguée

Et je pense que vu que le 01 janvier 2016, c'est dans moins de 2 semaines
on peut faire les changements dès maintenant sans que ça pose problème.




Le 18 décembre 2015 à 20:12, Philippe Verdy  a écrit :

> Le tag "admin_level=9" va bien, mais plutôt que "border_type" qui est bien
> chargé (avec ses valeurs génériques en anglais), je verrais plutôt
> "admin_type:FR=*" (avec le suffixe :FR pour le statut strictement
> franco_français).
>
> Je garderais aussi "boundary=administrative" pour ce niveau 9 et non pas
> boundary=local_authority (qui n'a pas d'admin_level, surtout pas en France
> quand les EPCI peuvent être à chevel entre des entités adminsitrative de
> niveau différents et grouper des entités de statut légal différents).
>
> Il ne s'agit en effet pas de différencier les types de frontières (même
> pas visuellement) ni la disposition hiérarchique.
>
> De plus cette différenciation est à mettre non pas sur les ways
> frontières, mais sur les relations définissant les surfaces. Sur les ways
> frontières le border_type est là uniquement pour dfiférencier visuellement
> le tracé entre deux administratives (ou plus avec la hiérarchie applicable
> à chaque côté), ou pour diférencier des frontières qui ne sont pas
> nécessairement fermées (exemple les limites maritimes) et le typenon pas
> des entités séparées par cette frontière mais de l'accord qui les lie me^me
> quand les entites séparées sont de types différents (ce qui est courant sur
> des limites internationales). Le border_type sur un chemin frontière ne
> peut pas indiquer précisément le type des entités situées à droite et/ou à
> gauche
>
> On a un autre cas similaire pour le niveau 6 des deux entitées de l'ancien
> Rhône (département ou métropole ?), ou encore pour le niveau 3 pour les
> statuts des entités composant la France en Outremer. ou encore au niveau 2
> sur des frontières contestées par d'autres pays.
>
> Ici il s'agit juste de pouvoir non pas changer les niveaux hiérarchiques
> mais pouvoir ensuite détailler le statut réel de chaque entité territoriale
> (avec un statut légal donné ici purement franco-français) qui utilise (ou
> pas!) les chemins frontières. administrivement dans la hiérarchie
> nationale, "admin_level=*" modélise la déconcentration de l'Etat, mais on
> cherche à coder séparément les tyopes de collectivités territoriales selon
> leur autonomie de fonctionnement propre., mais cette précision n'est
> souvent mpême pas nécessaire sauf en tant qu'annotation pour révéler leur
> statut complet détaillé (sachant que le décodage de leurs noms officiel est
> assez compliqué à faire et plein d'exceptions spécifiques).
>
>
>
> Le 18 décembre 2015 à 14:52, Jérôme Amagat  a
> écrit :
>
>> Vu l'ampleur pris par ces communes nouvelles et donc l'explosion des
>> communes déléguées, je pense que l'on devrait créer un tag pour
>> différencier ces anciennes communes de quartiers ou d'autres choses taguer
>> avec admin_level=9 ou 10.
>> Je verrai bien quelque chose sur le modèle des communauté de communes :
>> type=boundary
>> boundary=local_authority
>> local_authority:FR=commune déléguée (ainsi que "commune associée" pour
>> l'ancien système de fusion de communes)
>>
>> ou alors utiliser admin_level=9 avec le tag border_type (
>> http://wiki.openstreetmap.org/wiki/Key:border_type) pour différencier
>> les types de frontières :
>> type=boundary
>> boundary=local_authority
>> admin_level=9
>> border_type=commune déléguée
>>   commune associée
>>   arondissement
>>
>>
>> Le 17 décembre 2015 à 10:11, adrien carpentier 
>> a écrit :
>>
>>> Salut à tous!
>>> je viens de recevoir cette info :
>>> http://www.maire-info.com/article.asp?param=19055=PLUS=1
>>> il y a du gâteau de Noël dans l'air...
>>> idem, une nouvelle CU en NPDC
>>>
>>> http://www.lagazettedescommunes.com/420297/vers-une-nouvelle-communaute-urbaine-dans-le-pas-de-calais/?utm_source=quotidien_medium=Email_campaign=27-11-2015-quotidien
>>> @ bientôt
>>> adrien
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
>

Re: [OSM-talk-fr] Accès ancienne version du cadastre (osm: message 8 of 20)

2015-12-19 Par sujet osm . sanspourriel 
mets simplement un start_date=2015-12-31 (ce n'est pas plutôt le 
1026-01-01 ? D'un point de vue comptabilité c'est plus simple !)
Ou tu préfixes par construction 
:, voir 
http://wiki.openstreetmap.org/wiki/Lifecycle_prefix.


Le 19/12/2015 14:34, Stéphane Péneau - stephane.pen...@wanadoo.fr a écrit :

Coucou !

Est-ce que quelqu'un connait une méthode pour accéder à d'anciennes 
versions du cadastre ?


En effet, dans le lot des communes nouvelles, des communes fusionnées 
depuis 1974 retrouvent leurs limites communales, pour devenir des 
communes déléguées.


La commune fusionnée :
Vihiers : https://www.openstreetmap.org/relation/547829

communes qui retrouvent des limites : Saint-Hilaire-du-Bois et Voide



H me !! J'ai déjà créé la commune nouvelle, et je viens de me 
rendre compte que sa date de création n'est pas au 15 décembre, mais 
au 31.

Du coup, je suis en avance, et idem pour une autre :
http://www.openstreetmap.org/relation/5753848

Bon, à 10 jours près, je ne supprime pas ce que j'ai fait... si ?

Stf

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


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

Re: [OSM-talk-fr] près de 200 nouvelles communes au 1er jv 2016

2015-12-19 Par sujet Philippe Verdy 
Ca va très bien pour qualifier cet admin_level=9. Y compris les
arrondissements de Paris/Lyon/Marseille, les communes déléguées, les
communes associées.

Pour être complet on devrait aussi mettre un "admin_type:FR=*" sur
l'admin_level=8 au moins pour les communes ayant ces subdivisions
admin_level=9, mais la loi ne leur donne pas vraiment de nom distinctif
(sauf pour les "communes nouvelles") et les désigne simplement comme
"communes", quelle que soit leur organisation.
.
En revanche pas besoin d'admin_type pour les communes simples en
admin_level=8 où n'existe donc qu'un seul maire de droit commun (pas de
maires délégués, de maires de secteurs, de maires d'arrondissements... un
seul registre d'état-civil, un seul code INSEE, un seul plan cadastral).
c'est encore l'immense majorité.


Le 19 décembre 2015 à 22:15, Jérôme Amagat  a
écrit :

> c'est vrai que border_type c'est pour les frontières alors pourquoi pas
> admin_type.
>
> ça pourrait faire pour les communes nouvelles, (comme les autres communes)
> :
> type=boundary
> boundary=administrative
> admin_level=8
> name=*
> et
> source=* (Arrêté préfectoral)
> start_date=2016-01-01
>
> et pour les communes déléguées :
> type=boundary
> boundary=administrative
> admin_level=9
> name=*
> et
> source=* (Arrêté préfectoral)
> start_date=2016-01-01
> admin_type:FR=commune déléguée
>
> Et je pense que vu que le 01 janvier 2016, c'est dans moins de 2 semaines
> on peut faire les changements dès maintenant sans que ça pose problème.
>
>
>
>
> Le 18 décembre 2015 à 20:12, Philippe Verdy  a écrit :
>
>> Le tag "admin_level=9" va bien, mais plutôt que "border_type" qui est
>> bien chargé (avec ses valeurs génériques en anglais), je verrais plutôt
>> "admin_type:FR=*" (avec le suffixe :FR pour le statut strictement
>> franco_français).
>>
>> Je garderais aussi "boundary=administrative" pour ce niveau 9 et non pas
>> boundary=local_authority (qui n'a pas d'admin_level, surtout pas en France
>> quand les EPCI peuvent être à chevel entre des entités adminsitrative de
>> niveau différents et grouper des entités de statut légal différents).
>>
>> Il ne s'agit en effet pas de différencier les types de frontières (même
>> pas visuellement) ni la disposition hiérarchique.
>>
>> De plus cette différenciation est à mettre non pas sur les ways
>> frontières, mais sur les relations définissant les surfaces. Sur les ways
>> frontières le border_type est là uniquement pour dfiférencier visuellement
>> le tracé entre deux administratives (ou plus avec la hiérarchie applicable
>> à chaque côté), ou pour diférencier des frontières qui ne sont pas
>> nécessairement fermées (exemple les limites maritimes) et le typenon pas
>> des entités séparées par cette frontière mais de l'accord qui les lie me^me
>> quand les entites séparées sont de types différents (ce qui est courant sur
>> des limites internationales). Le border_type sur un chemin frontière ne
>> peut pas indiquer précisément le type des entités situées à droite et/ou à
>> gauche
>>
>> On a un autre cas similaire pour le niveau 6 des deux entitées de
>> l'ancien Rhône (département ou métropole ?), ou encore pour le niveau 3
>> pour les statuts des entités composant la France en Outremer. ou encore au
>> niveau 2 sur des frontières contestées par d'autres pays.
>>
>> Ici il s'agit juste de pouvoir non pas changer les niveaux hiérarchiques
>> mais pouvoir ensuite détailler le statut réel de chaque entité territoriale
>> (avec un statut légal donné ici purement franco-français) qui utilise (ou
>> pas!) les chemins frontières. administrivement dans la hiérarchie
>> nationale, "admin_level=*" modélise la déconcentration de l'Etat, mais on
>> cherche à coder séparément les tyopes de collectivités territoriales selon
>> leur autonomie de fonctionnement propre., mais cette précision n'est
>> souvent mpême pas nécessaire sauf en tant qu'annotation pour révéler leur
>> statut complet détaillé (sachant que le décodage de leurs noms officiel est
>> assez compliqué à faire et plein d'exceptions spécifiques).
>>
>>
>>
>> Le 18 décembre 2015 à 14:52, Jérôme Amagat  a
>> écrit :
>>
>>> Vu l'ampleur pris par ces communes nouvelles et donc l'explosion des
>>> communes déléguées, je pense que l'on devrait créer un tag pour
>>> différencier ces anciennes communes de quartiers ou d'autres choses taguer
>>> avec admin_level=9 ou 10.
>>> Je verrai bien quelque chose sur le modèle des communauté de communes :
>>> type=boundary
>>> boundary=local_authority
>>> local_authority:FR=commune déléguée (ainsi que "commune associée" pour
>>> l'ancien système de fusion de communes)
>>>
>>> ou alors utiliser admin_level=9 avec le tag border_type (
>>> http://wiki.openstreetmap.org/wiki/Key:border_type) pour différencier
>>> les types de frontières :
>>> type=boundary
>>> boundary=local_authority
>>> admin_level=9
>>> border_type=commune déléguée
>>>   commune associée
>>>

Re: [OSM-talk-fr] Voies récentes dans Fantoir, absentes d'OSM

2015-12-19 Par sujet bernard 

Bonsoir,
J'ai traité le 59 et le 62
Bon taux de réussite en particulier pour le 62 où j'ai pratiquement tout 
résolu.

Le cadastre était à 100 % dessiné, et 1/3 des voies nommées.
Au départ, je n'utilisais pas l'onglet BANO, j'ai du faire des recherches.
Ces recherches m'ont permis de compléter les données (bulletins municipaux)
BANO est très pratique pour situer mais il faut interpréter
Bonne soirée

Bernard

Le 19/12/2015 10:31, Claude a écrit :

Le 16/12/2015 14:09, Donat ROBAUX a écrit :


-- Message transféré --
From: "Vincent de Château-Thierry" 
To: "Discussions sur OSM en français" 
Cc:
Date: Wed, 16 Dec 2015 07:37:41 +0100
Subject: Re: [OSM-talk-fr] Voies récentes dans Fantoir, absentes
d'OSM
Bonjour,

Le 18/10/2015 09:41, Vincent de Château-Thierry a écrit :

Bonjour,
Quand on présente OSM, on aime insister sur notre capacité à
coller à
l'actualité au jour près : ouverture de magasin ou de portion
de route,
nouveau sens de circulation, création de voie.
Par ailleurs une information donnée par FANTOIR est la date
de création
des noms de voies.
J'ai voulu mesurer notre capacité à "coller" à l'actualité, en
confrontant les voies récentes de FANTOIR et le contenu d'OSM.

(...)

Et si ça semble opportun à certains, il sera aussi possible à
peu de
frais de présenter, par exemple, les n rues les plus récentes
d'un
département.


La page des voies récentes vient de changer : la liste ne
concerne plus qu'un département à la fois, avec les 50 voies les
plus récentes inconnues d'OSM. Le tri est par date FANTOIR
décroissante.

L'URL reste inchangée :
http://cadastre.openstreetmap.fr/fantoir/voies_recentes_manquantes.html

vos retours bienvenus,
vincent


Oh super! merci beaucoup Vincent. Tu m'enlèves une bonne épine du 
pied. ;)
Puisque c'est bientôt Noël, est-ce possible d'envisager un tri par 
code INSEE également?


Donat


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

Bonjour

j'ai fait un test sur mon département (63)

les deux premières lignes ne sont pas des voies nouvelles mais des 
erreurs  dans Fantoir


1e ligne La Potence à Limons.
sur le terrain et au cadastre "Les Potences" au même endroit

2eme ligne "Les Culiers"
Sur le Cadastre il y a "Les Culliers" à cet emplacement qui ne 
figurait pas dans OSM


je n'ai pas regardé la suite.


claude



--
 Envoyé avec Mozilla Thunderbird ---


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


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

Re: [OSM-talk-fr] Accès ancienne version du cadastre (osm: message 8 of 20)

2015-12-19 Par sujet Philippe Verdy 
Le 19 décembre 2015 à 20:38,  a écrit :

> mets simplement un start_date=2015-12-31 (ce n'est pas plutôt le
> 1026-01-01 ? D'un point de vue comptabilité c'est plus simple !)
>

(Passons sur le "1026" au lieu de "2016", c'est une faute de frappe
évidente).

- C'est effectivement le 1er janvier pour la date de début effective, pas
le 31 décembre.
- Pour la date de fin des anciennes entités c'est le 31 décembre, les
mairies de ces communes sont d'ailleurs ouvertes le 31 décembre jusqu'au
soir, au minimum le service pour les inscriptions sur les listes
électorales de 2016 (si la mairie ferme à 16h ou 17h, c'est encore possible
il me semble en dernière minute dans le poste local de police ou
gendarmerie, qui se contente d'enregistrer la demande sur un formulaire
daté qui sera transmis et traitée par la commune nouvelle lors de sa
réouverture).

Pour ces deux dates, comme on ne précise pas l'heure (pas nécessaire), la
donnée est a priori inclusive : une date de début (start_date) commence à 0
h (00:00:00), une date de fin (end_date) finit à 24 h (23:59:60).

On pourrait éventuellement abréger aussi les dates: "start_date=2016"
(donnée inclusive, c'est donc le 1er janvier inclus), et "end_date=2015"
(donnée inclusive, c'est donc jusqu'au 31 décembre inclus). Ces
abréviations sont compatibles avec le format de date ISO qui ne requière
pas qu'on précise les dates et heures avec toute la précision possible.
Cependant par soucis de clarté (notamment les dates de fin), il vaut mieux
préciser au moins le mois et le jour et éviter absolument "end_date=2016".

Bref :
- "start_date=2016-01-01" pour la nouvelle entité
- "end_date=2015-12-31" pour l'ancienne



De toute façon la nouvelle commune doit nécessairement réviser ses listes
électorales dès janvier, et les faire valider rapidement (au plus tard 15
jours avant les élections de début mars, et même un peu avant puisqu'il
faut aussi permettre l'ouverture des campagnes électorales et valider les
candidatures puisque les candidats à une élection officielle doivent être
des électeurs inscrits). La commune doit tenirt compte des électeurs
disparus (décès de l'état-civil) et arrivés (inscrits, ou mineurs
préinscrits atteignant leur majorité durant l'année et qui sont sur une
annexe à la liste principale avec la date, où ils sont automatiquement
ajoutés à la liste, selon la date du scrutin dans l'année). La commune doit
aussi traiter les radiations de ses listes pour les électeurs qui se sont
inscrits dans une autre commune ou perdent leur droit d'électeur (elle en
est notifiée par la préfecture ou par les tribunaux). Pour cela ce sera un
objets des premières réunions du nouveau conseil municipal en janvier et
transmettre les listes à jour en préfecture.

En février c'est le temps possible pour les recours éventuels devant les
tribunaux administratifs (ces recours existent le plus souvent du fait de
candidats, ou partis politiques ou associations locales, ils viennent
rarement des électeurs individuels eux-même; ce n'est pas tant la qualité
d'électeur qui est contestée que les cas de double inscriptions et la
répartition des inscrits sur des sous-listes par bureau de vote, selon leur
adresse de résidence dans la commune qui pose problème). Les recours
existent cependant dans certains cas pour des électeurs qui se voient
refuser une inscription suite à un changement de résidence ou pour ceux qui
ont deux résidences ou plus occupées chacune une partie de l'année mais où
les communes les considèrent toutes comme secondaires, normalement ce
devrait être la résidence fiscale mais les jsutificatifs d'adresse peuvent
être contradictoires selon les sources et leur date d'émission.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Accès ancienne version du cadastre (osm: message 8 of 20)

2015-12-19 Par sujet Philippe Verdy 
Les numéros des zones cadatrales actuelles doivent permettre de retrouver
ces limites. à défaut de source cartographique, il doit exister un texte
mentionnant les listes de zones et de parcelles concernées (mais attention
dans le détail car il y a pu y avoir des changements de dédouvpage des
parcelles, ou une zone a pu être scindée (les zones sont à prioiri pas
fusionnées, mais peuvent avoir été renumérotées)

Le 19 décembre 2015 à 20:38,  a écrit :

> mets simplement un start_date=2015-12-31 (ce n'est pas plutôt le
> 1026-01-01 ? D'un point de vue comptabilité c'est plus simple !)
> Ou tu préfixes par construction
> :, voir
> 
> http://wiki.openstreetmap.org/wiki/Lifecycle_prefix.
>
> Le 19/12/2015 14:34, Stéphane Péneau - stephane.pen...@wanadoo.fr a
> écrit :
>
> Coucou !
>
> Est-ce que quelqu'un connait une méthode pour accéder à d'anciennes
> versions du cadastre ?
>
> En effet, dans le lot des communes nouvelles, des communes fusionnées
> depuis 1974 retrouvent leurs limites communales, pour devenir des communes
> déléguées.
>
> La commune fusionnée :
> Vihiers : https://www.openstreetmap.org/relation/547829
>
> communes qui retrouvent des limites : Saint-Hilaire-du-Bois et Voide
>
>
>
> H me !! J'ai déjà créé la commune nouvelle, et je viens de me
> rendre compte que sa date de création n'est pas au 15 décembre, mais au 31.
> Du coup, je suis en avance, et idem pour une autre :
> http://www.openstreetmap.org/relation/5753848
>
> Bon, à 10 jours près, je ne supprime pas ce que j'ai fait... si ?
>
> Stf
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Accès ancienne version du cadastre (osm: message 8 of 20)

2015-12-19 Par sujet Philippe Verdy 
Le 19 décembre 2015 à 20:38,  a écrit :

> mets simplement un start_date=2015-12-31 (ce n'est pas plutôt le
> 1026-01-01 ? D'un point de vue comptabilité c'est plus simple !)
>

(Passons sur le "1026" au lieu de "2016", c'est une faute de frappe
évidente).

- C'est effectivement le 1er janvier pour la date de début effective, pas
le 31 décembre.
- Pour la date de fin des anciennes entités c'est le 31 décembre, les
mairies de ces communes sont d'ailleurs ouvertes le 31 décembre jusqu'au
soir, au minimum le service pour les inscriptions sur les listes
électorales de 2016 (si la mairie ferme à 16h ou 17h, c'est encore possible
il me semble en dernière minute dans le poste local de police ou
gendarmerie, qui se contente d'enregistrer la demande sur un formulaire
daté qui sera transmis et traitée par la commune nouvelle lors de sa
réouverture).

Pour ces deux dates, comme on ne précise pas l'heure (pas nécessaire), la
donnée est a priori inclusive : une date de début (start_date) commence à 0
h (00:00:00), une date de fin (end_date) finit à 24 h (23:59:60).

On pourrait éventuellement abréger aussi les dates: "start_date=2016"
(donnée inclusive, c'est donc le 1er janvier inclus), et "end_date=2015"
(donnée inclusive, c'est donc jusqu'au 31 décembre inclus). Ces
abréviations sont compatibles avec le format de date ISO qui ne requière
pas qu'on précise les dates et heures avec toute la précision possible.
Cependant par soucis de clarté (notamment les dates de fin), il vaut mieux
préciser au moins le mois et le jour et éviter absolument "end_date=2016".

Bref :
- "start_date=2016-01-01" pour la nouvelle entité
- "end_date=2015-12-31" pour l'ancienne



De toute façon la nouvelle commune doit nécessairement réviser ses listes
électorales dès janvier, et les faire valider rapidement (au plus tard 15
jours avant les élections de début mars, et même un peu avant puisqu'il
faut aussi permettre l'ouverture des campagnes électorales et valider les
candidatures puisque les candidats à une élection officielle doivent être
des électeurs inscrits). La commune doit tenirt compte des électeurs
disparus (décès de l'état-civil) et arrivés (inscrits, ou mineurs
préinscrits atteignant leur majorité durant l'année et qui sont sur une
annexe à la liste principale avec la date, où ils sont automatiquement
ajoutés à la liste, selon la date du scrutin dans l'année). La commune doit
aussi traiter les radiations de ses listes pour les électeurs qui se sont
inscrits dans une autre commune ou perdent leur droit d'électeur (elle en
est notifiée par la préfecture ou par les tribunaux). Pour cela ce sera un
objets des premières réunions du nouveau conseil municipal en janvier et
transmettre les listes à jour en préfecture.

En février c'est le temps possible pour les recours éventuels devant les
tribunaux administratifs (ces recours existent le plus souvent du fait de
candidats, ou partis politiques ou associations locales, ils viennent
rarement des électeurs individuels eux-même; ce n'est pas tant la qualité
d'électeur qui est contestée que les cas de double inscriptions et la
répartition des inscrits sur des sous-listes par bureau de vote, selon leur
adresse de résidence dans la commune qui pose problème). Les recours
existent cependant dans certains cas pour des électeurs qui se voient
refuser une inscription suite à un changement de résidence ou pour ceux qui
ont deux résidences ou plus occupées chacune une partie de l'année mais où
les communes les considèrent toutes comme secondaires, normalement ce
devrait être la résidence fiscale mais les jsutificatifs d'adresse peuvent
être contradictoires selon les sources et leur date d'émission.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-19 Par sujet osm . sanspourriel 
Ma question serait plutôt : y a-t-il un besoin spécifique que 
comcommaker ne remplit pas actuellement ?
En quoi devrait-il être adapté ? Ajout automatique des attributs 
proposés par Jérôme ? Saisie d'un attribut start_date ?
Modification des communes déléguées : un end_date simple comme je vois 
pour l'Alsace 
 
(end_date  
2015-12-31) ?


Logiquement ce serait plutôt un :
admin_level:-2015=8
admin_level:2016-=9
(format ISO : la date de création des communes fusionnées étant la date 
de début des nouveaux niveaux et la date de fin des anciens étant la veille)
Effectivement, là on a du boulot systématique à faire et comcommaker 
fait déjà l'essentiel.

Au fait, y-a-t-il des codes INSEE pour les nouvelles entités ?

Ajouter aussi les sources (JO ou autres) pour les admin_level (des 
nouvelles et anciennes entités).


Jean-Yvon

Le 18/12/2015 15:40, Stéphane Péneau - stephane.pen...@wanadoo.fr a écrit :
Au fait ! ComcomMaker ne pourrait-il pas être adapté pour nous 
faciliter la tâche dans ces créations de communes nouvelles ?


Stf


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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-19 Par sujet Philippe Verdy 
Comcommaker n'est pas si pratique à utiliser que ça, pour fusionner
quelques communes on a plus vite fait de les charger manuellement et
copier-coller les ways de chacune, supprimer tous les doublons de ways
(marqués en rose dans JOSM dans la liste des membres de la nouvelle
relation) et refermer les ways dans l'ordre avec le bouton de tri.

Derrière ça, il faut changer l'admin_level des ways intérieurs (ceux qui
était en rose) de 8 à 9

Si jamais la fusion de communes a concerné des communes de deux
arrondissements départementaux différents, il faudrait aussi mettre à jour
l'arrondissement, qui a du être modifié aussi par le même décret pour que
la commune nouvelle soit dans un et un seul arrondissement, c'est à dire
dans la compétence d'un seul et même sous-préfet (si c'est le cas
l'admin_level passera de 7 à 9.



Mais si jamais ce n'est pas le cas, l'admin_level reste à 7 et les communes
déléguées resteraient dans des arrondissements séparés, un sous-préfet
gérant encore certaines communes délégués, tandis que que la commune
déléguée désignée comme chef-lieu de la commune nouvelle sera de la
compétence d'un autre sous-préfet, le même que la commune nouvelle...

Je doute que ce micmac arrive, ce serait une aberration administrative sans
nom, mais en France tout est possible, l'Etat ne se réforme pas forcément
aussi vite que les collectivités locales et peut oublier un décret
d'application, il n'est pas exempt de conflits de compétences entre ses
services et administrations, qui se règle alors seulement plus tard par les
tribunaux administratifs, ou par la solution du réglement transitoire du
litige non pas au niveau des sous-préfectures mais des préfectures...

D'ailleurs les sous-préfets sont dans le colimateur depuis longtemps et
pourraient disparaitre en même temps que les arrondissements
départementaux, mais des communes et EPCI s'y opposent (et leurs adminstrés
via les assos locales) pour éviter le transfert des services des
sous-préfectures vers la préfecture. On le voit encore avec les nouvelles
régions qui se disputent maintenant les services des anciennes régions
(l'Etat propose à la place des "maisons de l'Etat" pour un nombre limité de
services, et en transfère d'autres sur Internet ou vers les collectivités
locales). Avec le rôle croissant des coopérations intercommunales et la
réduction du nombre de collectivités locales, l'ancienne structure
administrative déconcentrée de l'Etat a du mal à rester adaptée, et devient
inutilement lourde quand il ne gère plus des missions qui ont été
transférées.

Le 19 décembre 2015 à 09:31,  a écrit :

> Ma question serait plutôt : y a-t-il un besoin spécifique que comcommaker
> ne remplit pas actuellement ?
> En quoi devrait-il être adapté ? Ajout automatique des attributs proposés
> par Jérôme ? Saisie d'un attribut start_date ?
> Modification des communes déléguées : un end_date simple comme je vois
> pour l'Alsace
>  (end_date
> 
> 2015-12-31) ?
>
> Logiquement ce serait plutôt un :
> admin_level:-2015=8
> admin_level:2016-=9
> (format ISO : la date de création des communes fusionnées étant la date de
> début des nouveaux niveaux et la date de fin des anciens étant la veille)
> Effectivement, là on a du boulot systématique à faire et comcommaker fait
> déjà l'essentiel.
> Au fait, y-a-t-il des codes INSEE pour les nouvelles entités ?
>
> Ajouter aussi les sources (JO ou autres) pour les admin_level (des
> nouvelles et anciennes entités).
>
> Jean-Yvon
>
> Le 18/12/2015 15:40, Stéphane Péneau - stephane.pen...@wanadoo.fr a
> écrit :
>
> Au fait ! ComcomMaker ne pourrait-il pas être adapté pour nous faciliter
> la tâche dans ces créations de communes nouvelles ?
>
> Stf
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-19 Par sujet Philippe Verdy 
Comcommaker n'est pas si pratique à utiliser que ça, pour fusionner
quelques communes on a plus vite fait de les charger manuellement et
copier-coller les ways de chacune, supprimer tous les doublons de ways
(marqués en rose dans JOSM dans la liste des membres de la nouvelle
relation) et refermer les ways dans l'ordre avec le bouton de tri.

Derrière ça, il faut changer l'admin_level des ways intérieurs (ceux qui
était en rose) de 8 à 9

Si jamais la fusion de communes a concerné des communes de deux
arrondissements départementaux différents, il faudrait aussi mettre à jour
l'arrondissement, qui a du être modifié aussi par le même décret pour que
la commune nouvelle soit dans un et un seul arrondissement, c'est à dire
dans la compétence d'un seul et même sous-préfet (si c'est le cas
l'admin_level passera de 7 à 9.



Mais si jamais ce n'est pas le cas, l'admin_level reste à 7 et les communes
déléguées resteraient dans des arrondissements séparés, un sous-préfet
gérant encore certaines communes délégués, tandis que que la commune
déléguée désignée comme chef-lieu de la commune nouvelle sera de la
compétence d'un autre sous-préfet, le même que la commune nouvelle...

Je doute que ce micmac arrive, ce serait une aberration administrative sans
nom, mais en France tout est possible, l'Etat ne se réforme pas forcément
aussi vite que les collectivités locales et peut oublier un décret
d'application, il n'est pas exempt de conflits de compétences entre ses
services et administrations, qui se règle alors seulement plus tard par les
tribunaux administratifs, ou par la solution du réglement transitoire du
litige non pas au niveau des sous-préfectures mais des préfectures...

D'ailleurs les sous-préfets sont dans le colimateur depuis longtemps et
pourraient disparaitre en même temps que les arrondissements
départementaux, mais des communes et EPCI s'y opposent (et leurs adminstrés
via les assos locales) pour éviter le transfert des services des
sous-préfectures vers la préfecture. On le voit encore avec les nouvelles
régions qui se disputent maintenant les services des anciennes régions
(l'Etat propose à la place des "maisons de l'Etat" pour un nombre limité de
services, et en transfère d'autres sur Internet ou vers les collectivités
locales). Avec le rôle croissant des coopérations intercommunales et la
réduction du nombre de collectivités locales, l'ancienne structure
administrative déconcentrée de l'Etat a du mal à rester adaptée, et devient
inutilement lourde quand il ne gère plus des missions qui ont été
transférées.

Le 19 décembre 2015 à 09:31,  a écrit :

> Ma question serait plutôt : y a-t-il un besoin spécifique que comcommaker
> ne remplit pas actuellement ?
> En quoi devrait-il être adapté ? Ajout automatique des attributs proposés
> par Jérôme ? Saisie d'un attribut start_date ?
> Modification des communes déléguées : un end_date simple comme je vois
> pour l'Alsace
>  (end_date
> 
> 2015-12-31) ?
>
> Logiquement ce serait plutôt un :
> admin_level:-2015=8
> admin_level:2016-=9
> (format ISO : la date de création des communes fusionnées étant la date de
> début des nouveaux niveaux et la date de fin des anciens étant la veille)
> Effectivement, là on a du boulot systématique à faire et comcommaker fait
> déjà l'essentiel.
> Au fait, y-a-t-il des codes INSEE pour les nouvelles entités ?
>
> Ajouter aussi les sources (JO ou autres) pour les admin_level (des
> nouvelles et anciennes entités).
>
> Jean-Yvon
>
> Le 18/12/2015 15:40, Stéphane Péneau - stephane.pen...@wanadoo.fr a
> écrit :
>
> Au fait ! ComcomMaker ne pourrait-il pas être adapté pour nous faciliter
> la tâche dans ces créations de communes nouvelles ?
>
> Stf
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Voies récentes dans Fantoir, absentes d'OSM

2015-12-19 Par sujet Claude 

Le 16/12/2015 14:09, Donat ROBAUX a écrit :


-- Message transféré --
From: "Vincent de Château-Thierry" >
To: "Discussions sur OSM en français" >
Cc:
Date: Wed, 16 Dec 2015 07:37:41 +0100
Subject: Re: [OSM-talk-fr] Voies récentes dans Fantoir, absentes d'OSM
Bonjour,

Le 18/10/2015 09:41, Vincent de Château-Thierry a écrit :

Bonjour,
Quand on présente OSM, on aime insister sur notre capacité à
coller à
l'actualité au jour près : ouverture de magasin ou de portion
de route,
nouveau sens de circulation, création de voie.
Par ailleurs une information donnée par FANTOIR est la date de
création
des noms de voies.
J'ai voulu mesurer notre capacité à "coller" à l'actualité, en
confrontant les voies récentes de FANTOIR et le contenu d'OSM.

(...)

Et si ça semble opportun à certains, il sera aussi possible à
peu de
frais de présenter, par exemple, les n rues les plus récentes d'un
département.


La page des voies récentes vient de changer : la liste ne concerne
plus qu'un département à la fois, avec les 50 voies les plus
récentes inconnues d'OSM. Le tri est par date FANTOIR décroissante.

L'URL reste inchangée :
http://cadastre.openstreetmap.fr/fantoir/voies_recentes_manquantes.html

vos retours bienvenus,
vincent


Oh super! merci beaucoup Vincent. Tu m'enlèves une bonne épine du pied. ;)
Puisque c'est bientôt Noël, est-ce possible d'envisager un tri par 
code INSEE également?


Donat


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

Bonjour

j'ai fait un test sur mon département (63)

les deux premières lignes ne sont pas des voies nouvelles mais des 
erreurs  dans Fantoir


1e ligne La Potence à Limons.
sur le terrain et au cadastre "Les Potences" au même endroit

2eme ligne "Les Culiers"
Sur le Cadastre il y a "Les Culliers" à cet emplacement qui ne figurait 
pas dans OSM


je n'ai pas regardé la suite.


claude



--
 Envoyé avec Mozilla Thunderbird ---

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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-19 Par sujet Philippe Verdy 
Le 19 décembre 2015 à 15:03, Stéphane Péneau  a
écrit :

> Selon le cas, il y a plusieurs manip à faire :
> basculer les anciennes limites des communes en admin_level 10 si elles ne
> sont pas utilisées par la commune nouvelle
>

Si c'est bien une "commune nouvelle", les anciennes communes persistent en
tant que "communes déléguées", donc niveau 9, pas 10.
Elles conservent aussi chacune leur propre découpage en quartiers
administratifs en niveau 10 (ce quartiers n'ont pas de code INSEE de
commune).
OK l'EPCI disparait, mais pas les communes membres (avec leur propre
état-civil, leur code INSEE propre).

Seul ennui, quel code INSEE pour la commune nouvelle (ce ne peut pas être
le code INSEE de l'EPCI, qui était en fait un numéro SIREN, mais ce nulméro
SIREN disparait nécessairement aussi, la commune nouvelle n'est légalement
pas la même organisation que l'EPCI, même si elle lui succède; l'EPCI ne
disparaitra qu'après transfert effectif des compétences, fermeture et
validation des comptes, transferts des contrats en cours avec les autres
prestataires et organisations, amendements des contrats de travail et
transferts légaux des personnels, mais les deux organisations vont devoir
fonctionner légalement simultanément quelques temps au plan comptable,
social, juridique : en France la dissolution d'une organisation peut
prendre quelques mois, et même un peu plus s'il y a des procédures
judiciaires en cours).

Bref supprimer toute référence éventuelle de code INSEE dans l'EPCI (s'il y
en a eu un), mais laisser éventuellement pendant quelques temps le code
SIREN jusqu'à ce qu'on connaisse le nouveau code SIREN de la commune
nouvelle), laissr un FIXME pour noter l'absence de code INSEE et la
correction à faire du code SIREN (l'Insee devrait attribuer le code SIREN
en se basant sur le préfix standard 21 et le nouveau code INSEE de la
commune nouvelle, ce code pouvant être celui d'une des communes déléguées,
à priori celle où est établi le chef-lieu de la commune nouvelle si la
comune nouvelle en reprend aussi le nom).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Accès ancienne version du cadastre

2015-12-19 Par sujet Philippe Verdy 
Pour cette commune de Vihiers (code INSEE 49310), il suffit de regarder les
numéros des 76 feuilles cadastrales actuelles, ils commencent par 000, 286
ou 379 selon l'ancienne commune (ce numéro est ensuite suivi d'une ou deux
lettres et de chiffres). Le 000 c'est pour Vivihiers proprement dit, les
autres sont les anciens INSEE des anciennes communes, qui devraient être
repris tels quels, ils ne sont à priori pas réutilisés.

Le 19 décembre 2015 à 14:34, Stéphane Péneau  a
écrit :

> Coucou !
>
> Est-ce que quelqu'un connait une méthode pour accéder à d'anciennes
> versions du cadastre ?
>
> En effet, dans le lot des communes nouvelles, des communes fusionnées
> depuis 1974 retrouvent leurs limites communales, pour devenir des communes
> déléguées.
>
> La commune fusionnée :
> Vihiers : https://www.openstreetmap.org/relation/547829
>
> communes qui retrouvent des limites : Saint-Hilaire-du-Bois et Voide
>
>
>
> H me !! J'ai déjà créé la commune nouvelle, et je viens de me
> rendre compte que sa date de création n'est pas au 15 décembre, mais au 31.
> Du coup, je suis en avance, et idem pour une autre :
> http://www.openstreetmap.org/relation/5753848
>
> Bon, à 10 jours près, je ne supprime pas ce que j'ai fait... si ?
>
> Stf
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Voies récentes dans Fantoir, absentes d'OSM

2015-12-19 Par sujet Vincent de Château-Thierry 

Bonjour,

Le 19/12/2015 10:31, Claude a écrit :


j'ai fait un test sur mon département (63)

les deux premières lignes ne sont pas des voies nouvelles mais des
erreurs  dans Fantoir

1e ligne La Potence à Limons.
sur le terrain et au cadastre "Les Potences" au même endroit

2eme ligne "Les Culiers"
Sur le Cadastre il y a "Les Culliers" à cet emplacement qui ne figurait
pas dans OSM


Lorsqu'il s'agit d'erreurs Fantoir, si tu les indiques sur la page de la 
commune :

http://cadastre.openstreetmap.fr/fantoir/index.html#insee=63196=0
au moyen des listes déroulantes, alors les noms en question ne seront 
plus visibles dans la page des voies récentes.
D'une manière générale, toutes les voies qui n'ont pas le statut 'Ok' 
sur http://cadastre.openstreetmap.fr/fantoir/ ne sont pas considérées 
dans la page des voies récentes inconnues.


vincent

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

[OSM-talk-fr] Accès ancienne version du cadastre

2015-12-19 Par sujet Stéphane Péneau 

Coucou !

Est-ce que quelqu'un connait une méthode pour accéder à d'anciennes 
versions du cadastre ?


En effet, dans le lot des communes nouvelles, des communes fusionnées 
depuis 1974 retrouvent leurs limites communales, pour devenir des 
communes déléguées.


La commune fusionnée :
Vihiers : https://www.openstreetmap.org/relation/547829

communes qui retrouvent des limites : Saint-Hilaire-du-Bois et Voide



H me !! J'ai déjà créé la commune nouvelle, et je viens de me 
rendre compte que sa date de création n'est pas au 15 décembre, mais au 31.

Du coup, je suis en avance, et idem pour une autre :
http://www.openstreetmap.org/relation/5753848

Bon, à 10 jours près, je ne supprime pas ce que j'ai fait... si ?

Stf

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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-19 Par sujet Stéphane Péneau 

Selon le cas, il y a plusieurs manip à faire :

Un EPCI qui devient commune nouvelle :
remplacer l'epci par la commune :
changer le type de relation
changer le nom
ajouter admin_center, population, lien wiki
basculer les anciennes limites des communes en admin_level 10 si elles 
ne sont pas utilisées par la commune nouvelles


si ce sont simplement des communes qui deviennent commune nouvelle, 
c'est à peu prêt la même chose, sauf qu'il faut créer une nouvelle 
relation au lieu d'en modifier une existante.


Le 19/12/2015 09:31, osm.sanspourr...@spamgourmet.com a écrit :
Ma question serait plutôt : y a-t-il un besoin spécifique que 
comcommaker ne remplit pas actuellement ?
En quoi devrait-il être adapté ? Ajout automatique des attributs 
proposés par Jérôme ? Saisie d'un attribut start_date ?
Modification des communes déléguées : un end_date simple comme je vois 
pour l'Alsace 
 
(end_date 
 
2015-12-31) ?


Logiquement ce serait plutôt un :
admin_level:-2015=8
admin_level:2016-=9
(format ISO : la date de création des communes fusionnées étant la 
date de début des nouveaux niveaux et la date de fin des anciens étant 
la veille)
Effectivement, là on a du boulot systématique à faire et comcommaker 
fait déjà l'essentiel.

Au fait, y-a-t-il des codes INSEE pour les nouvelles entités ?

Ajouter aussi les sources (JO ou autres) pour les admin_level (des 
nouvelles et anciennes entités).


Jean-Yvon

Le 18/12/2015 15:40, Stéphane Péneau - stephane.pen...@wanadoo.fr a 
écrit :
Au fait ! ComcomMaker ne pourrait-il pas être adapté pour nous 
faciliter la tâche dans ces créations de communes nouvelles ?


Stf




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


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