subject:"Re\: \[OSM\-talk\-fr\] Découpages des académies..."

Je crois que tu ne connais pas le sens du mot orthogonal. Car si c'était
réellement orthogonal, ce critère de niveau serait utilisable **seul**
comme critère de sélection sans avoir jamais à la lier à un autre critère,
pour obtenir une liste d'éléments homogène. Ce qui n'est évidemment pas le
cas, puisque les niveaux sont toujours liés à autre chose : niveau de quoi ?
C'est comme le tag type : type de quoi ?


Le 8 juin 2013 16:05, Vincent de Château-Thierry v...@laposte.net a écrit
:

 Bonjour,

 Le 08/06/2013 15:28, Christian Quest a écrit :

  Si on regarde un peu plus loin que le sujet des académies, je pense
 qu'on va découvrir des découpages scolaires plus ou moins
 hiérarchiques, peut être pas en France, mais il y a de fortes chances
 qu'il y en ait dans d'autres pays... pendant un peu plus loin que les
 bords de notre hexagone ;)

 De plus mon idée avec boundary:level=* est d'avoir un tag un peu plus
 générique qui pourrait s'appliquer à tout type de boundary


 J'approuve complètement cette idée de tag boundary:level, qui deviendrait
 orthogonal au tag boundary, sans lien particulier avec une des valeurs,
 comme c'est aujourd'hui le cas avec admin_level.
 On combinerait boundary=* et boundary:level=* selon le besoin, et sans
 confusion.
 Et en toute logique, il faudrait si on l'applique, le propager aussi aux
 boundary=administrative, à la place d'admin_level. Peut-être pas pour
 demain matin, mais pour de nouveaux types de limites (telles les académies,
 s'il y a besoin de hiérarchiser des niveaux) pourquoi pas démarrer
 directement avec ?

 vincent


 __**_
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-frhttp://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] Découpages des académies...

2013-06-09 Par sujet Christian Quest

Le pseudo département de L'Epte sur layers a disparu.
Le diagnostic était donc bon ;)

-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] Découpages des académies...



Le 09/06/2013 10:15, Christian Quest a écrit :

Le pseudo département de L'Epte sur layers a disparu.
Le diagnostic était donc bon ;)


Bien vu :-)

Bon dimanche orthogonal,
vincent

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

Re: [OSM-talk-fr] Découpages des académies...

Le 8 juin 2013 16:05, Vincent de Château-Thierry v...@laposte.net a écrit
:


 Et en toute logique, il faudrait si on l'applique, le propager aussi aux
 boundary=administrative, à la place d'admin_level.


Certainement pas (ou à la limite seulement dans les relations
administratives (et qui ne sont QUE administratives et ne servent pas aussi
de limites pour autre chose).
L'ennui c'est pour les ways (fermés ou non) qui ont des utilisations
multiples. Il se posera alors la question de savoir à quel autre tag
présent sur ce way correspond ce level car justement le level n'est PAS
orthogonal mais lié à un seul autre tag.

C'est bien pour ça qu'on a un tag nommé admin_level (lié très fortement à
boundary=administrative pour lui apporter une sous-précision) et qu'on a
relevé un problème d'interprétation quant on l'a appliqué (à tord) sur les
frontières religieuses (qui n'ont rien de commun avec des frontières
administratives).

Franchement je ne comprend pas l'utilité même de vouloir unifier des tags
sous un même nom alors qu'ils ont des significations complètement
diférentes et ne sont pas liés aux mêmes données (et clairement pas
orthogonaux comme peuvent l'être name, url, wikipedia, natural,
landuse et boundary).

Il faudrait réfléchir plus sérieusement en terme de modélisation globale
des données et de leur interprétation dans un ensemble beaucoup plus vaste
qui en plus connaîtra des évolutions : un tel mélange de concepts dès le
départ différents est nuisible assez vite et fait apparaître les anomalies.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Découpages des académies...



Le 09/06/2013 13:08, Philippe Verdy a écrit :

Le 8 juin 2013 16:05, Vincent de Château-Thierry v...@laposte.net
mailto:v...@laposte.net a écrit :


Et en toute logique, il faudrait si on l'applique, le propager aussi
aux boundary=administrative, à la place d'admin_level.


Certainement pas (ou à la limite seulement dans les relations
administratives (et qui ne sont QUE administratives et ne servent pas
aussi de limites pour autre chose).


Je veux bien un exemple d'une relation admin qui sert à autre chose. 
S'il y a réellement 2 notions, alors on fait 2 relations, quitte à ce 
qu'elles aient les mêmes membres.



L'ennui c'est pour les ways (fermés ou non) qui ont des utilisations
multiples. Il se posera alors la question de savoir à quel autre tag
présent sur ce way correspond ce level car justement le level n'est
PAS orthogonal mais lié à un seul autre tag.


Ma proposition de généraliser boundary:level était surtout pour les 
relations, mais je ne l'ai pas précisé. Tu as raison de souligner la 
question des ways. Dans le cas des ways, il y aurait plusieurs possibilités.

Je vois au moins :
- garder le couple boundary=administrative+boundary:level=valeur 
actuelle d'admin_level (status quo, manière de reconnaître 
l'antériorité des limites admins dans de nombreux cas, les autres 
limites étant dérivées de celles-ci),
- migrer vers le couple boundary=administrative+boundary:level=valeur 
actuelle d'admin_level

= homogénéiser les tags entre ways et relations
- aller au bout de la logique de boundary:level, et donc enlever des 
ways ce tag, vu qu'il peut, selon le type de limite décrite, avoir 
plusieurs valeurs pour le même way. Les ways seraient juste taggués 
type=boundary, sans référence à un niveau ni à un type de limite, ces 2 
infos étant portées par chaque relation qui référence le way,
- affecter boundary:level avec la plus petite valeur de 'level', issue 
de toutes les relations qui référencent le way (en gros ce qu'on fait 
déjà, juste pour les relations administratives)


Bref, pas simple, et à discuter. Je penche personnellement pour la 3e 
proposition (enlever les tags). Mais c'est un peu radical vis-à-vis de 
l'existant...
À court terme, ça me semble plus directement applicable aux relations 
elles-mêmes, quitte à faire cohabiter dans un premier temps pour des 
questions de compatibilité les tags admin_level et boundary:level.



Franchement je ne comprend pas l'utilité même de vouloir unifier des
tags sous un même nom alors qu'ils ont des significations complètement
diférentes et ne sont pas liés aux mêmes données (et clairement pas
orthogonaux comme peuvent l'être name, url, wikipedia, natural,
landuse et boundary).


La signification n'est pas la même, mai le concept, oui : on parle 
d'organisations hiérarchiques, où la notion de niveau (level) a tout son 
sens.


vincent

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

Re: [OSM-talk-fr] Découpages des académies...


Le 09/06/2013 13:08, Philippe Verdy a écrit :
Le 8 juin 2013 16:05, Vincent de Château-Thierry v...@laposte.net 
mailto:v...@laposte.net a écrit :



Et en toute logique, il faudrait si on l'applique, le propager
aussi aux boundary=administrative, à la place d'admin_level.


Tout à fait.


Certainement pas (ou à la limite seulement dans les relations 
administratives (et qui ne sont QUE administratives et ne servent pas 
aussi de limites pour autre chose).
L'ennui c'est pour les ways (fermés ou non) qui ont des utilisations 
multiples. Il se posera alors la question de savoir à quel autre tag 
présent sur ce way correspond ce level car justement le level 
n'est PAS orthogonal mais lié à un seul autre tag.


C'est bien pour ça qu'on a un tag nommé admin_level (lié très 
fortement à boundary=administrative pour lui apporter une 
sous-précision) et qu'on a relevé un problème d'interprétation quant 
on l'a appliqué (à tord) sur les frontières religieuses (qui n'ont 
rien de commun avec des frontières administratives).

ON, je en l'occurrence, l'ai appliqué après réflexion.
On, Sly en l'occurrence, avait repéré un problème sur layers.osm.fr et a 
très bien réussi à le résoudre.
ON, toi en l'occurrence, ne semble pas avoir perçu comment Sly avait 
résolu le problème sur layers.osm.fr


Franchement je ne comprend pas l'utilité même de vouloir unifier des 
tags sous un même nom alors qu'ils ont des significations complètement 
diférentes et ne sont pas liés aux mêmes données (et clairement pas 
orthogonaux comme peuvent l'être name, url, wikipedia, 
natural, landuse et boundary).
Franchement je ne comprends pas l'utilité de multiplier les clefs alors 
qu'une bonne logique booléenne résout les problèmes.
Réemployer les mêmes clefs, ça permet de minimiser les clefs ! Ça permet 
d'alléger les tables dans postgres.

Ça permet d'utiliser la logique plutôt que le bavardage.

Il faudrait réfléchir plus sérieusement.

Tout à fait. Tu peux t'y mettre.

Heureusement que d'autres ont déjà commencé ! Ce qui permet d'utiliser 
des mêmes clefs secondaires conjointement avec des clefs primaires 
différentes : produce, operator... orthogonaux ou pas.

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

Re: [OSM-talk-fr] Découpages des académies...

Le cas des relations ayant les mêmes membres s'est déjà posé, parce que
JOSM par exempel les signale comme des doublons, malgré leurs tags
différents. Certains ne voient pas cela comme étant juste un warning
destiné à vérifier qu'il n'y a pas doublon (ce qui cause aussi des
problèmes de rendu ou d'analyse dans les applications), et cumulent dans la
relation les tags destinés à des fonctions différentes.
Dans ce cas, in ne sait plus comment interpréter ces tags

Mais sur les éléments de géométrie de base (ways et noeuds), clairement il
faut que les tags dont l'interprétation dépend directement d'un autre tag
et pas d'un autre, il faut que ce tag soit clairement associé par son nom à
cet autre tag qu'il sert à préciser.

Ainsi admin_level a clairement été défini dès le départ pour ajouter une
précision à boundary=administrative et certainement pas autre chose comme
ce qui a été fait (en France seulement et à l'initiative en fait d'une
seule personne qui l'a imposé partout sans réfléchir aux conséquences,
notamment car le tag n'avait jamais été concu pour être utilisé à autre
chose : les prérequis ne fonctionnaient plus, sur un tag qui était déjà
très largement utilisé dans la façon dont il avait été décrit, et cette
réutilisation abusive a cassé des applications existantes qui ne se sont
pas adaptées car elles étaient basées sur les spécifications existantes).

La prochaine fois que vous voulez étendre la signification d'un tag pour
autre chose, réfléchissez un peu à la compatibilité. Et il ne suffit pas de
compléter la doc sur le wiki, car cela resterea unilatéral alors que le tag
est déjà utilisé d'une autre façon par énormément de monde qui n'a pas été
consulté.

Noter aussi que les relations ne sont pas les seuls moyens de représenter
une zone: s'il n'y a pas lieu de découper les frontières parce qu'un
élément de même type n'est pas présent à ses frontières, OSM suppose déjà
qu'une relation n'est ni nécessaire, ni souhaitable (on ne veut pas de
relation à un seul membre par exemple), et on se retrouve donc avec des
chemins qui devraient disposer exactement des mêmes tags...

Il n'y a pas à faire de dichotomie d'usage des tags entre relations,
chemins et noeuds dans OSM, les mêmes tags doivent être utilisables pour
les trois avec la même signification, et c'est bien plus important qu'une
prétendue unification non nécessaire de tags en apparence identiques mais
qui ont des rôles bien différents (le pire tag actuel étant type=* qui ne
signifie plus rien de valable, devenu impossible à utiliser aujourd'hui et
donc devenu clairement redondant et à remplacer partout par des tags
spécialisés).



Le 9 juin 2013 14:27, Vincent de Château-Thierry v...@laposte.net a écrit
:


 Le 09/06/2013 13:08, Philippe Verdy a écrit :

 Le 8 juin 2013 16:05, Vincent de Château-Thierry v...@laposte.net
 mailto:v...@laposte.net a écrit :



 Et en toute logique, il faudrait si on l'applique, le propager aussi
 aux boundary=administrative, à la place d'admin_level.


 Certainement pas (ou à la limite seulement dans les relations
 administratives (et qui ne sont QUE administratives et ne servent pas
 aussi de limites pour autre chose).


 Je veux bien un exemple d'une relation admin qui sert à autre chose. S'il
 y a réellement 2 notions, alors on fait 2 relations, quitte à ce qu'elles
 aient les mêmes membres.


  L'ennui c'est pour les ways (fermés ou non) qui ont des utilisations
 multiples. Il se posera alors la question de savoir à quel autre tag
 présent sur ce way correspond ce level car justement le level n'est
 PAS orthogonal mais lié à un seul autre tag.


 Ma proposition de généraliser boundary:level était surtout pour les
 relations, mais je ne l'ai pas précisé. Tu as raison de souligner la
 question des ways. Dans le cas des ways, il y aurait plusieurs possibilités.
 Je vois au moins :
 - garder le couple boundary=administrative+**boundary:level=valeur
 actuelle d'admin_level (status quo, manière de reconnaître l'antériorité
 des limites admins dans de nombreux cas, les autres limites étant dérivées
 de celles-ci),
 - migrer vers le couple boundary=administrative+**boundary:level=valeur
 actuelle d'admin_level
 = homogénéiser les tags entre ways et relations
 - aller au bout de la logique de boundary:level, et donc enlever des ways
 ce tag, vu qu'il peut, selon le type de limite décrite, avoir plusieurs
 valeurs pour le même way. Les ways seraient juste taggués type=boundary,
 sans référence à un niveau ni à un type de limite, ces 2 infos étant
 portées par chaque relation qui référence le way,
 - affecter boundary:level avec la plus petite valeur de 'level', issue de
 toutes les relations qui référencent le way (en gros ce qu'on fait déjà,
 juste pour les relations administratives)

 Bref, pas simple, et à discuter. Je penche personnellement pour la 3e
 proposition (enlever les tags). Mais c'est un peu radical vis-à-vis de
 l'existant...
 À court terme, ça me semble plus directement applicable aux relations

Re: [OSM-talk-fr] Découpages des académies...

Les clés dans les extractions vers Postgres peuvent être réduites même sans
réutiliser les tags dans OSM. Les requêtes faites dans les tables de
features Postgres n'ont strictement rien à voir, les modèles de données
sont complètement différents.

Très mauvais argument donc. C'est hors sujet et ne justifie en rien le fait
d'avoir des tags clairement séparés dans OSM (même au prix d'une prétendue
économie de stockage, si les tags surchargés deviennent ambigus, non
seulement on complique les requêtes d'exportation, mais en plus elles
commence à retourner des données qui n'ont rien à voir et ne devraient pas
être importées dans Postgres.

Postgres n'a aucune obligation d'utiliser les mêmes clés OSM, il utilise
des tables séparées pour chaque feature, et avec des colonnes dont les noms
sont spécifiques à chaque table (le nom de la table elle-même les isole,
même s'ils sont homonymes, ils peuvent donc y être simplifiés). Il n'y a
PAS de clé dans Postgres dans un export GIS au même sens que dans OSM.



Le 9 juin 2013 15:06, Vincent Pottier vpott...@gmail.com a écrit :

  Le 09/06/2013 13:08, Philippe Verdy a écrit :

 Le 8 juin 2013 16:05, Vincent de Château-Thierry v...@laposte.net a
 écrit :


 Et en toute logique, il faudrait si on l'applique, le propager aussi aux
 boundary=administrative, à la place d'admin_level.

   Tout à fait.


  Certainement pas (ou à la limite seulement dans les relations
 administratives (et qui ne sont QUE administratives et ne servent pas aussi
 de limites pour autre chose).
 L'ennui c'est pour les ways (fermés ou non) qui ont des utilisations
 multiples. Il se posera alors la question de savoir à quel autre tag
 présent sur ce way correspond ce level car justement le level n'est PAS
 orthogonal mais lié à un seul autre tag.

  C'est bien pour ça qu'on a un tag nommé admin_level (lié très
 fortement à boundary=administrative pour lui apporter une sous-précision)
 et qu'on a relevé un problème d'interprétation quant on l'a appliqué (à
 tord) sur les frontières religieuses (qui n'ont rien de commun avec des
 frontières administratives).

 ON, je en l’occurrence, l'ai appliqué après réflexion.
 On, Sly en l’occurrence, avait repéré un problème sur layers.osm.fr et a
 très bien réussi à le résoudre.
 ON, toi en l’occurrence, ne semble pas avoir perçu comment Sly avait
 résolu le problème sur layers.osm.fr


  Franchement je ne comprend pas l'utilité même de vouloir unifier des
 tags sous un même nom alors qu'ils ont des significations complètement
 diférentes et ne sont pas liés aux mêmes données (et clairement pas
 orthogonaux comme peuvent l'être name, url, wikipedia, natural,
 landuse et boundary).

 Franchement je ne comprends pas l'utilité de multiplier les clefs alors
 qu'une bonne logique booléenne résout les problèmes.
 Réemployer les mêmes clefs, ça permet de minimiser les clefs ! Ça permet
 d'alléger les tables dans postgres.
 Ça permet d’utiliser la logique plutôt que le bavardage.

   Il faudrait réfléchir plus sérieusement.

 Tout à fait. Tu peux t'y mettre.

 Heureusement que d'autres ont déjà commencé ! Ce qui permet d'utiliser des
 mêmes clefs secondaires conjointement avec des clefs primaires différentes
 : produce, operator... orthogonaux ou pas.
 --
 FrViPofm

 ___
 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] Découpages des académies...

2013-06-09 Par sujet arnaud....@gmail.com


Philippe,


Postgres n'a aucune obligation d'utiliser les mêmes clés OSM, il 
utilise des tables séparées pour chaque feature, et avec des colonnes 
dont les noms sont spécifiques à chaque table (le nom de la table 
elle-même les isole, même s'ils sont homonymes, ils peuvent donc y 
être simplifiés). Il n'y a PAS de clé dans Postgres dans un export GIS 
au même sens que dans OSM.




Tu peux clarifier ce passage s'il te plaît. Je ne comprends pas ce que 
tu veux dire.



Merci.

A.

--

Arnaud Vandecasteele
SIG - WebMapping - Spatial Ontology - GeoCollaboration

Web Site
http://www.marinegis.com/?page_id=131
http://geotribu.net/


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

Re: [OSM-talk-fr] Découpages des académies...

Le 9 juin 2013 15:06, Vincent Pottier vpott...@gmail.com a écrit :

 Il faudrait réfléchir plus sérieusement.

 Tout à fait. Tu peux t'y mettre.


Commence par te l'appliquer à toi-même. quand tu comprendras que la base
OSM pour l'instant n'est pas structurée du tout comme une base GIS et que
son modèle de données ne permet pas des distinctions aussi claires. Le seul
moyen avec le modèle OSM plat de simuler les tables de features d'une base
GIS c'est d'utiliser des conventions de préfixes pour nommer les tags (le
préfixe deventant l'équivalent du nom de la table de feature externe, dans
laquelle tu ne mélanges pas les choix et les carottes même si ce sont des
légumes).


 Heureusement que d'autres ont déjà commencé ! Ce qui permet d'utiliser des
 mêmes clefs secondaires conjointement avec des clefs primaires différentes
 : produce, operator... orthogonaux ou pas.


On en reparlera le jour où OSM commencera à supporter dans sa base
directement des tables de features et pas seulement des objets
indifférenciés, avec aussi l'intégration des schémas de données. Pour
l'instant on n'y est pas (et ce n'est même pas envisagé). Alors soyons
propre et évitons de tout mélanger (c'est déjà assez compliqué d'interroger
la base OSM justement faute du moindre modèle de données).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Découpages des académies...



Le 09/06/2013 15:28, Philippe Verdy a écrit :

Le cas des relations ayant les mêmes membres s'est déjà posé, parce que
JOSM par exempel les signale comme des doublons, malgré leurs tags
différents. Certains ne voient pas cela comme étant juste un warning
destiné à vérifier qu'il n'y a pas doublon (ce qui cause aussi des
problèmes de rendu ou d'analyse dans les applications), et cumulent dans
la relation les tags destinés à des fonctions différentes.
Dans ce cas, in ne sait plus comment interpréter ces tags


Un exemple ? Un lien concret, je veux dire.


Mais sur les éléments de géométrie de base (ways et noeuds), clairement
il faut que les tags dont l'interprétation dépend directement d'un autre
tag et pas d'un autre, il faut que ce tag soit clairement associé par
son nom à cet autre tag qu'il sert à préciser.


clairement est de trop dans ce paragraphe. Rien compris.


La prochaine fois que vous voulez étendre la signification d'un tag pour
autre chose, réfléchissez un peu à la compatibilité. Et il ne suffit pas
de compléter la doc sur le wiki, car cela resterea unilatéral alors que
le tag est déjà utilisé d'une autre façon par énormément de monde qui
n'a pas été consulté.


réfléchissez un peu à la compatibilité : ça me semble assez bien 
résumer ce qu'on essaie de faire dans ce fil.



Noter aussi que les relations ne sont pas les seuls moyens de
représenter une zone: s'il n'y a pas lieu de découper les frontières
parce qu'un élément de même type n'est pas présent à ses frontières, OSM
suppose déjà qu'une relation n'est ni nécessaire, ni souhaitable (on ne
veut pas de relation à un seul membre par exemple), et on se retrouve
donc avec des chemins qui devraient disposer exactement des mêmes tags...


Une zone, non. Mais un _découpage_ , si. Sauf à dupliquer les 
frontières, ce qu'on ne fait pas dans OSM.


vincent

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

Re: [OSM-talk-fr] Découpages des académies...

J'ai l'impression que j'aurai du mal à expliquer ça vu qu'apparemment tu ne
sais pas ce qu'est une base SQL, un modèle de données, et un schéma.

Ce que je peux dire c'est qu'OSM est structuré comme si tout était un seul
feature unique réunissant tous les features qu'une base GIS normale
utilise (y compris les bases utilisées pour faire tous les rendus OSM
actuels, car ils ne peuvent pas travailler directement avec le
pseudo-schéma OSM où tout est mélangé et horriblement compliqué, sans faire
d'abord une traduction, et c'est dans cette traduction que cela se
complique énormément dès qu'on commence à réutiliser des tags identiques
pour des usages très différents qui n'ont pas à figurer dans la même table
de feature externe).

La solutoin basée sur des combinaisons booléennes n'est qu'une
heuristique, avec des tas d'erreurs. Ce n'est pas viable, et cela échouera
dès que quelqu'un tentera à nouveau de surcharger les mêmes tags pour
encore un nouvel usage. Bref les requêtes sont de plus en plus compliquées
et sans cesse à corriger. C'est une véritable perte de temps et un gachis
de ressources sur les serveurs qui doivent faire encore plus de travail.

Le 9 juin 2013 15:39, arnaud@gmail.com arnaud@gmail.com a écrit :

Philippe,

Postgres n'a aucune obligation d'utiliser les mêmes clés OSM, il
utilise des tables séparées pour chaque feature, et avec des colonnes dont
les noms sont spécifiques à chaque table (le nom de la table elle-même les
isole, même s'ils sont homonymes, ils peuvent donc y être simplifiés). Il
n'y a PAS de clé dans Postgres dans un export GIS au même sens que dans OSM.

Tu peux clarifier ce passage s'il te plaît. Je ne comprends pas ce que tu
veux dire.

Merci.

--
--**--**
Arnaud Vandecasteele
SIG - WebMapping - Spatial Ontology - GeoCollaboration

Web Site
http://www.marinegis.com/?**page_id=131http://www.marinegis.com/?page_id=131
http://geotribu.net/

__**_
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.**org/listinfo/talk-frhttp://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] Découpages des académies...

Le 9 juin 2013 15:46, Vincent de Château-Thierry v...@laposte.net a écrit
:


  Noter aussi que les relations ne sont pas les seuls moyens de
 représenter une zone: s'il n'y a pas lieu de découper les frontières
 parce qu'un élément de même type n'est pas présent à ses frontières, OSM
 suppose déjà qu'une relation n'est ni nécessaire, ni souhaitable (on ne
 veut pas de relation à un seul membre par exemple), et on se retrouve
 donc avec des chemins qui devraient disposer exactement des mêmes tags...


 Une zone, non. Mais un _découpage_ , si. Sauf à dupliquer les frontières,
 ce qu'on ne fait pas dans OSM.


Ah bon ??? Comment ne pas oublier le cas des îles (maritimes, ou îles
d'un découpage autre que terre/mer). Je maintiens qu'on se retrouve à gérer
aussi bien des relations (pour éviter un partage) ou pas de relation du
tout (chemin fermé) pour les mêmes types d'objets, et qu'il n'y a pas lieu
de les taguer différemment, MÊME et SURTOUT si on éviter de dupliquer les
frontières.

On a par exemple une règle admise dans la base OSM qui est de ne PAS créer
de relation pour un seul membre, ce qui impose de descendre les tags de la
relation vers le chemin ou le noued membre et supprimer cette relation
parasite (ou ne pas en créer).

De fait les tags sont conservés, et doivent pouvoir se mélanger librement
sans conflit d'interprétation. Et pas question d'utiliser des tags
différents selon que c'est une relation ou un chemin ou un noeud.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Découpages des académies...

2013-06-09 Par sujet arnaud....@gmail.com


On 09/06/2013 11:18, Philippe Verdy wrote:
J'ai l'impression que j'aurai du mal à expliquer ça vu qu'apparemment 
tu ne sais pas ce qu'est une base SQL, un modèle de données, et un schéma.


Oui tu as raison avec un doctorant en informatique, je ne sais pas ce 
que je sais...


Je t'ai demandé dans mon 1er mail, de manière fort polie, de clarifier 
tes propos.

Maintenant je vais le faire d'une manière moins protocolaire.
Ton mail précédent, tout comme celui-ci, ne sont qu'une suite de mots, à 
consonance technique, sans fondements.
Mais bon ce ne sera pas la première fois que tu affirmes quelque chose 
de complètement faux, nous y sommes habitués.
La solutoin basée sur des combinaisons booléennes n'est qu'une 
heuristique, avec des tas d'erreurs. Ce n'est pas viable, et cela 
échouera dès que quelqu'un tentera à nouveau de surcharger les mêmes 
tags pour encore un nouvel usage. Bref les requêtes sont de plus en 
plus compliquées et sans cesse à corriger. C'est une véritable perte 
de temps et un gachis de ressources sur les serveurs qui doivent faire 
encore plus de travail.


Philippe, honnêtement as-tu, ne serait ce qu'une fois dans ta vie, 
importé une base OSM et effectué des requêtes?

Si oui, je serai heureux de voir un bout de code, même une requête.
Car à part brasser du vide, tu ne fais pas avancer grand chose.

Ne te sens surtout pas obligé de répondre.
A moins que tu ne souhaites vraiment que je redise sur la liste tes 4 
vérités.


Arnaud




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

Re: [OSM-talk-fr] Découpages des académies...



Le 09/06/2013 15:33, Philippe Verdy a écrit :

Les clés dans les extractions vers Postgres peuvent être réduites même
sans réutiliser les tags dans OSM. Les requêtes faites dans les tables
de features Postgres n'ont strictement rien à voir, les modèles de
données sont complètement différents.



Postgres n'a aucune obligation d'utiliser les mêmes clés OSM, il
utilise des tables séparées pour chaque feature, et avec des colonnes
dont les noms sont spécifiques à chaque table (le nom de la table
elle-même les isole, même s'ils sont homonymes, ils peuvent donc y être
simplifiés).


Encore une belle illustration de ton ignorance bavarde. Prends un jour 
le temps de mouliner des données brutes OSM dans une base Postgres via 
osm2pgsql ou osmosis, qui sont je pense les deux technologies les plus 
populaires pour charger les données en base. Tu apprendras comment ces 
logiciels fonctionnent, et ça t'éviteras ce genre de couplet 100% erroné.


Il n'y a PAS de clé dans Postgres dans un export GIS au

même sens que dans OSM.


Encore une phrase qui ne veut rien dire.

vincent

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

Re: [OSM-talk-fr] Découpages des académies...

Vous le faites exprès ou quoi pour ne pas comprendre ? Si vous avez des
compétences en bases de données (c'est aussi mon boulot, me^me si ça ne
vous semble pas évident) ne feignez pas de rien comprendre.

OSM n'a dans sa table qu'une table unique (en fait 3 pour séparer seulement
noeuds, chemins et relations, plus des tables annexes pour les membres de
relation), et les 3 tables utilisent une table unique pour tous les tags
(type d'objet=un des 3, id, clé, valeur). Juste de quoi reproduire ce qu'on
voit dans les requêtes XML de son API et rien de plus.

OSM n'a aucune table de feature, il n'a aucune structure relationelle (ou
si peu que ce n'est pas utilisable et qu'on doit tout convertir avec des
requêtes déjà compliquées) qui permette de faire ce qu'on a dans un rendu
quelconque (où par exemple on stocke séparément les routes, les voies
ferrées, les villes, les forêts, etc... le nombre de tables générées étant
dépendant de chaque application et de ce qu'elle souhaite représenter).

Le 9 juin 2013 16:00, Vincent de Château-Thierry v...@laposte.net a écrit
:

Le 09/06/2013 15:33, Philippe Verdy a écrit :

Les clés dans les extractions vers Postgres peuvent être réduites même
sans réutiliser les tags dans OSM. Les requêtes faites dans les tables
de features Postgres n'ont strictement rien à voir, les modèles de
données sont complètement différents.

Postgres n'a aucune obligation d'utiliser les mêmes clés OSM, il
utilise des tables séparées pour chaque feature, et avec des colonnes
dont les noms sont spécifiques à chaque table (le nom de la table
elle-même les isole, même s'ils sont homonymes, ils peuvent donc y être
simplifiés).

Encore une belle illustration de ton ignorance bavarde. Prends un jour le
temps de mouliner des données brutes OSM dans une base Postgres via
osm2pgsql ou osmosis, qui sont je pense les deux technologies les plus
populaires pour charger les données en base. Tu apprendras comment ces
logiciels fonctionnent, et ça t'éviteras ce genre de couplet 100% erroné.

Il n'y a PAS de clé dans Postgres dans un export GIS au

même sens que dans OSM.

Encore une phrase qui ne veut rien dire.

vincent

__**_
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.**org/listinfo/talk-frhttp://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] Découpages des académies...


Le 09/06/2013 16:18, Philippe Verdy a écrit :
Vous le faites exprès ou quoi pour ne pas comprendre ? Si vous avez 
des compétences en bases de données (c'est aussi mon boulot, me^me si 
ça ne vous semble pas évident) ne feignez pas de rien comprendre.


OSM n'a dans sa table qu'une table unique (en fait 3 pour séparer 
seulement noeuds, chemins et relations, plus des tables annexes pour 
les membres de relation), et les 3 tables utilisent une table unique 
pour tous les tags (type d'objet=un des 3, id, clé, valeur). Juste de 
quoi reproduire ce qu'on voit dans les requêtes XML de son API et rien 
de plus.


OSM n'a aucune table de feature, il n'a aucune structure 
relationelle (ou si peu que ce n'est pas utilisable et qu'on doit tout 
convertir avec des requêtes déjà compliquées) qui permette de faire ce 
qu'on a dans un rendu quelconque (où par exemple on stocke séparément 
les routes, les voies ferrées, les villes, les forêts, etc... le 
nombre de tables générées étant dépendant de chaque application et de 
ce qu'elle souhaite représenter).



Philippe,
Si tu veux survivre plus de cinq minutes à l'incrédulité générale et au 
fait de passer irrémédiablement pour un c**, je te conseille de nous 
poster le schéma de tes tables postgis ou le lien vers un schéma que tu 
utilises.


Sinon, je crois qu'on fera tienne cette devinette :
La différence entre Philippe et un ventilateur ?
Et bien je vous laisse deviner !


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

Re: [OSM-talk-fr] Découpages des académies...


Le 09/06/2013 15:41, Philippe Verdy a écrit :




Le 9 juin 2013 15:06, Vincent Pottier vpott...@gmail.com 
mailto:vpott...@gmail.com a écrit :



Il faudrait réfléchir plus sérieusement.

Tout à fait. Tu peux t'y mettre.


Commence par te l'appliquer à toi-même.

Merci, c'est fait.
quand tu comprendras que la base OSM pour l'instant n'est pas 
structurée du tout comme une base GIS et que son modèle de données ne 
permet pas des distinctions aussi claires. Le seul moyen avec le 
modèle OSM plat de simuler les tables de features d'une base GIS c'est 
d'utiliser des conventions de préfixes pour nommer les tags (le 
préfixe deventant l'équivalent du nom de la table de feature externe, 
dans laquelle tu ne mélanges pas les choix et les carottes même si ce 
sont des légumes).


Heureusement que d'autres ont déjà commencé ! Ce qui permet
d'utiliser des mêmes clefs secondaires conjointement avec des
clefs primaires différentes : produce, operator... orthogonaux ou pas.


On en reparlera le jour où OSM commencera à supporter dans sa base 
directement des tables de features et pas seulement des objets 
indifférenciés, avec aussi l'intégration des schémas de données. Pour 
l'instant on n'y est pas (et ce n'est même pas envisagé). Alors soyons 
propre et évitons de tout mélanger (c'est déjà assez compliqué 
d'interroger la base OSM justement faute du moindre modèle de données).

As-tu déjà essayé sur une base osm2psql quelque chose du genre :
SELECT
name,
way
FROM
france_polygon
WHERE
boundary='administrative'
AND
admin_level='8'

Si oui, alors on en reparlera...
--
FrViPofm
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Découpages des académies...

Justement oui, mais tu ne parles pas là du tout de la base OSM elle-même !

Ta base osm2psql n'a rien à voir, c'est le résultat d'un import avec un
script de conversion ecrit en C qui effectue des sous-selection compliquées
pour traduire le schéma OSM en features importés dans ta base.

Bref tu fais encore semblant de ne pas comprendre que les deux bases n'ont
absolument rien à voir entre elles, les tables n'ont pas du tout le même
structure, et là vous êtres en train de décider quelquechose pour la base
OSM (les noms des tags), alors que ces tags sont totalement inexistants
dans ta requête donnée en exemple (ta requête contient juste des noms de
colonnes dans une table de feature appelée france_polygon).



Le 9 juin 2013 16:50, Vincent Pottier vpott...@gmail.com a écrit :

  Le 09/06/2013 15:41, Philippe Verdy a écrit :




 Le 9 juin 2013 15:06, Vincent Pottier vpott...@gmail.com a écrit :

Il faudrait réfléchir plus sérieusement.

 Tout à fait. Tu peux t'y mettre.


  Commence par te l'appliquer à toi-même.

 Merci, c'est fait.

   quand tu comprendras que la base OSM pour l'instant n'est pas
 structurée du tout comme une base GIS et que son modèle de données ne
 permet pas des distinctions aussi claires. Le seul moyen avec le modèle OSM
 plat de simuler les tables de features d'une base GIS c'est d'utiliser des
 conventions de préfixes pour nommer les tags (le préfixe deventant
 l'équivalent du nom de la table de feature externe, dans laquelle tu ne
 mélanges pas les choix et les carottes même si ce sont des légumes).


  Heureusement que d'autres ont déjà commencé ! Ce qui permet d'utiliser
 des mêmes clefs secondaires conjointement avec des clefs primaires
 différentes : produce, operator... orthogonaux ou pas.


  On en reparlera le jour où OSM commencera à supporter dans sa base
 directement des tables de features et pas seulement des objets
 indifférenciés, avec aussi l'intégration des schémas de données. Pour
 l'instant on n'y est pas (et ce n'est même pas envisagé). Alors soyons
 propre et évitons de tout mélanger (c'est déjà assez compliqué d'interroger
 la base OSM justement faute du moindre modèle de données).

 As-tu déjà essayé sur une base osm2psql quelque chose du genre :
 SELECT
 name,
 way
 FROM
 france_polygon
 WHERE
 boundary='administrative'
 AND
 admin_level='8'

 Si oui, alors on en reparlera...
 --
 FrViPofm

 ___
 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] Découpages des académies...

2013-06-09 Par sujet Christian Quest

Le 9 juin 2013 16:18, Philippe Verdy verd...@wanadoo.fr a écrit :
 Vous le faites exprès ou quoi pour ne pas comprendre ? Si vous avez des
 compétences en bases de données (c'est aussi mon boulot, me^me si ça ne vous
 semble pas évident) ne feignez pas de rien comprendre.

 OSM n'a dans sa table qu'une table unique (en fait 3 pour séparer seulement
 noeuds, chemins et relations, plus des tables annexes pour les membres de
 relation), et les 3 tables utilisent une table unique pour tous les tags
 (type d'objet=un des 3, id, clé, valeur). Juste de quoi reproduire ce qu'on
 voit dans les requêtes XML de son API et rien de plus.


Le schéma de la base utilisé par l'API est destiné à un unique usage:
le fonctionnement de l'API d'édition.
Ce schéma ne tire même pas partie de PostGIS car cela ne lui servirai
à pas grand chose.

Ce schéma n'a donc aucun rapport avec l'usage qu'on peut faire des
données. C'est d'ailleurs ce que j'explique souvent: les données OSM
n'ont pas de structure prédéterminée autre que sémantique, on est dans
une logique NoSQL et en fonction de l'usage qu'on veut en faire
(rendu, géocodage, routage, etc) on va les structurer de telle ou
telle façon (d'où des schémas différents proposés par osm2pgsql,
osmosis ou imposm).


Tes propos, bien que paraissant cohérents, sont purement théoriques et
ne reposent visiblement sur aucune expérience pratique.

Pour faire un rendu avec un schéma osm2pgsql, on utilise seulement 3 tables:
- une pour les objets ponctuels,
- une pour les objets linéaires,
- une pour les objets surfaciques.

Contrairement à ce que tu crois, routes, voies ferrées, lignes
électriques sont dans une seule et même table: planet_osm_line
Les polygones de découpages admin (donc les villes), les landuse (donc
les forêts), les terrains de sports sont dans la table
planet_osm_polygon

Philippe, si tu pouvais prendre le temps de te renseigner sérieusement
ça ferai gagner du temps à pas mal de monde:
- ceux qui lisent et qui savent et qui vont perdre du temps à corriger
tes affirmations,
- ceux qui lisent et ne savent pas qu'il faut prendre avec des
pincettes tes affirmations (l'unique raison qui fait que je lis encore
tes messages et que j'y réponds).

-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] Découpages des académies...

Enfin tu commences à comprendre !

Les tags dans OSM ne sont pas ce que tu utilises dans ta base issue d'un
export et d'une traduction avec osm2pgsql (ou autre chose) vers une base
GIS.

Toute la discussion portait sur les tables OSM qui n'ont pas de structure
(tu l'admets enfin), donc ont besoin d'avoir des tags précis (sinon c'est
ton script de traduction osm2pgsql qui va se tromper...)

Maintenant si ton problème est que tu mélanges tous les polygones
surfaciques dans ta base dans la même table, avec nécessité de créer une
colonne pour chaque tag distinct, et si ta base de données limite le nombre
de colonnes possibles par table, alors oui tu as un problème dans ta base,
mais ce n'est pas le problème d'OSM lui-même. Parce sur tu aurais pu tout
autant séparer ces polygones pour avoir une base bien plus facile à
exploiter. Tu auras de toute façon autant de problème à distinguer les
objets importés de cette façon que dans les données OSM initiales, si tu as
mélangé les tags en en surchargeant certains pour des rôles différents.

C'est toi qui sur ta base prend la décision de faire ce schéma GIS
ultrasimplifié, réduit à pas grand chose d'utilisable.

Et même si tu mets tes polygones dans la même table (en fait uniquement
pour stoker la géométrie), ta base SQL peut encore stocker les tags par
type de feature dans des tables séparées. A mon avis c'est une des
premières choses que tu dois faire après cet import avant de pouvoir
continuer, tu es amené à grouper un certain nombre de polygones, chercher
des équivalences, ou ignorer certaines différences pour les unifier. Une
partie de ce traval sera fait dans ton script osm2pgsql modifié localement
selon tes besoins, plutôt que d'avoir à le faire après import dans ta base.

OSM dans sa base ne t'impose absolument pas de tout mélanger, et c'est ton
script osm2pgsql (dont il existe autant de versions que de moteurs de rendu
à l'utiliser) qui a besoin d'être amélioré pour mieux classer les choses.
C'est toi qu iest entièrement responsable de ton schéma interne, qui ne
nous intéresse pas dans la base OSM (donc on n'a pas à être gêné par ça
pour nommer correctement et distinguer les tags, qu'en fait tu n'utilises
plus directement dans ta base issue de ta propre traduction).



Le 9 juin 2013 17:28, Christian Quest cqu...@openstreetmap.fr a écrit :

 Le 9 juin 2013 16:18, Philippe Verdy verd...@wanadoo.fr a écrit :
  Vous le faites exprès ou quoi pour ne pas comprendre ? Si vous avez des
  compétences en bases de données (c'est aussi mon boulot, me^me si ça ne
 vous
  semble pas évident) ne feignez pas de rien comprendre.
 
  OSM n'a dans sa table qu'une table unique (en fait 3 pour séparer
 seulement
  noeuds, chemins et relations, plus des tables annexes pour les membres de
  relation), et les 3 tables utilisent une table unique pour tous les tags
  (type d'objet=un des 3, id, clé, valeur). Juste de quoi reproduire ce
 qu'on
  voit dans les requêtes XML de son API et rien de plus.
 

 Le schéma de la base utilisé par l'API est destiné à un unique usage:
 le fonctionnement de l'API d'édition.
 Ce schéma ne tire même pas partie de PostGIS car cela ne lui servirai
 à pas grand chose.

 Ce schéma n'a donc aucun rapport avec l'usage qu'on peut faire des
 données. C'est d'ailleurs ce que j'explique souvent: les données OSM
 n'ont pas de structure prédéterminée autre que sémantique, on est dans
 une logique NoSQL et en fonction de l'usage qu'on veut en faire
 (rendu, géocodage, routage, etc) on va les structurer de telle ou
 telle façon (d'où des schémas différents proposés par osm2pgsql,
 osmosis ou imposm).


 Tes propos, bien que paraissant cohérents, sont purement théoriques et
 ne reposent visiblement sur aucune expérience pratique.

 Pour faire un rendu avec un schéma osm2pgsql, on utilise seulement 3
 tables:
 - une pour les objets ponctuels,
 - une pour les objets linéaires,
 - une pour les objets surfaciques.

 Contrairement à ce que tu crois, routes, voies ferrées, lignes
 électriques sont dans une seule et même table: planet_osm_line
 Les polygones de découpages admin (donc les villes), les landuse (donc
 les forêts), les terrains de sports sont dans la table
 planet_osm_polygon

 Philippe, si tu pouvais prendre le temps de te renseigner sérieusement
 ça ferai gagner du temps à pas mal de monde:
 - ceux qui lisent et qui savent et qui vont perdre du temps à corriger
 tes affirmations,
 - ceux qui lisent et ne savent pas qu'il faut prendre avec des
 pincettes tes affirmations (l'unique raison qui fait que je lis encore
 tes messages et que j'y réponds).

 --
 Christian Quest - OpenStreetMap France
 Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

 ___
 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] Découpages des académies...


Le 09/06/2013 17:47, Philippe Verdy a écrit :

Enfin tu commences à comprendre !

Toi, pas.


Les tags dans OSM ne sont pas ce que tu utilises dans ta base issue 
d'un export et d'une traduction avec osm2pgsql (ou autre chose) vers 
une base GIS.

Si, les tags dans OSM sont traduits dans ma base postgis.


Toute la discussion portait sur les tables OSM qui n'ont pas de 
structure (tu l'admets enfin), donc ont besoin d'avoir des tags précis 
(sinon c'est ton script de traduction osm2pgsql qui va se tromper...)

Toute ? Non !
(voir le début d'une célèbre BD gauloise)

Tes propos, Philippe. Tes propos portent sur des tables OSM. Et je ne 
suis même pas sur que tu sois allé voir le schéma.


Maintenant si ton problème...

Mon problème ?
Mais Philippe, on est nombreux à utiliser les données OSM sur base de 
donnée locale.





C'est toi qui sur ta base prend la décision de faire ce schéma GIS 
ultrasimplifié, réduit à pas grand chose d'utilisable.

Philippe.

DONNE-NOUS LE SCHÉMA DE TA BASE MIRACLE !
ou arête de dire des âneries. (et je reste poli !)

--
FrViPofm

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

Re: [OSM-talk-fr] Découpages des académies...

2013-06-09 Par sujet Christian Quest

Le 9 juin 2013 17:47, Philippe Verdy verd...@wanadoo.fr a écrit :
 Toute la discussion portait sur les tables OSM qui n'ont pas de structure
 (tu l'admets enfin), donc ont besoin d'avoir des tags précis (sinon c'est
 ton script de traduction osm2pgsql qui va se tromper...)


La notion de table OSM n'a pas de sens... c'est ça que je voulais
surtout faire passer comme idée, mais visiblement ça te dépasse peut
être à cause d'un ancrage trop fort dans les notions GIS historiques.

 Maintenant si ton problème est que tu mélanges tous les polygones
 surfaciques dans ta base dans la même table, avec nécessité de créer une
 colonne pour chaque tag distinct, et si ta base de données limite le nombre
 de colonnes possibles par table, alors oui tu as un problème dans ta base,
 mais ce n'est pas le problème d'OSM lui-même. Parce sur tu aurais pu tout
 autant séparer ces polygones pour avoir une base bien plus facile à
 exploiter. Tu auras de toute façon autant de problème à distinguer les
 objets importés de cette façon que dans les données OSM initiales, si tu as
 mélangé les tags en en surchargeant certains pour des rôles différents.

 C'est toi qui sur ta base prend la décision de faire ce schéma GIS
 ultrasimplifié, réduit à pas grand chose d'utilisable.


Visiblement tu ne connais pas osm2pgsql, car c'est comme ça que cet
outil (très largement utilisé faut-il le rappeler) fonctionne.
Je n'ai fait aucun choix sur ce schéma.

 Et même si tu mets tes polygones dans la même table (en fait uniquement pour
 stoker la géométrie), ta base SQL peut encore stocker les tags par type de
 feature dans des tables séparées. A mon avis c'est une des premières choses
 que tu dois faire après cet import avant de pouvoir continuer, tu es amené à
 grouper un certain nombre de polygones, chercher des équivalences, ou
 ignorer certaines différences pour les unifier. Une partie de ce traval sera
 fait dans ton script osm2pgsql modifié localement selon tes besoins, plutôt
 que d'avoir à le faire après import dans ta base.


Aucune modification de script pour ma part. osm2pgsql est utilisé tel quel.


 OSM dans sa base ne t'impose absolument pas de tout mélanger, et c'est ton
 script osm2pgsql (dont il existe autant de versions que de moteurs de rendu
 à l'utiliser) qui a besoin d'être amélioré pour mieux classer les choses.

Bon, c'est confirmé... pour combler tes lacunes sur osm2pgsql c'est
ici que ça se passe: http://wiki.openstreetmap.org/wiki/Osm2pgsql


 C'est toi qu iest entièrement responsable de ton schéma interne, qui ne nous
 intéresse pas dans la base OSM (donc on n'a pas à être gêné par ça pour
 nommer correctement et distinguer les tags, qu'en fait tu n'utilises plus
 directement dans ta base issue de ta propre traduction).


Et pourtant... j'utilise les tags directement, étonnant non ?

Les tags sont stockés en hstore (nommé tags avec une extrême
originalité donc).
Au cas où, voilà le lien pour te documenter :
http://wiki.openstreetmap.org/wiki/Osm2pgsql#hstore

Dans notre cas (vous vous souvenez, les académies), cela donnerai:

SELECT way FROM planet_osm_polygon WHERE boundary='educational AND
tags-'boundary:level'=5;


Dernier post sur le hors-sujet pour moi.
-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] Découpages des académies...

Désolé mais on ne parle visiblement pas de la même chose.

Pas la peine d'accuser l'autre de ses lacunes puisque dès le départ vous
avez confondu (avec insistance en plus, ce qui est pourtant faux !) la base
OSM avec vos bases Pgsql traduites par un script spécifique (tuné en
fonction de Mapnik le plus souvent).
Tout cela n'a rien à voir avec les tags d'OSM, j'insiste, c'est votre
cuisine locale.

Et même si vous conservez les tags dans un hstore vous aurez les mêmes
ambiguités à résoudre si elles ne sont pas résolues dès le départ dans la
base OSM (non structurée). Ce hstore en passant n'a aucune problème à
garder les tags OSM originaux, puisqu'en fait votre base ne l'utilise que
comme source de métafonnées annexes, dans un vrac aussi informe que la bae
OSM d'origine.

Personnellement je n'utilise pas du tout Mapnik (en fait je ne fais que
visualiser des rendus effectués par d'autres, mais ce n'est pas les seuls
rendus que je visualise) ce n'est pas mon problème et je n'en ai absolument
pas besoin (et plein de monde utilisant les données d'OSM n'en a pas besoin
non plus et n'est pas gêné par les restrictions ou insuffisances ou
limitations de Mapnik).

Et je ne vois pas pourquoi OSM devrait être contraint par ce que sait (ou
ne sait pas) faire Mapnik. Bien au contraire, si on est plus précis dans la
base OSM, c'est Mapnik qui aura moins de difficultés à interpréter les
résultats puisqu'il n'aura plus d'ambiguités.



Le 9 juin 2013 18:27, Christian Quest cqu...@openstreetmap.fr a écrit :

 Le 9 juin 2013 17:47, Philippe Verdy verd...@wanadoo.fr a écrit :
  Toute la discussion portait sur les tables OSM qui n'ont pas de structure
  (tu l'admets enfin), donc ont besoin d'avoir des tags précis (sinon c'est
  ton script de traduction osm2pgsql qui va se tromper...)
 

 La notion de table OSM n'a pas de sens... c'est ça que je voulais
 surtout faire passer comme idée, mais visiblement ça te dépasse peut
 être à cause d'un ancrage trop fort dans les notions GIS historiques.

  Maintenant si ton problème est que tu mélanges tous les polygones
  surfaciques dans ta base dans la même table, avec nécessité de créer une
  colonne pour chaque tag distinct, et si ta base de données limite le
 nombre
  de colonnes possibles par table, alors oui tu as un problème dans ta
 base,
  mais ce n'est pas le problème d'OSM lui-même. Parce sur tu aurais pu tout
  autant séparer ces polygones pour avoir une base bien plus facile à
  exploiter. Tu auras de toute façon autant de problème à distinguer les
  objets importés de cette façon que dans les données OSM initiales, si tu
 as
  mélangé les tags en en surchargeant certains pour des rôles différents.
 
  C'est toi qui sur ta base prend la décision de faire ce schéma GIS
  ultrasimplifié, réduit à pas grand chose d'utilisable.
 

 Visiblement tu ne connais pas osm2pgsql, car c'est comme ça que cet
 outil (très largement utilisé faut-il le rappeler) fonctionne.
 Je n'ai fait aucun choix sur ce schéma.

  Et même si tu mets tes polygones dans la même table (en fait uniquement
 pour
  stoker la géométrie), ta base SQL peut encore stocker les tags par type
 de
  feature dans des tables séparées. A mon avis c'est une des premières
 choses
  que tu dois faire après cet import avant de pouvoir continuer, tu es
 amené à
  grouper un certain nombre de polygones, chercher des équivalences, ou
  ignorer certaines différences pour les unifier. Une partie de ce traval
 sera
  fait dans ton script osm2pgsql modifié localement selon tes besoins,
 plutôt
  que d'avoir à le faire après import dans ta base.
 

 Aucune modification de script pour ma part. osm2pgsql est utilisé tel quel.


  OSM dans sa base ne t'impose absolument pas de tout mélanger, et c'est
 ton
  script osm2pgsql (dont il existe autant de versions que de moteurs de
 rendu
  à l'utiliser) qui a besoin d'être amélioré pour mieux classer les choses.

 Bon, c'est confirmé... pour combler tes lacunes sur osm2pgsql c'est
 ici que ça se passe: http://wiki.openstreetmap.org/wiki/Osm2pgsql


  C'est toi qu iest entièrement responsable de ton schéma interne, qui ne
 nous
  intéresse pas dans la base OSM (donc on n'a pas à être gêné par ça pour
  nommer correctement et distinguer les tags, qu'en fait tu n'utilises plus
  directement dans ta base issue de ta propre traduction).
 

 Et pourtant... j'utilise les tags directement, étonnant non ?

 Les tags sont stockés en hstore (nommé tags avec une extrême
 originalité donc).
 Au cas où, voilà le lien pour te documenter :
 http://wiki.openstreetmap.org/wiki/Osm2pgsql#hstore

 Dans notre cas (vous vous souvenez, les académies), cela donnerai:

 SELECT way FROM planet_osm_polygon WHERE boundary='educational AND
 tags-'boundary:level'=5;


 Dernier post sur le hors-sujet pour moi.
 --
 Christian Quest - OpenStreetMap France
 Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org

Re: [OSM-talk-fr] Découpages des académies...

admin_level vaut pour boundary=administrative, on a vu l'effet pervers
de l'utiliser ailleurs (Nominatim qui ressort les diocèses par
exemple).

Si il est utile, un boundary:level serait plus cohérent, non ?

Par contre un petit tag pour indiquer la zone A/B/C de vacances y
aurait bien sa place...


Le 7 juin 2013 23:42, Vincent de Château-Thierry v...@laposte.net a écrit :


 Le 07/06/2013 23:07, Francescu GAROBY a écrit :

 Tu parles des académies de l'Éducation Nationale, c'est bien ça ?
 Je proposerais bien boundary=educative, éventuellement couplé à un
 admin_level (mais pour quel usage ?), pour rester cohérent avec les
 boundary=administrative et les boundary=religious


 Le 7 juin 2013 22:59, Christian Quest cqu...@openstreetmap.fr
 mailto:cqu...@openstreetmap.fr a écrit :


 Le découpage des académies ? Ca vous inspire ?

 boundary=* ?

 En attendant, j'ai eu besoin de créer celle de Versailles qui n'est
 qu'en multipolygone sans rien d'autre...


 De ce que je comprends du découpage [1], on n'a pas forcément une
 imbrication de zones, et si c'est confirmé (par ceux qui savent mieux que
 moi) alors pourquoi s'embêter avec un tag de type level ?

 vincent

 [1] : http://fr.wikipedia.org/wiki/Acad%C3%A9mie_(%C3%A9ducation)


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



-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] Découpages des académies...

2013-06-08 Par sujet Nicolas Dumoulin

Le samedi 8 juin 2013 08:36:02 Christian Quest a écrit :
 admin_level vaut pour boundary=administrative, on a vu l'effet pervers
 de l'utiliser ailleurs (Nominatim qui ressort les diocèses par
 exemple).
 
 Si il est utile, un boundary:level serait plus cohérent, non ?

Je verrai plutôt educative:level, ce serait plus cohérent selon moi.

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-talk-fr] Découpages des académies...

2013-06-08 Par sujet Philippe Verdy

pourquoi a-t-on même besoin d'un level pour les académies ? C'est quoi la
hiérarchie envisagée ???
N'est pas suffisant d'avoir boundary=educational (meilleur terme en anglais
pour le secteur éducatif) ?

Ou l'idée c'est de créer la carte scolaire locale (qui en fait est du
ressort des collectivités qu'on a déjà cartographiées, surtout les EPCI,
les frontières de quartiers étant peu pertinentes sur cette carte, sauf les
arrondissements municipaux)


Le 8 juin 2013 15:14, Nicolas Dumoulin 
nicolas_openstreetmap@dumoulin63.net a écrit :

 Le samedi 8 juin 2013 08:36:02 Christian Quest a écrit :
  admin_level vaut pour boundary=administrative, on a vu l'effet pervers
  de l'utiliser ailleurs (Nominatim qui ressort les diocèses par
  exemple).
 
  Si il est utile, un boundary:level serait plus cohérent, non ?

 Je verrai plutôt educative:level, ce serait plus cohérent selon moi.

 --
 Nicolas Dumoulin
 http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

 ___
 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] Découpages des académies...

Ca fait penser à un niveau d'éducation plus qu'un niveau de découpage
et l'intérêt c'est que boundary:level pourrait être utilisé sur
d'autres types de découpages (religieux par exemple).
Multiplier les clés de tags ne me semble pas une bonne idée, mais bon
c'est qu'une impression.


Le 8 juin 2013 15:14, Nicolas Dumoulin
nicolas_openstreetmap@dumoulin63.net a écrit :
 Le samedi 8 juin 2013 08:36:02 Christian Quest a écrit :
 admin_level vaut pour boundary=administrative, on a vu l'effet pervers
 de l'utiliser ailleurs (Nominatim qui ressort les diocèses par
 exemple).

 Si il est utile, un boundary:level serait plus cohérent, non ?

 Je verrai plutôt educative:level, ce serait plus cohérent selon moi.

 --
 Nicolas Dumoulin
 http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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



-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] Découpages des académies...

2013-06-08 Par sujet Philippe Verdy

Le niveau d'éducation serait en fait plutôt educational:grade, non ?
Sinon on a déjà des tags de classification française pour les écoles
maternelles primaires, secondaires, professionelles, supérieures, mais rien
de vraiment probant par niveau de type Bac-2 ou Bac+5, ou CE1.

Je répète aussi que educative n'est pas le bon mot (ce serait un
francisme), en anglais on dit educational.



Le 8 juin 2013 15:19, Christian Quest cqu...@openstreetmap.fr a écrit :

 Ca fait penser à un niveau d'éducation plus qu'un niveau de découpage
 et l'intérêt c'est que boundary:level pourrait être utilisé sur
 d'autres types de découpages (religieux par exemple).
 Multiplier les clés de tags ne me semble pas une bonne idée, mais bon
 c'est qu'une impression.


 Le 8 juin 2013 15:14, Nicolas Dumoulin
 nicolas_openstreetmap@dumoulin63.net a écrit :
  Le samedi 8 juin 2013 08:36:02 Christian Quest a écrit :
  admin_level vaut pour boundary=administrative, on a vu l'effet pervers
  de l'utiliser ailleurs (Nominatim qui ressort les diocèses par
  exemple).
 
  Si il est utile, un boundary:level serait plus cohérent, non ?
 
  Je verrai plutôt educative:level, ce serait plus cohérent selon moi.
 
  --
  Nicolas Dumoulin
  http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin
 
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-fr



 --
 Christian Quest - OpenStreetMap France
 Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

 ___
 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] Découpages des académies...

Si on regarde un peu plus loin que le sujet des académies, je pense
qu'on va découvrir des découpages scolaires plus ou moins
hiérarchiques, peut être pas en France, mais il y a de fortes chances
qu'il y en ait dans d'autres pays... pendant un peu plus loin que les
bords de notre hexagone ;)

De plus mon idée avec boundary:level=* est d'avoir un tag un peu plus
générique qui pourrait s'appliquer à tout type de boundary


Le 8 juin 2013 15:20, Philippe Verdy verd...@wanadoo.fr a écrit :
 pourquoi a-t-on même besoin d'un level pour les académies ? C'est quoi la
 hiérarchie envisagée ???
 N'est pas suffisant d'avoir boundary=educational (meilleur terme en anglais
 pour le secteur éducatif) ?

 Ou l'idée c'est de créer la carte scolaire locale (qui en fait est du
 ressort des collectivités qu'on a déjà cartographiées, surtout les EPCI, les
 frontières de quartiers étant peu pertinentes sur cette carte, sauf les
 arrondissements municipaux)


 Le 8 juin 2013 15:14, Nicolas Dumoulin
 nicolas_openstreetmap@dumoulin63.net a écrit :

 Le samedi 8 juin 2013 08:36:02 Christian Quest a écrit :

  admin_level vaut pour boundary=administrative, on a vu l'effet pervers
  de l'utiliser ailleurs (Nominatim qui ressort les diocèses par
  exemple).
 
  Si il est utile, un boundary:level serait plus cohérent, non ?

 Je verrai plutôt educative:level, ce serait plus cohérent selon moi.

 --
 Nicolas Dumoulin
 http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

 ___
 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




-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] Découpages des académies...

2013-06-08 Par sujet Philippe Verdy

Dans les autres pays les cartes scolaires sont fortement orientés selon les
confession religieuses, et encore moins bien régulé par l'état, avec plus
de concurrence. Ce qui rend ces hiérarchies supposées encore moins
pertinentes.
Pour l'instant pas la peine de faire des suppositions, on ne devrait se
pencher que sur ce qu'on a réellement à cartographier.

On verra le moment venu pour les autres pays si on a des choses à commenter
sur le sujet, mais pas sur que cette liste soit appropriée pour discuter
des autres pays (surtout non francophones). Laissons ces autres communautés
en décider, et voyons plus tard seulement ce qu'on peut en tirer de commun
s'il y a lieu.


Le 8 juin 2013 15:28, Christian Quest cqu...@openstreetmap.fr a écrit :

 Si on regarde un peu plus loin que le sujet des académies, je pense
 qu'on va découvrir des découpages scolaires plus ou moins
 hiérarchiques, peut être pas en France, mais il y a de fortes chances
 qu'il y en ait dans d'autres pays... pendant un peu plus loin que les
 bords de notre hexagone ;)

 De plus mon idée avec boundary:level=* est d'avoir un tag un peu plus
 générique qui pourrait s'appliquer à tout type de boundary


 Le 8 juin 2013 15:20, Philippe Verdy verd...@wanadoo.fr a écrit :
  pourquoi a-t-on même besoin d'un level pour les académies ? C'est quoi
 la
  hiérarchie envisagée ???
  N'est pas suffisant d'avoir boundary=educational (meilleur terme en
 anglais
  pour le secteur éducatif) ?
 
  Ou l'idée c'est de créer la carte scolaire locale (qui en fait est du
  ressort des collectivités qu'on a déjà cartographiées, surtout les EPCI,
 les
  frontières de quartiers étant peu pertinentes sur cette carte, sauf les
  arrondissements municipaux)
 
 
  Le 8 juin 2013 15:14, Nicolas Dumoulin
  nicolas_openstreetmap@dumoulin63.net a écrit :
 
  Le samedi 8 juin 2013 08:36:02 Christian Quest a écrit :
 
   admin_level vaut pour boundary=administrative, on a vu l'effet pervers
   de l'utiliser ailleurs (Nominatim qui ressort les diocèses par
   exemple).
  
   Si il est utile, un boundary:level serait plus cohérent, non ?
 
  Je verrai plutôt educative:level, ce serait plus cohérent selon moi.
 
  --
  Nicolas Dumoulin
  http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin
 
  ___
  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
 



 --
 Christian Quest - OpenStreetMap France
 Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

 ___
 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] Découpages des académies...

2013-06-08 Par sujet Vincent de Château-Thierry


Bonjour,

Le 08/06/2013 15:28, Christian Quest a écrit :

Si on regarde un peu plus loin que le sujet des académies, je pense
qu'on va découvrir des découpages scolaires plus ou moins
hiérarchiques, peut être pas en France, mais il y a de fortes chances
qu'il y en ait dans d'autres pays... pendant un peu plus loin que les
bords de notre hexagone ;)

De plus mon idée avec boundary:level=* est d'avoir un tag un peu plus
générique qui pourrait s'appliquer à tout type de boundary



J'approuve complètement cette idée de tag boundary:level, qui 
deviendrait orthogonal au tag boundary, sans lien particulier avec une 
des valeurs, comme c'est aujourd'hui le cas avec admin_level.
On combinerait boundary=* et boundary:level=* selon le besoin, et sans 
confusion.
Et en toute logique, il faudrait si on l'applique, le propager aussi aux 
boundary=administrative, à la place d'admin_level. Peut-être pas pour 
demain matin, mais pour de nouveaux types de limites (telles les 
académies, s'il y a besoin de hiérarchiser des niveaux) pourquoi pas 
démarrer directement avec ?


vincent

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

Re: [OSM-talk-fr] Découpages des académies...

2013-06-08 Par sujet Vincent Pottier


Le 08/06/2013 16:05, Vincent de Château-Thierry a écrit :


J'approuve complètement cette idée de tag boundary:level, qui 
deviendrait orthogonal au tag boundary, sans lien particulier avec une 
des valeurs, comme c'est aujourd'hui le cas avec admin_level.
On combinerait boundary=* et boundary:level=* selon le besoin, et sans 
confusion.
Et en toute logique, il faudrait si on l'applique, le propager aussi 
aux boundary=administrative, à la place d'admin_level. Peut-être pas 
pour demain matin, mais pour de nouveaux types de limites (telles les 
académies, s'il y a besoin de hiérarchiser des niveaux) pourquoi pas 
démarrer directement avec ?


vincent

+1
Et comme je sois être l'auteur de 95 % au moins des 
boundary=religious_administration ça peut s'appliquer sans problème par 
un bot avec mon accord !

--
FrViPofm

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

Re: [OSM-talk-fr] Découpages des académies...

2013-06-08 Par sujet Vincent de Château-Thierry




Le 08/06/2013 18:10, Vincent Pottier a écrit :

Le 08/06/2013 16:05, Vincent de Château-Thierry a écrit :


J'approuve complètement cette idée de tag boundary:level, qui
deviendrait orthogonal au tag boundary, sans lien particulier avec une
des valeurs, comme c'est aujourd'hui le cas avec admin_level.
On combinerait boundary=* et boundary:level=* selon le besoin, et sans
confusion.
Et en toute logique, il faudrait si on l'applique, le propager aussi
aux boundary=administrative, à la place d'admin_level. Peut-être pas
pour demain matin, mais pour de nouveaux types de limites (telles les
académies, s'il y a besoin de hiérarchiser des niveaux) pourquoi pas
démarrer directement avec ?

vincent

+1
Et comme je sois être l'auteur de 95 % au moins des
boundary=religious_administration ça peut s'appliquer sans problème par
un bot avec mon accord !


Eh ben yapluka :-)

Sinon un phénomène étrange sur layers à l'instant :
http://layers.openstreetmap.fr/?zoom=9lat=48.71193lon=2.12575layers=BFFTF
On voit en tant que département un découpage qui ressemble étrangement à 
l'Académie de Versailles, elle qui n'est pourtant tagguée qu'en 
multipolygon, sans précision d'admin_level sur la relation. Et ce nom 
L'Epte, que je ne retrouve pas dans une relation sur cette emprise.

Si quelqu'un y comprend quelque chose ?

vincent

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

Re: [OSM-talk-fr] Découpages des académies...