Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-26 Par sujet Philippe Verdy 
Le 26 janvier 2012 23:49, Vincent de Chateau-Thierry
 a écrit :
>
>
> Le 26/01/2012 23:08, Philippe Verdy a écrit :
>
>
>>
>> JAMAIS je n'ai voulu supprimer des frontières, je les ai toutes
>> laissées (j'ai fait un seul test uniquement du boundary_segment sur la
>> côte nord de l'Ille-et-Vilaine et j'attendais de voir le résultat, car
>> il y avait déjà des boundary_segments incohérents et très difficiles à
>> mettre à jour, pour la frontière française, que le serveur peine
>> énormément à gérer et que chaque édition locale sur la côte nécessite
>> un chargement énorme de données et de pénibles synchonisations de
>> dizaines de milliers de noeuds: les boundary_segments de la France
>> sont trop acutellement beaucoup longs, et même si on décide de garder
>> les ways pour les côtes de l'Ille-et-Vilaine, les segments de
>> frontière frontçaise par départements sont à privilégier au niveau de
>> la zone France, afin de soulager le travail: c'est un redécoupage plus
>> fin qui ne change pas le modèle actuel pour la France; mais il reste
>> que le problème est aussi ardu pour la Bretagne).
>
>
> Le fait de splitter les limites côtières (et uniquement elles) françaises en
> relations "boundary_segment" à raison d'une relation par département, a déjà
> été discuté ici et admis. J'avais proposé de m'en occuper et je ne l'ai pas
> fait :
> http://lists.openstreetmap.org/pipermail/talk-fr/2011-November/037663.html
> Tu peux prendre le relais.
> À noter qu'il existe déjà un boundary_segment pour les Côtes d'Armor :
> http://www.openstreetmap.org/browse/relation/1846740
> créé de mon côté en guise de test,
> et un autre créé par toi pour l'Ille-et-Vilaine, et auquel je n'ai pas
> touché en "réparant" le contour de ce département hier :
> http://www.openstreetmap.org/browse/relation/1979939
>
> Donc pour la Bretagne, on ne part pas de rien.

OK, donc je vais continuer à ajouter les splits départementaux, pour
qu'enfin on puisse remplacer les segments trop grands de la frontière
française (pour l'instant ils restent là), par les segments
départementaux.

Mais que faire alors de la frontière de la région Bretagne elle-même
(très compliqué ?) peut-on la splitter en utilisant alors les segments
départementaux qu'on aura créés ??

Dernier point: je ne suis pas le seul à vouloir utiliser les subareas
(même si on n'en a pas besoin pour dessiner une surface): regardez par
exemple la Belgique et l'Espagne, qui les utilisent comme métadonnées
intégrées directement dans les mêmes relations de frontières (et PAS
dans des relations différentes).

Je n'ai jamais nié l'intérêt de la définition par frontières (quoique
l'absence de support partout des boundary_segments pose encore
problème).

Je ne l'ai jamais remise en cause, pas même lors de mon essai
d'utiliser le boundary_segment de la côte nord l'Ille-et-Vilaine, au
lieu de dupliquer les ways comme on ne fait encore, avec toutes les
incohérences que cela génère quand les différents niveaux ne sont pas
mis en jour en même temps, ce qui n'est franchement pas facile à faire
pour les hauts niveaux qui contiennent des centaines de ways
désordonnées et anonymes, raison pour laquelle je me bat en permanence
pour essayer de les faire apparaitre comme formant des boucles
complètes, afin d'identifier les ways à ajouter ou supprimer de la
relation mère  !)

On est pas les seuls en France à avoir ces incohérences (les Allemands
se plaignent, et les Anglais aussi surement, mais je n'ai pas regardé
si eux aussi utilisaient les subareas pour faciliter la maintenance
des ways de toutes les relations de niveau inférieur quand une petite
zone locale a été modifié...).

Les Belges utilisent les subareas avec un outil qui se charge tout
seul de reconstruire les frontières de niveau inférieur, lorsqu'une
plus petite zone de niveau supérieure est modifiée: pas d'incohérence
(sauf temporairement: le robot fait le travail bien mieux qu'un
humain, sans erreur). Ils l'utilisent aussi pour faciliter l'import de
données externes (depuis des bases de données qui n'ont strictement
AUCUNE définition géolocalisée permettant la recherche des
sous-zones).

Cette automatisation des "remontées" de frontières automatisées est
justement possible dès qu'une zone est entièrement partitionnée en
zones filles.

S'il manque des tracés, ce n'est pas du tout un problème: la zone est
marquée comme non encore partitionnée ou contient des "FIXME" pour les
zones manquantes (que strictement rien n'empêche de créer
immédiatement même sans encore aucune frontière définie, afin de
permettre justement des imports externes des données géolocalisées qui
manquent: on crée la zone sans frontières, ou avec une frontière
incomplète pas encore fermée, on la référence avec un "subarea", et on
avance...).

Ceux qui travaillent sur le dessin d'un niveau (et ont un accès direct
à des bases OpenData ou qui aiment dessiner des frontières précises
verront ces manques de frontières suffisantes (qui sont signalés par
nos outils).


Notez que la défi

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-26 Par sujet Vincent de Chateau-Thierry 



Le 26/01/2012 23:08, Philippe Verdy a écrit :



JAMAIS je n'ai voulu supprimer des frontières, je les ai toutes
laissées (j'ai fait un seul test uniquement du boundary_segment sur la
côte nord de l'Ille-et-Vilaine et j'attendais de voir le résultat, car
il y avait déjà des boundary_segments incohérents et très difficiles à
mettre à jour, pour la frontière française, que le serveur peine
énormément à gérer et que chaque édition locale sur la côte nécessite
un chargement énorme de données et de pénibles synchonisations de
dizaines de milliers de noeuds: les boundary_segments de la France
sont trop acutellement beaucoup longs, et même si on décide de garder
les ways pour les côtes de l'Ille-et-Vilaine, les segments de
frontière frontçaise par départements sont à privilégier au niveau de
la zone France, afin de soulager le travail: c'est un redécoupage plus
fin qui ne change pas le modèle actuel pour la France; mais il reste
que le problème est aussi ardu pour la Bretagne).


Le fait de splitter les limites côtières (et uniquement elles) 
françaises en relations "boundary_segment" à raison d'une relation par 
département, a déjà été discuté ici et admis. J'avais proposé de m'en 
occuper et je ne l'ai pas fait :

http://lists.openstreetmap.org/pipermail/talk-fr/2011-November/037663.html
Tu peux prendre le relais.
À noter qu'il existe déjà un boundary_segment pour les Côtes d'Armor :
http://www.openstreetmap.org/browse/relation/1846740
créé de mon côté en guise de test,
et un autre créé par toi pour l'Ille-et-Vilaine, et auquel je n'ai pas 
touché en "réparant" le contour de ce département hier :

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

Donc pour la Bretagne, on ne part pas de rien.

vincent

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-26 Par sujet Philippe Verdy 
Le 26 janvier 2012 10:57, Pieren  a écrit :
> 2012/1/26 Philippe Verdy :
>
>> il peut alors de façon paliative
>> (uniquement paliative) utiliser l'autre axe vertical (surfaces,
>> "subareas").
>
> Dans tes arguments, tu parts toujours du principe que la relation
> "boundary" est parfois incomplète, ce qui induit ensuite Nominatim en
> erreur. Mais la même chose peut arriver dans le modèle surfacique. La
> relation peut manquer un subarea, une commune ou un département. Ou en
> avoir en trop. On ne peut jamais garantir l'intégrité des données. Et
> si un modèle diffère de l'autre (par exemple, une île qui serait dans
> l'un mais pas dans l'autre), il est impossible de savoir
> automatiquement qui a raison et qui a tord. Il faudra donc toujours
> passer par un contrôle manuel en cas de problème.
> Tu peux écrire des mails de 25 pages, tu n'as toujours pas démontré en
> quoi le modèle "subarea" n'est pas équivalent au modèle "boundary"
> actuel pour définir un multipolygone. Au contraire, comme d'autres
> l'ont déjà dit, le modèle surfacique ne marche que lorsque l'ensemble
> des subarea est défini.

C'est faux ! On peut très bien créer une nouvelle relation de
frontières avec un membre subarea ajouté à la zone plus grande, sans
avoir pour l'instant l'ensemble de ses frontières, mais par exemple
juste un admin_center. On la crée rapidement, avec les autres
métadonnées, on ajoute un fixme pour les frontières manquantes (ou
approximatives à redessiner avec une source cadastrale).

Cela ne remplace PAS le tracé des frontières. Et jamais je n'ai
défendu cette position.

> Hors, de nombreuses régions en France n'ont
> pas encore toutes leurs limites communales.

Justement c'est le cas en Mayenne, où il manquait aussi les 3
arrondissements que je suis en train d'ajouter SANS supprimer aucune
frontière. Les frontières restent là, je n'ai rien changé là-dessus.

C'est pour cela que le
> modèle "boundary" a toujours été préféré dans OSM jusqu'à aujourd'hui.

> Si tu ne peux pas vivre sans relations de type surfacique et
> pyramidal, soit, mais pas dans la même relation de type "boundary". Si
> tu penses que les deux peuvent se compléter, rien ne t'empêche de
> sélectionner l'une ou l'autre en fonction de l'attribut "type=*" (les
> tags "name" et "admin_level" pouvant être identiques).

Pas dans la même relation ? Tout l'intérêt est perdu car cela revient
à dédoubler toutes les relations filles, sans permettre de mettre un
seul lien avec l'autre relation par frontières, alors qu'il suffit
d'ajouter dans la relation mère UN SEUL membre par relation contenue
dans une autre.

Le volume de données  est négligeable au regard des données des
frontières: pas de relation en double portant les mêmes noms, les
mêmes références INSEE, NUTS ou autre, aucun besoin de modifier les
frontières ou de les doublonner. Ta solution serait pire car alors il
y aurait ambuiguité sur la relation à mettre à jour par des outils de
recherche externe, si on trouve deux relations avec le même type, les
mêmes tags (de référence) et les mêmes admin_level ! Alors que cela
désigne strictement le même objet... Où est le modèle relationnel dans
tout ça ???

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-26 Par sujet sly (sylvain letuffe) 
Le jeudi 26 janvier 2012 23:08:18, Philippe Verdy a écrit :
> Non, désolé, le stop concernait le seul test du bounary_segment.

Alors je m'excuse si je n'ai pas été clair, mais maintenant que tout est 
clarifié tout va bien, l'incident est clos concernant les role:subarea, on n'en 
veut pas.

Ce qui n'empêche pas, comme on a pu le dire que tu créés, si tu le veux, des 
relations différentes, avec un autre type=bidule sur le modèle subarea.

Pour les type=boundary_segment, pour l'instant, restons avec les contours de 
la france (contraintes techniques obligent) nous passerons peut-être, 
ultérieurement à des niveau régions et départements.

> (...)

Sans vouloir te vexer, ni m'abaisser de trop à m'attarder sur la forme de tes 
emails, tu as souvent des points valident à avancer, des idées pertinentes à 
défendre, que tu noies dans un terrible flot trop long de paroles qui répète 
plusieurs fois ce que tu as déjà dis et finissent à mon avis par desservir les 
idées qui s'y cachent. Ce qui est dommage.

-- 
sly (sylvain letuffe)


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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-26 Par sujet Philippe Verdy 
Mon dernier changset en contient encore, mais dans mes données
locales, je les ai toutes supprimées, et je suis en train de mettre à
jour les conflits éventuels pour qu'ils ne soient plus là: ceci
terminé, il ne devrait plus en rester.

Ce n'est pas mon intention de faire un edit war.

Je trouve dommage que vous ne considériez pas cela comme une
métadonnée qui ne change rien à vos méthodes, et qui pourant facilite
le contrôle d'adhérence des frontières entre les niveaux (un contrôle
actuellement totalement inexistant dans OSM, et qui a conduit à des
aberrhations dans les tests d'inclusion d'une surface dans une autre,
que je me proposais de résoudre facilement avec ces métadonnées qui
facilitent ce contrôle, même si vous n'en avez pas besoin pour
travailler sur les frontières d'un niveau donné.

Sans le contrôle d'adhérence, impossible de corriger les résultats
farfelus (très nombreux) produits par l'heuristique de Nominatim (et
ailleurs...). Je voudrais que vous vous en rendiez compte !
Franchement je ne vois pas du tout ce qui vous gênait dans ces
métadonnées (les quelques membres supplémentaires de rôle "subarea").

Et impossible d'intégrer des métadonnées externes hiérachisées qui ne
trouvent pas les zones s'il n'y a pas d'adhérence avec le SEUL modèle
spacial. Par exemple, le récent import des noms de communes bretonnes
n'a pas trouvé ces tas de communes qui pourtant étaient sur les
cartes. Difficile de mettre à jour des chiffres de population, des
données administratives à l'échelle d'un pays (trop de données à
charger depuis le serveur qui refuse alors les requêtes trop
volumineuses).

Je vous ai expliqué l'intérêt, sincèrement c'était des métadonnées
très utiles aussi à contrôler (et corriger) la cohérence des cartes
des différents niveaux, et qui évitent d'importer des données
cartographiques au mauvais endroit ou de créer des objets en doublon
(qui alors se superposent et compliquent la tâche des éditeurs).

Le 26 janvier 2012 17:42, Vincent de Chateau-Thierry
 a écrit :
>
>> De : "sly (sylvain letuffe)"
>
>>
>> > Les éditions ont continué cette nuit, pour propager des subarea :
>> > http://www.openstreetmap.org/browse/changeset/10499268
>>
>> Bordel de p de foutage de gueule
>>
>> Ho, on a dit stop !
>>
>> > Cette fois-ci, ce sont les Pays-de-Loire. Sly, je ne sais pas quelle était
>> > la teneur
>> > de ton mail, mais manifestement ça n'aura pas suffit à stopper la démarche
>> > de verdy_p.
>>
>> Il était COURT (contrairement aux discours fleuve qu'on a pu voir ces 
>> derniers
>> temps), précis, clair et diplomatique. Mais il disait en 3 lignes : STOP
>>
>> Et comme il a lu notre discussion vu qu'il y a répondu (encore que je ne sois
>> pas sûr que ça suffise à prouver qu'il l'ait lu), on ne peut plus supposer la
>> non information.
>>
>> La diplomatie et la discussion n'ayant pas suffit, j'ai peur que l'edit war 
>> ne
>> soit plus très loin.
>>
>> Et, comme OSM dispose de fonctions d'annulation extrêmement simples à 
>> utiliser
>> et extrêmement efficace (j'ironise), on peut parier sur soit des dommage
>> collatéraux, soit sur des suppressions par erreur, soit sur plus de problèmes
>> encore.
>>
>> Voici mon dernier message envoyé, j'espère qu'on va en rester là, Philippe, 
>> ça
>> ne m'amuse pas du tout, please, stop !
>> 
>> re moi,
>>
>> Hé ho, on a dit : STOP pour les subarea, on a pour l'instant été correct,
>> discuté correctement et on est tous d'accord sauf toi pour continuer.
>>
>> Il ne te semble pas que ta manière de faire ne peut que dégénérer ?
>>
>> Alors passons à autre chose, c'est triste, mais c'est une menace.
>>
>> Il n'y aura pas d'autre sommation, soit tu t'arrêtes, soit je fais la demande
>> de bannir ton compte, et en attendant j'annule tous les changesets que tu
>> fera par un logiciel et tout le monde y perdra du temps et ça ne peut que
>> finir en EDIT war avec des pertes tristes.
>>
>> Comme en plus tu sembles t'y connaître en développement (d'après tes mails),
>> et que pas de chance, moi aussi, ça ne peut que être néfaste à tout le monde
>> et potentiellement violent.
>>
>> Alors, s'il te plait, arrêtes.
>>
>> --
>> sly
>> ***
>>
>
> J'ai procédé dans ce changeset :
> http://www.openstreetmap.org/browse/changeset/10504679
> à la suppression des membres de type "subarea" de quelques relations 
> régionales,
> départementales, voire communales (Paris). Je ne garantis pas qu'il n'en 
> reste pas
> ailleurs.
> C'est clairement triste d'en arriver à ce type d'action. Le message de Sly 
> donnait
> pourtant une image claire de la situation et des risques encourus. En 
> espérant qu'on
> passe rapidement (et sereinement :-) ) à autre chose !
>
> vincent
>
> Une messagerie gratuite, garantie à vie et des services en plus, ça vous 
> tente ?
> Je crée ma boîte mail www.laposte.net
>
> ___
> Talk-fr mailing list
> Talk-fr@openstr

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-26 Par sujet Philippe Verdy 
Non, désolé, le stop concernait le seul test du bounary_segment.
J'avais demandé des explications sur ce qui ne fonctionnait pas, et je
n'en ai pas ajoutés.
Pour le reste je n'ai strictement rien cassé avec les subareas, et
personne ne l'a démontré.
OK j'ai fait un test, mais il n'a pas été un échec.

Ce n'est QUE maintenant qu'on me dit stop sur les subareas et que vous
les enlevez. C'est dommage, car vous les enlevez sans avoir signalé
quel problème était causé. Alors que j'ai voulu montrer les problèmes
que causent leur absence.

JAMAIS je n'ai voulu supprimer des frontières, je les ai toutes
laissées (j'ai fait un seul test uniquement du boundary_segment sur la
côte nord de l'Ille-et-Vilaine et j'attendais de voir le résultat, car
il y avait déjà des boundary_segments incohérents et très difficiles à
mettre à jour, pour la frontière française, que le serveur peine
énormément à gérer et que chaque édition locale sur la côte nécessite
un chargement énorme de données et de pénibles synchonisations de
dizaines de milliers de noeuds: les boundary_segments de la France
sont trop acutellement beaucoup longs, et même si on décide de garder
les ways pour les côtes de l'Ille-et-Vilaine, les segments de
frontière frontçaise par départements sont à privilégier au niveau de
la zone France, afin de soulager le travail: c'est un redécoupage plus
fin qui ne change pas le modèle actuel pour la France; mais il reste
que le problème est aussi ardu pour la Bretagne).

Je ne vois pas où est « l'editwar » pour des propriétés ajoutées (les
subareas documentés) qui n'ôte rien à la modélisation dans la
direction horizontale que je n'ai JAMAIS voulu supprimer. A côté de
cela, on ajoute des tas d'autres tags et propriétés qui sont ignorées
par un logiciel ou un autre, et ces subareas ne sont que des
propriétés de plus, même si vous voulez continuer à travailler
uniquement au niveau frontières (malgré l'intérêt de l'autre direction
modélisation par surfaces qui assure aussi une meilleure compatibilité
avec des sources externes qui peinent énormément à intégrer leurs
données).

JE ne vais pas en remettre (attention j'ai une sauvegarde en cours et
des conflits de sauvegarde, sur des modifs non encore fermées à
l'heure actuelle: j'en profite pour supprimer les subareas qui y sont
encore, sur la Mayenne: mon intention n'est pas de les remettre, mais
je viens seulement de lire cet ORDRE, même si je ne comprends pas
votre réaction aussi virulente).

Le 26 janvier 2012 17:42, Vincent de Chateau-Thierry
 a écrit :
>
>> De : "sly (sylvain letuffe)"
>
>>
>> > Les éditions ont continué cette nuit, pour propager des subarea :
>> > http://www.openstreetmap.org/browse/changeset/10499268
>>
>> Bordel de p de foutage de gueule
>>
>> Ho, on a dit stop !
>>
>> > Cette fois-ci, ce sont les Pays-de-Loire. Sly, je ne sais pas quelle était
>> > la teneur
>> > de ton mail, mais manifestement ça n'aura pas suffit à stopper la démarche
>> > de verdy_p.
>>
>> Il était COURT (contrairement aux discours fleuve qu'on a pu voir ces 
>> derniers
>> temps), précis, clair et diplomatique. Mais il disait en 3 lignes : STOP
>>
>> Et comme il a lu notre discussion vu qu'il y a répondu (encore que je ne sois
>> pas sûr que ça suffise à prouver qu'il l'ait lu), on ne peut plus supposer la
>> non information.
>>
>> La diplomatie et la discussion n'ayant pas suffit, j'ai peur que l'edit war 
>> ne
>> soit plus très loin.
>>
>> Et, comme OSM dispose de fonctions d'annulation extrêmement simples à 
>> utiliser
>> et extrêmement efficace (j'ironise), on peut parier sur soit des dommage
>> collatéraux, soit sur des suppressions par erreur, soit sur plus de problèmes
>> encore.
>>
>> Voici mon dernier message envoyé, j'espère qu'on va en rester là, Philippe, 
>> ça
>> ne m'amuse pas du tout, please, stop !
>> 
>> re moi,
>>
>> Hé ho, on a dit : STOP pour les subarea, on a pour l'instant été correct,
>> discuté correctement et on est tous d'accord sauf toi pour continuer.
>>
>> Il ne te semble pas que ta manière de faire ne peut que dégénérer ?
>>
>> Alors passons à autre chose, c'est triste, mais c'est une menace.
>>
>> Il n'y aura pas d'autre sommation, soit tu t'arrêtes, soit je fais la demande
>> de bannir ton compte, et en attendant j'annule tous les changesets que tu
>> fera par un logiciel et tout le monde y perdra du temps et ça ne peut que
>> finir en EDIT war avec des pertes tristes.
>>
>> Comme en plus tu sembles t'y connaître en développement (d'après tes mails),
>> et que pas de chance, moi aussi, ça ne peut que être néfaste à tout le monde
>> et potentiellement violent.
>>
>> Alors, s'il te plait, arrêtes.
>>
>> --
>> sly
>> ***
>>
>
> J'ai procédé dans ce changeset :
> http://www.openstreetmap.org/browse/changeset/10504679
> à la suppression des membres de type "subarea" de quelques relations 
> régionales,
> départementales, voire communales (Paris). Je ne gara

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-26 Par sujet Vincent de Chateau-Thierry 

> De : "sly (sylvain letuffe)" 

> 
> > Les éditions ont continué cette nuit, pour propager des subarea :
> > http://www.openstreetmap.org/browse/changeset/10499268
> 
> Bordel de p de foutage de gueule
> 
> Ho, on a dit stop !
> 
> > Cette fois-ci, ce sont les Pays-de-Loire. Sly, je ne sais pas quelle était
> > la teneur 
> > de ton mail, mais manifestement ça n'aura pas suffit à stopper la démarche
> > de verdy_p. 
> 
> Il était COURT (contrairement aux discours fleuve qu'on a pu voir ces 
> derniers 
> temps), précis, clair et diplomatique. Mais il disait en 3 lignes : STOP
> 
> Et comme il a lu notre discussion vu qu'il y a répondu (encore que je ne sois 
> pas sûr que ça suffise à prouver qu'il l'ait lu), on ne peut plus supposer la 
> non information.
> 
> La diplomatie et la discussion n'ayant pas suffit, j'ai peur que l'edit war 
> ne 
> soit plus très loin.
> 
> Et, comme OSM dispose de fonctions d'annulation extrêmement simples à 
> utiliser 
> et extrêmement efficace (j'ironise), on peut parier sur soit des dommage 
> collatéraux, soit sur des suppressions par erreur, soit sur plus de problèmes 
> encore.
> 
> Voici mon dernier message envoyé, j'espère qu'on va en rester là, Philippe, 
> ça 
> ne m'amuse pas du tout, please, stop !
> 
> re moi,
> 
> Hé ho, on a dit : STOP pour les subarea, on a pour l'instant été correct, 
> discuté correctement et on est tous d'accord sauf toi pour continuer.
> 
> Il ne te semble pas que ta manière de faire ne peut que dégénérer ?
> 
> Alors passons à autre chose, c'est triste, mais c'est une menace.
> 
> Il n'y aura pas d'autre sommation, soit tu t'arrêtes, soit je fais la demande 
> de bannir ton compte, et en attendant j'annule tous les changesets que tu 
> fera par un logiciel et tout le monde y perdra du temps et ça ne peut que 
> finir en EDIT war avec des pertes tristes.
> 
> Comme en plus tu sembles t'y connaître en développement (d'après tes mails), 
> et que pas de chance, moi aussi, ça ne peut que être néfaste à tout le monde 
> et potentiellement violent.
> 
> Alors, s'il te plait, arrêtes.
> 
> --
> sly
> ***
> 

J'ai procédé dans ce changeset :
http://www.openstreetmap.org/browse/changeset/10504679
à la suppression des membres de type "subarea" de quelques relations régionales,
départementales, voire communales (Paris). Je ne garantis pas qu'il n'en reste 
pas
ailleurs. 
C'est clairement triste d'en arriver à ce type d'action. Le message de Sly 
donnait
pourtant une image claire de la situation et des risques encourus. En espérant 
qu'on
passe rapidement (et sereinement :-) ) à autre chose !

vincent

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

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-26 Par sujet sly (sylvain letuffe) 

> Les éditions ont continué cette nuit, pour propager des subarea :
> http://www.openstreetmap.org/browse/changeset/10499268

Bordel de p de foutage de gueule

Ho, on a dit stop !

> Cette fois-ci, ce sont les Pays-de-Loire. Sly, je ne sais pas quelle était
> la teneur 
> de ton mail, mais manifestement ça n'aura pas suffit à stopper la démarche
> de verdy_p. 

Il était COURT (contrairement aux discours fleuve qu'on a pu voir ces derniers 
temps), précis, clair et diplomatique. Mais il disait en 3 lignes : STOP

Et comme il a lu notre discussion vu qu'il y a répondu (encore que je ne sois 
pas sûr que ça suffise à prouver qu'il l'ait lu), on ne peut plus supposer la 
non information.

La diplomatie et la discussion n'ayant pas suffit, j'ai peur que l'edit war ne 
soit plus très loin.

Et, comme OSM dispose de fonctions d'annulation extrêmement simples à utiliser 
et extrêmement efficace (j'ironise), on peut parier sur soit des dommage 
collatéraux, soit sur des suppressions par erreur, soit sur plus de problèmes 
encore.

Voici mon dernier message envoyé, j'espère qu'on va en rester là, Philippe, ça 
ne m'amuse pas du tout, please, stop !

re moi,

Hé ho, on a dit : STOP pour les subarea, on a pour l'instant été correct, 
discuté correctement et on est tous d'accord sauf toi pour continuer.

Il ne te semble pas que ta manière de faire ne peut que dégénérer ?

Alors passons à autre chose, c'est triste, mais c'est une menace.

Il n'y aura pas d'autre sommation, soit tu t'arrêtes, soit je fais la demande 
de bannir ton compte, et en attendant j'annule tous les changesets que tu 
fera par un logiciel et tout le monde y perdra du temps et ça ne peut que 
finir en EDIT war avec des pertes tristes.

Comme en plus tu sembles t'y connaître en développement (d'après tes mails), 
et que pas de chance, moi aussi, ça ne peut que être néfaste à tout le monde 
et potentiellement violent.

Alors, s'il te plait, arrêtes.

--
sly
***
-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-26 Par sujet Vincent de Chateau-Thierry 
Bonjour,

> De : "sly (sylvain letuffe)" 

>
> On mercredi 25 janvier 2012, sly (sylvain letuffe) wrote:
> > On mercredi 25 janvier 2012, Pieren wrote:
> > > Et donc on ne fait rien ? Alors que tout le monde à part l'auteur des
> > > modifs semble d'accord pour une séparation des modèles dans des
> > > relations différentes à minima ?
> > 
> > Je vote bien évidement pour le retour arrière sur ces relations comme la 
> > majorité des exprimés et laisse loisir à ceux qui défendent ce modèle de le 
> > créer, mais de manière séparé et isolé.
> > 
> > Visiblement, la nuit été chargée en modification, je lui envoi un email 
> > pour 
> > lui demander s'il peut les retirer, ce sera plus simple car il sait quelles 
> > modifications il a fait.
> 
> Pardon, je viens de lui envoyer le mail.
> 

Les éditions ont continué cette nuit, pour propager des subarea :
http://www.openstreetmap.org/browse/changeset/10499268
Cette fois-ci, ce sont les Pays-de-Loire. Sly, je ne sais pas quelle était la 
teneur
de ton mail, mais manifestement ça n'aura pas suffit à stopper la démarche de 
verdy_p.
Ce que confirment ses propos ici même ce matin, je cite :
"La même relation représentant la région peut contenir à la fois la
définition de ses frontières externes (définition horizontale dans
l'arbre hiérarchique), et inclure la liste de ses membres (définition
verticale dans l'arbre hiérarchique des niveaux)"

Pour avancer :

* la discussion peut avantageusement se poursuivre sur la page ouverte (merci 
Sly) ici :
http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Mod%C3%A8le
_somme_de_surface_ou_mod%C3%A8le_fronti%C3%A8re

Toutes les contributions y sont bienvenues, tant qu'on ne verse pas dans la 
logorrhée [1]

* côté données en base, il faut procéder au rétablissement de la seule 
modélisation
pour l'instant documentée [2] pour les limites administratives, et qui fait 
consensus.

Je n'ai pas fait l'inventaire des relations, mais il y a potentiellement les 
niveaux
région et département pour Pays-de-la-Loire, Poitou-Charentes et leurs 
départements,
ainsi que Paris et le Val-de-Marne. Liste non exhaustive. Je peux me charger de 
les
rétablir dans le courant de la journée, à moins que quelqu'un s'en charge 
avant, mais
dans ce cas qu'il se signale ici, ça nous évitera d'emmêler nos pinceaux.

merci
vincent

[1] : http://fr.wikipedia.org/wiki/Logorrh%C3%A9e
[2] : 
http://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_les_limites_administratives



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

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-26 Par sujet Pieren 
2012/1/26 Philippe Verdy :

> il peut alors de façon paliative
> (uniquement paliative) utiliser l'autre axe vertical (surfaces,
> "subareas").

Dans tes arguments, tu parts toujours du principe que la relation
"boundary" est parfois incomplète, ce qui induit ensuite Nominatim en
erreur. Mais la même chose peut arriver dans le modèle surfacique. La
relation peut manquer un subarea, une commune ou un département. Ou en
avoir en trop. On ne peut jamais garantir l'intégrité des données. Et
si un modèle diffère de l'autre (par exemple, une île qui serait dans
l'un mais pas dans l'autre), il est impossible de savoir
automatiquement qui a raison et qui a tord. Il faudra donc toujours
passer par un contrôle manuel en cas de problème.
Tu peux écrire des mails de 25 pages, tu n'as toujours pas démontré en
quoi le modèle "subarea" n'est pas équivalent au modèle "boundary"
actuel pour définir un multipolygone. Au contraire, comme d'autres
l'ont déjà dit, le modèle surfacique ne marche que lorsque l'ensemble
des subarea est défini. Hors, de nombreuses régions en France n'ont
pas encore toutes leurs limites communales. C'est pour cela que le
modèle "boundary" a toujours été préféré dans OSM jusqu'à aujourd'hui.
Si tu ne peux pas vivre sans relations de type surfacique et
pyramidal, soit, mais pas dans la même relation de type "boundary". Si
tu penses que les deux peuvent se compléter, rien ne t'empêche de
sélectionner l'une ou l'autre en fonction de l'attribut "type=*" (les
tags "name" et "admin_level" pouvant être identiques).

Pieren

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-26 Par sujet Philippe Verdy 
Pour les rencontres, ça va être délicat là où je suis (les kilomètres...)...

J'ai de bonnes raisons pour qu'on onclue simultanément les deux
modèles. Particulièrement pour cette base de données qui est et
restera en évolution permanente, et dans laquelle on aura toujours des
lacunes. Avoir les deux permet de les combler au moins partiellement
selon un axe vertical dans l'arbre (les surfaces hiérarchisées), ou
selon un axe horizontal dans l'arbre (l'ensemble des frontières d'un
même niveau). On peut progresser simultanément dans les deux
directions pour aboutir à une convergence.

Un moteur de rendu de tuiles n'a normalement besoin que des
frontières, mais si des frontières (ways, "boundary_segments",
multilinestring en GIS: axe horizontal de l'arbre) manquent dans une
relation, ou ne sont pas fermées, il peut alors de façon paliative
(uniquement paliative) utiliser l'autre axe vertical (surfaces,
"subareas").

Si on a une définition des "subareas" complètes (ou tout autre rôle
qu'il serait utile de mettre si on veut renseigner plusieurs types de
partitionnement de la surface mère) et pas encore de frontières, un
moteur peur facilement remonter les frontières à la relation mère, et
ajouter un "FIXME" pour vérifier cette frontière ajoutée
automatiquement (uniquement dans le cas où la relation mère n'a pas de
frontière définie, et  uniquement si le rôle (subarea) le permet (mais
une interdiction peut être mise en indiquant une propriété dans la
relation mère, au cas où les subareas ne sont volontairement pas (ou
pas encore) une partition complète de la surface définie par la
relation mère (cas où il manque encore des subareas membres dans la
relation mère). A mon avis un robot vérificateur ne doit pas faire
cette remontée sans supervision humaine (il peut produire une liste,
un humain ajoute des tags pour indiquer ce que le robot peut faire ou
pas, le robot passe faire la modif demandée et revérifie en mettant à
jour sa liste).

De même, si on a une définition des frontières complètes dans la
relation mère, un robot vérificateur peut faire la remontée des
subareas avec le bon rôle en utilisant la définition des frontières
trouvées par une recherche spaciale (attention: c'est seulement une
heuristique! le contrôle humain reste nécessaire aussi, comme le
prouve Nominatim qui fait ce type de recherches extrêmement lourdes à
calculer et qui nécessite de charger et calculer un volume énorme de
données depuis la base OSM).

Le 26 janvier 2012 09:37, Romain MEHUT  a écrit :
> Bonjour à tous,
>
> Cela fait un moment que je suis dépassé par cette discussion interminable.
> Est-ce qu'il ne serait pas intéressant que les différents "protagonistes" se
> rencontrent pour en discuter de vive-voix et avec des exemples à l'appui...?
>
> Romain
>
> Le 26 janvier 2012 09:33, Philippe Verdy  a écrit :
>>
>> Le 25 janvier 2012 18:09, Pieren  a écrit :
>> > 2012/1/25 Vincent de Chateau-Thierry :
>> >
>> >> Contrairement à ce que je disais hier soir, je n'ai en revanche pas
>> >> touché aux
>> >> ajouts de type "subarea" dans les relations Paris et Val de Marne, pour
>> >> la simple raison
>> >> que de tels ajouts se sont multipliés depuis hier :
>> >>
>> >> la Vienne :
>> >> http://www.openstreetmap.org/browse/relation/7377
>> >> Poitou-Charente :
>> >> http://www.openstreetmap.org/api/0.6/relation/8652
>> >> Seine-et-Marne :
>> >> http://www.openstreetmap.org/api/0.6/relation/7383
>> >>
>> >> etc, etc.
>> >>
>> >> Je suis tout à fait prêt à discuter du modèle par surfaces, le jour où
>> >> il sera proposé.
>> >> Pour l'instant, il est plutôt imposé (litote) au mépris des suggestions
>> >> alternatives (ne
>> >> pas squatter les relations existantes, avant tout), ce qui ne réunit
>> >> pas les conditions
>> >> minimales d'une discussion. Un jour peut-être.
>> >
>> > Et donc on ne fait rien ? Alors que tout le monde à part l'auteur des
>> > modifs semble d'accord pour une séparation des modèles dans des
>> > relations différentes à minima ?
>>
>> Tout d'abord je comprend très bien l'intérêt de la méthode de
>> construction par niveaux indépendants qui favorise la modélisation par
>> frontières. Je n'ai absolument rien à critiquer là-dessus. Cette
>> méthode permet effectivement de construire 100% d'un niveau et de
>> vérifier qu'il n'y a doublon des surfaces couvertes (intersections),
>> ni surfaces oubliées pour un niveau donné. Oui effectivement elle
>> permet de construire chaque niveau indépendamment de tous les autres.
>> De même elle permet de détecter au sein d'un même niveau les
>> frontières mitoyennes définies par des ways (ou boundary_segments si
>> on les utilise, débat séparé)  superposés: la méthode demandée veut
>> qu'on évite de superposer les ways d'un même niveau. Elle ne va pas au
>> delà: on obtient une couche séparée pour ce niveau.
>>
>> Cependant ce n'est pas parce qu'un niveau parait 100% terminé, avec
>> une couverture totale, pas de doublons, qu'elle est de qualité. Car on
>> me dit d'utiliser une requêt

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-26 Par sujet Marc SIBERT 
Bonjour,

Bla, bla bla. Tout ça pour vous rappeler l'origine d'OSM, ce qui explique
l'existant.

Une des bases philosophique d'OSM est l'ajout et la correction progressive.
C'est la raison même des tags qui peuvent s'accumuler sur un élément afin
d'ajouter de la précision dans sa définition : un premier contributeur
indique une route, un second sa catégorie, un troisième son nom, etc.

Je pense qu'il faut voir la méthode de définition des frontières sous le
même angle :
Un premier contributeur place une frontière (département, région, pays,
commune), un second vient ensuite et ajoute un autre niveau...
indépendamment du premier, mais en réutilisant les frontières déjà tracées.
Effectivement un système pyramidal ne s'applique absolument pas à cette
pratique : il faut commencer par la base puis remonter chaque couche sans
en oublier une seule car l'ajout d'une nouvelle couche intermédiaire oblige
à tout casser.

Ce qui est clair, c'est que la méthode actuelle (des contours) évite les
adhérences et facilite la maintenance (si si). Je peux casser une commune
sans casser le département. Imaginez la course (et la surveillance) pour
suivre 36000 communes pour que le pays soit intègre !

Mes 0.02 € (évidemment ma résistance au changement m'encourage à conserver
la solution actuelle).

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-26 Par sujet Romain MEHUT 
Bonjour à tous,

Cela fait un moment que je suis dépassé par cette discussion interminable.
Est-ce qu'il ne serait pas intéressant que les différents "protagonistes"
se rencontrent pour en discuter de vive-voix et avec des exemples à
l'appui...?

Romain

Le 26 janvier 2012 09:33, Philippe Verdy  a écrit :

> Le 25 janvier 2012 18:09, Pieren  a écrit :
> > 2012/1/25 Vincent de Chateau-Thierry :
> >
> >> Contrairement à ce que je disais hier soir, je n'ai en revanche pas
> touché aux
> >> ajouts de type "subarea" dans les relations Paris et Val de Marne, pour
> la simple raison
> >> que de tels ajouts se sont multipliés depuis hier :
> >>
> >> la Vienne :
> >> http://www.openstreetmap.org/browse/relation/7377
> >> Poitou-Charente :
> >> http://www.openstreetmap.org/api/0.6/relation/8652
> >> Seine-et-Marne :
> >> http://www.openstreetmap.org/api/0.6/relation/7383
> >>
> >> etc, etc.
> >>
> >> Je suis tout à fait prêt à discuter du modèle par surfaces, le jour où
> il sera proposé.
> >> Pour l'instant, il est plutôt imposé (litote) au mépris des suggestions
> alternatives (ne
> >> pas squatter les relations existantes, avant tout), ce qui ne réunit
> pas les conditions
> >> minimales d'une discussion. Un jour peut-être.
> >
> > Et donc on ne fait rien ? Alors que tout le monde à part l'auteur des
> > modifs semble d'accord pour une séparation des modèles dans des
> > relations différentes à minima ?
>
> Tout d'abord je comprend très bien l'intérêt de la méthode de
> construction par niveaux indépendants qui favorise la modélisation par
> frontières. Je n'ai absolument rien à critiquer là-dessus. Cette
> méthode permet effectivement de construire 100% d'un niveau et de
> vérifier qu'il n'y a doublon des surfaces couvertes (intersections),
> ni surfaces oubliées pour un niveau donné. Oui effectivement elle
> permet de construire chaque niveau indépendamment de tous les autres.
> De même elle permet de détecter au sein d'un même niveau les
> frontières mitoyennes définies par des ways (ou boundary_segments si
> on les utilise, débat séparé)  superposés: la méthode demandée veut
> qu'on évite de superposer les ways d'un même niveau. Elle ne va pas au
> delà: on obtient une couche séparée pour ce niveau.
>
> Cependant ce n'est pas parce qu'un niveau parait 100% terminé, avec
> une couverture totale, pas de doublons, qu'elle est de qualité. Car on
> me dit d'utiliser une requête spaciale pour trouver les inclusions
> entre niveaux. En particulier, les frontières définies par un niveau
> sont aussi réutilisées pour définir les niveaux inférieurs: en
> travaillant sur un niveau donné, on peut très bien obtenir le niveau N
> 100% complet, et avoir tout cassé aux niveaux 1 à N-1...
>
> De même, il n'y a strictement rien avec le modèle qui utilise
> UNIQUEMENT les frontières pour recoller les niveaux entre eux: par
> exemple quel propriété "boundary_level" doit être mise dans les ways
> (ou boundary-segments si on les crée) ? Il n'y a aucune méthode pour
> vérifier que ces boundary_level sont corrects.
>
> De même, un ensemble de surfaces (définies par frontières) définies
> dans un niveau N+1 et qui devraient former une partition du niveau N,
> ne le font pas: la requête spacile échoue (et on se retrouve donc avec
> l'Ille-et-Vilaine qui n'est pas en Bretagne car des morceaux en
> dépassent. Le modèle avec *uniquement* les frontières ne permet pas le
> contrôle de cohérence. On aboutit alors aux aberrations produites par
> Nominatim (qui cherche alors une heuristique afin de déterminer quelle
> région contient le plus probablement l'Ille-et-Vilaine, basée sur les
> distances entre centroïdes, une heuristique qui est largement fausse
> et produit de nombreuses erreurs; on pourrait améliorer l'heuristique
> en calculant la surface (en mètres carrés ou autre unité de surface)
> commune, mais un tel calcul est bien plus lourd car cela suppose
> d'abord déterminer les intersections de surfaces polygonales, avant de
> calculer la surface par décomposition en triangles élémentaires:
> calcul très complexe que Nominatim ne fera sans doute jamais).
>
> Je ne veux pas dire qu'il faut supprimer les frontières: je veux
> garder les deux comme un outil de vérification mais aussi de
> consultation de la base de données ave des requêtes simples non
> spaciales. Ce que je défend reste la méthode de construction d'un
> niveau donné commençant d'abord par le modèle à frontières, qu'il font
> conserver dans les données. Si on représente la topologie des
> relations obtenues, on dessine un arbre des surfaces en commençant par
> tous les noeuds de l'arbre représentant les zones d'un même niveau,
> ces niveaux consituant l'axe horizontal de l'arbre hiérarchique
> virtuel.
>
> Maintenant on a toutes les couches horizontales créées, on les recolle
> sur le plan vertical en libellant explicitement les branches de
> l'arbre virtuel: c'est un ajout que l'on fait, on ne supprime pas les
> frontières du tout (les ways actuels, ou les boundary_segm

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-26 Par sujet Philippe Verdy 
Le 25 janvier 2012 18:09, Pieren  a écrit :
> 2012/1/25 Vincent de Chateau-Thierry :
>
>> Contrairement à ce que je disais hier soir, je n'ai en revanche pas touché 
>> aux
>> ajouts de type "subarea" dans les relations Paris et Val de Marne, pour la 
>> simple raison
>> que de tels ajouts se sont multipliés depuis hier :
>>
>> la Vienne :
>> http://www.openstreetmap.org/browse/relation/7377
>> Poitou-Charente :
>> http://www.openstreetmap.org/api/0.6/relation/8652
>> Seine-et-Marne :
>> http://www.openstreetmap.org/api/0.6/relation/7383
>>
>> etc, etc.
>>
>> Je suis tout à fait prêt à discuter du modèle par surfaces, le jour où il 
>> sera proposé.
>> Pour l'instant, il est plutôt imposé (litote) au mépris des suggestions 
>> alternatives (ne
>> pas squatter les relations existantes, avant tout), ce qui ne réunit pas les 
>> conditions
>> minimales d'une discussion. Un jour peut-être.
>
> Et donc on ne fait rien ? Alors que tout le monde à part l'auteur des
> modifs semble d'accord pour une séparation des modèles dans des
> relations différentes à minima ?

Tout d'abord je comprend très bien l'intérêt de la méthode de
construction par niveaux indépendants qui favorise la modélisation par
frontières. Je n'ai absolument rien à critiquer là-dessus. Cette
méthode permet effectivement de construire 100% d'un niveau et de
vérifier qu'il n'y a doublon des surfaces couvertes (intersections),
ni surfaces oubliées pour un niveau donné. Oui effectivement elle
permet de construire chaque niveau indépendamment de tous les autres.
De même elle permet de détecter au sein d'un même niveau les
frontières mitoyennes définies par des ways (ou boundary_segments si
on les utilise, débat séparé)  superposés: la méthode demandée veut
qu'on évite de superposer les ways d'un même niveau. Elle ne va pas au
delà: on obtient une couche séparée pour ce niveau.

Cependant ce n'est pas parce qu'un niveau parait 100% terminé, avec
une couverture totale, pas de doublons, qu'elle est de qualité. Car on
me dit d'utiliser une requête spaciale pour trouver les inclusions
entre niveaux. En particulier, les frontières définies par un niveau
sont aussi réutilisées pour définir les niveaux inférieurs: en
travaillant sur un niveau donné, on peut très bien obtenir le niveau N
100% complet, et avoir tout cassé aux niveaux 1 à N-1...

De même, il n'y a strictement rien avec le modèle qui utilise
UNIQUEMENT les frontières pour recoller les niveaux entre eux: par
exemple quel propriété "boundary_level" doit être mise dans les ways
(ou boundary-segments si on les crée) ? Il n'y a aucune méthode pour
vérifier que ces boundary_level sont corrects.

De même, un ensemble de surfaces (définies par frontières) définies
dans un niveau N+1 et qui devraient former une partition du niveau N,
ne le font pas: la requête spacile échoue (et on se retrouve donc avec
l'Ille-et-Vilaine qui n'est pas en Bretagne car des morceaux en
dépassent. Le modèle avec *uniquement* les frontières ne permet pas le
contrôle de cohérence. On aboutit alors aux aberrations produites par
Nominatim (qui cherche alors une heuristique afin de déterminer quelle
région contient le plus probablement l'Ille-et-Vilaine, basée sur les
distances entre centroïdes, une heuristique qui est largement fausse
et produit de nombreuses erreurs; on pourrait améliorer l'heuristique
en calculant la surface (en mètres carrés ou autre unité de surface)
commune, mais un tel calcul est bien plus lourd car cela suppose
d'abord déterminer les intersections de surfaces polygonales, avant de
calculer la surface par décomposition en triangles élémentaires:
calcul très complexe que Nominatim ne fera sans doute jamais).

Je ne veux pas dire qu'il faut supprimer les frontières: je veux
garder les deux comme un outil de vérification mais aussi de
consultation de la base de données ave des requêtes simples non
spaciales. Ce que je défend reste la méthode de construction d'un
niveau donné commençant d'abord par le modèle à frontières, qu'il font
conserver dans les données. Si on représente la topologie des
relations obtenues, on dessine un arbre des surfaces en commençant par
tous les noeuds de l'arbre représentant les zones d'un même niveau,
ces niveaux consituant l'axe horizontal de l'arbre hiérarchique
virtuel.

Maintenant on a toutes les couches horizontales créées, on les recolle
sur le plan vertical en libellant explicitement les branches de
l'arbre virtuel: c'est un ajout que l'on fait, on ne supprime pas les
frontières du tout (les ways actuels, ou les boundary_segments
proposés) ! Cet ajout évite d'avoir recours ensuite systémantiquement
aux requêtes spaciales très lourdes et aux heuristiques pour gérer les
ambiguités (cas des surfaces de niveaux différents qui se chevauchent
géométriquement). Cette couche permet de vérifier la cohérence des
niveaux différents entre eux.

Je n'ai jamais milité pour la construction n'utilisant QUE le modèle
par surface, mais je ne milite pas non plus pour celle n'utilisant QUE
le m

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-25 Par sujet sly (sylvain letuffe) 
On mercredi 25 janvier 2012, sly (sylvain letuffe) wrote:
> On mercredi 25 janvier 2012, Pieren wrote:
> > Et donc on ne fait rien ? Alors que tout le monde à part l'auteur des
> > modifs semble d'accord pour une séparation des modèles dans des
> > relations différentes à minima ?
> 
> Je vote bien évidement pour le retour arrière sur ces relations comme la 
> majorité des exprimés et laisse loisir à ceux qui défendent ce modèle de le 
> créer, mais de manière séparé et isolé.
> 
> Visiblement, la nuit été chargée en modification, je lui envoi un email pour 
> lui demander s'il peut les retirer, ce sera plus simple car il sait quelles 
> modifications il a fait.

Pardon, je viens de lui envoyer le mail.


-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-25 Par sujet sly (sylvain letuffe) 
On mercredi 25 janvier 2012, Pieren wrote:
> Et donc on ne fait rien ? Alors que tout le monde à part l'auteur des
> modifs semble d'accord pour une séparation des modèles dans des
> relations différentes à minima ?

Je vote bien évidement pour le retour arrière sur ces relations comme la 
majorité des exprimés et laisse loisir à ceux qui défendent ce modèle de le 
créer, mais de manière séparé et isolé.

Visiblement, la nuit été chargée en modification, je lui envoi un email pour 
lui demander s'il peut les retirer, ce sera plus simple car il sait quelles 
modifications il a fait.


-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-25 Par sujet Pieren 
2012/1/25 Vincent de Chateau-Thierry :

> Contrairement à ce que je disais hier soir, je n'ai en revanche pas touché aux
> ajouts de type "subarea" dans les relations Paris et Val de Marne, pour la 
> simple raison
> que de tels ajouts se sont multipliés depuis hier :
>
> la Vienne :
> http://www.openstreetmap.org/browse/relation/7377
> Poitou-Charente :
> http://www.openstreetmap.org/api/0.6/relation/8652
> Seine-et-Marne :
> http://www.openstreetmap.org/api/0.6/relation/7383
>
> etc, etc.
>
> Je suis tout à fait prêt à discuter du modèle par surfaces, le jour où il 
> sera proposé.
> Pour l'instant, il est plutôt imposé (litote) au mépris des suggestions 
> alternatives (ne
> pas squatter les relations existantes, avant tout), ce qui ne réunit pas les 
> conditions
> minimales d'une discussion. Un jour peut-être.

Et donc on ne fait rien ? Alors que tout le monde à part l'auteur des
modifs semble d'accord pour une séparation des modèles dans des
relations différentes à minima ?

Pieren

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-25 Par sujet Vincent de Chateau-Thierry 

> De : "sly (sylvain letuffe)" 

>
> yo,
> 
> > Pour revenir au départ du sujet, on se trouve encore à l'heure qu'il est 
> > avec un contour d'Ille-et-Vilaine inutilisable. Sauf levée de boucliers 
> > (argumentée), je procéderai demain soir à son rétablissement sous forme 
> > d'une relation "classique"
> 
> Bien que nous soyons tous d'accord pour dire que nous sommes en désaccord, je 
> vote +1 pour le rétablissement du statu quo qui me semble la bonne manière de 
> casser un minimum de chose.
> 

Après ce vote unanime :-) je viens de procéder à la redéfinition de la relation 
qui décrit l'Ille-et-Vilaine :
http://www.openstreetmap.org/browse/changeset/10494903

Contrairement à ce que je disais hier soir, je n'ai en revanche pas touché aux 
ajouts de type "subarea" dans les relations Paris et Val de Marne, pour la 
simple raison
que de tels ajouts se sont multipliés depuis hier :

la Vienne :
http://www.openstreetmap.org/browse/relation/7377
Poitou-Charente :
http://www.openstreetmap.org/api/0.6/relation/8652
Seine-et-Marne :
http://www.openstreetmap.org/api/0.6/relation/7383

etc, etc.

Je suis tout à fait prêt à discuter du modèle par surfaces, le jour où il sera 
proposé.
Pour l'instant, il est plutôt imposé (litote) au mépris des suggestions 
alternatives (ne
pas squatter les relations existantes, avant tout), ce qui ne réunit pas les 
conditions
minimales d'une discussion. Un jour peut-être.

> > D'ici là, pour les tests en tous genres à 
> > base de relations imbriquées ou sommes de surfaces pour des entités 
> > Région, Département et au dessous, il est tout à fait possible de créer 
> > de toute pièce des relations avec un autre schéma de tags, qui servent 
> > de support à la discussion, et sans pour autant casser / squatter un 
> > existant qui fonctionne et qui sert aussi à des consommateurs de données 
> > OSM. C'est aussi valable pour les contours d'EPCI, sly :-).
> 
> J'admets avoir jouer la provoc, il faut néanmoins garder à l'esprit que ça 
> n'intéresse que peu un testeur/développeur de faire un outil qui gère des 
> données qui n'existent pas, et ça n'intéresse que peu un contributeur dont 
> les données qu'il rentre ne sont pas valorisées.
> ça fait un peu cercle vicieux dont OSM se sort généralement par le forcing, 
> forcing qui était plus facilement de mise quand nous n'avions que 2 rendus et 
> un pelé qui utilisait la base, et qui maintenant devient en effet de plus en 
> plus délicat.
> 

Bien d'accord là-dessus. Mais même dans le forcing, il y a des nuances :-)

vincent

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

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-25 Par sujet sly (sylvain letuffe) 
On mercredi 25 janvier 2012, Philippe Verdy wrote:
> Si on a bien défini les relations, il
> n'est plus nécessaire de modifier dans JOSM les frontières (trop
> lourdes à charger et vérifier). Un outil automatique peut générer ces
> frontières de la France de base par celle des régions définies dans la
> relation

Oui, c'est vrai, de même que la liste des départements d'une région peut être 
construite automatiquement si on dispose des frontières de la région et de 
celles des départements.

Encore une fois, les deux modèles permettent logicielemnet de construire 
l'autre, d'où à mon sens la non utilité d'avoir les deux.

La question est donc bien le choix de l'un ou l'autre modèle. Et comme chacun 
présente des inconvénients, tant que l'un n'est pas prouvé comme meilleur, le 
statu quo me semble la règle.

Cependant, comme dit dans les autres fils, la construction d'une deuxième 
relation pour chaque département, chaque région et la france et l'option 
retenu pour "expérimenter" avec le nouveau modèle, sans casser l'existant.

Y'a plus qu'a

-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-25 Par sujet Philippe Verdy 
Note: si les régions sont fermées (ce sont des collectivités locales,
dans la ligne de base du Cadastre), elles sont totalement définies
comme des partition du territoire français dans sa ligne de base (qui
inclut les eaux intérieures). Si on a bien défini les relations, il
n'est plus nécessaire de modifier dans JOSM les frontières (trop
lourdes à charger et vérifier). Un outil automatique peut générer ces
frontières de la France de base par celle des régions définies dans la
relation, ces frontières régionales étant elles-mêmes générables par
les frontières des départements, eux-mêmes générables par les
frontières des arrondissements en relation, eux-même par celle des
cantons (pas encore définis), eux-mêmes par celle des communes, voire
les arrondissements communaux ou pôles de proximité, districts
urbains, ou quartier (selon le découpage retenu par le Cadastre), Il
n'y a plus qu'à créer manuellement (ou importer) que les frontières du
Cadastre.

On crée alors manuellement les relations, et un robot construit les
frontières administratives des niveaux supérieurs, par récursion
automatiquement à partir des relations définies comme étant complètes.
Les lignes de côtes d'OSM peuvent continuer à être affinées mais n'ont
plus la nécessité de suivre celles du cadastre (on les affine avec les
données IGN ou les photos aériennes, cela n'influence pas le tracé des
communes).

Un robot n'a pas besoin de charger tout. Il peut le faire de façon
incrémentale et peut aussi créer les boundary_segments des frontières
communes à deux zones limitrophes de même niveau. Tout le travail
manuel est réduit: on ne charge plus la carte complète, le serveur est
soulagé, on n'a plus d'erreurs de niveaux ou de frontières mal
refermées, sauf au niveau le plus fin (ce que le robot peut détecter
et signaler (il ignore les frontrières non fermées des niveaux
supérieurs puisqu'il peut les reconstruire à partir des frontières de
niveau inférieur). et il fera le travail de mise à jour mieux qu'un
humain !

Le 25 janvier 2012 13:21, sly (sylvain letuffe)  a écrit :
> On lundi 23 janvier 2012, PhQ wrote:
>> Je vous demande de m'excuser de recadrer la discussion sur le
>> boundary_segment, mais ...
>
> Dans le barouf de ce fil de discussion, j'avais loupé cette question.
>
>> il y a le fait que la vérification de continuité ne se fait pas dans
>> l'éditeur de relation de JOSM.
>> Bien sur, on peut vérifier la continuité et la cohérence d'un
>> boundary_segment, mais à l'intérieur d'une
>> relation comprenant des segments et un boundary_segment, on ne sait pas si
>> ça ferme !
>
> Tu as tout à fait raison, il manque le support de JOSM pour gérer ça et c'est
> pénible, mais JOSM ne changera pas si on ne les utilises pas, et si on ne les
> utilises pas parce que JOSM ne les supportent pas, ben on avance plus.
>
>> Peut on vivre avec, et comment contourner cette lacune ?
>
> On peut vivre avec je pense, mais c'est pénible, on peut mettre en place des
> outils de contrôle externes, mais ce n'est qu'un palliatif.
>
> plusieurs cas :
> - Dans le cas de l'utilisation de la france entière, JOSM ramerait tellement,
> l'API ramerait tellement (et planterait), que avec ou sans, ça ne change
> rien, c'est pas possible. J'en ai fais le constat il y a 2 ans ce qui, déjà à
> l'époque, m'a obligé à changer le modèle pour le France. Et depuis, c'est
> encore pire. Donc là, à mon avis, c'est oui, car de toute façon on ne perd
> rien
>
> - Dans le cas des régions, ça devient très limite presque comme le cas du
> dessus
>
> - Dans le cas des départements et plus petits, on peut tout mettre dans JOSM,
> ça le fait "à peu près" donc pour ça, je suis pour de retarder tant que faire
> se peut jusqu'au jour ou JOSM supportera cela mieux
>
> Dans tous les cas de toutes façon, il faut prévoir des outils de surveillance
> de non fermage car tout le monde ne pense pas à vérifier avec JOSM (et tout
> le monde n'utilise pas JOSM)
>
> --
> sly
> qui suis-je : http://sly.letuffe.org
> email perso : sylvain chez letuffe un point org
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france [HS]

2012-01-25 Par sujet sly (sylvain letuffe) 
Je ne résiste pas, pour ajouter un peu d'humour à nominer cette phrase 
d'anthologie pour les Fortunes
http://wiki.openstreetmap.org/wiki/FR:Fortunes

> Verdy_p
> les côtes sont très grossières, et très éléatoires : travailler dessus sur
> des frontières très  longues est un enfer qui demande un temps infini de
> plus en plus long). 


-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-25 Par sujet sly (sylvain letuffe) 
On lundi 23 janvier 2012, PhQ wrote:
> Je vous demande de m'excuser de recadrer la discussion sur le
> boundary_segment, mais ...

Dans le barouf de ce fil de discussion, j'avais loupé cette question.

> il y a le fait que la vérification de continuité ne se fait pas dans
> l'éditeur de relation de JOSM.
> Bien sur, on peut vérifier la continuité et la cohérence d'un
> boundary_segment, mais à l'intérieur d'une
> relation comprenant des segments et un boundary_segment, on ne sait pas si
> ça ferme !

Tu as tout à fait raison, il manque le support de JOSM pour gérer ça et c'est 
pénible, mais JOSM ne changera pas si on ne les utilises pas, et si on ne les 
utilises pas parce que JOSM ne les supportent pas, ben on avance plus.
 
> Peut on vivre avec, et comment contourner cette lacune ?

On peut vivre avec je pense, mais c'est pénible, on peut mettre en place des 
outils de contrôle externes, mais ce n'est qu'un palliatif.

plusieurs cas :
- Dans le cas de l'utilisation de la france entière, JOSM ramerait tellement, 
l'API ramerait tellement (et planterait), que avec ou sans, ça ne change 
rien, c'est pas possible. J'en ai fais le constat il y a 2 ans ce qui, déjà à 
l'époque, m'a obligé à changer le modèle pour le France. Et depuis, c'est 
encore pire. Donc là, à mon avis, c'est oui, car de toute façon on ne perd 
rien

- Dans le cas des régions, ça devient très limite presque comme le cas du 
dessus

- Dans le cas des départements et plus petits, on peut tout mettre dans JOSM, 
ça le fait "à peu près" donc pour ça, je suis pour de retarder tant que faire 
se peut jusqu'au jour ou JOSM supportera cela mieux

Dans tous les cas de toutes façon, il faut prévoir des outils de surveillance 
de non fermage car tout le monde ne pense pas à vérifier avec JOSM (et tout 
le monde n'utilise pas JOSM)

-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-25 Par sujet sly (sylvain letuffe) 
yo,

> Pour revenir au départ du sujet, on se trouve encore à l'heure qu'il est 
> avec un contour d'Ille-et-Vilaine inutilisable. Sauf levée de boucliers 
> (argumentée), je procéderai demain soir à son rétablissement sous forme 
> d'une relation "classique"

Bien que nous soyons tous d'accord pour dire que nous sommes en désaccord, je 
vote +1 pour le rétablissement du statu quo qui me semble la bonne manière de 
casser un minimum de chose.


> D'ici là, pour les tests en tous genres à  
> base de relations imbriquées ou sommes de surfaces pour des entités 
> Région, Département et au dessous, il est tout à fait possible de créer 
> de toute pièce des relations avec un autre schéma de tags, qui servent 
> de support à la discussion, et sans pour autant casser / squatter un 
> existant qui fonctionne et qui sert aussi à des consommateurs de données 
> OSM. C'est aussi valable pour les contours d'EPCI, sly :-).

J'admets avoir jouer la provoc, il faut néanmoins garder à l'esprit que ça 
n'intéresse que peu un testeur/développeur de faire un outil qui gère des 
données qui n'existent pas, et ça n'intéresse que peu un contributeur dont 
les données qu'il rentre ne sont pas valorisées.
ça fait un peu cercle vicieux dont OSM se sort généralement par le forcing, 
forcing qui était plus facilement de mise quand nous n'avions que 2 rendus et 
un pelé qui utilisait la base, et qui maintenant devient en effet de plus en 
plus délicat.



-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-25 Par sujet Philippe Verdy 
Le 25 janvier 2012 11:48, Christian Quest  a écrit :
> N'y a-t-il pas un petit problème quand toutes les subarea n'existent pas
> encore ?

Non, on peut faire les deux et avancer des deux côtés à la fois. Le
travail sur les subareas est toutefois bien plus facile et plus rapide
à compléter.

> On est loin du compte avec la définition des commune il nous en manque
> encore pas loin de 25%, ce qui fait que par endroit il n'est pas facile de
> définir les limites des EPCI (pas possible avec comcom maker par exemple).
>
> Personne n'a réagit à l'idée d'avoir 2 relations, une 100% frontières
> géographiques et l'autre pour stocker les informations logiques (donc les
> subareas mais aussi d'autres choses si c'est utile).

Il y a déjà les deux relations (spaciales des frontières pour chaque
zone séparément et relationelles entre zones de niveaux différents).

Le découpage spacial correspond (pas la définition hiérarchique) à ne
considérer l'arbe que sur un axe horizontal, niveau par niveau.

Alors que les subareas dessine l'arbre sur l'axe vertical en
présentant ses branches. On doit pouvoir même avoir éventuellement
plusieurs découpages en sous-zones il suffirait d'avoir des rôles
différents selon le type de découpage considéré, par exemple "subarea"
pour le découpage principal administratif, à priori sans recouvrement,
"subarea:epci" pour la liste des EPCI, "subarea:pays" pour les "pays"
administratifs français qui regroupent les EPCI, "subarea:voynet" pour
les pays plus larges de la nouvelle loi (ces découpages de zones ne
sont pas nécessairement exchaustifs non plus au sens qu'ils ne
regroupent pas pour un même type de découpage forcement exactement
100% de la zone à subdiviser, mais pour un même type de découpage
d'une même zone mère, il ne devrait y avoir aucune intersection entre
les sous-zones utilisant le même rôle).

D'où mon idée de mentionner dans la zone mère quel rôle de membres
constitue une partition exacte: s'il manque des "subarea" ou s'il ne
couvrent pas 100% de la zone mère, on ne mentionne pas le rôle
"subarea" dans la propriété "partitions=subarea" de la zone mère. Si
on trouve "partitions=subarea", cela indique à un robot vérificateur
qu'il peut vérifier voire reconstruire les frontières de la zone mère
à partie des frontières des membre utilisant le rôle  "subarea"
mentionné par la propriété.

Ave ce système, on peut progresser et y aller au fur et à mesure, et
aider à reconstruire les frontières manquantes ou mal refermées ou pas
assez exhaustives avec un outil automatique.

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-25 Par sujet sly (sylvain letuffe) 
Le mercredi 25 janvier 2012 11:48:33, Christian Quest a écrit :
> N'y a-t-il pas un petit problème quand toutes les subarea n'existent pas
> encore ?

C'est un des problèmes soulevé il y a longtemps: temps que nous n'avons pas 
toutes les communes, le modèle par surface ne fonctionnera que très mal 
(logique, plein de niveau admin inférieurs seront faux en terme de surface, 
contenu, etc.).
Attention : je ne dis pas pour autant que quand nous les aurons toutes, ce 
sera bien ;-)


> Personne n'a réagit à l'idée d'avoir 2 relations, une 100% frontières
> géographiques et l'autre pour stocker les informations logiques (donc les
> subareas mais aussi d'autres choses si c'est utile).

Je suis contre de le recommander sur le wiki car c'est un double travail qui 
pourrait être utiliser à autre chose et qui embrouille les mappeurs qui se 
pose la question de comment "bien" faire.

Je ne suis en revanche pas contre, que ça soit expliqué sur une autre page, 
disant qu'aucun consensus ne s'est dégagé, que le but est de répondre à ça et 
ça, que le type de relation utilisé doit être type=boundary_relationnelle 
(différent) et que certain mappent des relations comme ça.

Certes, ça téléchargera encore un peu plus de donnée de l'API à chaque fois 
qu'on télécharge une commune, mais on est plus à ça près ;-)

-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-25 Par sujet Christian Quest 
N'y a-t-il pas un petit problème quand toutes les subarea n'existent pas
encore ?

On est loin du compte avec la définition des commune il nous en manque
encore pas loin de 25%, ce qui fait que par endroit il n'est pas facile de
définir les limites des EPCI (pas possible avec comcom maker par exemple).

Personne n'a réagit à l'idée d'avoir 2 relations, une 100% frontières
géographiques et l'autre pour stocker les informations logiques (donc les
subareas mais aussi d'autres choses si c'est utile).
--
Christian
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-25 Par sujet Philippe Verdy 
Le 25 janvier 2012 10:19, Pieren  a écrit :
> 2012/1/25 Philippe Verdy :
>> Je sais parfaitement pourquoi l'Ille-et-Vilaine n'est pas classée en
>> Bretagne par Nominatim: la requête spaciale échoue, car
>> l'Ille-et-Vilaine n'est pas entièrement incluse dans la Bretagne (ce
>> sont les îles oubliées...).
>
> Dans ce cas, il suffit d'ajouter les îles manquantes dans la relation
> et attendre que nominatim se remette à jour. Avec des subarea, on
> aurait aussi ce genre de problème. Si une relation est incomplète, on
> ne peut pas espérer que les logiciels ne fassent pas d'erreurs.




Non, avec les subareas, ce problème disparaitrait complètement: elles
sont simples à définir, très stables, indépendantes de la précision
des tracés ou de leur complétude, ne grossiront pas même si on
améliore la précision, elles soulagent énormément les requêtes. Et une
fois complètes (ce qui est facile à faire en peu de temps), elles
permettront de regénérer entièrement toutes les frontières de niveaux
supérieur, par récursion, afin que les cartes dessinées se mettent à
jour. Elles seront très utiles pout finalement aboutir à une cohérence
complète: plutôt que de perdre du temps à corriger les frontières
oubliées ou à la remettre en ordre pour les fermer et vérifier
qu'elles sont bien fermées, on ne travaille plus que sur les
frontières des zones les plus petites, ces zones (définies comme
relations de type boundary) qu'ont inclue ensuite comme relations
membres d'une zone plus grande avec un rôle "subarea".




La frontière de la zone de niveau supérieur, une fois que toutes les
subareas ont été incluses pour former une partition complète, peut
être regénérée automatiquement, et les boundary segments peuvent être
définis aussi automatiquement (plus tard) pour les frontières communes
des sous-zones. L'automatisation évitera toutes ces erreurs car on
commet nettement moins d'erreurs en travaillant au niveau le plus fin
de la carte: plus besoin de corriger les frontières des zones de
niveau supérieur, cela se fera par un bot, qui pourra le faire si une
zone contient des subareas, et si la zone mère est marquée comme
listant exhaustivement ses sous-zones (par exemple un attribut de la
relation "partitions"="subarea" indique que les membres de type
"subarea" forment une partition, et que donc ses frontières peuvent
être déduites, mises à jour automatiquement, des frontières de ses
sous-zones de rôle "subarea".




Rien donc n'est à changer aux outils qui dessinent les tuiles: ils
peuvent continuer à ignorer les membres de rôle subarea (ou tout autre
rôle si on désire faire plusieurs partitions différentes d'une zone,
ou faire des sous-zones formant une partition incomplète, ce rôle
restant alors non listé dans l'attribut "partitions"="subarea").




Je ne dis pas qu'il faut remplacer les frontières (boundaries, voire
boundary_segments) par des subareas, mais que les deux peuvent
énormément faciliter le travail: on travaille localement sur la carte,
qui se remet alors à jour de façon automatisable sur les zones de
niveau supérieur. Au final, on charge moins le serveur car la plupart
des éditions successives se fera au niveau local, ce qui affectera
beaucoup moins de tuiles, et demandera aux cartographes moins de
travail pour fouiller la carte, localiser les chemins et noeuds
puisqu'on peut naviguer facilement de façon récursive.




Et avec moins d'erreurs (grace au travail des bots), on pourra en in
corriger ce que Nominatim n'arrive pas à calculer correctement. Les
bots qui importent aussi des métadonnées n'auront plus besoin de
charger sans arrêt les noeuds et chemins: ils auront juste à parcourir
les relations, ce qui sera bien plus facile, plus rapide, plus
efficace, et produira des données de bien meilleure qualité que la
seule recherche géométrique qui est trop lourde.




Tu saisis l'intérêt ?

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-25 Par sujet Pieren 
2012/1/25 Philippe Verdy :
> Je sais parfaitement pourquoi l'Ille-et-Vilaine n'est pas classée en
> Bretagne par Nominatim: la requête spaciale échoue, car
> l'Ille-et-Vilaine n'est pas entièrement incluse dans la Bretagne (ce
> sont les îles oubliées...).

Dans ce cas, il suffit d'ajouter les îles manquantes dans la relation
et attendre que nominatim se remette à jour. Avec des subarea, on
aurait aussi ce genre de problème. Si une relation est incomplète, on
ne peut pas espérer que les logiciels ne fassent pas d'erreurs.

Pieren

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-24 Par sujet Philippe Verdy 
Je sais parfaitement pourquoi l'Ille-et-Vilaine n'est pas classée en
Bretagne par Nominatim: la requête spaciale échoue, car
l'Ille-et-Vilaine n'est pas entièrement incluse dans la Bretagne (ce
sont les îles oubliées...).

Nominatim tente alors une recherche approximative basée sur la plus
courte distance entre centroïdes et en déduit que le centroïde de
l'Ille-et-Vilaine est plus proche de celui des pays de la Loire que de
celui de la Bretagne (il ne sait pas encore utiliser les subareas,
c'est vrai, mais il pourrait le faire pour régler définitivemlent le
problème de façon simple au lieu de s'appuyer sur les définitions
spaciales de frontières).

Nominatim se plante car justement c'est un ordinateur. Il dépend de
règles algorithmiques qui ont des failles: ce n'est pas un algorithme
qu'il emploie mais un heuristique. Avec ses failles. Un humain ne
ferait pas cette erreur et ignorerait de lui-même les petites
imperfections frontralières entre la définition des zones de niveaux
différents.

Il n'y a actuelelment AUCUN contrôle de cohérence de la base entre les
niveaux administratifs différents. Uniquement entre zones de même
niveau. Et c'est une lacune grave de la base OSM, que les subareas
vont permettre de régler.

La stabilité et l'exactitude de la base de données milite fortement
pour l'utilisation des subareas, et permet de palier justement très
facilement à ces imperfections, permet de les détecter, et de les
corriger facilement.

Je peux donner de nombreux exemples de ces problèmes, et le modèle que
j'ai cité en exemple pour les 20 arrondissements communaux de Paris et
les 3 arrondissements départementaux du Val-de-Marne montrent qu'il
n'y a aucune anomalie, aucune ambiguïté, et une modélisation simple et
lisible, à la fois pour un humain ET pour un ordinateur. Et cela
n'entraine aucune anomalie non plus pour les logiciels de rendus ou
d'analyse et d'exploitation des cartes.
Cette double modélisation (spaciale et relationelle) n'est pas un
luxe, elles se complètent.

Tu as raison de dire qu'avec une modélisation relationelle (subareas)
il faudrait faire des requêtes récursives pour chercher les zones
parentes. Mais même dans ce cas, les requêtes à la base OSM bien qu'un
peu plus nombreuses (pour une zone seule), fourniront en fait des
résultats beaucoup moins massifs et demanderont beaucoup moins de
travail au serveur: le volume des valeurs retournées dans un modèle
relationnel est plusieurs milleurs de fois inférieur: au lieu d'un
seule énorme resultset, on obtient une poignée de tous petits
resultsets, très faciles et rapides à traiter.

De fait: essaye dans JOSM, en partant d'un claque vide, de chercher et
charger tous les arrondissements de Paris: avec une requête spaciale,
cela demande des requêtes volumineuses. C'est encore pire pour le
découpage de zones plus grandes (les régions ou tout le pays: de
nombreuses régions ne parviennent pas à se charger dans JOSM, le
serveur retourne une erreur à cause du volume de données à charger,
même en ne demandant à charger que les "membres incomplets", ou alors
il faut choisir une heure de basse charge du serveur pour parvenir à
charger ces relations). Il faut des heures ou des jours pour charger
la frontière de la France... C'est intenable.

On a donc besoin des deux: modélisation relationelle (pour
l'exploitation des cartes et le travail dessus, ou pour enrichir les
cartes de données tierces, par exempel statistiques ou métadonnées),
et modélisation spaciale (uniquement pour le rendu des cartes sur les
tuiles afin de les dessiner). Ce sont deux travaux indépendants, mais
qui se complètent l'un l'autre.

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-24 Par sujet Vincent de Chateau-Thierry 

Bonsoir,

Le 24/01/2012 18:05, verdy_p a écrit :



Tentons de ne pas tout mélanger :
1- Il y a le boulot pour les ordinateurs
2- Et le boulot pour les humains

Je privilégie de loin la réduction de 2), si 1) devient intenable, ce qui
n'est pas le cas, nous repenserons 2)


Justement, le 1) est intenable, et produit dix mille fois trop d'erreurs.
C'est un enfer à maintenir de façon cohérente et cela entraine une
redondance énorme en nombre de membres à copier de relation en relation, et
des requêtes géométriques très couteuses, là ou les requêtes relationnelles
sont bien plus efficaces.


C'est bien facile d'affirmer avec autant d'assurance de telles 
assertions sans donner aucun exemple. Mais sans matière, tu ne fais rien 
avancer.


(...)


Regarde l'exemple que j'ai fait sur Paris pour les arrondissements: aucune
redondance, et une grande facilité de navigation et d'exploitation pour
créer des cartes statistiques sans faire aucune requête spaciale (par
exemple pour faire des agrégats statistiques de population, sans doubles
comptes, et pourtant exhaustives).


Ce que tu appelles "aucune redondance" consiste a avoir _en double_ dans 
la même relation (http://www.openstreetmap.org/browse/relation/7444 ) 
tous les ways frontières entre arrondissements "extérieurs" et communes 
de la petite couronne : les ways sont directement dans la relation, et 
rajoutés comme membres des relations décrivant chacun de ces 
arrondissements extérieurs. Sans parler des ways frontières entre 
arrondissements, qui sont chacun présent 2 fois aussi au travers des 
relations. Aucune redondance...


(...)


L'édition est aussi facilitée puisque les membres inclus sont bien plus
localisés, on n'a plus à gérer des listes de centaines de membres difficiles
à contrôler et trier pour vérifier qu'ils sont bien continus ou complets.
L'éditeur n'a plus à charger et sauvegarder autant de données (des dizaines
de milliers de noeuds dès qu'on modifie une limite en bordure de région,
bien plus en core si on est en frontière de pays, car les différents types
de frontières s'y superposent... Et on évite les erreurs constantes du
serveur qui peine à afficher l'historique, et retourne souvent "data
full"...

Je te suggère de commencer à éditer les relations admins en ne chargeant 
que les quelques ways qui te sont nécessaires, au cas par cas. J'ai 
toujours fait ça, que ce soit pour tracer une limite de commune, ou 
réparer une relation cassée, et ça se passe très bien. Et dans les cas 
où ça n'est pas possible, oui, il faut tout charger, mais ça doit rester 
l'exception. Charger un département, c'est quelques minutes de 
chargement, c'est largement supportable une fois de temps en temps. 
Charger, au delà, une région entière voire la France, je serais bien 
curieux d'en connaître la motivation pour de l'édition.


/*/

Pour revenir au départ du sujet, on se trouve encore à l'heure qu'il est 
avec un contour d'Ille-et-Vilaine inutilisable. Sauf levée de boucliers 
(argumentée), je procéderai demain soir à son rétablissement sous forme 
d'une relation "classique", c'est à dire modélisée comme toutes les 
autres emprises administratives françaises, selon le schéma renseigné ici :

http://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_les_limites_administratives
Idem pour les tentatives "subarea" de Paris et du Val-de-Marne : s'il 
s'agit de proposer un modèle par somme de surfaces, comme le disait 
Pieren, autant le faire complètement, et non en imbriquant ça dans un 
schéma par limites ("boundaries").


Quand on sera capable, au prix d'une discussion et d'un consensus, de 
trouver un autre modèle (à supposer que ce soit nécessaire), alors on 
pourra modifier les données. D'ici là, pour les tests en tous genres à 
base de relations imbriquées ou sommes de surfaces pour des entités 
Région, Département et au dessous, il est tout à fait possible de créer 
de toute pièce des relations avec un autre schéma de tags, qui servent 
de support à la discussion, et sans pour autant casser / squatter un 
existant qui fonctionne et qui sert aussi à des consommateurs de données 
OSM. C'est aussi valable pour les contours d'EPCI, sly :-).


Et merci d'avoir lu jusqu'ici,
vincent

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-24 Par sujet sly (sylvain letuffe) 

J'ai répondu à pas mal de tes remarques dans d'autres mails que j'ai fais aux 
autres. Je vais juste prendre celle qui n'ont pas encore été adressées

> (il y a des "trous" volontaires dans les sous-zones

C'est gérable, avec le role inner pour les données et la primitive 
MULTIPOLYGON dans les bases spatiales

> , et 
> parfois des sous-zones à cheval sur deux zones de niveau supérieur, et le
> modèle géomatrique ne permet pas de représenter ça).

Sans aucun problème, la fonction standardisé est 
http://www.postgis.org/docs/ST_Intersects.html





-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-24 Par sujet verdy_p 


Le 24 janvier 2012 11:51, sly (sylvain letuffe)  a écrit
:
> On mardi 24 janvier 2012, verdy_p wrote:
>> > Pour verdy_p : toutes les utilisations que tu as cités peuvent déjà se
>> > faire avec le modèle actuel (modèle frontières) grâce aux bases de
>> données
>> > relationnelles.
>
> Je me suis trompé, je voulais dire "grâce aux bases de données spatiales"
>
>> Pas du tout ! Pour trouver ces relations de subdivision, ce ne sont pas
>> du
>> tout des modélisations de type relationnel, mais de type géométrique (2D
>> uniquement ! avec les limites que cela comporte quand on passe à la 3e
>> dimension sur les plans multicouches, par exemple si on veut modéliser
>> les
>> étages de la gare Montparnasse, avec une incertitude sur les élévations
>> sachant qu'il y a des couloirs en pente aussi !).
>
> Je ne comprends pas le rapport avec la gare Montparnasse, on parle ici
> d'entité administrative.
> (Et au pire, les bases de données spatiales, comme l'indique le nom,
> peuvent
> aussi trouver dans volume appartient un point 3D)
>
>> Par exemple trouve la relation qui lie le 1er arrondissement de Paris
>> (niveau 9) avec la commune de Paris (niveau 8).
>
> Ça se fait, ça tient en une ligne de SQL avec postgresql et la base
> osm2pgsql,
> je peux d'ailleurs faire pareil pour trouver que le 1er arrondissement de
> Paris est en europe, en france, en Ile de france, etc.
>
> En revanche, dans le modèle complètement relationnel que tu proposes, pour
> faire la même chose, tu sera obligé de passer niveau après niveau, puisque
> l'arrondissement de Paris n'est pas en subarea de l'europe.
>
> Je le répète, les deux modèles permettent la même chose, il me semble
> juste
> une perte de temps d'utiliser les deux.
> En plus, comme l'espagne les utilises, attendons 3 ans, et nous leur
> demanderons si c'est mieux ou moins bien !
>
>> C'est un gâchis énorme de requêtes SQL. Et oui cela ne facilite pas du
>> tout
>> le travail sur la carte et ses mises à jour. Et produire des cartes
>> statistiques par exemple est un enfer sans les "subareas".
>
> Tentons de ne pas tout mélanger :
> 1- Il y a le boulot pour les ordinateurs
> 2- Et le boulot pour les humains
>
> Je privilégie de loin la réduction de 2), si 1) devient intenable, ce qui
> n'est pas le cas, nous repenserons 2)

Justement, le 1) est intenable, et produit dix mille fois trop d'erreurs.
C'est un enfer à maintenir de façon cohérente et cela entraine une
redondance énorme en nombre de membres à copier de relation en relation, et
des requêtes géométriques très couteuses, là ou les requêtes relationnelles
sont bien plus efficaces.

Ne pas oublier non plus que les cartes ne seront pas toujours utilisées avec
des moteurs disposant de requêtes spaciales. De plus tu supposes que les
sous-zones forment une partition d'une zone principale, ce qui n'est PAS
toujours le cas (il y a des "trous" volontaires dans les sous-zones, et
parfois des sous-zones à cheval sur deux zones de niveau supérieur, et le
modèle géomatrique ne permet pas de représenter ça).

Donc j'insiste bien que la géométrie n'a de sens que pour définir une zone
toute seule (son contour et la surface qu'elle englobe) indépendamment de ce
qu'elle peut couvrir. Les sous-zones ne sont pas liées par une règle de
partition stricte, c'est une relation différente, non spaciale mais bien
relationnelle.

Regarde l'exemple que j'ai fait sur Paris pour les arrondissements: aucune
redondance, et une grande facilité de navigation et d'exploitation pour
créer des cartes statistiques sans faire aucune requête spaciale (par
exemple pour faire des agrégats statistiques de population, sans doubles
comptes, et pourtant exhaustives).

Les deux infos ne sont pas *nécessairement* redondantes et doivent aussi
permettre de faciliter le contrôle de cohérence. On met moins de membres
dans les relations (les boundary segments pour les contours partagés avec
les zones voisines, et les subarea pour les sous-zones contenues, dont on
peut vérifier qu'elles ne débordent pas de la zone mère et qu'elles forment
bien une partition (les exceptions à ces deux règles existent mais sont bien
plus faciles à gérer).

L'édition est aussi facilitée puisque les membres inclus sont bien plus
localisés, on n'a plus à gérer des listes de centaines de membres difficiles
à contrôler et trier pour vérifier qu'ils sont bien continus ou complets.
L'éditeur n'a plus à charger et sauvegarder autant de données (des dizaines
de milliers de noeuds dès qu'on modifie une limite en bordure de région,
bien plus en core si on est en frontière de pays, car les différents types
de frontières s'y superposent... Et on évite les erreurs constantes du
serveur qui peine à afficher l'historique, et retourne souvent "data
full"...


--
View this message in context: 
http://gis.638310.n2.nabble.com/Reflexions-sur-la-modelisation-dans-osm-des-niveaux-administratifs-en-france-tp7216522p7221023.html
Sent from the France mailing list archive at Nabble.com.

___

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-24 Par sujet Pieren 
2012/1/24 sly (sylvain letuffe) :
>
> hé ho, elle est où ta diplomatie légendaire ?
>

Je me suis énervé parce que j'ai vu un historique d'édition où de
nombreuses relations boundary étaient modifiées sans concertation, ni
examen des conséquences. Heureusement que Nominatim n'est plus mis à
jour depuis des mois...

Je ne vais pas revenir sur tous les points parce qu'il y en a trop. Je
voudrais juste donner quelques infos:
- les boundary_segments ne sont supportés par aucun logiciel, à part
ceux de Sly/Etienne Chové, donc uniquement franco-français. C'est
tellement vrai que nous avons maintenant deux relations identiques
pour le pays puisque les étrangers ne comprennaient pas pourquoi la
France était le seul pays sans polygon boundary dans leur bdd.
Résultat, au lieu d'avoir alléger les données de frontières, on les a
encore plus alourdies (d'où ma reflexion sur "c'était déjà le bordel
avant")
- les "subarea" sont une réinvention du fameux tag "is_in". C'est
juste pour éviter de faire des requêtes sql (et accessoirement à
apprendre à les faire). Ce rôle est uniquement documenté dans le wiki
du boundary administrative et pas dans celui du multipolygone. Il faut
savoir que la plupart des logiciels traitent les relations boundary
comme pour les multipolygones. Il y a donc une différence entre la doc
et les logiciels qui traitent les données OSM. Mais de toute façon,
les relations de relations ne sont pas supportées car elles posent des
problèmes techniques pas simples à résoudre lorsqu'on traite les
données en flux (ça oubligerait à faire deux passes ou de stocker les
relations en cache). Je comprends la facilité que cela amène pour
naviguer dans les relations. Je ne trouve pas utile de faire ce type
de construction pyramidale maintenue à la main si on peut le faire par
logiciel. Je n'approuve pas mais je n'empêcherais pas non plus ceux
qui veulent en faire, sauf que:
- mélanger dans la même relation "boundary" les contours extérieurs et
la somme des surfaces est un non-sens. Créez votre relation de type
"area" si ça vous chante pour mettre des subareas et laissez les
membres boundaries pour la relation "boundary". Il ne faut pas
mélanger des concepts différents sous le même nom. Les deux concepts
sont équivalents comme le dit Sly mais on a choisit il y a longtemps
d'opter pour les limites comme nos voisins à l'étranger et je ne vois
pas pourquoi, brutalement, on devrait passer d'un modèle à un autre ou
pire, cumuler les deux dans la même relation.
- certains militent pour la suppression du membre "admin_centre" de la
relation boundary/multipolygon car ils trouvent que ça n'en fait pas
partie. Ils veulent séparer la modélisation "géométrie" et
"administratif"
(http://lists.openstreetmap.org/pipermail/dev/2012-January/024229.html),
chose que je désapprouve. Mais c'est juste pour dire à quel point il
faut éviter de rendre ces relations un peu fourre-tout.
- osm2pqsql pour nominatim (gazetteer) et mapnik ignore les rôles. La
géométrie est reconstituée à partir de tous les ways membres de la
relation (voir build_geometry.cpp). C'est pourquoi actuellement, par
exemple, un building enrôlé comme admin_centre dans le relation sera
considéré comme un inner/enclave (et poser problème de géolocalisation
pour ce qui s'y trouve)
(http://lists.openstreetmap.org/pipermail/dev/2012-January/024226.html).
Ca n'est pas une raison pour ne pas mettre les rôles mais c'est aussi
juste pour dire que les relations ne doivent pas contenir trop de
choses différentes parce que cela rend l'interprétation des données de
plus en plus difficile pour les logiciels comme pour les humains.
- pour le modèle des relations de relations (boundary_segments), si
cela diminue le nombre de relations attachées à un way, cela augmente
aussi le nombre de relations (n+1) et rend aussi l'interprétation des
données plus difficile (on ne voit plus d'un coup d'oeil de quelles
relations fait partie un way). Donc là aussi, je n'ai rien contre leur
emploi mais en étant pragmatique, c.a.d que lorsqu'on n'a pas le
choix.

Pieren

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-24 Par sujet Emilie Laffray 
2012/1/24 sly (sylvain letuffe) 

> >Enfin bon j'attends
> > avec impatience le jour ou on aura des objects polygones ce qui permettra
> > d'eviter le melange entre le semantique et le geographique.
>
> Aller, aujourd'hui, je m'acharne sur Emilie, demain je m'occuperais d'un
> autre.
>
> Bien évidement, rien contre toi, mais contre ce courant de pensé que je
> constate sur dev, sur talk, et même ici.
>
> Courant de pensé que je qualifierais même de religion.
>
> Une religion qui dit : "ne vous inquiétez pas, le messie viendra, la
> nouvelle
> primitive pour les area va tout changer et nous sauver,
> et son nom sera API 0.7"
>
> C'est une religion, car à chaque fois que nous n'avons pas de solution nous
> invoquons ce messie, des fois c'est même une secte car certains
> disent : "pourquoi t'embêter à réfléchir, l'API 0.7 va tout changer et
> réglera nos problèmes"
>
> Mais hélas, la vérité est la même que pour une religion, tous savent que
> dieu(x) existe, mais personne ne sait ni ou ni comment ni sous quelle
> forme.
>
> Je pense qu'il faut sortir de ça et analyser ce que l'on sait vraiment du
> http://wiki.openstreetmap.org/wiki/The_Future_of_Areas
>
> J'ai pourtant tout lu et la seule chose qui m'a convaincu car :
> - on pouvait migrer de l'ancien vers le nouveau système
> - on pouvait continuer à ne charger qu'une partie pour éviter de foutre en
> l'air JOSM
> - on pouvait éviter de superposer à l'infini des chemins
> - on pouvait éviter des constructions inbitables
>
> C'était de remplacer type=multipolygon par "" et garder toute la
> logique des roles inner/outer, des membres.
>
> Franchement quelle révolution, ça va juste foutre le merdier pour un
> moment et
> gagner trois fois rien (un checker de fermeture, interdire les autres roles
> pour que les développeurs imposent leur vu au mappeurs, bravo !)
>

Je ne crois pas au messie :) Mais je crois en l'ajout d'un type polygone.
Je t'avouerais que ca fait quelque temps que je n'ai pas lu dev justement
pour des raisons de religion! Je suis tres pragmatique de ce point de vue
la. La 0.7 ne sera qu'une iteration et comme la precedente risque de
prendre pas de temps. Apres, je ne suis meme pas sure qu'il y est quelque
chose de decide par les developeurs :) Il y a beaucoup de gens qui ont mis
plein de trucs sur le wiki et qui n'ont absolument aucun chance d'etre
adopte.
Maintenant lors du precedent hack week end a Londres, si consensus il y a
pour la 0.7 c'est bien le polygone, le reste c'est tres flou.

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-24 Par sujet sly (sylvain letuffe) 
>Enfin bon j'attends
> avec impatience le jour ou on aura des objects polygones ce qui permettra
> d'eviter le melange entre le semantique et le geographique.

Aller, aujourd'hui, je m'acharne sur Emilie, demain je m'occuperais d'un 
autre.

Bien évidement, rien contre toi, mais contre ce courant de pensé que je 
constate sur dev, sur talk, et même ici.

Courant de pensé que je qualifierais même de religion.

Une religion qui dit : "ne vous inquiétez pas, le messie viendra, la nouvelle 
primitive pour les area va tout changer et nous sauver, 
et son nom sera API 0.7"

C'est une religion, car à chaque fois que nous n'avons pas de solution nous 
invoquons ce messie, des fois c'est même une secte car certains 
disent : "pourquoi t'embêter à réfléchir, l'API 0.7 va tout changer et 
réglera nos problèmes"

Mais hélas, la vérité est la même que pour une religion, tous savent que 
dieu(x) existe, mais personne ne sait ni ou ni comment ni sous quelle forme.

Je pense qu'il faut sortir de ça et analyser ce que l'on sait vraiment du 
http://wiki.openstreetmap.org/wiki/The_Future_of_Areas

J'ai pourtant tout lu et la seule chose qui m'a convaincu car :
- on pouvait migrer de l'ancien vers le nouveau système
- on pouvait continuer à ne charger qu'une partie pour éviter de foutre en 
l'air JOSM
- on pouvait éviter de superposer à l'infini des chemins
- on pouvait éviter des constructions inbitables

C'était de remplacer type=multipolygon par "" et garder toute la 
logique des roles inner/outer, des membres.

Franchement quelle révolution, ça va juste foutre le merdier pour un moment et 
gagner trois fois rien (un checker de fermeture, interdire les autres roles 
pour que les développeurs imposent leur vu au mappeurs, bravo !)

-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-24 Par sujet sly (sylvain letuffe) 
On mardi 24 janvier 2012, Christian Quest wrote:
> Le sujet semble sensible vu le ton de plusieurs messages...

Je le déplore d'ailleurs alors qu'on est là pour discuter, mais bon, l'humain 
aime la fight, ça doit être ça.

> Quand on travaille sur la base de données, c'est quand même plus simple de
> passer par des liens logiques entre relations pour naviguer dans les
> hiérarchies administratives, non ? 
> Les requêtes spatiales sont coûteuses en 
> calcul et c'est de pire en pire vue le nombre croissant d'objets dans les
> bases, autant s'en passer quand on peut.

Voilà qui est un la première bonne question :
- Est-ce que le programme gagne ou perd du temps

Je vais tenter d'aider de mes connaissances, mais ça reste pas facile à savoir 
tant qu'on a pas les deux formats côte à côte pour faire des tests.

Prenons un exemple, la région Ille de France, avec le modèle "logique" 
ou "surfacique" ou "relationnel" on peut répondre facilement est simplement à 
la question : quels département sont dedans. Par contre, quand je veux 
répondre à la question : quelles communes sont dedans, je dois d'abord passer 
par les départements (à moins d'inclure en subarea tous les niveaux 
administratifs supérieurs mais ça c'est juste la folie) et ça, c'est pas 
forcément simple car il faut savoir quel est le ou les niveaux entre les deux 
(admin_level=6) et ça, ça ne se devine que parce qu'on est habitué, ça n'est 
portable qu'en france, dans d'autres pays, il y aura un admin level=5 ou un 
autre tag.

Si maintenant je veux tous les bâtiments d'ille de france, c'est juste 
impossible, car il n'y a pas de relation subarea pour lier les entités 
administratives et les bâtiments. De sorte que je suis obligé d'avoir les 
deux modèles quand même, je suis donc obligé de réfléchir selon chaque besoin 
si je dois utiliser le premier ou le deuxième modèle, ça me semble pas 
jouable et pas homogène comme méthode

> Je ne vois pas trop quel problème cela pose de mélanger au sein d'une même
> relation des objets géographiques et logiques (sémantiques). 

Moi, je vois que ça fait plus de boulot pour le mappeur, et ça, je ne vois pas 
ce qui le justifie.
Si quelqu'un a "vraiment" besoin d'un modèle logique pour accélérer des 
traitements ou faire je ne sais quoi, ce qu'il y a de génial, c'est qu'il 
pourra construire sa base de donnée en partant du modèle surfacique pour 
accélérer ou pour son traitement. L'inverse n'est pas vrai.

> Les deux types d'infos sont utiles. On peut considérer que c'est redondant,
> c'est vrai, mais cette redondance permet aussi de vérifier la cohérence et
> d'assurer un contrôle de qualité.

Ça, c'est encore un autre débat, mais intéressant aussi. Je dirais quand même 
que l'informatique nous a appris que dans bien des cas, la redondance ne 
faisait que créer des problèmes, et pas en résoudre.
Et puis, d'autres bases existent déjà (le cadastre) qui permet, comme je le 
fais, de faire un peu de contrôle qualité par la comparaison. Je ne pense pas 
que ça soit utile d'avoir deux modèles dans osm dans ce seul but.
 
> Si ce mélange au sein d'une même relation est vraiment source de problème,
> devrait-on créer 2 relations, une purement logique (niveau N -> niveau N+1
> avec les sub_area et autres choses du même ordre) et une géographique pour
> avoir juste les contours ?

Selon moi, ça ne change pas grand chose. Ajouter un 
"if role différent de inner/outer then rien faire" est chiant à mettre 
partout, mais c'est quand même possible et ça coûtera moins cher au mappeur.
Mais je pense qu'avant d'en arriver là, il faut déjà se demander
subarea : pour quel usage ?

> En ayant rajouté bon nombre d'EPCI ces derniers jours, je trouve l'approche
> uniquement "frontière" trop limitée.

Voilà la deuxième bonne question :
- Est-ce que le mappeur gagne ou perd du temps

Pour les EPCI, je n'en ai pas rentré, mais j'ai bien l'impression que oui, 
c'est plus galère d'inclure les frontières que d'inclure les communes.

Et cela est à mon avis dû à une loi mathématique :
Le périmètre d'un cercle est en f(r) celui d'une surface est en f(r²)

Plus ça devient gros, et moins on aura de membre sur un modèle frontière, et 
inversement.
Donc pour les départements/commune, je pense que c'est plus simple en modèle 
frontière, pour les EPCI/communes c'est plus simple en modèle surface

Mon avis n'a pas changé, vu qu'on ne sait rien, il faut tester. Et je propose 
de sacrifier les taggeurs d'EPCI sur l'autel de la recherche et leur proposer 
d'utiliser le modèle surfacique. L'avenir nous permettra de comparer tout ce 
que ça implique (logiciel pour exporter, outil de check, facilité à rentrer, 
etc.)

J'accepte toutefois qu'on me réponde "c'est pas éthique". Car comment laisser, 
en pensant que c'est une mauvaise idée, des gens faire quelque chose qui sera 
changé par la suite et du temps perdu.

La science aussi produit ses héros


-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

__

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-24 Par sujet Emilie Laffray 
2012/1/24 sly (sylvain letuffe) 

>
> > La encore,
> > ça n'est que relativement récemment que osm2pgsql a été modifié pour
> > ignorer les subarea car ça faisait tout planté justement lié a ce mélange
> > hideux de sémantique et de géographique.
>
> Bluff detected.
>
>
Non.


> Non, osm2pgsql dernière version dans le svn n'a pas de code pour exclure
> les
> subarea.
> Cependant, si ça marche encore a peu près, c'est parce que osm2pgsql ne
> support par les relations pyramidales et comme les role subarea concerne
> des
> relations, ouf, elles sont ignorées.
> Seulement, ça créer un problème pour l'avenir :
> - Si quelqu'un rentre en subarea non plus une relation mais un way fermé ça
> plante
> - Si quelqu'un tente de coder dans osm2pgsql le support des relations
> pyramidales, il va galérer un peu plus à lister tous les rôles selon qu'ils
> soient relationnels ou géométrique
>

Du code a du etre rajoute pour ignorer activement tout ce qui n'est pas une
partie venant d'un multipolygone car les relations subarea entrainaient des
problemes pour osm2pgsql. Tu es libre de demander a John Burgess toi meme :)

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-24 Par sujet sly (sylvain letuffe) 

> La encore,
> ça n'est que relativement récemment que osm2pgsql a été modifié pour
> ignorer les subarea car ça faisait tout planté justement lié a ce mélange
> hideux de sémantique et de géographique. 

Bluff detected.

Non, osm2pgsql dernière version dans le svn n'a pas de code pour exclure les 
subarea.
Cependant, si ça marche encore a peu près, c'est parce que osm2pgsql ne 
support par les relations pyramidales et comme les role subarea concerne des 
relations, ouf, elles sont ignorées.
Seulement, ça créer un problème pour l'avenir :
- Si quelqu'un rentre en subarea non plus une relation mais un way fermé ça 
plante
- Si quelqu'un tente de coder dans osm2pgsql le support des relations 
pyramidales, il va galérer un peu plus à lister tous les rôles selon qu'ils 
soient relationnels ou géométrique



-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-24 Par sujet Emilie Laffray 
2012/1/24 Christian Quest 

> Le sujet semble sensible vu le ton de plusieurs messages...
>
> J'avoue que je découvre les sub_area.
>
> Quand on travaille sur la base de données, c'est quand même plus simple de
> passer par des liens logiques entre relations pour naviguer dans les
> hiérarchies administratives, non ? Les requêtes spatiales sont coûteuses en
> calcul et c'est de pire en pire vue le nombre croissant d'objets dans les
> bases, autant s'en passer quand on peut.
>
> Je ne vois pas trop quel problème cela pose de mélanger au sein d'une même
> relation des objets géographiques et logiques (sémantiques). Emilie tu peux
> développer ce qui est vraiment horrible dans ces immondices ? ;)
> Il faut faire le tri pour utiliser l'un ou l'autre selon ses besoins ?
>
> Les deux types d'infos sont utiles. On peut considérer que c'est
> redondant, c'est vrai, mais cette redondance permet aussi de vérifier la
> cohérence et d'assurer un contrôle de qualité.
>
> Si ce mélange au sein d'une même relation est vraiment source de problème,
> devrait-on créer 2 relations, une purement logique (niveau N -> niveau N+1
> avec les sub_area et autres choses du même ordre) et une géographique pour
> avoir juste les contours ?
>
>
> En ayant rajouté bon nombre d'EPCI ces derniers jours, je trouve
> l'approche uniquement "frontière" trop limitée.
>
>
Personnellement, mon probleme avec l'implementation des sub area est le
fait que l'on melange des inner/outer et des sub areas. Enfin bon j'attends
avec impatience le jour ou on aura des objects polygones ce qui permettra
d'eviter le melange entre le semantique et le geographique.
L'idee meme d'un sub area est tres bonne, l'implementation est calamiteuse
a mes yeux.

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-24 Par sujet sly (sylvain letuffe) 
On mardi 24 janvier 2012, verdy_p wrote:
> > Pour verdy_p : toutes les utilisations que tu as cités peuvent déjà se
> > faire avec le modèle actuel (modèle frontières) grâce aux bases de données
> > relationnelles.

Je me suis trompé, je voulais dire "grâce aux bases de données spatiales"

> Pas du tout ! Pour trouver ces relations de subdivision, ce ne sont pas du
> tout des modélisations de type relationnel, mais de type géométrique (2D
> uniquement ! avec les limites que cela comporte quand on passe à la 3e
> dimension sur les plans multicouches, par exemple si on veut modéliser les
> étages de la gare Montparnasse, avec une incertitude sur les élévations
> sachant qu'il y a des couloirs en pente aussi !).

Je ne comprends pas le rapport avec la gare Montparnasse, on parle ici 
d'entité administrative.
(Et au pire, les bases de données spatiales, comme l'indique le nom, peuvent 
aussi trouver dans volume appartient un point 3D)
 
> Par exemple trouve la relation qui lie le 1er arrondissement de Paris
> (niveau 9) avec la commune de Paris (niveau 8). 

Ça se fait, ça tient en une ligne de SQL avec postgresql et la base osm2pgsql, 
je peux d'ailleurs faire pareil pour trouver que le 1er arrondissement de 
Paris est en europe, en france, en Ile de france, etc.

En revanche, dans le modèle complètement relationnel que tu proposes, pour 
faire la même chose, tu sera obligé de passer niveau après niveau, puisque 
l'arrondissement de Paris n'est pas en subarea de l'europe.

Je le répète, les deux modèles permettent la même chose, il me semble juste 
une perte de temps d'utiliser les deux.
En plus, comme l'espagne les utilises, attendons 3 ans, et nous leur 
demanderons si c'est mieux ou moins bien !

> C'est un gâchis énorme de requêtes SQL. Et oui cela ne facilite pas du tout
> le travail sur la carte et ses mises à jour. Et produire des cartes
> statistiques par exemple est un enfer sans les "subareas".

Tentons de ne pas tout mélanger :
1- Il y a le boulot pour les ordinateurs
2- Et le boulot pour les humains

Je privilégie de loin la réduction de 2), si 1) devient intenable, ce qui 
n'est pas le cas, nous repenserons 2)



-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-24 Par sujet Christian Quest 
Le sujet semble sensible vu le ton de plusieurs messages...

J'avoue que je découvre les sub_area.

Quand on travaille sur la base de données, c'est quand même plus simple de
passer par des liens logiques entre relations pour naviguer dans les
hiérarchies administratives, non ? Les requêtes spatiales sont coûteuses en
calcul et c'est de pire en pire vue le nombre croissant d'objets dans les
bases, autant s'en passer quand on peut.

Je ne vois pas trop quel problème cela pose de mélanger au sein d'une même
relation des objets géographiques et logiques (sémantiques). Emilie tu peux
développer ce qui est vraiment horrible dans ces immondices ? ;)
Il faut faire le tri pour utiliser l'un ou l'autre selon ses besoins ?

Les deux types d'infos sont utiles. On peut considérer que c'est redondant,
c'est vrai, mais cette redondance permet aussi de vérifier la cohérence et
d'assurer un contrôle de qualité.

Si ce mélange au sein d'une même relation est vraiment source de problème,
devrait-on créer 2 relations, une purement logique (niveau N -> niveau N+1
avec les sub_area et autres choses du même ordre) et une géographique pour
avoir juste les contours ?


En ayant rajouté bon nombre d'EPCI ces derniers jours, je trouve l'approche
uniquement "frontière" trop limitée.

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-24 Par sujet Emilie Laffray 
2012/1/24 verdy_p 

> > Pour verdy_p : hélas sur tes exemples sur nominatim, je peux te dire ce
> qui
> va se passer : Plus rien ne pourra plus être indiqué comme étant dans
> l'ille
> et vilaine puisque nominatim utilise osm2pgsql qui ne supporte pas cette
> construction.
>
> Ne parlons pas de Nominatim, il a ses bogues et même avant d'avoir fait ce
> test de frontière pour l'Ille-et-Vilaine, cela fait longtemps qu'il classe
> toutes les communes d'Ille-et-Vilaine dans les Pays de la Loire (recherchez
> Rennes, j'ai eu beau modifier un peu la position du nœud, il a pris la
> nouvelle position, mais pas tenu compte de la relation parente qui est bien
> en Ille-et-Vilaine, et l'Ille-et-Vilaine en Bretagne...).
>
> Ce bogue de Nominatim ne vient pas du modèle utilisé dans la base OSM est
> propre à ses propres mises à jour (il en omet plein et stocke des tonnes de
> données anciennes en doublon avec les données récentes, et ne conserve que
> les anciennes alors qu'elles ne sont plus dans la base OSM principale).
>
> Regardez le Trac de Nominatim, il y a des tonnes de cas semblables, car il
> utilise une recherche géométrique très approximative, apparemment basée sur
> la distance d'un lieu aux centroïdes des régions les plus proches, pour
> tenter de résoudre ses propres anomalies de doublons (dont les doublons
> avec
> des données qui n'existent plus dans la base OSM et qu'il aurait du
> supprimer depuis longtemps de sa propre base).
>
> Et de fait, le centroïde de l'Ille-et-Vilaine (vers Betton, pas loin de
> Rennes) est plus proche du centroïde des Pays de la Loire (pas loin de
> Nord-sur-Erdre) que de celui de la Bretagne (à mi-chemin entre Carhaix et
> Ploermel)... Ces anomalies de Nominatim sont très fréquents pour les lieux
> et zones les plus excentrés d'une zone mère, souvent les zones
> frontalières...
>
>
Brève réponse pour Nominatim puisque je connais Brian. Par définition,
Nominatim utilisera un polygone quand il existe. Sinon cela utilisera un
mécanisme de weighed Voronoi qui est sur de donner des choses
approximatives. Le plus gros problème est que Nominatim doit gérer des
normes différentes dans tous les pays. C'est un peu une grosse catastrophe
vu la variété des données. Cela prend pas moins de 9 jours pour faire un
import de base de planet.osm et ces chiffres datent d'il y a près d'un an
maintenant. Je ne suis pas sure que ça soit en rajoutant de nouvelles
manières de tagguer que l'on va réparer les données et les résultats dans
Nominatim. C'est le problème de tout geocodeur: il faut avoir une
compréhension des données sous-jacentes pour pouvoir faire quelque chose
d'utile et qui fonctionne. On parle de la France en terme de complexité
mais il y a bien pire que la France, il y a le Royaume Uni.
Personnellement, après 2 ans de travail sur les limites administratives
anglaises, je suis toujours a me demander comment tout fonctionne.
De plus, Nominatim a toujours eus du mal a lire les frontières de la France
a la base vu le format utilisé. De plus, Nominatim utilise osm2pgsql pour
créer ses données. Autrement dit, si ça ne passe pas dans osm2pgsql, on
peut toujours se tamponner pour avoir quelque chose.
Quelques mots sur l'utilisation du subarea. Je considère l'utilisation du
sub area dans une relation comme une aberration totale telle qu'elle est
faite pour l'Espagne et la Pologne car ça mélange des données sémantiques
et géographiques ce qui est vraiment quelque chose d'horrible. La encore,
ça n'est que relativement récemment que osm2pgsql a été modifié pour
ignorer les subarea car ça faisait tout planté justement lié a ce mélange
hideux de sémantique et de géographique. Oui pour améliorer les choses, non
pour faire des immondices.
Quant a Nominatim, Brian travaille sur une version 2 de Nominatim qui
devrait permettre de nettoyer le code et d'améliorer les performances mais
la encore patch welcome pour ceux qui peuvent.

Emilie Laffray

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-23 Par sujet verdy_p 
> Pour verdy_p : hélas sur tes exemples sur nominatim, je peux te dire ce qui
va se passer : Plus rien ne pourra plus être indiqué comme étant dans l'ille
et vilaine puisque nominatim utilise osm2pgsql qui ne supporte pas cette
construction.

Ne parlons pas de Nominatim, il a ses bogues et même avant d'avoir fait ce
test de frontière pour l'Ille-et-Vilaine, cela fait longtemps qu'il classe
toutes les communes d'Ille-et-Vilaine dans les Pays de la Loire (recherchez
Rennes, j'ai eu beau modifier un peu la position du nœud, il a pris la
nouvelle position, mais pas tenu compte de la relation parente qui est bien
en Ille-et-Vilaine, et l'Ille-et-Vilaine en Bretagne...).

Ce bogue de Nominatim ne vient pas du modèle utilisé dans la base OSM est
propre à ses propres mises à jour (il en omet plein et stocke des tonnes de
données anciennes en doublon avec les données récentes, et ne conserve que
les anciennes alors qu'elles ne sont plus dans la base OSM principale).

Regardez le Trac de Nominatim, il y a des tonnes de cas semblables, car il
utilise une recherche géométrique très approximative, apparemment basée sur
la distance d'un lieu aux centroïdes des régions les plus proches, pour
tenter de résoudre ses propres anomalies de doublons (dont les doublons avec
des données qui n'existent plus dans la base OSM et qu'il aurait du
supprimer depuis longtemps de sa propre base).

Et de fait, le centroïde de l'Ille-et-Vilaine (vers Betton, pas loin de
Rennes) est plus proche du centroïde des Pays de la Loire (pas loin de
Nord-sur-Erdre) que de celui de la Bretagne (à mi-chemin entre Carhaix et
Ploermel)... Ces anomalies de Nominatim sont très fréquents pour les lieux
et zones les plus excentrés d'une zone mère, souvent les zones
frontalières...


--
View this message in context: 
http://gis.638310.n2.nabble.com/Reflexions-sur-la-modelisation-dans-osm-des-niveaux-administratifs-en-france-tp7216522p7218873.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-23 Par sujet verdy_p 
> Pour verdy_p : toutes les utilisations que tu as cités peuvent déjà se
faire avec le modèle actuel (modèle frontières) grâce aux bases de données
relationnelles.

Pas du tout ! Pour trouver ces relations de subdivision, ce ne sont pas du
tout des modélisations de type relationnel, mais de type géométrique (2D
uniquement ! avec les limites que cela comporte quand on passe à la 3e
dimension sur les plans multicouches, par exemple si on veut modéliser les
étages de la gare Montparnasse, avec une incertitude sur les élévations
sachant qu'il y a des couloirs en pente aussi !).

Par exemple trouve la relation qui lie le 1er arrondissement de Paris
(niveau 9) avec la commune de Paris (niveau 8). C'est impossible sans
télécharger toute la zone de Paris et faire un calcul de géométrie très
complexe après avoir cherché dans cette zone (téléchargée par les
coordonnées de la "bounding box", voire en passant par de petites bounding
box autour des noeuds).

C'est un gâchis énorme de requêtes SQL. Et oui cela ne facilite pas du tout
le travail sur la carte et ses mises à jour. Et produire des cartes
statistiques par exemple est un enfer sans les "subareas".

Les deux modélisations des contours externes (avec les boundary et
boudary_segments de rôles inner ou outer), et des sous-surfaces (de rôle
subarea) ne modélisent pas la même chose, elles ne sont pas antonymes ni
automatiquement complémentaires l'une de l'autre (même si c'est normalement
le cas pour les zones administratives dont les niveaux sont des partitions).

Pour moi, je ne veux pas l'une ou l'autre, mais LES DEUX modélisations à la
fois car ce n'est pas la même chose (d'ailleurs rien n'oblige une zone
administrative de niveau N à être entièrement couverte par les zones de
niveaux N+1, il peut y avoir des parties volontairement oubliée car elles
n'existent pas ou plus à ce niveau ; ce cas est fréquent aux Etats-Unis, au
Canada, en Russie, en Australie, en Inde); ce cas commence à se présenter
aussi en France avec des collectivités territoriales qui disparaissent ou
changent de statut (par exemple la Corse est-elle encore une région
française métropolitaine, son statut étant celui d'une collectivité
territoriale qui n'a plus le nom de "région" ?) Les EPCI ne sont pas à
strictement parler une partition des départements puisque qu'il y a des
communautés de communes ou des pays qui comprennent des communes d'un autre
département ou d'une autre région, et des communes hors de toute EPCI (comme
Dinard par exemple dans le 35, qui va rejoindre une EPCI dont le siège est
dans le 22).

Selon l'usage qui est fait de la base de données, on prendra les relations
selon le modèle relationnel adéquat. Mais la modélisation purement
géométrique est un échec flagrant et conduit à des tonnes d'incohérences
dans la base de données, et un surplus inutile de données dupliquées
(ensembles chemins recopiés dans plein de relation, plus ou moins
complètement), ce qui n'a STRICTEMENT RIEN de "relationnel" (au sens SGBD du
terme).


--
View this message in context: 
http://gis.638310.n2.nabble.com/Reflexions-sur-la-modelisation-dans-osm-des-niveaux-administratifs-en-france-tp7216522p7218811.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-23 Par sujet sylvain letuffe 
Re-bonne nuit,

Je vais intervenir un peu plus en profondeur que tout à l'heure est diviser
ma vision des choses tag par tag en ce qui concerne la modélisation des
frontières administratives françaises.

== baratin je suis trop balèze ==
Je vais commencer par me présenter pour ceux qui ne me connaissent pas :

C'est moi qui est écrit et lancé cette proposition de type=boundary_segment
http://wiki.openstreetmap.org/wiki/Relations/Proposed/boundary_segment

C'est moi qui est écrit la page qui explique son utilisation pour la france
:
http://wiki.openstreetmap.org/wiki/France_boundary_pyramidal_construction

C'est moi qui, au début, ais fait le tout premier découpage avec des
type=boundary_segment

Et c'est moi qui entretient et développe les outils de contrôle et
d'exportation des niveau administratifs français 2,4,6,8
http://suivi.openstreetmap.fr/communes/
http://export.openstreetmap.fr/contours-administratifs/
http://beta.letuffe.org

Voilà, c'est tout, c'était juste pour la ramener et me venter comme
d'habitude.

Non, ce que je veux dire par là, c'est que je pense avoir une vision assez
poussée tant du coté du développeur que du coté contributeur pour tenter de
concilier : données utilisables et donnée rentrables dans osm (et ouvrir ma
gueule)

== Tag par tag, comment améliorer ==

Pas la peine de répéter que rentrer des contours administratifs,
aujourd'hui, ça marche, mais c'est un peu la pagaille pour des raisons de
standardisation mondiale et que même si le modèle actuel est mieux que de
superposer 20 chemins les uns sur les autres, il y a sans doute matière à
améliorer

=== role : subarea ===
( http://wiki.openstreetmap.org/wiki/Relation:boundary )
Ce modèle nous renvoi directement au débat somme de surface VS contour:
http://lists.openstreetmap.org/pipermail/talk-fr/2011-March/031437.html

Pour résumer, on ne sait pas de façon certaine lequel est le mieux, bien que
je fasse parti de ceux qui pense que notre modèle actuel me semble avoir
plus d'avantage, mais pour l'instant, personne n'a pû prouver qu'une
utilisation des données était rendue impossible par l'un ou l'autre, ce qui
nous amène a conclure que c'est perdre du temps que d'avoir les deux.
subarea (modèle somme de surface) est donc inutile dans l'état actuel des
contours administratif qui utilise déjà le modèle de frontières, il ne faut
donc pas l'encourager ou alors, il faut tout changer et ne faire plus que
ça.

Pour verdy_p : toutes les utilisations que tu as cités peuvent déjà se faire
avec le modèle actuel (modèle frontières) grâce aux bases de données
relationnelles

=== outer/inner/exclave/enclave/(rien) ===

Au niveau du modèle des données tout ça se résume à deux notions : c'est un
trou ou c'est autour, on a donc trop de rôle pour rien à mon avis.
Vu que le modèle des mutipolygones est bien défini et utilisent outer/inner,
je propose d'utiliser ces rôles pour la france

=== type=boundary/multipolygon ===
Encore une fois, la construction des deux est parfaitement similaire, on
sait qu'un contour est administratif parce qu'il a boundary=administrative,
le type=boundary n'est donc qu'une autre manière de dire type=multipolygon,
le traitement des type=multipolygon est aussi très répandu, donc aucune
raison d'avoir des incompatibilité d'utilisation "fortes" et cela
simplifierait la vie des débutants en leur disant, une fois pour toute,
type=boundary/multipolygon c'est pareil, pour éviter que tu te poses la
question : Mettons des type=multipolygon pour nos relations administratives

=== tags boundary=administrative sur les ways ===
Je vais pas me faire des amis, mais je rappel juste que tagguer les ways qui
sont dans la relation est un doublon car vu qu'ils sont dans la relation, on
sait qu'il sont des frontières administratives.
On règlerait plein de problème de rendu (superposition de couleur) et de
travail dupliqué à les enlever.


=== type=boundary_segment ===
Le plus dur pour la fin ;-)

ha que je regrète d'avoir nommé le tag ainsi !
idem que avant : cette relation porte déjà le tag boundary=administrative,
on sait donc ce que c'est une frontière, il eu été plus judicieux d'utiliser
le tag type pour définir de manière indépendante de ce que c'est, ça forme.
Mon rêve du moment, c'est de la transformer en :
type=multilinestring
pour ne pas faire bande à part, et utiliser des termes déjà connus dans le
monde GIS :
http://en.wikipedia.org/wiki/Well-known_text

Et aussi pour dire, définissons des formes complexes grâce aux relations
mais ré-utilisons les, plutôt que d'avoir ensuite des mappeurs qui peinent à
comprendre les relations, des programmeurs qui re-codent plusieurs fois la
même chose.

Passé ce désagrément de mot (mais je vais écrire une proposition sur le
wiki), le modèle de pyramide me plaît toujours, oui car dans notre modèle
actuel, il permet de limiter le nombre de relations auxquelles appartient un
way de frontière administrative. Et non, en effet, je le dis à mes
détracteurs, ça ne va pas être mégasupersimple, mais le peut

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-23 Par sujet verdy_p 
Tu dis que les moteur de rendu ignorent les rôles outer et inner : c'est
faux, affirmé sans preuve.

La notion d'exclave même est ambiguë: quand une zone consiste en deux zones
séparées, laquelle est une exclave de l'autre ? Il n'y a pas une sous-zone
plus importante que l'autre, les deux sont membres à part égale, avec
chacune un rôle "outer" (y compris pour les "petites" îles). Le rôle "inner"
ne sert qu'à exclure une zone qui autrement serait reconnue comme faisant
partie de la zone extérieure et qui serait donc remplie par la même couleur
ou motif.

Les rôles inner et outer fonctionnent parfaitement, même si les moteurs de
rendu reconnaissent encore les rôles enclave (considérés comme inner),
exclave et anonymes (considérés tous deux comme outer) qui persistent.

De même, les moteurs doivent encore faire le tri des chemins et rechercher
l'ordre normal ou inverse des noeuds pour interconnecter ces chemins (ce qui
prend du temps dans le moteur de rendu si on ne mâche pas le travail en les
préconnectant au moins entre deux chemins, sachant qu'il n'est pas possible
de définir un sens unique pour un chemin quand le chemin sépare deux zones
contigües: les rues à sens unique doivent donc avoir une propriété pour
définir le sens de circulation: oneway=yes ou oneway=-1 quand c'est en sens
inverse de la numérotation des noeuds dans le chemin), puis finalement
déterminer un sens antihoraire unique de parcours des noeuds de chaque
chemin membre pour remplir la zone: c'est un travail de géométrie
obligatoire dans tout moteur pour le rendu correct d'une surface fermée, ou
pour une recherche dans la base de donnée afin de savoir si un point est
dans la zone (à l'exclusion des enclaves) ou pas.

Notez que si le travail de calcul de géométrie d'un moteur est correct, il
n'a même pas besoin non plus des rôles inner ou outer: quand un chemin en
contient un autre enclavé (que ce chemin soit membre directement ou membre
d'une relation fille "inner" ou "outer", et de type "boundary" totalement
fermé ou de type "boudary_segment" non totalement fermé), la seule règle de
parité suffit à déterminer si un point est dedans ou dehors.

Algorithme : en traçant une ligne droite infinie de direction quelconque et
passant par ce point à tester (par exemple horizontale: on ne suit que la
ligne du parallèle à la latitude du point à tester par exemple), il suffit
de compter le nombre de chemins traversés en commençant à zéro depuis un des
côtés infinis de la droite (par exemple d'Ouest en Est) : si le compteur est
pair à ce point alors le point est dehors, si le compteur est impair le
point est dedans; un cas spécial est quand un point est sur le chemin
lui-même (par exemple quand le point testé est un nœud du chemin) ; l'autre
cas spécial est quand la ligne imaginaire passe par un segment entier
(c'est-à-dire par deux nœuds successifs du chemin : il ne faut en compter
qu'un).

Il n'est même pas nécessaire dans cet algorithme de trier les nœuds (si on a
utilisé comme ligne imaginaire un parallèle passant par le point à tester,
il suffit juste de tester si les latitudes des nœuds du chemin: si la
latitude du nœud est inférieure ou égale à la latitude compter -1, sinon
compter +1, et faire cela pour tous les nœuds du chemin: le résultat est
identique). Cependant le tri de nœuds (par exemple en sens antihoraire
systématique pour les contours fermés) permet de gagner du temps et facilite
non pas le dessin du remplissage des intérieurs, mais celui des contours
(par exemple des bordures de zones en traits pointillés jointifs aux nœuds,
ou l'ajout de flèches de direction), et évite des discontinuités dans le
tracé de tuiles rendues séparément.

Cet algorithme fonctionne déjà, et heureusement pour nous tous et OSM ! Un
moteur de rendu qui ne fait pas ça est totalement bogué et sera totalement
incapable de dessiner une carte correcte.

Bref ton assertion est fausse.

--
View this message in context: 
http://gis.638310.n2.nabble.com/Reflexions-sur-la-modelisation-dans-osm-des-niveaux-administratifs-en-france-tp7216522p7218649.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-23 Par sujet verdy_p 
Quelques exemples de modélisation des membres de rôle subarea, que j'ai
testés et qui fonctionnent:

- Paris (au niveau de la commune, niveau 8, les 20 arrondissements, de
niveau 9, sont listés comme membres avec rôle "subarea", le contour externe
est toujours là aussi). Notez que le département de Paris (niveau 6) a déjà
depuis longtemps un membre "subarea" pour son seul arrondissement
départemental (niveau 7), lui même ayant un membre "subarea" pour sa seule
commune (niveau 8). On pourrait continuer avec les quartiers administratifs
(niveau 10) de chaque arrondissement parisien...

- Le Val-de-Marne (au niveau département, niveau 6, les 3 arrondissements
départementaux de Créteil, L'Haÿe-les-Roses, et Nogent-sur-Marne, de niveau
7, sont listés comme membres avec le rôle "subarea"). On pourrait encore
faire la même chose pour les communes membres de ces arrondissements, avec
là aussi des membres de type subarea ajouté à chaque relation
d'arrondissement pour chaque commune dans cet arrondissement.

Tous les outils de validation actuels marchent très bien... La modélisation
est claire. Et la vérification de cohérence est possible, de même que
l'automatisation des recherches d'adresse.

Et on peut facilement monter/descendre les niveaux avec les relations
enfants (membres) et parentes sans rechercher en zoomant au hasard sur un
point de la carte et sans avoir à tout charger autour.

Je pourrais aussi subdiviser les frontières séparant les arrondissements
avec boundary_segments qui remplaceraient les chemins membres de ces
arrondissements, et remplacer les chemins membres de la frontière de Paris
(et des communes limitrophes) avec ces mêmes relations membres de type
boundary_segment. Ce système est récursif et facile à faire et mettre en
place (je ne l'ai pas encore fait). C'est le sens même de la définition
pyramidale.


--
View this message in context: 
http://gis.638310.n2.nabble.com/Reflexions-sur-la-modelisation-dans-osm-des-niveaux-administratifs-en-france-tp7216522p7218460.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-23 Par sujet sly (sylvain letuffe) 
Bonne nuit,

> Stoppez le massacre ! C'était déjà le bordel avant mais là, ça devient
> le pompon.

hé ho, elle est où ta diplomatie légendaire ?

Tout doux, on va réfléchir entre humains sans nécessairement sauter à la gorge 
de ce pauvre verdy_p que j'ai invité à discuter avec nous pour voir comment on 
peut faire au mieux. "Evoluer, sans trop casser"


Je reviendrais sur les autres points, mais je vais parler brièvement du tag 
subarea :

> Très confus, là. Il faut aussi dire que le terme "subarea" est
> extrêmement mal choisi. Cette notion représente une somme de surfaces
> dans son usage alors que l'unique documentation que je trouve
> (http://wiki.openstreetmap.org/wiki/Relation:boundary) parle de
> "boundaries of sublevels". J'aimerais avoir des statistiques de son
> usage (marginal, ama) mais il est urgent de ne pas utiliser un tag qui
> casse tous nos polygones de limites administratives car ce role n'est
> reconnu par AUCUN logiciel à part le validator de JOSM (peut-être
> parce que ça vient de la même personne Dirk Stocker) !

Il s'agit en effet de la même personne avec qui je me suis péniblement battu en 
édit war sur la page que tu cites.
L'arrivé de cette proposition de "subarea" (qui, pour résumer, consiste à 
inclure dans une relation d'admin_level=n, toutes les relations d'admin_level 
n+1)
N'a été discutée nulle part, a été parachuté sur le wiki sans réélle 
justification que : "vu que certains l'ont fait, indiquons qu'il faut le faire"
(voir la talk page en anglais pour les combats)

Pour la france, je continue donc à défendre la non utilisation de ce modèle 
bien que je suis à l'écoute de ceux qui m'expliquerons ce qu'elle apporte.
Et j'ai sauvé du massacre en traduisant in-extrémis la page que je recommande 
de suivre :
http://wiki.openstreetmap.org/wiki/FR:Relation:boundary


-- 
sly (sylvain letuffe)

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-23 Par sujet verdy_p 
Note: l'usage des subarea ne CASSE PAS les boundary actuelles. Ce sont des
rôles totalement indépendants: les boundary ou boundary segment décrivent le
contour extérieur d'une zone, alors que les subarea décrivent ce qui est à
l'intérieur de la zone (le sous-découpage qui contient des frontières
supplémentaires).

Les deux sont utiles, sachant qu'à terme tout de même la somme des subarea
doit produire une partition de la zone principale et l'union de ces subareas
devrait correspondre exactement au contour de la zone principale (après
élimination des frontières internes entre subdivisions).

Je ne vois rien de confus là-dedans. Si un outil ne sait pas quoi faire d'un
membre d'une relation avec un rôle nommé (comme subarea, admin_center,
label), il doit l'ignorer et cela ne doit pas l'empêcher de tracer le
contour de la zone et la remplir dans une couleur ou un motif donné. En
revanche:

* Il DOIT savoir utiliser les rôles inner et outer pour remplir la surface
correctement (enclave/exclave devraient fonctionner encore mais sont
obsolètes; de même les chemins membres sans rôle nommés devraient encore
être traités comme s'ils avaient le rôle outer; même s'il est préférable de
mentionner ce rôle outer explicitement dans les données). Ces rôles doivent
servir aussi à savoir si un point est dans une zone ou pas (cela concerne
Nominatim...).

* Qu'un rôle inner ou outer soit effecté à un membre de type boundary (zone
fermée) ou boundary_segment (portion de contour, membre lui-même d'une ou
plusieurs relation de zones fermées), ne doit pas influer sur le rendu ou le
test d'inclusion d'un point dans une zone fermée

* Il DOIT utiliser les rôles outer (et exclave ou anonymes pour
compatibilité ascendante), inner (et enclave pour compatibilité ascendante)
pour tracer les traits de contours (ou pour savoir si un nouveau noeud est
sur le contour ou pas; principalement dans l'éditeur pour détecter une
intersection possible)

Certes des outils facilitant la modification des zones partitionnées en
sous-zones serait le bienvenu, mais pour l'instant ce travail reste
possible, la modélisation est claire cela moi, et peut se faire à la main
avec les outisl actuels (même si ces outils ne vérifient pas encore leur
cohérence, mais de toute façon ils ne savent pas non plus faire cette
vérification car justement il manque des données de modélisation, ce que les
membres polygones de type boundary_segments et les membres de rôle subarea
devraient permettre de très bien modéliser avec précision, et en facilitant
énormément aussi le travail sur la carte).


--
View this message in context: 
http://gis.638310.n2.nabble.com/Reflexions-sur-la-modelisation-dans-osm-des-niveaux-administratifs-en-france-tp7216522p7218352.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-23 Par sujet verdy_p 
Encore une fois, je ne vouis toujours pas de quel problème tu parles. Ton
exemple (l'URL) ne démontre aucun problème (sauf si ton cache local n'est
pas à jour et utilise des données anciennes qu ne sont pas celles dans la
base de données).

Je n'ai encore vu STRICTEMENT AUCUN problème avec ce test très limité. Qu'on
me démontre quel outil est affecté... Oui il peut y en avoir des tonnes (pas
forcément tous discutés ici et hors d'OSM sur des sites tiers comme le
tien), mais justement en tant que base de données, la cohérence milite
forcément pour une telle modélisation destinée à éliminer les incohérences.

Par exemple je ne sais pas comment régler le problème dans Nominatim, qui
continue à classer l'Ille-et-Vilaine dans les Pays de la Loire (alors que la
base de données OSM est à jour): ce sont des bogues propres à Nominatim qui
se plante pour une raison inconnue, et à voir le Trac de Nominatim, ces
problèmes d'adresses parentes sont récurrents et fréquents. Ce devrait être
des bogues majeurs, pourtant Trac les classe comme mineurs. Les utilisateurs
se plaignent d'ailleurs du retard des mises à jour: alors que les auteurs
disent que le retard n'est que de quelques heures, tout prouve le contraire:
Nominatim oublie des tonnes de mises à jour et donne des résultats
incohérents: il ne sait pas purger les anciennes infos fausses et régler les
conflits, du coup on se retrouve par exemple avec Rennes affiché à la fois
en Bretagne et dans les Pays de la Loire, Nominatim détecte les deux, mais
ne garde que la version la plus ancienne obsolète (affichée en noir dans les
détails), pas la plus récente (qu'il affiche en gris dans les détails), dans
sa tentative boguée de résoudre les conflits (puisque justement il ne
vérifie même pas que les anciennes données qu'il a sont encore dans la base
de données OSM).

Je pense qu'on ne peut pas avancer si on regarde ces anomalies sérieuses.
Ces outils tiers (ou bases de données dérivées comme Nominatim) doivent être
corrigés le but d'ODM étant de donner des infos exactes, à charge pour les
outils dérivés (de recherche, de rendu, etc.) de se mettre à jour
correctement. LA base OSM doit rester la réference si elle est déjà la
source de ces outils.

Les boundary_segment sont déjà présents dans la base de données depuis
longtemps. Les discussions sur les rôles concernés (inner/outer recommandés,
enclave/exclave obsolètes, admin_center et label) et types de relations
(boundary ou boundary_segment) ont déjà eu lieu à une échelle bien plus
vaste que seulement la France.

Et le problème dont on parle ici ne concerne pas que la France, loin de là:
les rôles boundary_segment sont nécessaires (pour modéliser correctement les
contours de zones qui se touchent et forment une partition de zones plus
grandes), de même que les subarea (justement pour permettre une exploitation
des cartes et une navigation facile, autant que les vérifications de
cohérence de la base de données OSM elle-même). 

Bref même si j'ai fait un test limité, à une seule petite frontière
(uniquement la côte de l'Ille-et-Vilaine, en ayant conservé les autres
chemins terrestres pour l'instant dans la relation, même s'il est évident
qu'il faudrait aussi les répartir dans leur propres boundary_segments), je
n'ai encore vu aucun problème supplémentaire que cela génère, même dans JOSM
(si vous êtes à jour ! Ma version stable actuelle est la 4667, je le lance
avec le lien JNLP officiel qui se charge de télécharger tout seul les JAR et
vérifier les mises à jour).

Donc oui je ne me contente pas de regarder les moteurs de rendu de tuiles,
je regarde aussi les effets dans les outils dérivés qu'on peut avoir, ainsi
que dans les éditeurs. Pour ce que je vois, il n'y a aucun problème que ce
soit dans l'éditeur en ligne d'OSM ou dans JOSM, les deux éditeurs
principaux utilisés (et qui ne sont pas développés seulement pour la France
mais pour la cartographie de tous les pays).

Mon idée n'est pas de casser les relations existantes: elles persistent, je
les complète et je les enrichis pour rendre les cartes plus faciles à
exploiter (et à modifier ! la modification des frontières est aujourd'hui un
enfer et produit trop d'incohérences, avec des frontières oubliées; ce qui a
justement pu produire des effets indésirables comme ceux constatés sur
Nominatim qui a chargé des données incohérentes et fausses, indépendamment
de son bogue actuel qui fait qu'il ne sait pas se remettre à jour depuis
même avec ldes données corrigées dans la base OSM, ce qui est un second
problème).

Note: le fait que l'Ille-et-Vilaine apparait dans les Pays de la Loire dans
Nominatim est très ancien et antérieur à mon petit test d'hier sur cette
limite côtière. Mon test n'a pour l'instant rien changé à ce que fait
Nominatim...


--
View this message in context: 
http://gis.638310.n2.nabble.com/Reflexions-sur-la-modelisation-dans-osm-des-niveaux-administratifs-en-france-tp7216522p7218307.html
Sent from the France mailing list archive at Nabble.com.

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-23 Par sujet Pieren 
2012/1/23 verdy_p :

Stoppez le massacre ! C'était déjà le bordel avant mais là, ça devient
le pompon.

> Il n'y a aucun problème signalé par JOSM, ni warning, ni error; d'ailleurs
> les notions d'enclave/exclave sont obsolètes, il n'y a plus que "outer"
> (partie principale et toutes les exclaves d'une zone) et "inner" (toutes les
> enclaves d'une zone principale externe ou toutes les autres zones
> principales enclavées)...

On pourrait aussi totalement ignorer les roles "outer" et "inner"
puisque ces roles sont ignorés par les logiciels de rendu. Mais JOSM
se plaindra quand même si le role n'est pas défini. Alors oublions les
couinements du validator.

> JOSM vérifie cependant toujours l'ordonnancement des relations et noeuds de
> segments: d'une façon générale on doit toujours préférer le sens
> trigonométrique (anti-horaire), car c'est sinon un tri que doit faire tous
> les systèmes de rendus de tuiles, et cela prend du temps. Ce sens est à
> garder même pour les zones "inner" (puisque ces enclaves sont aussi des
> chemins ou relations ayant leur propre définition en tant que zone "outer",
> ces chemins en sens anti-horaire sont normalement partagés).

L'ordre et l'orientation des ways qui définissent un polygone n'ont
aucune importance. Les logiciels qui traitent ces données partent du
principe qu'elles ne sont pas forcément triées par l'éditeur et elles
sont capables de les remettre dans l'ordre automatiquement et très
rapidement. Aucun type de relation n'impose un ordre précis dans ses
membres, excepté certains itinéraires (type 'route').

>
> Pour les éditeurs, il est essentiel de s'assurer que les chemins ou segments
> d'une relation sont aussi connectés et dans l'ordre

Connectés, oui. Dans l'ordre, non. Même si JOSM propose une fonction
bien pratique de tri dans l'éditeur de relations qui permet de
vérifier que la boucle est bouclée, ça n'est pas indispensable.

> A l'avenir, il devrait aussi y avoir l'utilisation des membres de type
> "subarea" (mais pas avant que le découpage d'une zone soit une partition
> exacte). Cela permettra aussi des navigations dans la carte et des
> vérifications supplémentaires de cohérence: une relation qui comporte des
> "subarea" doit avoir un contour couvrant exactement l'ensemble des
> "subarea", sans trou car sinon ce sont des zones "subarea" oubliées, et ces
> subareas doivent n'avoir aucune intersection de surface entre elles.

Très confus, là. Il faut aussi dire que le terme "subarea" est
extrêmement mal choisi. Cette notion représente une somme de surfaces
dans son usage alors que l'unique documentation que je trouve
(http://wiki.openstreetmap.org/wiki/Relation:boundary) parle de
"boundaries of sublevels". J'aimerais avoir des statistiques de son
usage (marginal, ama) mais il est urgent de ne pas utiliser un tag qui
casse tous nos polygones de limites administratives car ce role n'est
reconnu par AUCUN logiciel à part le validator de JOSM (peut-être
parce que ça vient de la même personne Dirk Stocker) !

Pieren

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-23 Par sujet Vincent de Chateau-Thierry 

Bonsoir,

Le 23/01/2012 21:51, verdy_p a écrit :

Tu me dis que le département d'Ille-et-Vilaine "ne ferme plus", je ne vois
rien de tel dans le fichier CSV que tu indiques, qui cherche plutôt à
associer les zones avec les images cadastrales et rechercher les références
INSEE des communes.

C'est toujours bon dans ce fichier pour l'Ille-et-Vilaine. De quel problème
parles-tu ?



Le problème est illustré ici :
http://beta.letuffe.org/?layers=BFFTFF&zoom=7&lat=48.30871&lon=-1.51981

Le polygone principal du dept 35 n'est plus reconnu comme un polygone 
par osm2pgsql [1], du coup il n'est pas rendu sur cette carte, et par 
ailleurs il ne permet plus de savoir quelles communes incluses dans ce 
polygone sont déjà dans la base, d'où la liste intégrale des communes du 
35 dans le fichier CSV.


> verdy_p a écrit :
>> sly :
>> (...) si c'est pas
>> encore un peu tôt pour le faire compte tenu des outils très rares
>> qui savent utiliser cette méthode.
> Tu parles de quels outils ? Visiblement, les "boundary_segment" sont
> bien supportés et reconnus par tous les outils de modification, rendu
> de tuiles, et vérification. Il n'y a aucune difficulté que je voie
> (et d'ailleurs la France elle-même utilise déjà ces segments, même si
> le découpage n'est pas adéquat, la division s'étant faite de façon
> très arbritraire).

Visiblement...non. La carte citée plus haut est une illustration de la 
limite actuelle des outils. Car il n'y a pas que les moteurs de rendu : 
il y a les outils d'intégration comme osmosis ou osm2pgsql, outils qui 
permettent à tout un chacun d'utiliser le contenu OSM. OSM est une base 
de données qui ne se réduit pas à ce que des moteurs de rendu savent en 
faire. Et la carte ci-dessus est elle même un outil de vérification, qui 
ne "supporte" pas bien cette modélisation.


Au sujet des boundary_segments, de mon côté je n'ai rien contre, on a 
déjà évoqué plusieurs fois ici l'idée de morceler par département les 
limites côtières dans le cadre de la relation France :

http://www.openstreetmap.org/browse/relation/1362232
en appliquant cette modélisation.

En revanche je suis tout à fait opposé à une "méthode" qui consiste, 
unilatéralement, à tester une modélisation avec des conséquences telles 
que celles sur le dept 35 actuellement. La modélisation des limites 
administratives est un sujet récurrent ici-même, et j'espère bien que ça 
continuera. À l'inverse, si on modélise à marche forcée, sans 
concertation, pour a posteriori découvrir les conséquences, je ne vois 
aucun gain.


En résumé je souhaite pour le court terme qu'on conserve une 
modélisation par ways pour les limites administratives des régions aux 
communes. Corollaire : il m'apparaît nécessaire de rétablir la 
construction par ways de la relation définissant l'Ille-et-Vilaine.
En parallèle, essayons, pourquoi pas, de trouver un autre modèle, mais 
alors en en discutant ici _avant_, donc en réfléchissant aux 
conséquences, par exemple sur les outils qui permettent d'exploiter le 
contenu OSM.


vincent

[1] : http://wiki.openstreetmap.org/wiki/Osm2pgsql

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-23 Par sujet PhQ 
Je vous demande de m'excuser de recadrer la discussion sur le
boundary_segment, mais ...
en dehors du Validator qui crache son venin, ce qui n'est pas bien grave en
soi,
il y a le fait que la vérification de continuité ne se fait pas dans
l'éditeur de relation de JOSM.
Bien sur, on peut vérifier la continuité et la cohérence d'un
boundary_segment, mais à l'intérieur d'une
relation comprenant des segments et un boundary_segment, on ne sait pas si
ça ferme !

Peut on vivre avec, et comment contourner cette lacune ?

-
Crazy Mapper authentique
--
View this message in context: 
http://gis.638310.n2.nabble.com/Reflexions-sur-la-modelisation-dans-osm-des-niveaux-administratifs-en-france-tp7216522p7217921.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-23 Par sujet verdy_p 
Tu me dis que le département d'Ille-et-Vilaine "ne ferme plus", je ne vois
rien de tel dans le fichier CSV que tu indiques, qui cherche plutôt à
associer les zones avec les images cadastrales et rechercher les références
INSEE des communes.

C'est toujours bon dans ce fichier pour l'Ille-et-Vilaine. De quel problème
parles-tu ?


--
View this message in context: 
http://gis.638310.n2.nabble.com/Reflexions-sur-la-modelisation-dans-osm-des-niveaux-administratifs-en-france-tp7216522p7217723.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-23 Par sujet verdy_p 
Il me semble que les références INSEE ne sont pas simples à trouver, mais ce
n'est pas le cas des références du cadastre qui découpent les communes en
sous-zones numérotées sur la totalité du territoire français, y compris les
eaux territoriales (au moins jusqu'à la "ligne de base", le reste des eaux
territoriales n'étant pas à la charge des communes, départements et régions
mais appartenant au domaine de l'Etat représenté par ses préfets; au delà,
la ZEE n'est pas à la charge des préfets mais seulement des services
nationaux de l'Etat, de ses ministères et de sa diplomatie).

Cependant ces zones du cadastre sont plus petites que ce qu'on appelle
généralement un quartier (par exemple un hameau ayant un nom bien défini
dans une commune rurale ayant plusieurs "centres" sera parfois lui-même
redécoupé dans le cadastre en zones plus petites). C'est le cas des trèves
en Bretagne (souvent d'anciens villages, parfois plusieurs anciens villages
et hameaux proches) qui ne sont pas toutes devenues des communes, ou alors
ont été séparées après la Révolution dans des communes séparées.

Je ne sais pas trop quel nom donner à ces "zones cadastrales".

Les limites administratives ne sont aussi pas les lignes côtières (dans la
carte actuelle ce ne sont que des lignes géographiques physiques, un peu
arbitraire car dépendant fortement de la précision des vues, des heures de
marées, et du régime fluvial ou de l'existence ou non d'un barrage ou seuil
de séparation des eaux).


--
View this message in context: 
http://gis.638310.n2.nabble.com/Reflexions-sur-la-modelisation-dans-osm-des-niveaux-administratifs-en-france-tp7216522p7217688.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-23 Par sujet verdy_p 
Puisque c'est de moi dont on parle ici, j'apporte une précision: j'utilise
JOSM depuis un bon moment.

Il faut peut-être te mettre à jour à la version actuelle. (Personnellement
je ne l'ai pas téléchargé, j'utilise le lien JNLP qui fait les vérifications
de mise à jour tout seul, l'application restant installée seulement dans un
cache; la mise à jour se fait toute seule vers la dernière version stable).

Il n'y a aucun problème signalé par JOSM, ni warning, ni error; d'ailleurs
les notions d'enclave/exclave sont obsolètes, il n'y a plus que "outer"
(partie principale et toutes les exclaves d'une zone) et "inner" (toutes les
enclaves d'une zone principale externe ou toutes les autres zones
principales enclavées)...

JOSM vérifie cependant toujours l'ordonnancement des relations et noeuds de
segments: d'une façon générale on doit toujours préférer le sens
trigonométrique (anti-horaire), car c'est sinon un tri que doit faire tous
les systèmes de rendus de tuiles, et cela prend du temps. Ce sens est à
garder même pour les zones "inner" (puisque ces enclaves sont aussi des
chemins ou relations ayant leur propre définition en tant que zone "outer",
ces chemins en sens anti-horaire sont normalement partagés).

Pour les éditeurs, il est essentiel de s'assurer que les chemins ou segments
d'une relation sont aussi connectés et dans l'ordre (sinon l'éditeur passe
un temps infini à rechercher les inclusions lors des modifications et peut
faire des erreurs et oublier de conserver des connexions: c'est aussi un
problème de performance dans l'éditeur, et sur les serveurs de rendus de
tuiles qui ont déjà beaucoup de travail à faire).

A l'avenir, il devrait aussi y avoir l'utilisation des membres de type
"subarea" (mais pas avant que le découpage d'une zone soit une partition
exacte). Cela permettra aussi des navigations dans la carte et des
vérifications supplémentaires de cohérence: une relation qui comporte des
"subarea" doit avoir un contour couvrant exactement l'ensemble des
"subarea", sans trou car sinon ce sont des zones "subarea" oubliées, et ces
subareas doivent n'avoir aucune intersection de surface entre elles.

Les subareas sont aussi supportées par JOSM.

--
View this message in context: 
http://gis.638310.n2.nabble.com/Reflexions-sur-la-modelisation-dans-osm-des-niveaux-administratifs-en-france-tp7216522p7217650.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-23 Par sujet sly (sylvain letuffe) 
On lundi 23 janvier 2012, PhQ wrote:
> Je suis pour à 100% l'utilisation du concept boundary_segment,
> malheureusement
> l'outil de validation JOSM le détecte en avertissement comme inconnu.
> J'ai loupé quelque chose ou il faut faire un ticket "ehancement" dans JOSM 
> pour faire avancer la chose ?

Ce ne sera ni la première ni la dernière fausse erreur/warning que le 
validateur JOSM aura renvoyé !

Si ce n'est que ça, je ne m'inquiète pas

-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-23 Par sujet PhQ 
Je suis pour à 100% l'utilisation du concept boundary_segment,
malheureusement
l'outil de validation JOSM le détecte en avertissement comme inconnu.
J'ai loupé quelque chose ou il faut faire un ticket "ehancement" dans JOSM 
pour faire avancer la chose ?

-
Crazy Mapper authentique
--
View this message in context: 
http://gis.638310.n2.nabble.com/Reflexions-sur-la-modelisation-dans-osm-des-niveaux-administratifs-en-france-tp7216522p7216902.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

2012-01-23 Par sujet Christian Quest 
Réflexion passionnante... j'ai commencé à saisir les EPCI de la région
parisienne ainsi que des quartiers dans de grosses communes
(admin_level=10) et là aussi je vois les limites du modèle actuel.

A propos des EPCI, j'ai trouvé leur liste sur le site de l'INSEE et j'y
ajoute donc un "ref:INSEE" depuis peu. Pour les quartiers, je n'ai pas
trouvé de référence cohérente d'une commune à l'autre, même en ayant
fouillé du côté des TRIRIS de l'INSEE.

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