[OSM-talk-fr] L'Aquitaine en Espagne ?

Jeu 7 Avr 14:09:38 UTC 2016

Visiblement le serveur Overpass a un problème car il ne met plus du tout à
jour ses zones:

  "version": 0.6,
  "generator": "Overpass API",
  "osm3s": {
    "timestamp_osm_base": "2016-04-07T14:04:02Z",
    "timestamp_areas_base": "2016-03-30T00:26:01Z",
...

(le timestamp pour les areas n'a pas bougé d'un iota depuis hier, le retard
passe à 9 jours)

Le 6 avril 2016 à 19:09, Philippe Verdy <verdy_p at wanadoo.fr> a écrit :

> Dans le détail j'ai regardé, il n'y a pas d'anomalie géométriques dans la
> base OSM.
> La seule anomalie est un retard de la base des zones (areas) dans Overpass
> Turbo. Voici ce qui est retourné dans le détail des données:
>
>     "timestamp_osm_base": "2016-04-06T16:58:03Z",
>     "timestamp_areas_base": "2016-03-30T00:26:01Z",
>
> (on le voit aussi en survolant à la souris les infos statistiques
> affichées dans le coin inférieur droit de la carte)
>
> Bref la cause en est la modification de certains points de la frontière
> franco-espagnole depuis hier (recalage de quelques points sur les bornes
> frontières "'boundary_stone") sur les frontières des 3 communes françaises
> concernées par ces petits ajustements (Itxassou, Urrugne et Birriatou).
>
> Overpass Turbo a un retard de 8 jours pour sa base de zones, il faudra
> donc attendre un peu, sinon on peut améliorer la précision des requêtes en
> allant chercher la géométrie réelle dans les données OSM, pour éviter des
> inclusions trop grossières, car il n'y a aucune garantie à aucun moment que
> ces "area", ici {{geocodeArea:Spain}}, soient exactes ou à jour (il faut
> les considérer comme approximatives).
>
>
> Le 6 avril 2016 à 02:47, Philippe Verdy <verdy_p at wanadoo.fr> a écrit :
>
>> Il semble en plus que ces modifs viennent toutes d'un seul utilisateur
>> (bascophone selon ses commentaires) qui vient de bouger (il y a une
>> quinzaine d'heures) certains noeuds et d'en remplacer certains (pour passer
>> par d'autres noeuds, dont quelques noeuds ajoutés pour les "boundary
>> stone". Puis de réparer plus ou moins bien ce qui était cassé, en le
>> retraçant.
>>
>> Mais il ne semble pas s'être occupé correctement de reconnecter toutes
>> les relations dépendantes, même si ces modifs pourraient être justifiées
>> (notamment pour les positions des "boundary stones" observées sur le
>> terrain)
>>
>> Le 6 avril 2016 à 02:38, Philippe Verdy <verdy_p at wanadoo.fr> a écrit :
>>
>>> Voir donc les frontières internationales de ces communes françaises et
>>> comparer à celles de la commune espagnole voisine:
>>>
>>> *166907 <http://www.openstreetmap.org/relation/166907> Itxassou, 166733
>>> <http://www.openstreetmap.org/relation/166733> Urrugne, 166739
>>> <http://www.openstreetmap.org/relation/166739> Birriatou*
>>>
>>> Je n'ai pas regardé partout. Mais les ways ne correspondent pas
>>> exactement au moins pour ces trois communes françaises
>>>
>>> Le 6 avril 2016 à 02:33, Philippe Verdy <verdy_p at wanadoo.fr> a écrit :
>>>
>>>> Ajoute un critère "({{bbox}})" dans la requête (pour limiter les
>>>> données à une zone rectangulaire), et met admin_level=8 et tu verras aussi
>>>> les communes françaises inclues "en Espagne".
>>>>
>>>> Globalement, il semble que les segments frontières qui étaient communs
>>>> aux deux pays ont été séparés par endroit, ne se superposent plus
>>>> exactement le way utilisé d'un côté ne correspond pas exactement au way
>>>> utilisé de l'autre côté de la frontière, l'un deux ayant sans doute omis
>>>> certains noeuds intermédiaires ajoutés de l'autre, ou supprimés d'un seul
>>>> côté. Sans doute l'effet de quelqu'un qui a redessiné ces ways manuellement
>>>> côté français ou espagnol et pas refait la conflation correctement, ou une
>>>> restauration partielle de frontière brisée (au lieu de réinclure le segment
>>>> manquant qui existe dans la relation voisine, quelqu'un a retracé le bout
>>>> manquant par dessus l'autre).
>>>>
>>>> Le 6 avril 2016 à 02:24, Philippe Verdy <verdy_p at wanadoo.fr> a écrit :
>>>>
>>>>> D'ailleurs dans ta requête, change juste admin_level=4 en
>>>>> admin_level=2, et tu obtiens la France et l'Espagne.
>>>>> Change en admin_level=6 tu tu vois les provinces espagnoles (sauf
>>>>> celles qui sont aussi des communautés autonomes de niveau 4, dont Madrid,
>>>>> la région de Murcie, les Asturies et la Navarre), plus... le département
>>>>> des Pyrénées-Atlantiques.
>>>>>
>>>>> Je chercherais donc dans la double inclusion de cette petite île sur
>>>>> la frontière franco-espagnole à double souveraineté (entre Irun et Hendaye
>>>>> au milieu de la Bidassoa), qu'un contriibuteur espagnol a placée
>>>>> entièrement sous souveraineté espagnole, alors qu'avant elle était coupée
>>>>> en deux (arbitrairement il faut dire alors qu'il aurait fallu l'inclure
>>>>> dans les frontières des deux pays, ou bien créer une frontière de niveau 2
>>>>> séparée pour ce "condominion", comme cela a été fait entre le Luxembourg et
>>>>> l'Allemagne sur les eaux des fleuves qui servent de frontières).
>>>>>
>>>>>
>>>>> Le 6 avril 2016 à 01:52, Philippe Verdy <verdy_p at wanadoo.fr> a écrit :
>>>>>
>>>>>> C'est la "geocodeArea: Spain" qui est approximative, tracée avec des
>>>>>> grands segments qui débordent les frontières.
>>>>>>
>>>>>> Il manque ensuite un vrai critère de filtrage par pays. Les seuls
>>>>>> filtres ici sont sur boundary=administrative et admin_level=4 et le
>>>>>> résultat est juste car cette "goecodeArea" inclut des noeuds de la
>>>>>> frontière mais aussi des ways tout entiers.
>>>>>>
>>>>>> On ne peut pas s'attendre à un filtrage exact avec les geocodeArea
>>>>>> utilisés par Overpass qui incluent des parties frontalières dans d'autres
>>>>>> pays (on peut le voir aussi en cherchant des noeuds de POIs ou des
>>>>>> rues/routes).
>>>>>>
>>>>>> De plus les polygones qui définissent ces "geocodeArea" sont mis à
>>>>>> jour lentement. Je pense en plus qu'ici il y a le problème de l'ile sur le
>>>>>> fleuve frontalier au pays basque, qui change tous les six mois de
>>>>>> souveraineté (6 mois française, 6 mois espagnole), et de la fome de gestion
>>>>>> commune entre les collectivités des deux pays de certains territoires
>>>>>> partagés (un vieil usage historique basque qui va au delà de la seule
>>>>>> question de souveraineté nationale même quand elle est exclusive ou alterne
>>>>>> de façon exclusive tous les 6 mois).
>>>>>>
>>>>>> Enfin il n'est pas exclu qu'un contributeur espagnol ait justement
>>>>>> repris dans les frontières des ccommunautés ou collectivités espagnoles ces
>>>>>> parties cogérées, ou qu'à l'inverse cela ait été fait pour la région
>>>>>> française (noter aussi qu'il y a des conflits frontaliers par sur de petits
>>>>>> secteurs par endroit): dans ce cas une simple sélection géométrique n'est
>>>>>> pas suffisante: on doit filtrer les relations des régions elles-mêmes si
>>>>>> elles se recouvrent partiellement. Le "geocodeArea" lui sera incapable de
>>>>>> réellement séparer les pays: c'est aussi une limite du modèle de sélection
>>>>>> purement géométrique (qui présuppose une partition de l'espace, sans aucun
>>>>>> recouvrement partiel).
>>>>>>
>>>>>> Pour résoudre ça proprement: mettre les attributs de pays sur les
>>>>>> relations concernées... ou utiliser les "subareas" que certains critiquent
>>>>>> alors qu'ils associent de façon claire les subdvisions à leur subdivision
>>>>>> parente (et cela n'a rien à voir avec la question d'une prétendue
>>>>>> représentation par frontières ou par surface, vieux débat sans objet car
>>>>>> c'est exactement la même chose, les deux étant représentés par des "ways"
>>>>>> OSM membres de la relation "boundary"'!).
>>>>>>
>>>>>>
>>>>>> Le 6 avril 2016 à 00:17, Vincent de Château-Thierry <osm.vdct at free.fr
>>>>>> > a écrit :
>>>>>>
>>>>>>> Bonsoir,
>>>>>>> signalé sur Twitter puis IRC :
>>>>>>> https://twitter.com/jbjensson/status/717283332933988352/photo/1
>>>>>>>
>>>>>>> Problème de requête Overpass ? De données ? Si quelqu'un a le temps
>>>>>>> de s'y pencher...
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20160407/2900c9a1/attachment.htm>