Re: [OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[Jérôme Seigneuret]

Il y a deux types de surfaciques pour un hameau/lieu-dit:
- celui du cadastre qui rattache des parcellles à un lieu-dit., des
parcelles avec ou sans bâti
- celui qu'on fait habituellement dans OSM en dessinant une grosse
patate autour des buildings et en y ajoutant les tags
"landuse=residential" et "place=hamlet" + name par exemple.

Pieren c'est clairement ça dans le premier cas! Mais je milite clairement
pour ne pas mettre "place=hamlet" + name comme dans ton deuxième cas car un
lieu dit c'est pas que le résidentiel mais aussi les terre de culture comme
dans le cas de place=farm et assimilé

Christian ça a l'air pas mal comme proposition. Ponctuel et zonale peuvent
coexister si l'on garde le même tag pour nommer l'ensemble (cohérence
oblige) donc encore une fois pas juste dans un landuse.
Pour moi les zones peuvent me servir dans tous les cas car dans le milieu
naturel (observation d'espèces par les groupe naturaliste) on utilise
souvent cette données comme information de rattachement.

Donc pour résumé on peut définir les choses ainsi :

1) un* place=** de type *polygone *pour les zones habitées quelques soit le
landuse! car il peut y avoir du mitage et dans ce cas déssiner en plus des
zones landuse=residential sans nom pour définir les limites des zone
habitées sur la limite des parcelles concernées.

2) *place=locality* pour les zones non habitées sous la forme d'un noeud

*précision*: un place=locality est-il seulement une zone sans bâti ou en
ruine? (sans activité humaine en bâti) et l'on considère dans ce cas qu'un
lieu-dit habité est une zone ou y il a du batî servant à une activité
humaine (habitation, entrepot, usine ...)??? ou c'est juste lié à
l'habitation


Le 16 octobre 2014 17:10, Christian Quest  a écrit
:

> On n'est pas en train de la mener la réflexion ? ;)
>
> Le test de David me semble intéressant justement pour expérimenter et
> montrer quelques limites.
> Côté tags je pense que les choix ne sont pas les bons.
>
> Côté modélisation, je n'ai pas d'avis ou plutôt celui-ci évolue au fur et
> à mesure des réflexions... il n'y a que les imbéciles qui ne changent
> jamais d'avis, non ?
>
> Vu le volume envisagé, il me semble important de bien se poser les
> questions assez tôt, de se poser la question de l'intérêt du surfacique par
> rapport au ponctuel.
>
> Se limiter en surfacique aux lieux-dits bâtis (potentiellement habités) et
> rester en ponctuel sur le reste me semblerait un bon compromis.
>
>
> Le 16 octobre 2014 16:35, JB  a écrit :
>
> Le 16/10/2014 15:47, Christian Quest a écrit :
>>
>>> Ca vaut quand même le coup de se poser la question de l'opportunité et
>>> de la modélisation de ces informations.
>>>
>> Tiens tiens, alors, elle en est où, la réflexion autour de l'import (ou
>> intégration ou un autre mot moins polémique) de tout les « lieux-dits » de
>> complément d'adresse en surfacique plutôt qu'en ponctuel ?
>>
>> Pour mémoire :
>> https://lists.openstreetmap.org/pipermail/talk-fr/2014-June/069036.html
>> et suivants, notamment :
>> https://lists.openstreetmap.org/pipermail/talk-fr/2014-June/069042.html
>> https://lists.openstreetmap.org/pipermail/talk-fr/2014-June/069044.html
>>
>> JB.
>>
>> PS : pour ma part, je pense toujours que ce sera plus un enfer qu'autre
>> chose, mais bon…
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[Christian Quest]

On n'est pas en train de la mener la réflexion ? ;)

Le test de David me semble intéressant justement pour expérimenter et
montrer quelques limites.
Côté tags je pense que les choix ne sont pas les bons.

Côté modélisation, je n'ai pas d'avis ou plutôt celui-ci évolue au fur et à
mesure des réflexions... il n'y a que les imbéciles qui ne changent jamais
d'avis, non ?

Vu le volume envisagé, il me semble important de bien se poser les
questions assez tôt, de se poser la question de l'intérêt du surfacique par
rapport au ponctuel.

Se limiter en surfacique aux lieux-dits bâtis (potentiellement habités) et
rester en ponctuel sur le reste me semblerait un bon compromis.


Le 16 octobre 2014 16:35, JB  a écrit :

> Le 16/10/2014 15:47, Christian Quest a écrit :
>
>> Ca vaut quand même le coup de se poser la question de l'opportunité et de
>> la modélisation de ces informations.
>>
> Tiens tiens, alors, elle en est où, la réflexion autour de l'import (ou
> intégration ou un autre mot moins polémique) de tout les << lieux-dits >> de
> complément d'adresse en surfacique plutôt qu'en ponctuel ?
>
> Pour mémoire :
> https://lists.openstreetmap.org/pipermail/talk-fr/2014-June/069036.html
> et suivants, notamment :
> https://lists.openstreetmap.org/pipermail/talk-fr/2014-June/069042.html
> https://lists.openstreetmap.org/pipermail/talk-fr/2014-June/069044.html
>
> JB.
>
> PS : pour ma part, je pense toujours que ce sera plus un enfer qu'autre
> chose, mais bon...
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



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

Re: [OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[Pieren]

2014-10-16 16:35 GMT+02:00 JB :

> Tiens tiens, alors, elle en est où, la réflexion autour de l'import (ou
> intégration ou un autre mot moins polémique) de tout les « lieux-dits » de
> complément d'adresse en surfacique plutôt qu'en ponctuel ?

Attention, il ne faut pas ajouter de la confusion à un problème déjà
assez compliqué.
Il y a deux types de surfaciques pour un hameau/lieu-dit:
- celui du cadastre qui rattache des parcellles à un lieu-dit., des
parcelles avec ou sans bâti
- celui qu'on fait habituellement dans OSM en dessinant une grosse
patate autour des buildings et en y ajoutant les tags
"landuse=residential" et "place=hamlet" + name par exemple. Ce que
Christian propose, c'est d'automatiser cette tâche en sélectionnant
les parcelles rattachées à un lieux-dit ET avec bâti.

La discussion qui nous intéresse ici concerne le premier type de
patate (toutes les parcelles rattachées à un lieux-dit, avec ou sans
bâti). Encore une fois, ce genre de rattachement est une décision de
la dgfip qu'on ne peut pas vérifier sur le terrain, la limite étant
souvent floue dans les zones entre deux, et qui n'a pas d'utilité pour
nous s'il n'y a pas d'adresses (donc pas de bâti).

Pieren

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

Re: [OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[JB]

Le 16/10/2014 15:47, Christian Quest a écrit :
Ca vaut quand même le coup de se poser la question de l'opportunité et 
de la modélisation de ces informations.
Tiens tiens, alors, elle en est où, la réflexion autour de l'import (ou 
intégration ou un autre mot moins polémique) de tout les « lieux-dits » 
de complément d'adresse en surfacique plutôt qu'en ponctuel ?


Pour mémoire :
https://lists.openstreetmap.org/pipermail/talk-fr/2014-June/069036.html
et suivants, notamment :
https://lists.openstreetmap.org/pipermail/talk-fr/2014-June/069042.html
https://lists.openstreetmap.org/pipermail/talk-fr/2014-June/069044.html

JB.

PS : pour ma part, je pense toujours que ce sera plus un enfer qu'autre 
chose, mais bon…


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

Re: [OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[Jérôme Seigneuret]

Ok dans ce cas:
1) doit-on ouvrir en France un vote sur cette pratique?
2) Doit-on requalifier les pages du wiki et supprimer ou repréciser le
level 10 en France ou proposer un renvoi sur key:place pour ce type de
niveau.
3) Pouvons-nous dire que les lieu-dits Cadastre aussi présent en toponyme
dans BANO sont à qualifier en tant que *place=* (lieu-dit sans habitation,
lieu-dit habité (max d'habitation 1 ou 2), hameau, voisinage, quartier)*
et spécifier plus clairement la catégorie de *place *à appliquer avec des
exemples concrets. pour éviter d'avoir autant de questions.

Après tu dis que c'est flou :| J'ai pas l'impression encore une fois (Dans
ce cas on peut considérer que sans pointage par un géomètre des limites
tous est flou). et le cadastre est flou déjà de base vu le nombre de
contentieux sur les limites de terrains (c'est fait à la chaîne d'arpentage
à la base)

C'est sur que la saisie des limites communales à déjà été chiant et très
long. Je comprend que ce maillage ne soit pas indispensable et qu'il
serrait assez difficile d'avoir quelque chose de cohérent sur tous le
territoire.

On doit donc décider de ne pas saisir cette donnée comme boundary et donc
faire soit un noeud soit une zone pour qualifier cette information en tant
que place si les limite sont connus.

Ainsi c'est pas incohérent.


Le 16 octobre 2014 15:47, Christian Quest  a écrit
:

> Ca vaut quand même le coup de se poser la question de l'opportunité et de
> la modélisation de ces informations.
>
> Si on généralise cette méthode, ce sont plusieurs millions de relations
> qui seraient nécessaires pour décrire tout ces lieux dits de cette façon...
> est-ce donc la bonne approche ?
> L'emprise de ceux-ci n'est pas précisément définit par les parcelles,
> c'est plutôt la parcelle qui est rattachée à un nom de lieux-dit. Alors
> définir des limites aussi précises pour quelques chose à l'origine d'assez
> flou, ça me fait bizarre.
>
> On est de plus dans une situation très différente des découpages
> administratifs, qui eux sont (en principe) précisément définis et conservés
> dans le COG et les découpages subcommunaux de l'INSEE (la notion de
> quartiers/grand quartiers ou d'IRIS et de TRIRIS).
>
> Pour moi boundary=administrative + admin_level=10 ne me semblent pas du
> tout adaptés.
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[Christian Quest]

Ca vaut quand même le coup de se poser la question de l'opportunité et de
la modélisation de ces informations.

Si on généralise cette méthode, ce sont plusieurs millions de relations qui
seraient nécessaires pour décrire tout ces lieux dits de cette façon...
est-ce donc la bonne approche ?
L'emprise de ceux-ci n'est pas précisément définit par les parcelles, c'est
plutôt la parcelle qui est rattachée à un nom de lieux-dit. Alors définir
des limites aussi précises pour quelques chose à l'origine d'assez flou, ça
me fait bizarre.

On est de plus dans une situation très différente des découpages
administratifs, qui eux sont (en principe) précisément définis et conservés
dans le COG et les découpages subcommunaux de l'INSEE (la notion de
quartiers/grand quartiers ou d'IRIS et de TRIRIS).

Pour moi boundary=administrative + admin_level=10 ne me semblent pas du
tout adaptés.

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

Re: [OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[Jérôme Seigneuret]

Philippe ça revient à ce que je vient de dire. C'est pas à considérer comme
une erreur mais comme un travail en cours. Comme tu le proposais,

1) Il faudrait générer les relations même si le nom n'est pas affiché en
mettant le FIXME que tu proposais. Ainsi la cohérence serait parfaite. Mais
il n'y a pas d'erreur à proprement parlé de tag ou de saisie. Juste des
relations non réalisées.

Ça ne change pas le problème que l'on fait remonté (sur plusieurs sujet)
concernant la gestion et la saisie de cette informations en tant que place
(node, way) et celle de boundary.

Je vous invite donc à voir mon message précédent car comme David je me
retrouve confronté à savoir comment saisir ces infos.

Certains n'ont pas attendu et j'aimerai compléter le wiki pour éviter
d'avoir dans la base des saisies complètement différentes pour la même
information.


Le 15 octobre 2014 18:06, Philippe Verdy  a écrit :

> remonte au way du mail initial (détecté par Osmose comme "fragment de
> frontière isolé).
>
> http://www.openstreetmap.org/way/306246629
>
> il n'est utilisé par aucune relation contrairement à tous les autres,
> c'est un morceau oublié qui devrait fermer une relation manquante, il est
> au milieu d'une zone encore vierge, mais il est connecté aux extrémités aux
> autres limites de relations existantes.
>
>
> Le 15 octobre 2014 17:14, Jérôme Seigneuret  a
> écrit :
>
> *> Même lieu-dit, mais sur plusieurs feuilles cadastrales. L'idée est de
>> les fusionner par la suite lorsque l'approche *
>> *> typographique est identique*.
>> Après vu que c'est la même zone sur les planches il est tout à fait
>> envisageable et plus correcte d'enlever les limites inutiles pour avoir
>> qu'une seule zone
>>
>> Pour Overpass je viens de vérifier http://overpass-turbo.eu/s/5tv et il
>> n'y  pas de gap dans les relations présentés. Je vois donc pas de quoi tu
>> parles. Philippe, peux-tu me montrer un exemple sur le cas en cours via une
>> requête enregistrée? . Moi j'ai juste des trous car les zones n'ont pas été
>> générées avec de relations pour avoir une cohérence totale sur la commune
>> (PS c'est frais aussi donc on peut aussi attendre qu'il finisse ;-) ) et
>> voir aussi apparaître un FIXME sur les noms manquants.
>>
>> Reste que cela remonte le problème des toponymes locaux dont deux
>> possibilités sont offertes en France et sans cohérence ou précision
>> particulière à la saisie
>>
>> d'une par les *boundary *en way + relation (+ node *admin_center)*
>> d'autre part *place *en way closed (+/ou node d'étiquette central)
>>
>> En sachant que boundary au level 10 la doc dit  *limites des quartiers
>> utilisés pour la démocracie locale*
>> Pour moi c'est vague et ça dit tous et rien...
>>
>>  et que dans la doc *places
>> *on doit:
>>
>> Pour un toponyme correspondant à une aire administrative
>> 
>> : *D'ailleurs on ne devrait pas renvoyer sur boundary directement???*
>>
>>1. *Créer un chemin fermé autour du périmètre de l'aire utilisant un
>>ou plusieurs chemins. déjà la on devrait parler de chemin relié aux deux
>>extrémités ou fermé car fermé sous-entend fermé sur lui même comme les
>>polygones*
>>2. Mettre l'attribut boundary
>>=administrative
>> avec
>>ce chemin et avec le niveau approprié admin_level
>>=*.
>>3. Ajouter ces chemins à la relaltion administrative Relation:boundary
>>.
>>4. Ajouter l'attribut boundary
>>=administrative
>> et
>>le niveau administratif approprié admin_level
>>=* à la relation.
>>5. Fixer le rôle de chaque chemins qui sont à 'l'extérieur' à moins
>>que se soit une enclave, dans laquelle il n'y a plus qu'a mettre le rôle
>>inner.
>>6. On peut optionnellement mettre un noeud au centre de l'aire
>>administrative et lui donner le rôle de centre administratif 
>> "admin_centre".
>>
>>
>> Doit-on faire un choix, doit-on mettre des règles de saisie pour ce
>> niveau? Car pour moi c'est pas explicite et me semble quand même important
>> car ce sont des lieu-dit locaux employés régulièrement certes pas facile à
>> extraire du cadastre d'où l'ajout d'un simple tag place.
>>
>> Pour la limites des lieux-dit Pieren, je sais dans quelle région tu es
>> mais sur les plans cadastraux c'est quand même clairement délimité!
>>
>> On ne parle pas juste des panneaux qui eux ne correspond à rien d'autre
>> que des besoins de circulation.
>> Le cadastre n'est peut-être pas aussi propre dans toutes les régions mais
>> là c'est qua

Re: [OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[Philippe Verdy]

remonte au way du mail initial (détecté par Osmose comme "fragment de
frontière isolé).

http://www.openstreetmap.org/way/306246629

il n'est utilisé par aucune relation contrairement à tous les autres, c'est
un morceau oublié qui devrait fermer une relation manquante, il est au
milieu d'une zone encore vierge, mais il est connecté aux extrémités aux
autres limites de relations existantes.


Le 15 octobre 2014 17:14, Jérôme Seigneuret  a
écrit :

> *> Même lieu-dit, mais sur plusieurs feuilles cadastrales. L'idée est de
> les fusionner par la suite lorsque l'approche *
> *> typographique est identique*.
> Après vu que c'est la même zone sur les planches il est tout à fait
> envisageable et plus correcte d'enlever les limites inutiles pour avoir
> qu'une seule zone
>
> Pour Overpass je viens de vérifier http://overpass-turbo.eu/s/5tv et il
> n'y  pas de gap dans les relations présentés. Je vois donc pas de quoi tu
> parles. Philippe, peux-tu me montrer un exemple sur le cas en cours via une
> requête enregistrée? . Moi j'ai juste des trous car les zones n'ont pas été
> générées avec de relations pour avoir une cohérence totale sur la commune
> (PS c'est frais aussi donc on peut aussi attendre qu'il finisse ;-) ) et
> voir aussi apparaître un FIXME sur les noms manquants.
>
> Reste que cela remonte le problème des toponymes locaux dont deux
> possibilités sont offertes en France et sans cohérence ou précision
> particulière à la saisie
>
> d'une par les *boundary *en way + relation (+ node *admin_center)*
> d'autre part *place *en way closed (+/ou node d'étiquette central)
>
> En sachant que boundary au level 10 la doc dit  *limites des quartiers
> utilisés pour la démocracie locale*
> Pour moi c'est vague et ça dit tous et rien...
>
>  et que dans la doc *places
> *on doit:
>
> Pour un toponyme correspondant à une aire administrative
> 
> : *D'ailleurs on ne devrait pas renvoyer sur boundary directement???*
>
>1. *Créer un chemin fermé autour du périmètre de l'aire utilisant un
>ou plusieurs chemins. déjà la on devrait parler de chemin relié aux deux
>extrémités ou fermé car fermé sous-entend fermé sur lui même comme les
>polygones*
>2. Mettre l'attribut boundary
>=administrative
> avec
>ce chemin et avec le niveau approprié admin_level
>=*.
>3. Ajouter ces chemins à la relaltion administrative Relation:boundary
>.
>4. Ajouter l'attribut boundary
>=administrative
> et
>le niveau administratif approprié admin_level
>=* à la relation.
>5. Fixer le rôle de chaque chemins qui sont à 'l'extérieur' à moins
>que se soit une enclave, dans laquelle il n'y a plus qu'a mettre le rôle
>inner.
>6. On peut optionnellement mettre un noeud au centre de l'aire
>administrative et lui donner le rôle de centre administratif 
> "admin_centre".
>
>
> Doit-on faire un choix, doit-on mettre des règles de saisie pour ce
> niveau? Car pour moi c'est pas explicite et me semble quand même important
> car ce sont des lieu-dit locaux employés régulièrement certes pas facile à
> extraire du cadastre d'où l'ajout d'un simple tag place.
>
> Pour la limites des lieux-dit Pieren, je sais dans quelle région tu es
> mais sur les plans cadastraux c'est quand même clairement délimité!
>
> On ne parle pas juste des panneaux qui eux ne correspond à rien d'autre
> que des besoins de circulation.
> Le cadastre n'est peut-être pas aussi propre dans toutes les régions mais
> là c'est quand même bien clair.
> Quand tu dit que rien ne délimite précisement... Je te dis juste regarde
> le plan cadastral et tu verra que c'est pas vrai. Les zones sont bien
> défini et c'est aussi le cas vers chez moi.
>
> On n'est pas sur du CorineLandCover. C'est un doc administratif. Au pire
> c'est à préciser avec les planches papier dans les communes. D'où
> l'implications des collectivités dans le process de saisie et de validation.
>
> D'ailleurs avons-nous un niveau de précision pour OSM. Comme si les
> limites des communes ne bougaient pas et étaient connus parfaitement de
> tout administré. Quand tu as un échanges de parcelles entre commune vois tu
> la limites et es-tu au courant des échanges...? Bref on ne peut pas juste
> tapé juste sur la qualité pour refuser un niveau connu est exploité de
> découpage. Sinon on n'aurait pas grand chose dans la base.
>
> Le 15 octobre 2014 16:41, Pieren  a écrit :
>
> Je suis très sceptique sur ces découpages (outre le choix des tags).
>> Rien

Re: [OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[Jérôme Seigneuret]

*> Même lieu-dit, mais sur plusieurs feuilles cadastrales. L'idée est de
les fusionner par la suite lorsque l'approche *
*> typographique est identique*.
Après vu que c'est la même zone sur les planches il est tout à fait
envisageable et plus correcte d'enlever les limites inutiles pour avoir
qu'une seule zone

Pour Overpass je viens de vérifier http://overpass-turbo.eu/s/5tv et il n'y
 pas de gap dans les relations présentés. Je vois donc pas de quoi tu
parles. Philippe, peux-tu me montrer un exemple sur le cas en cours via une
requête enregistrée? . Moi j'ai juste des trous car les zones n'ont pas été
générées avec de relations pour avoir une cohérence totale sur la commune
(PS c'est frais aussi donc on peut aussi attendre qu'il finisse ;-) ) et
voir aussi apparaître un FIXME sur les noms manquants.

Reste que cela remonte le problème des toponymes locaux dont deux
possibilités sont offertes en France et sans cohérence ou précision
particulière à la saisie

d'une par les *boundary *en way + relation (+ node *admin_center)*
d'autre part *place *en way closed (+/ou node d'étiquette central)

En sachant que boundary au level 10 la doc dit  *limites des quartiers
utilisés pour la démocracie locale*
Pour moi c'est vague et ça dit tous et rien...

 et que dans la doc *places *on
doit:

Pour un toponyme correspondant à une aire administrative

: *D'ailleurs on ne devrait pas renvoyer sur boundary directement???*

   1. *Créer un chemin fermé autour du périmètre de l'aire utilisant un ou
   plusieurs chemins. déjà la on devrait parler de chemin relié aux deux
   extrémités ou fermé car fermé sous-entend fermé sur lui même comme les
   polygones*
   2. Mettre l'attribut boundary
   =administrative
    avec
   ce chemin et avec le niveau approprié admin_level
   =*.
   3. Ajouter ces chemins à la relaltion administrative Relation:boundary
   .
   4. Ajouter l'attribut boundary
   =administrative
    et le
   niveau administratif approprié admin_level
   =* à la relation.
   5. Fixer le rôle de chaque chemins qui sont à 'l'extérieur' à moins que
   se soit une enclave, dans laquelle il n'y a plus qu'a mettre le rôle inner.
   6. On peut optionnellement mettre un noeud au centre de l'aire
   administrative et lui donner le rôle de centre administratif "admin_centre".


Doit-on faire un choix, doit-on mettre des règles de saisie pour ce niveau?
Car pour moi c'est pas explicite et me semble quand même important car ce
sont des lieu-dit locaux employés régulièrement certes pas facile à
extraire du cadastre d'où l'ajout d'un simple tag place.

Pour la limites des lieux-dit Pieren, je sais dans quelle région tu es mais
sur les plans cadastraux c'est quand même clairement délimité!

On ne parle pas juste des panneaux qui eux ne correspond à rien d'autre que
des besoins de circulation.
Le cadastre n'est peut-être pas aussi propre dans toutes les régions mais
là c'est quand même bien clair.
Quand tu dit que rien ne délimite précisement... Je te dis juste regarde le
plan cadastral et tu verra que c'est pas vrai. Les zones sont bien défini
et c'est aussi le cas vers chez moi.

On n'est pas sur du CorineLandCover. C'est un doc administratif. Au pire
c'est à préciser avec les planches papier dans les communes. D'où
l'implications des collectivités dans le process de saisie et de validation.

D'ailleurs avons-nous un niveau de précision pour OSM. Comme si les limites
des communes ne bougaient pas et étaient connus parfaitement de tout
administré. Quand tu as un échanges de parcelles entre commune vois tu la
limites et es-tu au courant des échanges...? Bref on ne peut pas juste tapé
juste sur la qualité pour refuser un niveau connu est exploité de
découpage. Sinon on n'aurait pas grand chose dans la base.

Le 15 octobre 2014 16:41, Pieren  a écrit :

> Je suis très sceptique sur ces découpages (outre le choix des tags).
> Rien ne délimite précisément un lieux-dit. Son étendue est très vague,
> souvent issue d'une tradition orale. Même le cadastre est incapable de
> dire si une parcelle "appartient" à un lieu-dit ou à celui d'à côté
> (sauf s'il y a des adresses peut-être). Je pense que là, on fait trop
> dans le pifométrique et on veut donner une apparence de précision à
> quelque chose qui ne l'est pas.
>
> Pieren
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mail

Re: [OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[Pieren]

Je suis très sceptique sur ces découpages (outre le choix des tags).
Rien ne délimite précisément un lieux-dit. Son étendue est très vague,
souvent issue d'une tradition orale. Même le cadastre est incapable de
dire si une parcelle "appartient" à un lieu-dit ou à celui d'à côté
(sauf s'il y a des adresses peut-être). Je pense que là, on fait trop
dans le pifométrique et on veut donner une apparence de précision à
quelque chose qui ne l'est pas.

Pieren

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

Re: [OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[Jérôme Seigneuret]

Arf ça va trop vite et oui j'ai déjà répondu et dis que cela venait du
cadastre comme David l'a confirmé. Dans OSM on le considère avec des zones
de type place comme j'en parlais mais OSM en zone France permet de faire du
découpage en niveau dix mais les condition varient par pays et en
France *limites
des quartiers utilisés pour la démocracie locale*

*Donc c'est un gros paquet englobant des limites et des zones*

Pour revenir sur le fait qu'une zone porte le même nom c'est aussi possible
mais le cadastre n'efface pas la zone juste elle la renomme ace un petit
coup de blanco

Le 15 octobre 2014 15:58, David Crochet  a écrit :

> Bonjour
>
> Le 15/10/2014 15:21, Christian Quest a écrit :
>
>> ces relations ont été générées comment ?
>>
>
> Depuis les limites cadastrales des lieux-dits
>
> Cordialement
>
> --
> David Crochet
>
>
> ___
> 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] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[Philippe Verdy]

une zone délimitée peut malgré tout être créée sans nom, ou avec un nom
descriptif qui te semble approprié (avec une note ou FIXME indiquant que le
nom n'est pas officialisé ou n'a pas été trouvé).

Une fois la cohérence du découpage finie, tu pourras changer les tags.

Il n'y a pas que Layers pour en faire le rendu (parfois seulement après
plusieurs jours), Overpass t'en donne un presque instantanément (même si'l
ne vérifie pas tout et peut fermer arbitrairement une zone où il manque un
segment, mais observe comment il change le style de la bordure pour les
segments de fermeture ajoutés automatiquement là où il y a un trou)

Tu peux toujours ajouter du stylage MapCSS dans Overpass, mais je m'en sers
rarement car mes requêtes sont simples et sélectives sur des types d'objet
bien précis.


Le 15 octobre 2014 15:50, Jérôme Seigneuret  a
écrit :

> Ok, Je suis pas encore familier avec JOSM. J'ai pas pris le temps de m'y
> mettre plus que ça. J'ai plus l'habitude des solution web ou d'ArcGIS. Mais
> bon, tu as raisons de dire qu''iD que c'est pas l'idéal. Mais bon dans ce
> cas il faut limité les possibililé d'iD ou amélioré son fonctionnement pour
> éviter des désagréments sans pour autant dire.
>
> Quand tu veux décomposer des intersections, tu et obligé de coupé ton
> tronçon et c'est aussi le cas dans JOSM. Avec iD il n'y a pas de filtre et
> c'est dommage. Car c'est histoire de relation ne serait pas aussi chiante.
>
> Je viens de réouvrir le cadastre pour ta zone et elle n'a pas de nom dans
> le cadastre d'où le trou mais David pourra surement en dire plus. Je pense
> qu'il faut voir avec la mairie pour avoir plus de détail. Et je suis pas
> sur que le rattachement à une autre commune change de découpage des
> quartiers ou ensembles parcellaires.
>
> Je prendrai plus de temps pour JOSM plus tard pour le moment je suis sur
> une appli mobil de tracking pour Windows Phone.
>
>
>
> Le 15 octobre 2014 15:23, Philippe Verdy  a écrit :
>
> Il y a bien un PLU à la Ferté Macé (publié en annonce légale dans
>> Ouest-France, 1,60€ sur https://actulegales.fr/annonce-legale/1004035453).
>> Mais il va sans doute être obsolète car la commune souhaite s'associer avec
>> les autres communes de la communauté de communes pour passer au PLUi
>> (intercommunal).
>>
>> Je ne comprend pas trop comment tu manipules les choses sous iD mais je
>> n'ai jamais vu avoir besoin de couper une relation en deux et copier des
>> morceaux pour ensuite reconsituer la zone initiale en réassemblant après
>> avoir découpé une route.
>>
>> Je n"aime pas du tout iD pour faire des découpages complexes de toute
>> façon JOSM est tellement plus pratique, plus souple et permet de ne pas
>> être noyé sous das tas d'autres données. iD c'est fait pour des modifs très
>> locales (pas pus grande qu'une seule rue, ou ajouter un batiment, une
>> adresse, un nom; une limite de vitesse, un passage piéton.
>>
>> iD est une catastrophe pour ceux qui l'ont utilisé pour ajouter des
>> rond-points (en cassant des lignes de bus; et autres itinéraires dans
>> lesquels se forment des trous. iD mélange aussi tous les membres et ne
>> garde pas leur continuité, il coute cher ensuite pour ceux qui doivent
>> réparer. Je connais très peu de gens capables de comprendre comment
>> travailler efficacement avec des relations dans cet éditeur. Et puis
>> qu'est-ce que c'est lent et lourd en mémoire, le navigateur rame, les accès
>> constants au réseau sont pénibles, même sur une connexion fibre. A ,on avis
>> il surcharge même les serveurs de l'API d'OSM.
>>
>> La manipulation des relations dans iD passe par des dialogues de
>> sélection ultra compliqués et très lourds car peu sélectifs, il faut sans
>> cesse passer en revue les longues listes proposées et ne pas se tromper car
>> il y a peu d'indice et aucun filtrage. Il est inutilisable pour moi en
>> dessous du niveau de zoom 15; donc pas moyen de travailler dessus à
>> l'échelle d'une commune entière comme la Ferté-Macé (c'est illisible en
>> plus; on a baucoup de mal à sélectionner ce qu'on veut avec).
>>
>> iD c'est de l'occasionnel quand j'ai déjà une session OSM en cours et pas
>> envie de charger une autre calque. Parfois pour des modifs très légères
>> (par exemple corrections très simples dans OSMose sur un seul objet)
>> j'utilise directement rawedit (en XML) c'est plus vite fait, mais jamais je
>> n'utiliserai iD (ni même Potlatch2) pour Osmose, si possible j'utilise JOSM
>> pour tout (je peux provoirement cacher un calque et ouvrir un calque séparé
>> pour des modifs ponctuelles qui nécessitent plus de données que ce que je
>> ne veux pas garder dans le calque actuel si je ne veux pas ensuite purger
>> des tas d'éléments non modifiés et non utiles à la correction à faire).
>>
>> JOSM est mon ami (avec les touches CLTR+ALT+D ou une icone ajoutée sur la
>> barre d'icônes pour la même commande, plus pratique d'un clic qu'avec 3
>> touches). Il permet aussi de créer temporairement des relations de travail
>> pour

Re: [OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[David Crochet]

Bonjour

Le 15/10/2014 14:35, Philippe Verdy a écrit :

Dommage qu'il n'y ait pas la source pour savoir à quoi il correspond
exactemen


Elle est sur le chemin puisque la relations s'appuie sur les chemin : 
Cadastre


Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[David Crochet]

Bonjour

Le 15/10/2014 15:21, Christian Quest a écrit :

C'est normal d'en avoir trois qui se touchent et qui portent le même nom ?


Même lieu-dit, mais sur plusieurs feuilles cadastrales. L'idée est de 
les fusionner par la suite lorsque l'approche typographique est identique.


Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[David Crochet]

Bonjour

Le 15/10/2014 15:21, Christian Quest a écrit :

ces relations ont été générées comment ?


Depuis les limites cadastrales des lieux-dits

Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[David Crochet]

Bonjour

Le 15/10/2014 14:35, Philippe Verdy a écrit :

est-ce bien du niveau administratif 10 ?


Non, mais faute de mieux, je prends cette approche

 En tout cas cela ne correspond

pas exactement aux lieux-dits (certains lieux dits sont groupés,
d'autres sont découpés en 2 ou 3 pièces adjascentes) et cela laisse
suggérer justement que c'est basé sur un PLU.


Car les leiux dits, bien qu'ils portent le même nom sont sur deux 
feuilles cadastrales différentes, dont leurs noms est dupliqués d'autant.


Cordialement


--
David Crochet

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

Re: [OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[Philippe Verdy]

Mon hypothèse est celle du PLU. Les noms ne sont pas au hasard, on les voit
un peu partout cités (sans carte complète) dans les publications de la
mairie.

Je suppute que a source est soit une consultation visuelle du PLU, soit
directement un utilisateur du SIG communal, et qui importe comme il peut ce
qu'il voit et tente d'adapter à OSM. Je ne suis pas convincu que ce soit la
notion de "quartier" dans la commune; les zones sont individuellement très
peu peuplées, mais correspondent un peu aux lotissements (plus les terrains
agricoles environnants), des propriétés privées importantes peuvent être
découpées (exemple un camping ou le golf constitué par acquisition de
parcelles successives dans plusieurs zones), mais pas les équipements
communaux (écoles, stade, centres d'activité, services sociaux), et le lac
est tout entier rattaché avec ses berges, un petits bois attenant et un
lotissement tout au nord dans la même pièce.

Il y a une bonne cohérence dans ce découpage au vu des autres données
présentes. Pour l'instant je cherche mais je n'ai pas trouvé de source pour
le PLU communal actuel (ne parlons pas du PLUi envisagé)

Concernant le cadastre j'ai beaucoup de mal à le lire (mais surtout je
n'aime pas du tout ses projections tordues qui ne collent pas avec les
projections WGS84 de l'imagerie et qui déforment tout, et ont des gros
défauts d'affichage et demande un plugin JOSM assez bancal, qui oblige même
à redémarrer JOSM à tout bout de champ...).

Certains sont habitués, mais je ne m'y fais pas du tout à ce
Lambert-multizone franco-français, d'autant plus qu'il n'y a même pas de
conflation avec les communes voisines (ça pose des questions sur les
limites intercommunales..) non rapprochées.

Le 15 octobre 2014 15:21, Christian Quest  a écrit
:

> Mouais... ces relations ont été générées comment ?
>
> C'est normal d'en avoir trois qui se touchent et qui portent le même nom ?
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[David Crochet]

Bonjour

Le 15/10/2014 13:45, Philippe Verdy a écrit :

Bref je ne comprend pas sur quoi se base ce découpage


les lieux-dits du Cadastre

qui n plus est

incomplet au nord ouest de la commune.


car je n'ai que 24 par jour et je bosse IRL, donc désolé de ne pouvoir 
faire modifier l'espace-temps à ma guise.


Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[Jérôme Seigneuret]

Ok, Je suis pas encore familier avec JOSM. J'ai pas pris le temps de m'y
mettre plus que ça. J'ai plus l'habitude des solution web ou d'ArcGIS. Mais
bon, tu as raisons de dire qu''iD que c'est pas l'idéal. Mais bon dans ce
cas il faut limité les possibililé d'iD ou amélioré son fonctionnement pour
éviter des désagréments sans pour autant dire.

Quand tu veux décomposer des intersections, tu et obligé de coupé ton
tronçon et c'est aussi le cas dans JOSM. Avec iD il n'y a pas de filtre et
c'est dommage. Car c'est histoire de relation ne serait pas aussi chiante.

Je viens de réouvrir le cadastre pour ta zone et elle n'a pas de nom dans
le cadastre d'où le trou mais David pourra surement en dire plus. Je pense
qu'il faut voir avec la mairie pour avoir plus de détail. Et je suis pas
sur que le rattachement à une autre commune change de découpage des
quartiers ou ensembles parcellaires.

Je prendrai plus de temps pour JOSM plus tard pour le moment je suis sur
une appli mobil de tracking pour Windows Phone.



Le 15 octobre 2014 15:23, Philippe Verdy  a écrit :

> Il y a bien un PLU à la Ferté Macé (publié en annonce légale dans
> Ouest-France, 1,60€ sur https://actulegales.fr/annonce-legale/1004035453).
> Mais il va sans doute être obsolète car la commune souhaite s'associer avec
> les autres communes de la communauté de communes pour passer au PLUi
> (intercommunal).
>
> Je ne comprend pas trop comment tu manipules les choses sous iD mais je
> n'ai jamais vu avoir besoin de couper une relation en deux et copier des
> morceaux pour ensuite reconsituer la zone initiale en réassemblant après
> avoir découpé une route.
>
> Je n"aime pas du tout iD pour faire des découpages complexes de toute
> façon JOSM est tellement plus pratique, plus souple et permet de ne pas
> être noyé sous das tas d'autres données. iD c'est fait pour des modifs très
> locales (pas pus grande qu'une seule rue, ou ajouter un batiment, une
> adresse, un nom; une limite de vitesse, un passage piéton.
>
> iD est une catastrophe pour ceux qui l'ont utilisé pour ajouter des
> rond-points (en cassant des lignes de bus; et autres itinéraires dans
> lesquels se forment des trous. iD mélange aussi tous les membres et ne
> garde pas leur continuité, il coute cher ensuite pour ceux qui doivent
> réparer. Je connais très peu de gens capables de comprendre comment
> travailler efficacement avec des relations dans cet éditeur. Et puis
> qu'est-ce que c'est lent et lourd en mémoire, le navigateur rame, les accès
> constants au réseau sont pénibles, même sur une connexion fibre. A ,on avis
> il surcharge même les serveurs de l'API d'OSM.
>
> La manipulation des relations dans iD passe par des dialogues de sélection
> ultra compliqués et très lourds car peu sélectifs, il faut sans cesse
> passer en revue les longues listes proposées et ne pas se tromper car il y
> a peu d'indice et aucun filtrage. Il est inutilisable pour moi en dessous
> du niveau de zoom 15; donc pas moyen de travailler dessus à l'échelle d'une
> commune entière comme la Ferté-Macé (c'est illisible en plus; on a baucoup
> de mal à sélectionner ce qu'on veut avec).
>
> iD c'est de l'occasionnel quand j'ai déjà une session OSM en cours et pas
> envie de charger une autre calque. Parfois pour des modifs très légères
> (par exemple corrections très simples dans OSMose sur un seul objet)
> j'utilise directement rawedit (en XML) c'est plus vite fait, mais jamais je
> n'utiliserai iD (ni même Potlatch2) pour Osmose, si possible j'utilise JOSM
> pour tout (je peux provoirement cacher un calque et ouvrir un calque séparé
> pour des modifs ponctuelles qui nécessitent plus de données que ce que je
> ne veux pas garder dans le calque actuel si je ne veux pas ensuite purger
> des tas d'éléments non modifiés et non utiles à la correction à faire).
>
> JOSM est mon ami (avec les touches CLTR+ALT+D ou une icone ajoutée sur la
> barre d'icônes pour la même commande, plus pratique d'un clic qu'avec 3
> touches). Il permet aussi de créer temporairement des relations de travail
> pour garder des sélections d'objets en cours de modif ou à vérifier. Pour
> repérer facilement cette relation de travail dans la liste, je lui donne un
> tag "type=!TODO" au lieu de multipolygon, avec un point d'exclamation au
> début de la valeur pour qu'elle soit en tête de liste des relations (qui
> est classée par type puis par nom).
>
> Modifs terminées, je peux sauvegarder le fichier, purger la relation
> temporaire de la mémoire et je peux envoyer les données puis fusionner les
> données dans un calque principal pour le mettre à jour avec les données que
> je souhaite garder pour la suite.
>
> Le 15 octobre 2014 14:55, Jérôme Seigneuret  a
> écrit :
>
> http://overpass-turbo.eu/s/5tq une requete des way en question.
>> http://overpass-turbo.eu/s/5tv une requete des relation en question.
>>
>> Il y a des trous dans les relations et je pense qu'il manque des tronçon
>> pour fermer le tout.
>>
>> Sinon j'ai regardé le cadastre po

Re: [OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[David Crochet]

Bonjour

Le 15/10/2014 11:05, Jérôme Seigneuret a écrit :

Moi je préfère juste faire comme ici :
http://www.openstreetmap.org/way/277831410 au pire ne pas mettre le nom
dans le polygone mais sur un noeud et les lier si besoin...(il y a
peut-être mieux)


Oui c'est exactement cette définition que je recherche, mais il n'existe 
pas en tant que relation mais noeud ou chemin.


Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[David Crochet]

Bonjour

Le 15/10/2014 10:14, Philippe Verdy a écrit :

si sur le fait que ce découpage soit incomplet,


Il y a deux choses :
- j'ai pas eu le temps de tous les faire
- il y a des zones non nommées

mais juste sur la

question de la pertinence de ces données (pérennité, adéquation à une
utilisation par exemple pour des plans immobiliers) et surtout de leur
classification,


Dans les découpages administratifs, il y a du politique, de 
ecclésiastique et de l'administratif.

Le niveau 8 représente la commune, soit.
Ensuite il existe un découpage plus fin, les lieux dits et les quartiers.

Certes le niveau 10 définit le découpage des quartiers.

Ici, on est encore plus fin, c'est des lieux-dits
sauf que je m'aide d'outils qui me permettent de travailler sur du 
visuels (layers.osm.fr) je sais, c'est pas bien, mais j'ai pas mieux à 
mon niveau de connaissances et de compétences.


Mais comme je le disais, c'est en travail en cours, il restera à définir 
avec la ville, de nommer des lieux dits qui n'ont pas de noms, et aussi 
de leurs montrer des exclaves dans la commune ou des doublons. Pour les 
doublons, c'est logiques puisque le découpage est lié aux feuilles 
cadastrales. Les zones homonymiques seront logiquement à fusionner. Mais 
a voir avec la commune si c'est réellement le cas.


De même , cela permet de pointer de coquille typographique :
- Loisivière et L'Oisivière


Cordialement
--
David Crochet

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

Re: [OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[Philippe Verdy]

Il y a bien un PLU à la Ferté Macé (publié en annonce légale dans
Ouest-France, 1,60€ sur https://actulegales.fr/annonce-legale/1004035453).
Mais il va sans doute être obsolète car la commune souhaite s'associer avec
les autres communes de la communauté de communes pour passer au PLUi
(intercommunal).

Je ne comprend pas trop comment tu manipules les choses sous iD mais je
n'ai jamais vu avoir besoin de couper une relation en deux et copier des
morceaux pour ensuite reconsituer la zone initiale en réassemblant après
avoir découpé une route.

Je n"aime pas du tout iD pour faire des découpages complexes de toute façon
JOSM est tellement plus pratique, plus souple et permet de ne pas être noyé
sous das tas d'autres données. iD c'est fait pour des modifs très locales
(pas pus grande qu'une seule rue, ou ajouter un batiment, une adresse, un
nom; une limite de vitesse, un passage piéton.

iD est une catastrophe pour ceux qui l'ont utilisé pour ajouter des
rond-points (en cassant des lignes de bus; et autres itinéraires dans
lesquels se forment des trous. iD mélange aussi tous les membres et ne
garde pas leur continuité, il coute cher ensuite pour ceux qui doivent
réparer. Je connais très peu de gens capables de comprendre comment
travailler efficacement avec des relations dans cet éditeur. Et puis
qu'est-ce que c'est lent et lourd en mémoire, le navigateur rame, les accès
constants au réseau sont pénibles, même sur une connexion fibre. A ,on avis
il surcharge même les serveurs de l'API d'OSM.

La manipulation des relations dans iD passe par des dialogues de sélection
ultra compliqués et très lourds car peu sélectifs, il faut sans cesse
passer en revue les longues listes proposées et ne pas se tromper car il y
a peu d'indice et aucun filtrage. Il est inutilisable pour moi en dessous
du niveau de zoom 15; donc pas moyen de travailler dessus à l'échelle d'une
commune entière comme la Ferté-Macé (c'est illisible en plus; on a baucoup
de mal à sélectionner ce qu'on veut avec).

iD c'est de l'occasionnel quand j'ai déjà une session OSM en cours et pas
envie de charger une autre calque. Parfois pour des modifs très légères
(par exemple corrections très simples dans OSMose sur un seul objet)
j'utilise directement rawedit (en XML) c'est plus vite fait, mais jamais je
n'utiliserai iD (ni même Potlatch2) pour Osmose, si possible j'utilise JOSM
pour tout (je peux provoirement cacher un calque et ouvrir un calque séparé
pour des modifs ponctuelles qui nécessitent plus de données que ce que je
ne veux pas garder dans le calque actuel si je ne veux pas ensuite purger
des tas d'éléments non modifiés et non utiles à la correction à faire).

JOSM est mon ami (avec les touches CLTR+ALT+D ou une icone ajoutée sur la
barre d'icônes pour la même commande, plus pratique d'un clic qu'avec 3
touches). Il permet aussi de créer temporairement des relations de travail
pour garder des sélections d'objets en cours de modif ou à vérifier. Pour
repérer facilement cette relation de travail dans la liste, je lui donne un
tag "type=!TODO" au lieu de multipolygon, avec un point d'exclamation au
début de la valeur pour qu'elle soit en tête de liste des relations (qui
est classée par type puis par nom).

Modifs terminées, je peux sauvegarder le fichier, purger la relation
temporaire de la mémoire et je peux envoyer les données puis fusionner les
données dans un calque principal pour le mettre à jour avec les données que
je souhaite garder pour la suite.

Le 15 octobre 2014 14:55, Jérôme Seigneuret  a
écrit :

> http://overpass-turbo.eu/s/5tq une requete des way en question.
> http://overpass-turbo.eu/s/5tv une requete des relation en question.
>
> Il y a des trous dans les relations et je pense qu'il manque des tronçon
> pour fermer le tout.
>
> Sinon j'ai regardé le cadastre pour voir et c'est un regroupement de
> parcelle correspondant au lieu-dit (voir sur cadastre.gouv.fr)
> Un centre serait pas mal pour voir les nom des quartiers dans les relation.
>
>
> Pour le reste en effet sous iD si tu veux découper un way il faut déjà
> vérifier s'il n'est pas en relation avec un autre tracé au moment de faire
> le découpage sur le noeud souhaité.Une route superposé sur un découpage
> administratif (les noeud sont en relation par exemple) si tu découpes le
> noeud avec des relations, ça coupe tous les objets concernées par ce noeud.
>
> Et ça tu ne le sait pas forcément. Si tu as plusieurs niveaux de contours
> administratif c'est la même merde.  Le seul moyen que j'ai trouvé c'est de
> décomposer la relation au préalable puis couper l'entité puis refaire la
> relation si nécessaire.
>
> C'est en coupant une route que j'avais tous cassé la dernière fois.
>
> Je regarde le cadastre pour vérifier ta zone
>
>
>
>
> Le 15 octobre 2014 13:55, Philippe Verdy  a écrit :
>
> Layers en fait d'ailleurs un rendu de toutes ces relations qui sont bien là
>>
>>
>> http://layers.openstreetmap.fr/?zoom=13&lat=48.58094&lon=-0.35914&layers=BFFFTFF
>>
>>

Re: [OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[Christian Quest]

Mouais... ces relations ont été générées comment ?

C'est normal d'en avoir trois qui se touchent et qui portent le même nom ?

Je ne suis pas vraiment fan du admin_level=10 car on ne peut vraiment pas
comparer un lieu dit de quelques parcelles cultivées avec un quartier de
Paris bien identifié, qui a un comité de quartier et tout le bazar associé.

Ca ressemble plus à des place=locality mais surfaciques au lieu des
habituels ponctuels.

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

Re: [OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[Jérôme Seigneuret]

http://overpass-turbo.eu/s/5tq une requete des way en question.
http://overpass-turbo.eu/s/5tv une requete des relation en question.

Il y a des trous dans les relations et je pense qu'il manque des tronçon
pour fermer le tout.

Sinon j'ai regardé le cadastre pour voir et c'est un regroupement de
parcelle correspondant au lieu-dit (voir sur cadastre.gouv.fr)
Un centre serait pas mal pour voir les nom des quartiers dans les relation.


Pour le reste en effet sous iD si tu veux découper un way il faut déjà
vérifier s'il n'est pas en relation avec un autre tracé au moment de faire
le découpage sur le noeud souhaité.Une route superposé sur un découpage
administratif (les noeud sont en relation par exemple) si tu découpes le
noeud avec des relations, ça coupe tous les objets concernées par ce noeud.

Et ça tu ne le sait pas forcément. Si tu as plusieurs niveaux de contours
administratif c'est la même merde.  Le seul moyen que j'ai trouvé c'est de
décomposer la relation au préalable puis couper l'entité puis refaire la
relation si nécessaire.

C'est en coupant une route que j'avais tous cassé la dernière fois.

Je regarde le cadastre pour vérifier ta zone




Le 15 octobre 2014 13:55, Philippe Verdy  a écrit :

> Layers en fait d'ailleurs un rendu de toutes ces relations qui sont bien là
>
>
> http://layers.openstreetmap.fr/?zoom=13&lat=48.58094&lon=-0.35914&layers=BFFFTFF
>
> Il n'y a qu'un seul way qui ne correspond encore à aucune relation 10 bien
> qu'il soit marqué comme boundary de niveau 10 et ce way est connecté
> correctement par ses extrémités aux autres utilisés par des relations
> boundary de niveau 10.
>
> D'ailleurs je vois que depuis mon premier message il y a eu de nouvelles
> relations ajoutées pour les lieux-dits. Mais certains leiux-dits sont
> coupés en deux (La Sourdière par exemple) et pas du tout par l'ajout d'une
> limite de landuse et je ne vois pas pourquoi iD découperait une relation en
> deux relations. du fait qu'on découpe un segment, il a plutôt tendance à
> accumuler les ways découpés dans les relations existantes et y laisser des
> ways en trop...
>
>
>
>
> Le 15 octobre 2014 13:45, Philippe Verdy  a écrit :
>
> Non justement car ce sont bien tout un tas de relations administratives de
>> niveau 10 qui ont été créées toutes correctement fermées sauf une en cours
>> de tracé visiblement avec un chemin isolé de toute relations car
>> visiblement il manque des traits a l'est pour ne pas reprendre les
>> parcelles d'une voirie de jonction. Et id n'y est pour rien car chacune des
>> relations administratives des noms représentant selon les cas un lieu dit,
>> une rue, une place, ou presque tout un quartier... Et ce sont des groupes
>> de parcelles couvrant des propriétés différentes et des petites voiries de
>> desserte interne. Bref ca a été fait volontairement et sans aucun rapport
>> avec les landuse même si pour certaines relations (en minorité) il y a des
>> wommns avec les landuse. Bref je ne comprend pas sur quoi se base ce
>> découpage qui n plus est incomplet au nord ouest de la commune.
>>
>> Ne regarde pas que le way que j'ai indique mais les ways qui y sont
>> connecte par les extrémités. Un requête overpass sur les admin level 10
>> dans une BBox couvrant la commune et tu comprendras mieux.
>>
>> NB: c'est toi qui a créé ces relations?
>>  Le 15 oct. 2014 11:06, "Jérôme Seigneuret"  a
>> écrit :
>>
>> Les zones dont tu parles pour moi c'est pas du boundary, c'est du
>>> découpage cadastre des lieu-dits (voisinage dans un village ou quartier en
>>> ville ou hameau) En principe moi je fais juste un noeud toponyme mais on
>>> peu faire des zones toponymes et faire le lien vers le nom du contour
>>> administratif en question. d'ailleurs c'est bizarre car aucun tracé n'est
>>> fermé vu que le nom est sur le tracé
>>>
>>> on peut mettre un is_in=* pour lier avec le boundary de la commune
>>> certains font des landuse= residential mais je trouve ça pourri pour
>>>  faire des toponymes. Moi je préfère juste faire comme ici :
>>> http://www.openstreetmap.org/way/277831410 au pire ne pas mettre le nom
>>> dans le polygone mais sur un noeud et les lier si besoin...(il y a
>>> peut-être mieux)
>>>
>>> Le landuse est un autre objet pour moi. Mais je vais pas revenir sur ça
>>> c'est pas le sujet.
>>>
>>> Pour réparer moi je fais ça dans JOSM en important que le tronçon
>>> boundary en question par son id et en important uniquement les relations.
>>> Après en cas de problèmes JOSM demande de corriger les incohérence avant de
>>> faire la sauvegarde. J'avais fait une connerie de ce type sur Montpellier.
>>> J'ai juste refermé le way et fini.
>>>
>>> En même temps iD fou un peu la merde:
>>>  Si tu coupes un polygon pour en faire deux il coupe toute les relations
>>> et ça ressemble un peu à ce que tu présentes.
>>>
>>>
>>>
>>>
>>> Le 15 octobre 2014 10:14, Philippe Verdy  a écrit :
>>>
 En tentant de corriger des erreurs de frontières incomplètes dans
 Os

Re: [OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[Philippe Verdy]

Le découpage n'est visiblement pas fait n'importe comment, les noms sont
cohérents avec les noms des lieux place=* pour les lieux-dits, ou avec
certains équipements communaux (le stade)

Le tracé n'est pas non plus issu d'un import cadastral direct. C'est un
microzonage de la commune.

A mon avis la source (non indiquée) doit être un PLU (plan local
d'urbanisme), sans doute un PDF publié par la commune, retracé à la main en
sa basant sur l'imagerie Bing ou avec un fond de carte Mapnik (il est assez
précis dans la géolocalisation des noeuds, mais il est fait réemlement
indépendamment des traits des landuse ou ceux des rues ou voies communales
ou petits chemins ruraux.

Je vous très mal créer ce découpage dans iD et ne pas se mélanger les
pinceaux car il n'y a pas d'incohérence, juste un seul trait isolé pour un
polygone qui n'était pas complet, comme si le travail avait été laissé en
cours.

Noter aussi qu'il y a deux pièces nommés selon le lieu-dit "Le Rocher
Broutin", la plus grande au sud n'est faite presque que de forêt, mais la
forêt déborde un peu au nord sur la pièce homonyme (la séparation
correspond à peu près à un peut chemin forestier et un ruisseau longé par
ce chemin), et un peu sur une autre pièce couvrant le lieu-dit "La
Bigotière" (là encore en suivant à peu près un chemin forestier)

Les tracés de landuse sont plutôt pas mal faits (on est loin de l'import
CORINE dont il n'est même plus question ici), même si un peu plus de
précision pourrait encore être ajouté (soit sur ce tracé admin, soit sur
les chemins et rues) Le tracé évite convenablement de couper des bâtiments
en 2.

Mais ma question essentielle est : est-ce bien du niveau administratif 10 ?
En tout cas cela ne correspond pas exactement aux lieux-dits (certains
lieux dits sont groupés, d'autres sont découpés en 2 ou 3 pièces
adjascentes) et cela laisse suggérer justement que c'est basé sur un PLU.

Voire peut-être des IRIS, la commune étant assez peuplée pour avoir un tel
découpage; avec des pièces très petites dans les zones les plus densément
habitées - peu importe si ça découpe un lieu-dit - et très grandes pour les
zones de forêt ou grands champs agricoles (dans lesquels il y a inclus
dedans les zones habitées, des fermes, ou petits lotissements).

Le zonage en IRIS étant utile pour répartir les électeurs sur les listes
des bureaux de vote (indépendamment du lieu de vote qui regroupe pluseurs
bureaux souvent dans la même salle) en assemblant les électeurs attribués
sur chaque IRIS pour constituer les listes avec le quorum idéal qui
facilite le dépouillement (environ 400 électeurs inscrits ou un peu moins)
et évite de devoir recruter trop d'assesseurs (au delà du seul personnel
communal qui doit être présent au moins dans le lieu de rassemblement des
bureaux de vote avec au moins 2 personnes qui doivent rester présentes
durant toute la durée du scrutin, avec les électeurs volontaires qui se
présentent) Mais là le découpage est visiblement trop fin pour suffire à
constituer une liste électorale pour un bureau de vote, il y a beaucoup
trop de "pièces" par rapport à la population communale (je n'ai pas regardé
le nombre d'inscrits qui est plus petit)

Bref je ne critique pas le travail fait mais je doute que soit les bons
tags (et ce tracé ne fait pas doublon avec les lieux-dits en noeuds place=*
qui sont à part et pas liés directement). Dommage qu'il n'y ait pas la
source pour savoir à quoi il correspond exactement. Si pas de réponse de la
part de l'auteur, il va falloir consulter le site de la mairie, il y a
peut-être un document publié qui montre ce découpage (même s'il est encore
incomplet mais bien avancé).

Le 15 octobre 2014 13:53, Jérôme Seigneuret  a
écrit :

> Tu poses la question à David je suppose pour les relations. Perso j'en
> fait quasiment jamais. Je vais essayer la requête overpass pour voir et
> mieux comprendre.
>
> Le 15 octobre 2014 13:45, Philippe Verdy  a écrit :
>
> Non justement car ce sont bien tout un tas de relations administratives de
>> niveau 10 qui ont été créées toutes correctement fermées sauf une en cours
>> de tracé visiblement avec un chemin isolé de toute relations car
>> visiblement il manque des traits a l'est pour ne pas reprendre les
>> parcelles d'une voirie de jonction. Et id n'y est pour rien car chacune des
>> relations administratives des noms représentant selon les cas un lieu dit,
>> une rue, une place, ou presque tout un quartier... Et ce sont des groupes
>> de parcelles couvrant des propriétés différentes et des petites voiries de
>> desserte interne. Bref ca a été fait volontairement et sans aucun rapport
>> avec les landuse même si pour certaines relations (en minorité) il y a des
>> wommns avec les landuse. Bref je ne comprend pas sur quoi se base ce
>> découpage qui n plus est incomplet au nord ouest de la commune.
>>
>> Ne regarde pas que le way que j'ai indique mais les ways qui y sont
>> connecte par les extrémités. Un requête overpass sur les admin level 10
>> dans une BBox

Re: [OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[Philippe Verdy]

Layers en fait d'ailleurs un rendu de toutes ces relations qui sont bien là

http://layers.openstreetmap.fr/?zoom=13&lat=48.58094&lon=-0.35914&layers=BFFFTFF

Il n'y a qu'un seul way qui ne correspond encore à aucune relation 10 bien
qu'il soit marqué comme boundary de niveau 10 et ce way est connecté
correctement par ses extrémités aux autres utilisés par des relations
boundary de niveau 10.

D'ailleurs je vois que depuis mon premier message il y a eu de nouvelles
relations ajoutées pour les lieux-dits. Mais certains leiux-dits sont
coupés en deux (La Sourdière par exemple) et pas du tout par l'ajout d'une
limite de landuse et je ne vois pas pourquoi iD découperait une relation en
deux relations. du fait qu'on découpe un segment, il a plutôt tendance à
accumuler les ways découpés dans les relations existantes et y laisser des
ways en trop...




Le 15 octobre 2014 13:45, Philippe Verdy  a écrit :

> Non justement car ce sont bien tout un tas de relations administratives de
> niveau 10 qui ont été créées toutes correctement fermées sauf une en cours
> de tracé visiblement avec un chemin isolé de toute relations car
> visiblement il manque des traits a l'est pour ne pas reprendre les
> parcelles d'une voirie de jonction. Et id n'y est pour rien car chacune des
> relations administratives des noms représentant selon les cas un lieu dit,
> une rue, une place, ou presque tout un quartier... Et ce sont des groupes
> de parcelles couvrant des propriétés différentes et des petites voiries de
> desserte interne. Bref ca a été fait volontairement et sans aucun rapport
> avec les landuse même si pour certaines relations (en minorité) il y a des
> wommns avec les landuse. Bref je ne comprend pas sur quoi se base ce
> découpage qui n plus est incomplet au nord ouest de la commune.
>
> Ne regarde pas que le way que j'ai indique mais les ways qui y sont
> connecte par les extrémités. Un requête overpass sur les admin level 10
> dans une BBox couvrant la commune et tu comprendras mieux.
>
> NB: c'est toi qui a créé ces relations?
>  Le 15 oct. 2014 11:06, "Jérôme Seigneuret"  a
> écrit :
>
> Les zones dont tu parles pour moi c'est pas du boundary, c'est du
>> découpage cadastre des lieu-dits (voisinage dans un village ou quartier en
>> ville ou hameau) En principe moi je fais juste un noeud toponyme mais on
>> peu faire des zones toponymes et faire le lien vers le nom du contour
>> administratif en question. d'ailleurs c'est bizarre car aucun tracé n'est
>> fermé vu que le nom est sur le tracé
>>
>> on peut mettre un is_in=* pour lier avec le boundary de la commune
>> certains font des landuse= residential mais je trouve ça pourri pour
>>  faire des toponymes. Moi je préfère juste faire comme ici :
>> http://www.openstreetmap.org/way/277831410 au pire ne pas mettre le nom
>> dans le polygone mais sur un noeud et les lier si besoin...(il y a
>> peut-être mieux)
>>
>> Le landuse est un autre objet pour moi. Mais je vais pas revenir sur ça
>> c'est pas le sujet.
>>
>> Pour réparer moi je fais ça dans JOSM en important que le tronçon
>> boundary en question par son id et en important uniquement les relations.
>> Après en cas de problèmes JOSM demande de corriger les incohérence avant de
>> faire la sauvegarde. J'avais fait une connerie de ce type sur Montpellier.
>> J'ai juste refermé le way et fini.
>>
>> En même temps iD fou un peu la merde:
>>  Si tu coupes un polygon pour en faire deux il coupe toute les relations
>> et ça ressemble un peu à ce que tu présentes.
>>
>>
>>
>>
>> Le 15 octobre 2014 10:14, Philippe Verdy  a écrit :
>>
>>> En tentant de corriger des erreurs de frontières incomplètes dans
>>> Osmose, je me suis aperçu que la Ferté-Macé (en Mayenne) est découpé dans
>>> ce qui ne ,e semble pas être des quartiers mais des noms de parcelles (ou
>>> groupes de parcelles). Y compris des parcelles homonymes et limitrophes
>>> l'une de l'autre.
>>> Les noms sont parfois des lieux-dits, ou des noms de rues.
>>>
>>> Exemple autour de ceci:
>>>
>>> http://www.openstreetmap.org/way/306246629
>>>
>>> Le chemin est isolé mais la frontière n'est pas fermée (il n'est encore
>>> dans aucune relation mais a déjà un tag admin_level 10), et la commune
>>> n'est visiblement pas entièrement découpée, je ne vois pas comment corriger
>>> ces relations "administrative" pour les fermer correctement, et comment les
>>> retaguer correctement si ce n'est pas administratif.
>>>
>>> Pour l'instant je n'ai rien supprimé (ce tracé est tout demême complexe
>>> pour une seule commune), juste levé quelques anomalies géométriques pour
>>> vérifier la cohérence de ce découpage dont la classification reste tout de
>>> même à revoir si on doit garder ce découpage pour une certaine utilité (il
>>> ne me semble pas qu'il soi approprié pour les lieux-dits). Je me demande
>>> d'où ce découpage est issu : est-ce que c'est le découpage des zones
>>> cadastrales ? L'auteur comptait-il poursuivre ensuite avec les parcelles
>>> indiv

Re: [OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[Jérôme Seigneuret]

Tu poses la question à David je suppose pour les relations. Perso j'en fait
quasiment jamais. Je vais essayer la requête overpass pour voir et mieux
comprendre.

Le 15 octobre 2014 13:45, Philippe Verdy  a écrit :

> Non justement car ce sont bien tout un tas de relations administratives de
> niveau 10 qui ont été créées toutes correctement fermées sauf une en cours
> de tracé visiblement avec un chemin isolé de toute relations car
> visiblement il manque des traits a l'est pour ne pas reprendre les
> parcelles d'une voirie de jonction. Et id n'y est pour rien car chacune des
> relations administratives des noms représentant selon les cas un lieu dit,
> une rue, une place, ou presque tout un quartier... Et ce sont des groupes
> de parcelles couvrant des propriétés différentes et des petites voiries de
> desserte interne. Bref ca a été fait volontairement et sans aucun rapport
> avec les landuse même si pour certaines relations (en minorité) il y a des
> wommns avec les landuse. Bref je ne comprend pas sur quoi se base ce
> découpage qui n plus est incomplet au nord ouest de la commune.
>
> Ne regarde pas que le way que j'ai indique mais les ways qui y sont
> connecte par les extrémités. Un requête overpass sur les admin level 10
> dans une BBox couvrant la commune et tu comprendras mieux.
>
> NB: c'est toi qui a créé ces relations?
>  Le 15 oct. 2014 11:06, "Jérôme Seigneuret"  a
> écrit :
>
> Les zones dont tu parles pour moi c'est pas du boundary, c'est du
>> découpage cadastre des lieu-dits (voisinage dans un village ou quartier en
>> ville ou hameau) En principe moi je fais juste un noeud toponyme mais on
>> peu faire des zones toponymes et faire le lien vers le nom du contour
>> administratif en question. d'ailleurs c'est bizarre car aucun tracé n'est
>> fermé vu que le nom est sur le tracé
>>
>> on peut mettre un is_in=* pour lier avec le boundary de la commune
>> certains font des landuse= residential mais je trouve ça pourri pour
>>  faire des toponymes. Moi je préfère juste faire comme ici :
>> http://www.openstreetmap.org/way/277831410 au pire ne pas mettre le nom
>> dans le polygone mais sur un noeud et les lier si besoin...(il y a
>> peut-être mieux)
>>
>> Le landuse est un autre objet pour moi. Mais je vais pas revenir sur ça
>> c'est pas le sujet.
>>
>> Pour réparer moi je fais ça dans JOSM en important que le tronçon
>> boundary en question par son id et en important uniquement les relations.
>> Après en cas de problèmes JOSM demande de corriger les incohérence avant de
>> faire la sauvegarde. J'avais fait une connerie de ce type sur Montpellier.
>> J'ai juste refermé le way et fini.
>>
>> En même temps iD fou un peu la merde:
>>  Si tu coupes un polygon pour en faire deux il coupe toute les relations
>> et ça ressemble un peu à ce que tu présentes.
>>
>>
>>
>>
>> Le 15 octobre 2014 10:14, Philippe Verdy  a écrit :
>>
>>> En tentant de corriger des erreurs de frontières incomplètes dans
>>> Osmose, je me suis aperçu que la Ferté-Macé (en Mayenne) est découpé dans
>>> ce qui ne ,e semble pas être des quartiers mais des noms de parcelles (ou
>>> groupes de parcelles). Y compris des parcelles homonymes et limitrophes
>>> l'une de l'autre.
>>> Les noms sont parfois des lieux-dits, ou des noms de rues.
>>>
>>> Exemple autour de ceci:
>>>
>>> http://www.openstreetmap.org/way/306246629
>>>
>>> Le chemin est isolé mais la frontière n'est pas fermée (il n'est encore
>>> dans aucune relation mais a déjà un tag admin_level 10), et la commune
>>> n'est visiblement pas entièrement découpée, je ne vois pas comment corriger
>>> ces relations "administrative" pour les fermer correctement, et comment les
>>> retaguer correctement si ce n'est pas administratif.
>>>
>>> Pour l'instant je n'ai rien supprimé (ce tracé est tout demême complexe
>>> pour une seule commune), juste levé quelques anomalies géométriques pour
>>> vérifier la cohérence de ce découpage dont la classification reste tout de
>>> même à revoir si on doit garder ce découpage pour une certaine utilité (il
>>> ne me semble pas qu'il soi approprié pour les lieux-dits). Je me demande
>>> d'où ce découpage est issu : est-ce que c'est le découpage des zones
>>> cadastrales ? L'auteur comptait-il poursuivre ensuite avec les parcelles
>>> individuelles ?
>>>
>>> Jusqu'à présent on utilisait le niveau 9 pour les arrondissements de
>>> Paris Lyon Marseille o pour les communes associées au sein d'une même
>>> commune; le niveau 10 pour des quartiers réels, mais pas pour un découpage
>>> quasi parcellaire comme ici.
>>>
>>> Note: je ne m'adresse pas spécifiquement à cet auteur (il peut
>>> s'exprimer; je ne lui tape pas dessus et il peut avoir des intentions
>>> louables), si sur le fait que ce découpage soit incomplet, mais juste sur
>>> la question de la pertinence de ces données (pérennité, adéquation à une
>>> utilisation par exemple pour des plans immobiliers) et surtout de leur
>>> classification, pour que cela ne nuise pas aux autres utilisatio

Re: [OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[Philippe Verdy]

Non justement car ce sont bien tout un tas de relations administratives de
niveau 10 qui ont été créées toutes correctement fermées sauf une en cours
de tracé visiblement avec un chemin isolé de toute relations car
visiblement il manque des traits a l'est pour ne pas reprendre les
parcelles d'une voirie de jonction. Et id n'y est pour rien car chacune des
relations administratives des noms représentant selon les cas un lieu dit,
une rue, une place, ou presque tout un quartier... Et ce sont des groupes
de parcelles couvrant des propriétés différentes et des petites voiries de
desserte interne. Bref ca a été fait volontairement et sans aucun rapport
avec les landuse même si pour certaines relations (en minorité) il y a des
wommns avec les landuse. Bref je ne comprend pas sur quoi se base ce
découpage qui n plus est incomplet au nord ouest de la commune.

Ne regarde pas que le way que j'ai indique mais les ways qui y sont
connecte par les extrémités. Un requête overpass sur les admin level 10
dans une BBox couvrant la commune et tu comprendras mieux.

NB: c'est toi qui a créé ces relations?
 Le 15 oct. 2014 11:06, "Jérôme Seigneuret"  a
écrit :

> Les zones dont tu parles pour moi c'est pas du boundary, c'est du
> découpage cadastre des lieu-dits (voisinage dans un village ou quartier en
> ville ou hameau) En principe moi je fais juste un noeud toponyme mais on
> peu faire des zones toponymes et faire le lien vers le nom du contour
> administratif en question. d'ailleurs c'est bizarre car aucun tracé n'est
> fermé vu que le nom est sur le tracé
>
> on peut mettre un is_in=* pour lier avec le boundary de la commune
> certains font des landuse= residential mais je trouve ça pourri pour
>  faire des toponymes. Moi je préfère juste faire comme ici :
> http://www.openstreetmap.org/way/277831410 au pire ne pas mettre le nom
> dans le polygone mais sur un noeud et les lier si besoin...(il y a
> peut-être mieux)
>
> Le landuse est un autre objet pour moi. Mais je vais pas revenir sur ça
> c'est pas le sujet.
>
> Pour réparer moi je fais ça dans JOSM en important que le tronçon boundary
> en question par son id et en important uniquement les relations. Après en
> cas de problèmes JOSM demande de corriger les incohérence avant de faire la
> sauvegarde. J'avais fait une connerie de ce type sur Montpellier. J'ai
> juste refermé le way et fini.
>
> En même temps iD fou un peu la merde:
>  Si tu coupes un polygon pour en faire deux il coupe toute les relations
> et ça ressemble un peu à ce que tu présentes.
>
>
>
>
> Le 15 octobre 2014 10:14, Philippe Verdy  a écrit :
>
>> En tentant de corriger des erreurs de frontières incomplètes dans Osmose,
>> je me suis aperçu que la Ferté-Macé (en Mayenne) est découpé dans ce qui ne
>> ,e semble pas être des quartiers mais des noms de parcelles (ou groupes de
>> parcelles). Y compris des parcelles homonymes et limitrophes l'une de
>> l'autre.
>> Les noms sont parfois des lieux-dits, ou des noms de rues.
>>
>> Exemple autour de ceci:
>>
>> http://www.openstreetmap.org/way/306246629
>>
>> Le chemin est isolé mais la frontière n'est pas fermée (il n'est encore
>> dans aucune relation mais a déjà un tag admin_level 10), et la commune
>> n'est visiblement pas entièrement découpée, je ne vois pas comment corriger
>> ces relations "administrative" pour les fermer correctement, et comment les
>> retaguer correctement si ce n'est pas administratif.
>>
>> Pour l'instant je n'ai rien supprimé (ce tracé est tout demême complexe
>> pour une seule commune), juste levé quelques anomalies géométriques pour
>> vérifier la cohérence de ce découpage dont la classification reste tout de
>> même à revoir si on doit garder ce découpage pour une certaine utilité (il
>> ne me semble pas qu'il soi approprié pour les lieux-dits). Je me demande
>> d'où ce découpage est issu : est-ce que c'est le découpage des zones
>> cadastrales ? L'auteur comptait-il poursuivre ensuite avec les parcelles
>> individuelles ?
>>
>> Jusqu'à présent on utilisait le niveau 9 pour les arrondissements de
>> Paris Lyon Marseille o pour les communes associées au sein d'une même
>> commune; le niveau 10 pour des quartiers réels, mais pas pour un découpage
>> quasi parcellaire comme ici.
>>
>> Note: je ne m'adresse pas spécifiquement à cet auteur (il peut
>> s'exprimer; je ne lui tape pas dessus et il peut avoir des intentions
>> louables), si sur le fait que ce découpage soit incomplet, mais juste sur
>> la question de la pertinence de ces données (pérennité, adéquation à une
>> utilisation par exemple pour des plans immobiliers) et surtout de leur
>> classification, pour que cela ne nuise pas aux autres utilisations des
>> données (j'ai peur que ça pollue les recherches de Nominatim par exemple,
>> ou que cela nuise à la recherche d'adresses et lieux-dits, liée au projet
>> BANO).
>>
>> Le risque de conserver ce découpage au niveau admin 10 c'est la confusion
>> qui pourrait naitre du fait de l'association de communes voisines, o

Re: [OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[Jérôme Seigneuret]

Ok David merci pour l'info

Le 15 octobre 2014 13:22, David Crochet  a écrit :

> Bonjour
>
> Le 15/10/2014 11:05, Jérôme Seigneuret a écrit :
>
>> d'ailleurs c'est bizarre car aucun tracé n'est fermé vu que le nom est
>> sur le tracé
>>
>
> ce ne sont que des relations
>
> Cordialement
> --
> David Crochet
>
>
> ___
> 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] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[David Crochet]

Bonjour

Le 15/10/2014 11:05, Jérôme Seigneuret a écrit :

d'ailleurs c'est bizarre car aucun tracé n'est fermé vu que le nom est
sur le tracé


ce ne sont que des relations

Cordialement
--
David Crochet

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

Re: [OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[Jérôme Seigneuret]

Les zones dont tu parles pour moi c'est pas du boundary, c'est du découpage
cadastre des lieu-dits (voisinage dans un village ou quartier en ville ou
hameau) En principe moi je fais juste un noeud toponyme mais on peu faire
des zones toponymes et faire le lien vers le nom du contour administratif
en question. d'ailleurs c'est bizarre car aucun tracé n'est fermé vu que le
nom est sur le tracé

on peut mettre un is_in=* pour lier avec le boundary de la commune
certains font des landuse= residential mais je trouve ça pourri pour  faire
des toponymes. Moi je préfère juste faire comme ici :
http://www.openstreetmap.org/way/277831410 au pire ne pas mettre le nom
dans le polygone mais sur un noeud et les lier si besoin...(il y a
peut-être mieux)

Le landuse est un autre objet pour moi. Mais je vais pas revenir sur ça
c'est pas le sujet.

Pour réparer moi je fais ça dans JOSM en important que le tronçon boundary
en question par son id et en important uniquement les relations. Après en
cas de problèmes JOSM demande de corriger les incohérence avant de faire la
sauvegarde. J'avais fait une connerie de ce type sur Montpellier. J'ai
juste refermé le way et fini.

En même temps iD fou un peu la merde:
 Si tu coupes un polygon pour en faire deux il coupe toute les relations et
ça ressemble un peu à ce que tu présentes.




Le 15 octobre 2014 10:14, Philippe Verdy  a écrit :

> En tentant de corriger des erreurs de frontières incomplètes dans Osmose,
> je me suis aperçu que la Ferté-Macé (en Mayenne) est découpé dans ce qui ne
> ,e semble pas être des quartiers mais des noms de parcelles (ou groupes de
> parcelles). Y compris des parcelles homonymes et limitrophes l'une de
> l'autre.
> Les noms sont parfois des lieux-dits, ou des noms de rues.
>
> Exemple autour de ceci:
>
> http://www.openstreetmap.org/way/306246629
>
> Le chemin est isolé mais la frontière n'est pas fermée (il n'est encore
> dans aucune relation mais a déjà un tag admin_level 10), et la commune
> n'est visiblement pas entièrement découpée, je ne vois pas comment corriger
> ces relations "administrative" pour les fermer correctement, et comment les
> retaguer correctement si ce n'est pas administratif.
>
> Pour l'instant je n'ai rien supprimé (ce tracé est tout demême complexe
> pour une seule commune), juste levé quelques anomalies géométriques pour
> vérifier la cohérence de ce découpage dont la classification reste tout de
> même à revoir si on doit garder ce découpage pour une certaine utilité (il
> ne me semble pas qu'il soi approprié pour les lieux-dits). Je me demande
> d'où ce découpage est issu : est-ce que c'est le découpage des zones
> cadastrales ? L'auteur comptait-il poursuivre ensuite avec les parcelles
> individuelles ?
>
> Jusqu'à présent on utilisait le niveau 9 pour les arrondissements de Paris
> Lyon Marseille o pour les communes associées au sein d'une même commune; le
> niveau 10 pour des quartiers réels, mais pas pour un découpage quasi
> parcellaire comme ici.
>
> Note: je ne m'adresse pas spécifiquement à cet auteur (il peut s'exprimer;
> je ne lui tape pas dessus et il peut avoir des intentions louables), si sur
> le fait que ce découpage soit incomplet, mais juste sur la question de la
> pertinence de ces données (pérennité, adéquation à une utilisation par
> exemple pour des plans immobiliers) et surtout de leur classification, pour
> que cela ne nuise pas aux autres utilisations des données (j'ai peur que ça
> pollue les recherches de Nominatim par exemple, ou que cela nuise à la
> recherche d'adresses et lieux-dits, liée au projet BANO).
>
> Le risque de conserver ce découpage au niveau admin 10 c'est la confusion
> qui pourrait naitre du fait de l'association de communes voisines, ou d'une
> réelle division administrative pour les services intercommunaux (comme à
> Nantes avec ses "pôles de proximité" au sein de la métropole) qui sera
> nettement plus utile à mon avis.
>
> Si cela représente des zones cadastrales, cela pourrait être utile à plus
> grande échelle mais je pense qu'avant ça on aimerait plutôt avoir d'abord
> le découpage INSEE des IRIS (les deux projets ne sont pas incompatibles et
> peuvent coexister), à condition de décider des bons tags à utiliser:
>
> En Espagne ils ont des découpages sous-communaux très détaillés pour les
> "unités de population" (traduction approchante, le terme exact varie selon
> les communautés autonomes ou villes), et ça sert de brique de base pour les
> statistiques économiques, les découpages électoraux (par exemple bureaux de
> vote) ou la fiscalité locale (taux d'imposition foncière ou locative), les
> plans et règlements d'urbanisme, la gestion des réseaux publics et des
> ressources...
>
> En France on a encore du mal avec
> - les IRIS dont l'usage est encore mal maitrisé (boundary=statistical)- On
> aimerait avoir des données exploitables dessus.
> - le découpage pour les opérations électorales des bureaux de vote
> (boundary=electoral)
> - le zonage urbain légal (celui q

[OSM-talk-fr] découpage "administratif" niveau 10 à la Ferté-Macé (Mayenne)

[Philippe Verdy]

En tentant de corriger des erreurs de frontières incomplètes dans Osmose,
je me suis aperçu que la Ferté-Macé (en Mayenne) est découpé dans ce qui ne
,e semble pas être des quartiers mais des noms de parcelles (ou groupes de
parcelles). Y compris des parcelles homonymes et limitrophes l'une de
l'autre.
Les noms sont parfois des lieux-dits, ou des noms de rues.

Exemple autour de ceci:

http://www.openstreetmap.org/way/306246629

Le chemin est isolé mais la frontière n'est pas fermée (il n'est encore
dans aucune relation mais a déjà un tag admin_level 10), et la commune
n'est visiblement pas entièrement découpée, je ne vois pas comment corriger
ces relations "administrative" pour les fermer correctement, et comment les
retaguer correctement si ce n'est pas administratif.

Pour l'instant je n'ai rien supprimé (ce tracé est tout demême complexe
pour une seule commune), juste levé quelques anomalies géométriques pour
vérifier la cohérence de ce découpage dont la classification reste tout de
même à revoir si on doit garder ce découpage pour une certaine utilité (il
ne me semble pas qu'il soi approprié pour les lieux-dits). Je me demande
d'où ce découpage est issu : est-ce que c'est le découpage des zones
cadastrales ? L'auteur comptait-il poursuivre ensuite avec les parcelles
individuelles ?

Jusqu'à présent on utilisait le niveau 9 pour les arrondissements de Paris
Lyon Marseille o pour les communes associées au sein d'une même commune; le
niveau 10 pour des quartiers réels, mais pas pour un découpage quasi
parcellaire comme ici.

Note: je ne m'adresse pas spécifiquement à cet auteur (il peut s'exprimer;
je ne lui tape pas dessus et il peut avoir des intentions louables), si sur
le fait que ce découpage soit incomplet, mais juste sur la question de la
pertinence de ces données (pérennité, adéquation à une utilisation par
exemple pour des plans immobiliers) et surtout de leur classification, pour
que cela ne nuise pas aux autres utilisations des données (j'ai peur que ça
pollue les recherches de Nominatim par exemple, ou que cela nuise à la
recherche d'adresses et lieux-dits, liée au projet BANO).

Le risque de conserver ce découpage au niveau admin 10 c'est la confusion
qui pourrait naitre du fait de l'association de communes voisines, ou d'une
réelle division administrative pour les services intercommunaux (comme à
Nantes avec ses "pôles de proximité" au sein de la métropole) qui sera
nettement plus utile à mon avis.

Si cela représente des zones cadastrales, cela pourrait être utile à plus
grande échelle mais je pense qu'avant ça on aimerait plutôt avoir d'abord
le découpage INSEE des IRIS (les deux projets ne sont pas incompatibles et
peuvent coexister), à condition de décider des bons tags à utiliser:

En Espagne ils ont des découpages sous-communaux très détaillés pour les
"unités de population" (traduction approchante, le terme exact varie selon
les communautés autonomes ou villes), et ça sert de brique de base pour les
statistiques économiques, les découpages électoraux (par exemple bureaux de
vote) ou la fiscalité locale (taux d'imposition foncière ou locative), les
plans et règlements d'urbanisme, la gestion des réseaux publics et des
ressources...

En France on a encore du mal avec
- les IRIS dont l'usage est encore mal maitrisé (boundary=statistical)- On
aimerait avoir des données exploitables dessus.
- le découpage pour les opérations électorales des bureaux de vote
(boundary=electoral)
- le zonage urbain légal (celui qui définit les limites d'agglomérations
selon les distances maximales entre bâtiments et au delà les poles urbains;
boundary=urban?),
- les bassins d'emploi (pas nécessairement les mêmes découpages que les
intercommunalités et syndicats mixtes)
la carte scolaire publique, le zonage des services sociaux et
médico-hospitalier, le
- le découpage judiciaire des tribunaux (boundary=judiciary, comme en
Belgique),
- le découpage des secteurs de police (révisé avec police et gendarmerie,
plus fin que le découpage judiciaire avec des secteurs sur plusieurs
secteurs judiciaires)
- les régions de défense nationale (boundary=military),
- le découpage civil des régions aériennes autour des centres de contrôle
aérien (boundary=aerial?),
- les limites de compétence des ports autonomes (définis par décret depuis
1961, étendus vers 2003, et indépendant des intercommunalités),
- les zones franches (quel tags?)
- etc.

Et tout ça bien avant le découpage historique des anciennes planches
cadastrales (pour ensuite y numéroter les parcelles et le calcul des taxes
foncières ou la gestion des domaines publics locaux ou nationaux, ou la
gestion des concessions publiques au privé; y compris les mines, forages et
conduites de transport d'eau et d'énergie) d'avant leur numérisation (OSM
n'ayant pas vocation non plus à remplacer le cadastre pour ses aspects
légaux et réglementaires dans des opérations de cession immobilière, les
successions, la fiscalité, les plans d'urbanisme légaux et les permis de
construire,