Re: [OSM-talk-fr] Fwd: OSM et Parc amazonien de Guyane?

[Christian Quest]

Je prends contact.


Le 20 septembre 2013 01:16, Waxy  a écrit :

> Bonjour,
>
> Voici un courriel du Parc Amazonien de Guyane que je viens de recevoir.
> Si quelqu'un d'aguerri avec les institutions veut répondre à ma place,
> il n'y a pas de souci.
> Sinon que suggérez-vous comme réponse ou comme question à leur poser.
>
> Je pense qu'on peut leur suggérer le tag "source" pour "faire apparaitre
> [leur] nom en tant que producteur".
> Cependant ils peuvent avoir peur qu'il disparaisse par la suite. On leur
> suggère qu'un bot pourrait faire de la surveillance ? Possible ?
>
> Il faudrait aussi peut-être leur demander s'ils comptent faire des
> intégrations seulement eux-mêmes ou s'ils sont prêts à livrer des
> données sous licence compatible odbl, auquel cas des intégrations
> semi-automatiques par les contributeurs OSM pourraient être envisagées.
>
> "Nos données sont publiques, donc pleinement diffusables. Néanmoins nous
> aurions préféré signer un semblant de convention avec l’OSM" ne me
> semble pas d'une limpidité juridique à toute épreuve.
>
> Remarques ? Idées ? Un volontaire préfère s'en charger ?
>
> @+
>
>  Message original 
> Sujet:  OSM et Parc amazonien de Guyane?
> Date :  Thu, 19 Sep 2013 21:15:12 +0200 (CEST)
> De :Pauline Perbet 
> Pour :  
> Copie à :   Pierre Joubert 
>
>
>
> Bonjour,
>
>
>
> J’ai récupéré votre mail sur le site «http://tuxdomain.dyndns.org/», où
> nous téléchargeons régulièrement vos très bons extraits .img de la base
> OSM.
>
> En recherchant des informations concernant OpenStreetMap en Guyane, je
> retombe souvent sur votre nom.
>
> Supposant, donc, que vous êtes un contributeur actif de l’OSM en Guyane,
> je me permet de vous contacter.
>
>
>
> Le Parc amazonien de Guyane souhaite participer à l’amélioration de
> l’OSM, notamment en rajoutant les toponymes du sud de la Guyane.
>
> Nos données sont publiques, donc pleinement diffusables. Néanmoins nous
> aurions préféré signer un semblant de convention avec l’OSM, ou du moins
> faire apparaitre notre nom en tant que producteur.
>
> C’est dans ce cadre que nous vous contactons, en espérant que vous
> pourrez nous renseigner ou nous aiguiller.
>
>
>
> Merci pour votre contribution à la cartographie libre.
>
>
>
> Sincèrement,
>
>
>
> Pauline PERBET
> Géomaticienne
> _pauline.per...@guyane-parcnational.fr
> _
>
>
>
> pag
>
>
>
> Parc amazonien de Guyane
> 1 rue Lederson
> 97354 Remire-Montjoly
> Tél: 0594 29 12 52 | Fax: 0594 29 26 58
> http://www.parc-guyane.gf 
>
> N’imprimer que si nécessaire ...
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://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
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Fwd: OSM et Parc amazonien de Guyane?

[Waxy]

Bonjour,

Voici un courriel du Parc Amazonien de Guyane que je viens de recevoir.
Si quelqu'un d'aguerri avec les institutions veut répondre à ma place,
il n'y a pas de souci.
Sinon que suggérez-vous comme réponse ou comme question à leur poser.

Je pense qu'on peut leur suggérer le tag "source" pour "faire apparaitre
[leur] nom en tant que producteur".
Cependant ils peuvent avoir peur qu'il disparaisse par la suite. On leur
suggère qu'un bot pourrait faire de la surveillance ? Possible ?

Il faudrait aussi peut-être leur demander s'ils comptent faire des
intégrations seulement eux-mêmes ou s'ils sont prêts à livrer des
données sous licence compatible odbl, auquel cas des intégrations
semi-automatiques par les contributeurs OSM pourraient être envisagées.

"Nos données sont publiques, donc pleinement diffusables. Néanmoins nous
aurions préféré signer un semblant de convention avec l’OSM" ne me
semble pas d'une limpidité juridique à toute épreuve.

Remarques ? Idées ? Un volontaire préfère s'en charger ?

@+

 Message original 
Sujet:  OSM et Parc amazonien de Guyane?
Date :  Thu, 19 Sep 2013 21:15:12 +0200 (CEST)
De :Pauline Perbet 
Pour :  
Copie à :   Pierre Joubert 



Bonjour,



J’ai récupéré votre mail sur le site «http://tuxdomain.dyndns.org/», où
nous téléchargeons régulièrement vos très bons extraits .img de la base OSM.

En recherchant des informations concernant OpenStreetMap en Guyane, je
retombe souvent sur votre nom.

Supposant, donc, que vous êtes un contributeur actif de l’OSM en Guyane,
je me permet de vous contacter.



Le Parc amazonien de Guyane souhaite participer à l’amélioration de
l’OSM, notamment en rajoutant les toponymes du sud de la Guyane.

Nos données sont publiques, donc pleinement diffusables. Néanmoins nous
aurions préféré signer un semblant de convention avec l’OSM, ou du moins
faire apparaitre notre nom en tant que producteur.

C’est dans ce cadre que nous vous contactons, en espérant que vous
pourrez nous renseigner ou nous aiguiller.



Merci pour votre contribution à la cartographie libre.



Sincèrement,



Pauline PERBET
Géomaticienne
_pauline.per...@guyane-parcnational.fr
_



pag



Parc amazonien de Guyane
1 rue Lederson
97354 Remire-Montjoly
Tél: 0594 29 12 52 | Fax: 0594 29 26 58
http://www.parc-guyane.gf 

N’imprimer que si nécessaire ...

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

Re: [OSM-talk-fr] osrm ferroviaire ?

[DH]

Le 19/09/2013 18:48, Christian Quest a écrit :
Le 19 septembre 2013 18:24, Stéphane Péneau 
mailto:stephane.pen...@wanadoo.fr>> a écrit :


Le jeudi 19 septembre 2013 18:15:03, HELFER Denis a écrit :

La réponse simple à ta dernière question est « non » aussi
surprenant
que cela puisse paraitre.


Ca, pour être surprenant, ça l'est 



Et pourtant, si vous saviez !

Je rencontre régulièrement des services très officiels, grandes 
entreprises et autre qui s'extasient sur la richesse des données OSM 
et qui n'en reviennent pas de ce qui a pu être fait en partant d'une 
feuille blanche avec des moyens sommes toute relativement réduits.


On s'en rend compte assez régulièrement maintenant avec des données 
mises en opendata qui ont une qualité souvent moindre que celles 
présentes dans OSM... elles ont juste pour elles l'exhaustivité que 
nous n'avons souvent pas par manque d'un maillage suffisant du 
territoire par des contributeurs régulièrement actifs.


ton "juste" est pertinent. Nous le comprenons comme "juste fais le ©" ; 
le titulaire (*) de la donnée va raisonner "juste, c'est juste ? on peut 
utiliser ? non ? alors il faut continuer avec nos process".
Nous arrivons à un stade où le gap entre les néographes et les 
paléographes arrive à être suffisamment faible ou que la dynamique du 
crowdsourcing soit suffisamment puissante pour compenser la faiblesse 
des moyens publics par la bonne volonté (à combien peut être évaluer 
(valorisé ?) de la foule, du citoyen impacté par son territoire.
Il reste un travail énorme à faire pas uniquement sur la qualité de 
notre base (besoin interne), mais aussi sur notre capacité à améliorer 
les données qui nous sont proposées via l'open data. Pour ma part, je me 
suis fixé comme objectif de compléter la donnée PN issue de RFF sur mon 
périmètre de compétence (Alsace - Lorraine - Champagne-Ardenne). J'ai 
tendance à déborder de cet objectif initial (tracé de voies + aiguilles 
sur Nancy tellement l'ortho était tentante). Bref, il faut rentrer soit 
individuellement, soit collectivement (Mapcraft) sur la complétion 
d'objectifs atteignables dans un délai raisonnable


* le titulaire d'une donnée géographique est l'entité responsable de 
juri de la constitution et de l'entretien d'une information (DREAL pour 
les zones réglementaires environnementales, IGN pour le RGE, la DGFiP 
pour le découpage parcellaire, etc.) -> liste à établir sur le wiki pour 
mémo pour les distinguer des diffuseurs de cette même information (y 
compris sous des formes plus pratiques pour la communauté des 
réutilisateurs). Le Droit les appelle les producteurs de données, il 
faut comprendre, entre les lignes, que personne d'autre ne saurait se 
substituer à cette mission de service public quand bien même la donnée 
serait de meilleure qualité (selon quels critères d'ailleurs).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?

[Philippe Verdy]

Le 19 septembre 2013 18:30, Vincent de Château-Thierry  a
écrit :

> Pour toute la France et pour la totalité de sa structure adminsistrative
>
>> de niveau 2 à 8, il ne faudra pas plus de 4 membres (répartis parmi
>> les 4 relations existantes, soit effectivement 1 seul membre ajouté
>> en moyenne par relation !).
>>
> Sûrement pas : la répartition se fera surtout parmi les relations au
> dessus des communes, donc il faut enlever un bon 36000 à ton 2e 4.
>

Surement si ! les 36000 restent dans le total général (note bien que j'ai
pris la structure administrative dans sa totalité, autrement dit tous les
niveaux) ! Ce qui donne bel et bien une moyenne de 1 membre par relation.
Si tu enlèves 36000 cela veut dire que tu as supprimé les 36000 membres
représentant les communes dans les départements, uniquement parce que tu ne
les veux pas comme membres dans les départements, mais tu les voudras dans
les arrondissements départementaux, et les arrondissements départementaux
seront membres des départements et entreront dans le compte général des
relations pruses en compte et celui des membres qu'on leur ajoute.

Il reste maintenant à savoir 3 choses (du plus simple au plus compliqué à
analyser et décider) :

(1) quel rôle utiliser pour ces membres : jusqu'à présent on n'a jamais
prévu QUE le rôle "subarea" alors qu'en fin de compte on est dans une
logique ensembliste indépendante de la géométrie. Je pencherai pour un rôle
synonyme (mais plus clair) "include" (ce pourrait même être le rôle vide
par défaut s'il n'y a pas d'ambiguité en regardant juste le type d'objet,
mais on a déjà des membres qui sont des relations destinées à contenir des
fragments de frontières, sous forme de multi-polylignes non nécessairement
toutes fermées en anneaux).

(2)  à quel niveau placer le membre ajouté pour cet ensemble : la relation
parente ou la relation fille. En terme de stockage physique de la base de
données cela ne change rien puisque dans les deux cas les membres de
relations sont stockés dans un tableau à double entrée (avec une
orientation non inversible) qui peut être indexé dans un sens ou dans
l'autre et qui contient les références aux deux objets, ainsi qu'un
attribut pour cette paire, le "rôle". Cependant en terme physique il reste
plus efficace pour gérer les deux index d'en faire un lié directement à la
structure de stockage du tableau à double entrée, trié dans l'ordre de la
première colonne comme clé primaire et la seconde colonne comme clé
secondaire, sans avoir besoin de stocker des références indirectes (comme
un rowid"), et l'autre contenant uniquement un index pour la direction
opposée, et qui contiendra donc la seconde colonne la plus unique et la
référence à la première table d'index. Comme la première table-index dot
avoir comme première colonne clé primaire la moins unique, cette
table-index sera comme clé plutôt celle contenant une relation mère, la
seconde sera pour la relation fille.
A ce moment là la seconde table devient quasi-isomorphe de la table
concernant la relation fille seule et elle en suit le tri. ce qui fait que
la référence à la relation mère devient un attribut (0,1) de la "relation
OSM" fille, tandis que que la première table-index est stockée à part de la
"relation OSM" mère dans l'ordre de son index qui stocke alors physiquement:
- type OSM de la relation OSM mère
- id OSM de la relation OSM mère
- type OSM de la relation OSM fille
- id OSM de la relation OSM fllle
- nom du rôle (ou hashvalue du rôle si on a une table à part des rôles
utilisés pour économiser de la place)
- rowid de la relation OSM mère
- rowid de la relation OSM fille

La table-index stockant alors les relations OSM (filles) devient:
- id OSM de la relation OSM
- attribut (0,1) du rowid de la relation OSM mère (non renseigné et reste
NULL si elle n'a pas de mère)
- autres attrbuts et tags
Cependant cela n'est possible que si le rôle est figé; comme le nombre de
rôles n'est pas fini (plusieurs hiérarchies possibles) et rien dans le
schéma n'oblige à assurer une distibution de volumétrie aussi déséquilibrée
qu'une structure hiérarchique pure (on a des exceptions) cette solution est
moins avantageuse que de stocker plutôt des listes de membres dans la
relation mère plutôt que la fille (car de toute façon on ne peut pas
échapper à un stockage physique dans au moins 2 tables-index (ou 3 si on
stocke les rôles uniques remplacé par un rowid unique vers une table-index
de hachage des rôles). Même en terme de volume d'échange au format XML ou
GeoJSON, c'est sous forme de listes de membres stockés dans la relation OSM
mère que c'est le plus compact. Et c'est le plus naturel car la topologie
du schéma suit la dénomination aussi utilisée "sur le terrain" pour décrire
les membres d'une héirarchie adminsitrative.

(3) doit-on avoir un autre rôle pour les exclusions ? Autrement dit les
listes de membres doivent elles nécessairement être uniquement inclusives
et sans superposition (purement hiérarchiques, mais éventuellem

Re: [OSM-talk-fr] osrm ferroviaire ?

[Christian Quest]

Le 19 septembre 2013 18:24, Stéphane Péneau  a
écrit :

> Le jeudi 19 septembre 2013 18:15:03, HELFER Denis a écrit :
>
>  La réponse simple à ta dernière question est « non » aussi surprenant
>> que cela puisse paraitre.
>>
>
> Ca, pour être surprenant, ça l'est 
>
>

Et pourtant, si vous saviez !

Je rencontre régulièrement des services très officiels, grandes entreprises
et autre qui s'extasient sur la richesse des données OSM et qui n'en
reviennent pas de ce qui a pu être fait en partant d'une feuille blanche
avec des moyens sommes toute relativement réduits.

On s'en rend compte assez régulièrement maintenant avec des données mises
en opendata qui ont une qualité souvent moindre que celles présentes dans
OSM... elles ont juste pour elles l'exhaustivité que nous n'avons souvent
pas par manque d'un maillage suffisant du territoire par des contributeurs
régulièrement actifs.

La nouveauté c'est d'être aussi nombreux à collaborer sur une base de
données commune.
De nombreuses données existent mais par manque de partage beaucoup de
travail est fait en double, triple... sans cohérence, en silo avec la
difficulté des mises à jour, etc, etc...

L'idée qu'il y a beaucoup plus à gagner qu'à perdre en se mettant à
partager et collaborer commence à prendre. Enfin !

-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Plugin cadastre-fr, version 29829 (2.5)

[Stéphane Péneau]

Super, merci vincent !

Stf

Le jeudi 19 septembre 2013 14:56:45, V de Chateau-Thierry a écrit :



De : "Stéphane Péneau"

Me retrouvant à manger du mapcraft de la dordogne, je me retrouve avec
un paquet de communes dont les planches sont sans croisillons. J'ai
plusieurs fois rencontré le cas de ces planches sans repères, mais qui
étaient géoréférencées.
La version actuelle du plugin ne pouvant récupérer ce géoréférencement,
je me demandais s'il y avait tout de même un moyen de le savoir. Auquel
cas, je mettrais ces planches de côté en attendant une nouvelle version.


Si un géoréférencement existe, il sera visible sur le site du cadastre. En 
cherchant la
commune qui t'intéresse ici :
http://www.cadastre.gouv.fr/
puis en affichant une de ses planches, s'il y a géoréférencement, il apparaît 
en bas de
la fenêtre à la ligne "Coordonnées en projection". Si tu vois comme intitulé 
"métrique
locale" ça veut dire... qu'il n'y a rien à attendre comme aide, la planche 
n'est pas
géoréférencée. Mais si tu vois "Lambert xxx" ou "RGF93CCxxx" là c'est bon signe.

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
https://lists.openstreetmap.org/listinfo/talk-fr




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

Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?

[Christian Quest]

Le 19 septembre 2013 17:42, V de Chateau-Thierry  a écrit
:

>
> > De : "Christian Quest"
>
> > Il ne faut pas prendre "boundary" au pied de la lettre...
>
> Mouais... Ce serait pourtant rassurant de pouvoir considérer qu'un terme
> n'est pas
> choisi au hasard, non ?
>
> >
> Avec 2 relations, on se retrouvera à devoir recopier les tags sur les deux
> à moins que
> l'on pointe de l'un vers l'autre et on va avoir le choix de pointer d'un
> sens vers
> l'autre ou l'inverse (donc le débat et le bazar qui va avec).
>
> La recopie de tags, c'est 3 clic dans JOSM
> 1er : 3e bouton en partant de la gauche dans le panneau des relations =>
> ouvre une
> nouvelle relation copiée sur celle sélectionnée initialement
> 2e : bouton de tri 'A-Z' dans la fenêtre d'édition de la nouvelle relation
> pour
> sélectionner tous les membres
> 3e : bouton 'Poubelle' juste au dessus du précédent
> et voilà une relation toute neuve, avec tous les tags, et vide de membres.
> Donc bon...
>

Oui, et tout les problèmes de mise à jour qui vont avec... info dupliquée =
info pas synchronisée
Si on a les mêmes tags, c'est bien qu'on parle de la même "chose".



> >
>
> En quoi est-ce que ça gêne plus d'avoir des relations membres avec un rôle
> subarea que
> d'avoir déjà actuellement des nœuds admin_centre ou label ?
>
> Un exemple au hasard, l'Yonne (sacré hasard, hein ? :-) )
> Actuellement, la relation [1] a 259 membres : 258 ways et un node.
> En ajoutant les 455 références des 455 communes, on triple presque le
> nombre de membres,
> mais surtout on mélange 2 styles de références, on va vers des objets un
> peu monstrueux
> je trouve.
>


Tu aurais du prendre mieux... France (admin_level=2) et communes
(admin_level=8)... ça ferait 36700 membres dans la relation "France" ;)

L'idée est d'avoir une hiérarchie, donc dans admin_level=2 tu met les
membres du niveau du dessous, soit les régions (4) dans les régions tu met
les départements (6) et dans les départements les arrondissements (7) puis
dans ceux-ci les communes (8).

Le nombre de membres reste limité à chaque niveau.



> Les relations actuelles se concentrent sur la géométrie d'un objet, et
> rien d'autre.
>

Euh... alors on vire les admin_centre et les label ?



> Celles dont on parle avec les subarea ne décrivent pas de géométrie, mais
> des relations
> d'inclusion via la sémantique : un arbre, qui irait de la racine (le pays)
> aux communes
> voire aux quartiers, via des branches : les régions, les depts, etc.
>

Oui, et la même relation peut servir aux deux sans que cela ne gêne.



> Tout dans la même relation, je trouve ça à la fois moins lisible, moins
> évident à
> comprendre car hétéroclite, accessoirement plus lourd à manipuler. Bref,
> je ne vois pas
> d'avantages, plutôt (que) des inconvénients.
> En modélisant ça à part, on assure, mine de rien, une compatibilité pour
> les usages
> actuels des "boundary" : leurs consommateurs n'y verraient que du feu.
> Mais les
> nouvelles relations, hiérarchiques, seraient simples à combiner aux
> boundaries, avec
> une clé ultra simple pour ce qui concerne nos découpages admin : le
> ref:INSEE et rien
> que lui.
>
>
Tout dans la même relation ne gênera pas les consommateurs actuels... car
c'est déjà le cas à plusieurs endroits (Espagne, Belgique) et que je sache
osm2pgsql et consorts n'ont pas explosé en vol alors que ça fait un bout de
temps que subarea est utilisé et décrit dans le wiki au sein d'une même
relation.

C'est toute la beauté du "role" dans les relations qui ne sont pas de
simple collections d'objets. Il permet de regrouper des membres hétérogènes
ensemble. Le rôle n'existerait pas, ça serait effectivement un gros bazar
et je serai de ton avis.




> >
> Je préfère un seul objet OSM pour représenter une unique entité sur le
> terrain (la région
> machinchose, le département trucmuche).
> Ne serait-ce pas ton point de vue de géomaticien qui tique avec un objet
> représentant en
> même temps une surface et un linéaire ? ;)
>
> Va savoir :-)
> Mais moi aussi je préfère un seul objet par entité. Mais ici j'estime
> qu'on représente 2
> notions distinctes : d'un côté des emprises géométriques, indépendantes
> les unes des
> autres (ce qui est le problème à l'origine de ce fil) et de l'autre un
> arbre, ici
> administratif mais on pourrait appliquer ça à d'autres cas.
>
>

J'ai une approche moins géométrique et beaucoup SGBDR: un objet OSM
(relation) pour une entité (ici un département) et au sein de la relation
des membres qui peuvent décrire différents aspects de ce département, les
way qui composent sa frontière (outer/inner), les autres objets OSM qui
composent logique ce département (les subarea), un nœud pour placer un
libellé, un autre pour définir la position du centre administratif, voire
d'autres trucs futurs...


Quant au ref:INSEE, il est trop incomplet pour décrire la hiérarchie, il ne
donne qu'une info sur le département auquel appartient une commune, rien
sur l'arrondissement/canton, la région et c'est un 

Re: [OSM-talk-fr] osrm ferroviaire ?

[Fionn Halleman]

Si le raisonnement est très "macro" (de l'interurbain à l'échelle
européenne), alors l'absence de turn_restrictions ne doit pas être un
énorme problème. Ceci est aussi vrai pour le réseau routier, mais il
faudrait voir pour le cas du rail.

Et s'il fallait vraiment tenir compte du fait que les trains ne peuvent pas
prendre des virages en épingle :

1/  ils peuvent en revanche rebrousser chemin (j'ai en tête la liaison
Angoulême-Royan, ou la gare Saint-Charles à Marseille)
2/ on peut peut-être utiliser le fait qu'OSRM semble pouvoir appliquer des
pénalités selon l'angle du virage (sauf si c'est à 180°, auquel cas c'est
un rebroussement).

Un autre problème que j'ai remarqué (mais qui ne devrait pas être bloquant
pour un calcul d'iti interurbain) est que la base OSM est parfois très
précise (l'ensemble des voies est représentées), parfois au contraire
insuffisamment détaillée (un seul axe pour plusieurs voix, cf Bordeaux-La
Rochelle). Euh... Ce n'est d'ailleurs pas une donnée dont dispose RFF ?

Fionn


Le 19 septembre 2013 17:37, HELFER Denis  a écrit :

>  Oui Christian tu as raison : entre les traversée jonction simple, les
> doubles, les bifurcations droite, gauche, les voies uniques, les voies à
> sens unique, les voies à double sens, etc. Tous ceci est hors de portée du
> contributeur moyen (simplement parce que c’est indétectable sur une simple
> ortho fusse-t-elle celle de Nancy ;-).
>
> En fait, le nœud du problème est de convertir la base OSM actuelle en
> graphe gare-tronçon ferré à l’échelle européenne. 
>
> A noter que je me fous des lignes commerciales (pour le calcul
> d’itinéraire tout au moins).
>
> ** **
>
> *De :* Christian Quest [mailto:cqu...@openstreetmap.fr]
> *Envoyé :* jeudi 19 septembre 2013 17:15
> *À :* Discussions sur OSM en français
> *Objet :* Re: [OSM-talk-fr] osrm ferroviaire ?
>
> ** **
>
> Il y a des choses qu'il faudra sûrement traiter en plus qu'un simple
> rail.lua
>
> ** **
>
> Les voies ferrées sont tracées mais les aiguillages sont rarement
> renseignés, or lorsque 2 voies se croisent il n'y a pas forcément
> d'aiguillage, ça peut être un simple croisement. Les trains ne peuvent pas
> non plus faire des virages n'importe comment même si les way sont
> connectés... un beau casse tête en perspective où il faudrait déterminer le
> graphe aussi en se basant sur la géométrie des intersections...
>
> ** **
>
> Le 19 septembre 2013 17:06, Ab_fab  a écrit :
>
> Est-ce que cela peut se "résumer" à la bidouille d'un nouveau profil
> rail.lua ?
>
> https://github.com/DennisOSRM/Project-OSRM/tree/master/profiles
>
> ** **
>
> Ca a l'air d'être la conclusion de la discussion ici : 
>
> https://github.com/DennisOSRM/Project-OSRM/issues/90
>
> ** **
>
> Le 19 septembre 2013 16:56, HELFER Denis  a écrit :**
> **
>
> Bonjour à tous,
>
>  
>
> Je suis confronté à un problème pour l’heure insoluble. Je cherche à
> calculer la distance d’itinéraires entre deux gares ferroviaires
> quelconques au niveau européen. Pas de problème pour le routier, tout le
> monde sait faire. Pas de problème non plus pour le temps de trajet
> ferroviaire entre une origine et une destination, mais point de kilométrage.
> 
>
> Il existe bien des tables issues de la SNCF, mais elles sont soit
> anciennes (pas de LGV, par exemple) soit partielle (ou les deux).
>
> Des pistes sur des ressources existantes que j’aurai manqué ?
>
> La question subsidiaire (j’ai déjà pas mal fouillé le web sans succès) :
> quel serait la méthode et le cout (technique/financier) pour adapter osrm à
> du routing ferroviaire. J’ai déjà lu ceci :
> https://help.openstreetmap.org/questions/22927/how-to-begin-routing-rail-lines
> 
>
>  
>
> A vot’bon coeur
>
>  
>
>  
>
> *Denis HELFER*
>
> *Chargé d’études géomatiques*
>
> *Correspondant SI*
>
> *03 88 23 95 58 *
>
> [image: Description : Description : D:\Documents and
> Settings\asieffert\Mes documents\Mes images\Photos\RFF_sign_Alsace.JPG]***
> *
>
>  
>
> ** **
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> 
>
> ** **
>
> -- 
>
> ab_fab 
> "Il n'y a pas de pas perdus", Nadja
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://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
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
<>___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Outil d'intégration des adresses à nouveau disponible

[Romain MEHUT]

Saint-Brieuc peut également être ajoutée:
http://geobretagne.fr/geonetwork/srv/fr/metadata.show?uuid=98f14f1e-34bc-4eb6-bdd3-de9c1e135978

Merci.

Romain

Le 19 septembre 2013 11:42, Romain MEHUT  a écrit :

> Le 19 septembre 2013 11:19, Frédéric Rodrigo  a
> écrit :
>
>
>> Il y surement d’autres villes qui ont mise à disposition leur données
>> adresses depuis. Si vous en connaissait vous pouvez le signaler.
>>
>
> Oui j'avais déjà signalé le Grand Nancy: http://opendata.grand-nancy.org
>
> Merci pour l'ajout.
>
> Romain
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?

[Philippe Verdy]

Le 19 septembre 2013 17:42, V de Chateau-Thierry  a écrit
:

>
> > De : "Christian Quest"
>
> > Il ne faut pas prendre "boundary" au pied de la lettre...
>
> Mouais... Ce serait pourtant rassurant de pouvoir considérer qu'un terme
> n'est pas
> choisi au hasard, non ?
>
> >
> Avec 2 relations, on se retrouvera à devoir recopier les tags sur les deux
> à moins que
> l'on pointe de l'un vers l'autre et on va avoir le choix de pointer d'un
> sens vers
> l'autre ou l'inverse (donc le débat et le bazar qui va avec).
>
> La recopie de tags, c'est 3 clic dans JOSM
> 1er : 3e bouton en partant de la gauche dans le panneau des relations =>
> ouvre une
> nouvelle relation copiée sur celle sélectionnée initialement
> 2e : bouton de tri 'A-Z' dans la fenêtre d'édition de la nouvelle relation
> pour
> sélectionner tous les membres
> 3e : bouton 'Poubelle' juste au dessus du précédent
> et voilà une relation toute neuve, avec tous les tags, et vide de membres.
> Donc bon...
> >
>
> En quoi est-ce que ça gêne plus d'avoir des relations membres avec un rôle
> subarea que
> d'avoir déjà actuellement des nœuds admin_centre ou label ?
>
> Un exemple au hasard, l'Yonne (sacré hasard, hein ? :-) )
> Actuellement, la relation [1] a 259 membres : 258 ways et un node.
> En ajoutant les 455 références des 455 communes, on triple presque le
> nombre de membres,
> mais surtout on mélange 2 styles de références, on va vers des objets un
> peu monstrueux
> je trouve.
>

C'est à que tu te trompes complètement car tu ne comptes pas tout ! Tu ne
regarde QUE la relation de l'Yonne et pas les relations des communes. et tu
oublies aussi qu'entre les deux il y a les arrondissements.

Pour l'Yonne cela ajouterait SEULEMENT les 3 ou 4 membres des
arrondissements et c'est tout (1 membre unique par arrondissement pour
toute la base de données), mais pas toutes les communes; dans chaque
arrondissement il y a aura uniquement la cinquantaine de communes. dans la
commune il n'y aura rien du tout (sauf si elle a un découpage administrarif
infracommunal au niveau 9 ou plus).

Total ajouté dans la base : jamais plus de membres ajoutés qu'il y a de
relations dans la base. Et il ne s'agit de remonter dans le parent qu'une
seule et unique donnée, mais aucun de ses autres attributs (on ne duplique
pas les noms, on ne duplique pas non plus la géométrie comme on l'a fait à
l'excès dans les listes de chemins membres "outer"/"inner" où il faut
souvent remonter plein de chemins de la relation fille vers la mère, dont
le volume explose : il suffit de regarder les relations du pays, des réions
et départements=et même des arrondissements).

Franchement fais tes calculs correctement et va voir réellement la
situation en Espagne et en Belgique et fait le compte : ces membres ajoutés
sont une partie INFIME des données en comparaison des membres
"inner"/"outer" des listes de chemins.

Pour toute la France et pour la totalité de sa structure adminsistrative de
niveau 2 à 8, il ne faudra pas plus de 4 membres (répartis parmi les
4 relations existantes, soit effectivement 1 seul membre ajouté en
moyenne par relation !). Alors qu'on a pas loin du million de chemins et
des dizaines de millions de noeuds à télécharger ou mettre à jour pour
seulement en déduire (par un calcul très compliqué et faux en permanence
car jamais les données ne sont complètes et cohérentes) sa structure
administative  !

Il n'y a pas photo, le modèle ensembliste est très largement gagnant et
assure à lui tout seul une totale absence de redondance, donc la solidité
et la cohérence d'ensemble. Les chemins ne sont réellement nécessaires
qu'au niveau le plus fin des relations (donc dans les feuilles au niveau 8
si c'et le niveau final) et TOUS les autres chemins sont des redondances.
De plus il y a une autre redondance par le fait que chaque chemin est
mentionné au moins deux fois (par les relations limitrophes qu'il
délimite), ce qui n'arrive pas non plus avec la définition ensembliste.

Bref reprend tes calculs et n'oublie rien : mais si tu ne veux pas regarder
le problème complet, tu vas tirer des conclusions fausses comme ci-dessus.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osrm ferroviaire ?

[Stéphane Péneau]

Le jeudi 19 septembre 2013 18:15:03, HELFER Denis a écrit :

La réponse simple à ta dernière question est « non » aussi surprenant
que cela puisse paraitre.


Ca, pour être surprenant, ça l'est 



En revanche, c’est un projet dont l’horizon
n’est plus si lointain. Ce n’est pas encore dit que cela sera de
l’open data.


Croisons les doigts...

En attendant, j'ai commencé à dessiner la seconde voie de Nantes vers 
Bordeaux.


Stf

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

Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?

[Philippe Verdy]

Plutôt que les "is_in:*=*" ou les "left/right:*=*" franchement on peut
consolider beaucoup plus facilement et avec énormément moins de données
avec le modèle ensembliste (ne vous fiez pas au nom donné "subarea" pour le
rôle, ce n'est pas du tout une notion surfacique à proprement parler car
cela ne s'appuie pas du tout et ne nécessite d'ailleurs pas du tout la
moindre donnée géométrique, on n'a besoin d'aucun chemin ni aucun noeud et
aucune coordonnée).

Essayez avec le modèle purement géométrique d'obtenir la liste des 22
régions métropolitaines ! il faut télécharger actuellement plus de 800 000
chemins et plusieurs dizaines de millions de noeuds (et ces nombres sont
sans arrêt en hausse au fur et à mesure qu'on affine les données). Et des
heures de téléchargement, des millions de requêtes envoyées au serveur (ou
bien on peut télécharger un gros fichier dump de la base et passer
plusieurs jours à monter une base locale: quel gachis de temps pour tout le
monde !) et consommer une bande passante réseau de plusieurs gigaoctets.

Alors que 22 membres en tout et pour tout (membres ensembliste) dans la
base suffisent et permet d'avoir cette liste en quelques millisecondes avec
1 seule et unique requête qui nécessite une bande passante de moins d'1 Ko,
ce qui est accessible à n'importe quel utilisateur ayant une relation
internet lente ou un matériel très limité en capacité de stockage et de
calcul !

Cela n'exclue pas de stocker aussi dans les relations les contours externes
mais c'est autre chose et ce n'est pas une nécessité non plus ; déjà on ne
le fait plus pour la France entière car on aurait beaucoup trop de chemins
membres, la frontière est déjà scindée en plusieurs parties stockées à part
et on a beucoup de mal à synchroniser les différents niveaux hiérarchiques
de façon cohérente: mais ce sont ces frontières qui ont une redondance
énormes car on doit les reporter à tous les niveaux (et on passe son temps
à chercher comment les réparer efficacement et rapidement sans erreur.

Alors oui je suis favorable à la suppression des tags "is_in" (les membres
de rôle "subarea" sont énormément plus efficaces), et des tags "left/right"
beaucoup trop redondants et limités à une seule langue arbitraire (les
chemins frontières avec leurs rôles "inner/outer" suffisent, ces rôles
pouvant même être gérés comme synonymes puisque qu'on peut le déduire de la
géométrie, si elle est correcte et complète, la distinction entre "inner"
et "outer" est une facilité qui évite de devoir le calculer par un
traitement complexe nécessitant la connaissance intégrale du détail des
géométrie, mais ces distinctions ne sont pas volumineuses et restent utiles
pour détecter des incohérences et vérifier l'intention du tracé initial;
ces rôles 'inner" et "outer" sont vérifiables automatiquement de façon
asynchorne, et permettent aux outils tiers de fonctionner aussi sans avoir
à charger le détail complet des géométries)..



Le 19 septembre 2013 16:29, Pieren  a écrit :

> 2013/9/19 Pieren :
>
> Et si on va dans la consolidation, on peut aussi rétablir tous les
> "is_in" qui ont été injustement supprimés. Et mettre des
> "addr:country=France" sur toutes les adresses en France. Parce qu'il y
> aura toujours quelqu'un qui trouvera ça plus pratique pour lui. Et
> pis, ça consolide et on pourra mieux détecter les incohérences.
>
> Pieren
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osrm ferroviaire ?

[HELFER Denis]

La réponse simple à ta dernière question est « non » aussi surprenant que cela 
puisse paraitre. En revanche, c'est un projet dont l'horizon n'est plus si 
lointain. Ce n'est pas encore dit que cela sera de l'open data.


De : Fionn Halleman [mailto:fionn.halle...@valeurs-mobiles.fr]
Envoyé : jeudi 19 septembre 2013 18:03
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] osrm ferroviaire ?

Si le raisonnement est très "macro" (de l'interurbain à l'échelle européenne), 
alors l'absence de turn_restrictions ne doit pas être un énorme problème. Ceci 
est aussi vrai pour le réseau routier, mais il faudrait voir pour le cas du 
rail.

Et s'il fallait vraiment tenir compte du fait que les trains ne peuvent pas 
prendre des virages en épingle :

1/  ils peuvent en revanche rebrousser chemin (j'ai en tête la liaison 
Angoulême-Royan, ou la gare Saint-Charles à Marseille)
2/ on peut peut-être utiliser le fait qu'OSRM semble pouvoir appliquer des 
pénalités selon l'angle du virage (sauf si c'est à 180°, auquel cas c'est un 
rebroussement).

Un autre problème que j'ai remarqué (mais qui ne devrait pas être bloquant pour 
un calcul d'iti interurbain) est que la base OSM est parfois très précise 
(l'ensemble des voies est représentées), parfois au contraire insuffisamment 
détaillée (un seul axe pour plusieurs voix, cf Bordeaux-La Rochelle). Euh... Ce 
n'est d'ailleurs pas une donnée dont dispose RFF ?

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

Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?

[Vincent de Château-Thierry]

Le 19/09/2013 18:02, Philippe Verdy a écrit :



C'est à que tu te trompes complètement car tu ne comptes pas tout ! Tu
ne regarde QUE la relation de l'Yonne et pas les relations des communes.
et tu oublies aussi qu'entre les deux il y a les arrondissements.

Pour l'Yonne cela ajouterait SEULEMENT les 3 ou 4 membres des
arrondissements et c'est tout (1 membre unique par arrondissement pour
toute la base de données), mais pas toutes les communes; dans chaque
arrondissement il y a aura uniquement la cinquantaine de communes. dans
la commune il n'y aura rien du tout (sauf si elle a un découpage
administrarif infracommunal au niveau 9 ou plus).


Tu as raison, le niveau des arrondissements change les chiffres, en 
s'intercalant. Mais ça ne change rien au principe : ce que je décrivais 
pour une relation de département s'applique à une relation d'arrdt, en 
divisant (en moyenne par 3 ou 4) la liste des références de communes.



Pour toute la France et pour la totalité de sa structure adminsistrative
de niveau 2 à 8, il ne faudra pas plus de 4 membres (répartis parmi
les 4 relations existantes, soit effectivement 1 seul membre ajouté
en moyenne par relation !).
Sûrement pas : la répartition se fera surtout parmi les relations au 
dessus des communes, donc il faut enlever un bon 36000 à ton 2e 4.


Alors qu'on a pas loin du million de chemins

et des dizaines de millions de noeuds à télécharger ou mettre à jour
pour seulement en déduire (par un calcul très compliqué et faux en
permanence car jamais les données ne sont complètes et cohérentes) sa
structure administative  !

Il n'y a pas photo, le modèle ensembliste est très largement gagnant et
assure à lui tout seul une totale absence de redondance, donc la
solidité et la cohérence d'ensemble. Les chemins ne sont réellement
nécessaires qu'au niveau le plus fin des relations (donc dans les
feuilles au niveau 8 si c'et le niveau final) et TOUS les autres chemins
sont des redondances. De plus il y a une autre redondance par le fait
que chaque chemin est mentionné au moins deux fois (par les relations
limitrophes qu'il délimite), ce qui n'arrive pas non plus avec la
définition ensembliste.

Bref reprend tes calculs et n'oublie rien : mais si tu ne veux pas
regarder le problème complet, tu vas tirer des conclusions fausses comme
ci-dessus.


Je n'ai rien contre le modèle ensembliste, comme tu l'appelles. Je lui 
trouve un véritable intérêt pour sa capacité à décrire, autrement que 
par inclusion spatiale, des relations entre objets. Et je m'en sers au 
quotidien, donc je suis d'avance convaincu. Je pense que décrire ces 
relations dans OSM apporterait une vraie plus-value. Je parle ici en 
pensant aux usages, aux consommateurs. La demande initiale de Fionn est 
un cas d'usage, concret. Il y en aura d'autres à l'avenir, enfin on ne 
peut que l'espérer !
Là où, définitivement, j'ai un souci, c'est avec la volonté de tout 
ranger dans un même sac : géométrie et relations hiérarchiques. En 
pensant aussi bien à la maintenance qu'à la réutilisation, je ne suis 
pas convaincu par la pertinence. Mais bon, je radote.


vincent

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

Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?

[Philippe Verdy]

plutôt que de parler de notion "relationiste", moi je préfère parler de
notion "ensembliste".
- Certains sont trompés sur une fausse distinction entre modèle par
frontières et modèle par surface alors que c'est exactement la même chose
et fait avec les mêmes données de géométrie : des noeuds avec des
coordonnées, et des chemins pour les assembler et un attribut ou un type
unique permettant de donner une interprétation soit comme surface
bidimentionnelle soit comme tracé filaire unidimentionnel.
- Le nom du rôle "subarea" est trompeur. En fait ce serait plus clair si
c'était "include" (notion ensembliste, totalement détaché de la géométrie)
et on devrait pouvoir aussi ajouter un rôle "exclude" (notion également
ensembliste) ce qui permet aussi de créer des exceptions locales à un
modèle purement hiérarchique (les exceptions existent partout en géographie
humaine, à commencer par nos administrations compliquées), mais cela ne
change rien à la volumétrie et la modélisation. LE but n'est pas réellement
de déinir des surfaces (au sens géométrique) mais bien des ensembles
d'entités (il n'y a pas obligation non plus que les entités membres listées
en "include" ou "exclude" soient disjointes entre elles, rien que le rôle
"exclude" n'est utile que si justement il y a des intersections d'ensembles.

Si on doit modéliser ça: il vaut mieux en terme de volumétrie des données
lister les communes comme membres dans la relation EPCI (avec un rôle
"subarea" tel qu'il existe déjà, ou renommé "include"). plutôt que le
contraire (équivalent topologique aux actuels tags "is_in" qui sont
clairemetn indésirables).

Donc Bordeaux sera listé comme membre de la relation de la CUB, plutot que
le contraire (Bordeaux contient un membre avec un rôle spécifique pour
donner son EPCI à fiscalité propre, la CUB, mais combien de membres (et de
dôles spécifiques) faudra-t-il pour lister les EPCI et autres structures
(administratives, ministérielles et régaliennes, commerciales,
encironnementales) auxquelles Bordeaux est attaché). Logiquement c'est
Bordeaux qui est membre de la CUB et pas le contraire, soyons logique ! Un
unique nom de rôle "include" suffit pour modéliser les ensembles (si on
ajoute "exclude" c'est pour permettre d'inclure une sous-région comme les
autres, mais d'en exclure un fragment, ce qui simplifie les choses.


Le 19 septembre 2013 17:17, Fionn Halleman <
fionn.halle...@valeurs-mobiles.fr> a écrit :

> En attendant le grand soir relationniste, j'ai fait ma liste de communes
> de la CUB à la main. Ceci dit, j'ai besoin des autres communautés urbaines
> aussi, et des autres niveaux d'EPCI plus tard...
>
> Donc la discussion m'intéresse au-delà de mon petit problème bordelais : y
> a-t-il un consensus sur le fait que je peux ajouter un lien entre les
> relations commune et les relations EPCI ? Est-ce quelqu'un a un brouillon
> de comment ça se traduit dans les logiciels courants (me connaissant, je
> serais fichu de faire de la CUB une partie de Bordeaux au lieu du contraire)
>
> PS : venant d'un monde adepte de bases de données plates comme des crêpes,
> c'est un authentique trésor que cette notion de "relation".
>
> Fionn
>
>
>
> Le 19 septembre 2013 16:52, Philippe Verdy  a écrit :
>
> Plutôt que les "is_in:*=*" ou les "left/right:*=*" franchement on peut
>> consolider beaucoup plus facilement et avec énormément moins de données
>> avec le modèle ensembliste (ne vous fiez pas au nom donné "subarea" pour le
>> rôle, ce n'est pas du tout une notion surfacique à proprement parler car
>> cela ne s'appuie pas du tout et ne nécessite d'ailleurs pas du tout la
>> moindre donnée géométrique, on n'a besoin d'aucun chemin ni aucun noeud et
>> aucune coordonnée).
>>
>> Essayez avec le modèle purement géométrique d'obtenir la liste des 22
>> régions métropolitaines ! il faut télécharger actuellement plus de 800 000
>> chemins et plusieurs dizaines de millions de noeuds (et ces nombres sont
>> sans arrêt en hausse au fur et à mesure qu'on affine les données). Et des
>> heures de téléchargement, des millions de requêtes envoyées au serveur (ou
>> bien on peut télécharger un gros fichier dump de la base et passer
>> plusieurs jours à monter une base locale: quel gachis de temps pour tout le
>> monde !) et consommer une bande passante réseau de plusieurs gigaoctets.
>>
>> Alors que 22 membres en tout et pour tout (membres ensembliste) dans la
>> base suffisent et permet d'avoir cette liste en quelques millisecondes avec
>> 1 seule et unique requête qui nécessite une bande passante de moins d'1 Ko,
>> ce qui est accessible à n'importe quel utilisateur ayant une relation
>> internet lente ou un matériel très limité en capacité de stockage et de
>> calcul !
>>
>> Cela n'exclue pas de stocker aussi dans les relations les contours
>> externes mais c'est autre chose et ce n'est pas une nécessité non plus ;
>> déjà on ne le fait plus pour la France entière car on aurait beaucoup trop
>> de chemins membres, la frontière est déjà scindée en

Re: [OSM-talk-fr] Outil d'intégration des adresses à nouveau disponible

[Philippe Verdy]

Problème pour les datas de Rennes. Qui rapidement bloque l'outil avec des
tuiles qui ne se chargent plus du tout et le javascript qu part en boucle
interne, et va faire des requêtes n'importe où au serveur de tuiles pour
essayer de récupérer des tuiles partout sauf celles qu'on voudrait
afficher, et qui les affiche même pas à la position de la souris quand on
glisse la carte.

Ca commence à bloquer dès qu'on essaye de marquer un "point" de nom de rue
comme déjà OK dans la base OSM. Après 3 ou 4, on dirait qu'on commence à
tomber à cours de requêtes HTTTP et le javascript se bloque en attendant
une session, ou bien comemnce à mélanger les états des requêtes HTTP en
cours.pas détectées comme terminées.



Le 19 septembre 2013 12:16, Bruno Cortial  a
écrit :

>
> Le 19 septembre 2013 11:49, Philippe Verdy  a écrit :
>
> Le rendu carto a quelques problèmes de bloquage dans son javascript (avec
>> un comportement étrange du zoom, et une suraccélération de la souris).
>> Les tuiles ne se raffraichissent pas correctement, leur position ne
>> correspond pas au glissement du curseur. On dirait un paramètre incorrect
>> pour ajuster les zooms dans l'intégration javascript, ou bien un type de
>> projection incorrect.
>>
>>
> Toute cette m* de javascript est mon chef-d’œuvre de grand débutant
> JS, et comme telle restera inachevé (par moi) si aucun bug bloquant n'est
> remonté.Traduction: Ca juste marche !
>
> Plus sérieusement, c'est où le pb, quelle ville ? Pas la peine d'envoyer
> un permalink, çà marche pas ;-)
>
> Sinon, Philippe, si tu passes par Nantes ou Pornic, contactes-moi. On
> discutera calmement OSM, et on verra si tu es aussi endurant au clavier que
> derrière une chopine.
>
> A+
> BrunoC
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?

[Philippe Verdy]

Justement c''est le modèle purement géométrique qui a une quantité ENORME
de redondance en lui-même. beaucoup plus que le modèle ensembliste.

Et je suis en vieux routier des BDD, je sais aussi de quoi je parle. Et
ceux qui parlent de mettre le modèle ensembliste dans des relations
séparées à part des relations géométriques militent en fait pour un
redondance enorome de données (deux objets séparés avec duplication
intégrale des attributs juste pour gérer des listes de membres différentes,
alors qu'on a déjà la notion de "rôle" pour distinguer les listes de
membres sans rien dupliquer du tout).

Le modèle ensembliste pourtant est beaucoup plus efficace que d'ajouter
aussi des tags "is_in" : là oui ces derniers sont des redondances très
lourdes, très volumineuses, et difficiles à maintenir (mais la seule chose
qu'on a pu faire pour tenter de garder une trace des morceaux de géométries
cassées...). Rien que "is_in:country=*" génère des millions de copies de
l'attribut pour un pays comme la France.

En comparaison le modèle ensembliste générera ***1 et 1 seul*** membre par
commune (preuve qu'il n'a pas de redondance en lui-même) quel que soit le
nombre de niveaux administratifs gérés, et le modèle géométrique à
frontières génère 6 à 12 membres par commune, chaque chemin membre étant
inclus presque toujours au moins deux fois (et souvent plus pour les
niveaux adminsitratifs muttiples), ce qui montre une redondance intrinsèque
du modèle géométrique à lui tout seul (et qui pourtant n'arrive pas à se
stabiliser et qu'il est difficile de vérifier et parcourir, et qui rend
toute rechercher ultra compliquée et lourde à faire si c'est le seul moyen).

Si tu commence à parler d'éviter les redondances, alors clairement c'est le
modèle géométrique actuel (chemins frontières ou surfaces, même chose) qui
a perdu depuis toujours quand les données sont à la base essentiellement
hiérarchiques (et donc mieux représentés par un modèle ensembliste, avec
comme membres des régions filles sans aucune petite fille)


Le 19 septembre 2013 15:54, Pieren  a écrit :

> 2013/9/19 Christian Quest :
>
> > J'aime aussi cet ajout de redondance qui permet de détecter les
> > incohérences.
>
>
> Non (snip) Il faut écouter les vieux routiers des bdd : la
> redondance ne détecte pas les incohérences, elle les créer ! Encore
> plus dans un projet comme OSM où chaque entité peut être modifiée
> séparément et sans contrôle.
> Les relations boundary sont déjà très difficiles à maintenir. Vous
> allez doubler le travail sur 36000 communes, 100 départements et 22
> régions, doublez le nombre de relations (ou leur taille); tout ça pour
> éviter que quelques personnes remplissent une base spatiale avec
> osm2pgsql...
>
> Pieren
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] osrm ferroviaire ?

[HELFER Denis]

Bonjour à tous,

Je suis confronté à un problème pour l'heure insoluble. Je cherche à calculer 
la distance d'itinéraires entre deux gares ferroviaires quelconques au niveau 
européen. Pas de problème pour le routier, tout le monde sait faire. Pas de 
problème non plus pour le temps de trajet ferroviaire entre une origine et une 
destination, mais point de kilométrage.
Il existe bien des tables issues de la SNCF, mais elles sont soit anciennes 
(pas de LGV, par exemple) soit partielle (ou les deux).
Des pistes sur des ressources existantes que j'aurai manqué ?
La question subsidiaire (j'ai déjà pas mal fouillé le web sans succès) : quel 
serait la méthode et le cout (technique/financier) pour adapter osrm à du 
routing ferroviaire. J'ai déjà lu ceci : 
https://help.openstreetmap.org/questions/22927/how-to-begin-routing-rail-lines

A vot'bon coeur


Denis HELFER
Chargé d'études géomatiques
Correspondant SI
03 88 23 95 58
[Description : Description : D:\Documents and Settings\asieffert\Mes 
documents\Mes images\Photos\RFF_sign_Alsace.JPG]

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

Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?

[Pieren]

2013/9/19 Frédéric Rodrigo :
> Même si la redondance crée des problèmes, elle
> consolide l'ensemble.

Et c'est les mêmes qui suppriment les "left/right:village" sur les
ways qui nous disent ça...

Pieren

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

Re: [OSM-talk-fr] osrm ferroviaire ?

[Christian Quest]

Il y a des choses qu'il faudra sûrement traiter en plus qu'un simple
rail.lua

Les voies ferrées sont tracées mais les aiguillages sont rarement
renseignés, or lorsque 2 voies se croisent il n'y a pas forcément
d'aiguillage, ça peut être un simple croisement. Les trains ne peuvent pas
non plus faire des virages n'importe comment même si les way sont
connectés... un beau casse tête en perspective où il faudrait déterminer le
graphe aussi en se basant sur la géométrie des intersections...


Le 19 septembre 2013 17:06, Ab_fab  a écrit :

> Est-ce que cela peut se "résumer" à la bidouille d'un nouveau profil
> rail.lua ?
> https://github.com/DennisOSRM/Project-OSRM/tree/master/profiles
>
> Ca a l'air d'être la conclusion de la discussion ici :
> https://github.com/DennisOSRM/Project-OSRM/issues/90
>
>
> Le 19 septembre 2013 16:56, HELFER Denis  a écrit :
>
>>  Bonjour à tous,
>>
>> ** **
>>
>> Je suis confronté à un problème pour l’heure insoluble. Je cherche à
>> calculer la distance d’itinéraires entre deux gares ferroviaires
>> quelconques au niveau européen. Pas de problème pour le routier, tout le
>> monde sait faire. Pas de problème non plus pour le temps de trajet
>> ferroviaire entre une origine et une destination, mais point de kilométrage.
>> 
>>
>> Il existe bien des tables issues de la SNCF, mais elles sont soit
>> anciennes (pas de LGV, par exemple) soit partielle (ou les deux).
>>
>> Des pistes sur des ressources existantes que j’aurai manqué ?
>>
>> La question subsidiaire (j’ai déjà pas mal fouillé le web sans succès) :
>> quel serait la méthode et le cout (technique/financier) pour adapter osrm à
>> du routing ferroviaire. J’ai déjà lu ceci :
>> https://help.openstreetmap.org/questions/22927/how-to-begin-routing-rail-lines
>> 
>>
>> ** **
>>
>> A vot’bon coeur
>>
>> ** **
>>
>> ** **
>>
>> *Denis HELFER*
>>
>> *Chargé d’études géomatiques*
>>
>> *Correspondant SI*
>>
>> *03 88 23 95 58 *
>>
>> [image: Description : Description : D:\Documents and
>> Settings\asieffert\Mes documents\Mes images\Photos\RFF_sign_Alsace.JPG]**
>> **
>>
>> ** **
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> ab_fab 
> "Il n'y a pas de pas perdus", Nadja
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://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
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?

[Fionn Halleman]

En attendant le grand soir relationniste, j'ai fait ma liste de communes de
la CUB à la main. Ceci dit, j'ai besoin des autres communautés urbaines
aussi, et des autres niveaux d'EPCI plus tard...

Donc la discussion m'intéresse au-delà de mon petit problème bordelais : y
a-t-il un consensus sur le fait que je peux ajouter un lien entre les
relations commune et les relations EPCI ? Est-ce quelqu'un a un brouillon
de comment ça se traduit dans les logiciels courants (me connaissant, je
serais fichu de faire de la CUB une partie de Bordeaux au lieu du contraire)

PS : venant d'un monde adepte de bases de données plates comme des crêpes,
c'est un authentique trésor que cette notion de "relation".

Fionn



Le 19 septembre 2013 16:52, Philippe Verdy  a écrit :

> Plutôt que les "is_in:*=*" ou les "left/right:*=*" franchement on peut
> consolider beaucoup plus facilement et avec énormément moins de données
> avec le modèle ensembliste (ne vous fiez pas au nom donné "subarea" pour le
> rôle, ce n'est pas du tout une notion surfacique à proprement parler car
> cela ne s'appuie pas du tout et ne nécessite d'ailleurs pas du tout la
> moindre donnée géométrique, on n'a besoin d'aucun chemin ni aucun noeud et
> aucune coordonnée).
>
> Essayez avec le modèle purement géométrique d'obtenir la liste des 22
> régions métropolitaines ! il faut télécharger actuellement plus de 800 000
> chemins et plusieurs dizaines de millions de noeuds (et ces nombres sont
> sans arrêt en hausse au fur et à mesure qu'on affine les données). Et des
> heures de téléchargement, des millions de requêtes envoyées au serveur (ou
> bien on peut télécharger un gros fichier dump de la base et passer
> plusieurs jours à monter une base locale: quel gachis de temps pour tout le
> monde !) et consommer une bande passante réseau de plusieurs gigaoctets.
>
> Alors que 22 membres en tout et pour tout (membres ensembliste) dans la
> base suffisent et permet d'avoir cette liste en quelques millisecondes avec
> 1 seule et unique requête qui nécessite une bande passante de moins d'1 Ko,
> ce qui est accessible à n'importe quel utilisateur ayant une relation
> internet lente ou un matériel très limité en capacité de stockage et de
> calcul !
>
> Cela n'exclue pas de stocker aussi dans les relations les contours
> externes mais c'est autre chose et ce n'est pas une nécessité non plus ;
> déjà on ne le fait plus pour la France entière car on aurait beaucoup trop
> de chemins membres, la frontière est déjà scindée en plusieurs parties
> stockées à part et on a beucoup de mal à synchroniser les différents
> niveaux hiérarchiques de façon cohérente: mais ce sont ces frontières qui
> ont une redondance énormes car on doit les reporter à tous les niveaux (et
> on passe son temps à chercher comment les réparer efficacement et
> rapidement sans erreur.
>
> Alors oui je suis favorable à la suppression des tags "is_in" (les membres
> de rôle "subarea" sont énormément plus efficaces), et des tags "left/right"
> beaucoup trop redondants et limités à une seule langue arbitraire (les
> chemins frontières avec leurs rôles "inner/outer" suffisent, ces rôles
> pouvant même être gérés comme synonymes puisque qu'on peut le déduire de la
> géométrie, si elle est correcte et complète, la distinction entre "inner"
> et "outer" est une facilité qui évite de devoir le calculer par un
> traitement complexe nécessitant la connaissance intégrale du détail des
> géométrie, mais ces distinctions ne sont pas volumineuses et restent utiles
> pour détecter des incohérences et vérifier l'intention du tracé initial;
> ces rôles 'inner" et "outer" sont vérifiables automatiquement de façon
> asynchorne, et permettent aux outils tiers de fonctionner aussi sans avoir
> à charger le détail complet des géométries)..
>
>
>
> Le 19 septembre 2013 16:29, Pieren  a écrit :
>
> 2013/9/19 Pieren :
>>
>> Et si on va dans la consolidation, on peut aussi rétablir tous les
>> "is_in" qui ont été injustement supprimés. Et mettre des
>> "addr:country=France" sur toutes les adresses en France. Parce qu'il y
>> aura toujours quelqu'un qui trouvera ça plus pratique pour lui. Et
>> pis, ça consolide et on pourra mieux détecter les incohérences.
>>
>> Pieren
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?

[V de Chateau-Thierry]

> De : "Christian Quest"

> Il ne faut pas prendre "boundary" au pied de la lettre...

Mouais... Ce serait pourtant rassurant de pouvoir considérer qu'un terme n'est 
pas
choisi au hasard, non ?

>
Avec 2 relations, on se retrouvera à devoir recopier les tags sur les deux à 
moins que 
l'on pointe de l'un vers l'autre et on va avoir le choix de pointer d'un sens 
vers 
l'autre ou l'inverse (donc le débat et le bazar qui va avec).

La recopie de tags, c'est 3 clic dans JOSM 
1er : 3e bouton en partant de la gauche dans le panneau des relations => ouvre 
une
nouvelle relation copiée sur celle sélectionnée initialement
2e : bouton de tri 'A-Z' dans la fenêtre d'édition de la nouvelle relation pour
sélectionner tous les membres
3e : bouton 'Poubelle' juste au dessus du précédent
et voilà une relation toute neuve, avec tous les tags, et vide de membres. Donc 
bon...
>

En quoi est-ce que ça gêne plus d'avoir des relations membres avec un rôle 
subarea que 
d'avoir déjà actuellement des nœuds admin_centre ou label ?

Un exemple au hasard, l'Yonne (sacré hasard, hein ? :-) )
Actuellement, la relation [1] a 259 membres : 258 ways et un node.
En ajoutant les 455 références des 455 communes, on triple presque le nombre de 
membres,
mais surtout on mélange 2 styles de références, on va vers des objets un peu 
monstrueux
je trouve.
Les relations actuelles se concentrent sur la géométrie d'un objet, et rien 
d'autre.
Celles dont on parle avec les subarea ne décrivent pas de géométrie, mais des 
relations
d'inclusion via la sémantique : un arbre, qui irait de la racine (le pays) aux 
communes
voire aux quartiers, via des branches : les régions, les depts, etc.
Tout dans la même relation, je trouve ça à la fois moins lisible, moins évident 
à
comprendre car hétéroclite, accessoirement plus lourd à manipuler. Bref, je ne 
vois pas
d'avantages, plutôt (que) des inconvénients.
En modélisant ça à part, on assure, mine de rien, une compatibilité pour les 
usages 
actuels des "boundary" : leurs consommateurs n'y verraient que du feu. Mais les
nouvelles relations, hiérarchiques, seraient simples à combiner aux boundaries, 
avec
une clé ultra simple pour ce qui concerne nos découpages admin : le ref:INSEE 
et rien
que lui.

>
Je préfère un seul objet OSM pour représenter une unique entité sur le terrain 
(la région 
machinchose, le département trucmuche).
Ne serait-ce pas ton point de vue de géomaticien qui tique avec un objet 
représentant en 
même temps une surface et un linéaire ? ;)

Va savoir :-)
Mais moi aussi je préfère un seul objet par entité. Mais ici j'estime qu'on 
représente 2 
notions distinctes : d'un côté des emprises géométriques, indépendantes les 
unes des
autres (ce qui est le problème à l'origine de ce fil) et de l'autre un arbre, 
ici
administratif mais on pourrait appliquer ça à d'autres cas.

vincent

[1] : http://www.openstreetmap.org/browse/relation/7392

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
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osrm ferroviaire ?

[Ab_fab]

Est-ce que cela peut se "résumer" à la bidouille d'un nouveau profil
rail.lua ?
https://github.com/DennisOSRM/Project-OSRM/tree/master/profiles

Ca a l'air d'être la conclusion de la discussion ici :
https://github.com/DennisOSRM/Project-OSRM/issues/90


Le 19 septembre 2013 16:56, HELFER Denis  a écrit :

>  Bonjour à tous,
>
> ** **
>
> Je suis confronté à un problème pour l’heure insoluble. Je cherche à
> calculer la distance d’itinéraires entre deux gares ferroviaires
> quelconques au niveau européen. Pas de problème pour le routier, tout le
> monde sait faire. Pas de problème non plus pour le temps de trajet
> ferroviaire entre une origine et une destination, mais point de kilométrage.
> 
>
> Il existe bien des tables issues de la SNCF, mais elles sont soit
> anciennes (pas de LGV, par exemple) soit partielle (ou les deux).
>
> Des pistes sur des ressources existantes que j’aurai manqué ?
>
> La question subsidiaire (j’ai déjà pas mal fouillé le web sans succès) :
> quel serait la méthode et le cout (technique/financier) pour adapter osrm à
> du routing ferroviaire. J’ai déjà lu ceci :
> https://help.openstreetmap.org/questions/22927/how-to-begin-routing-rail-lines
> 
>
> ** **
>
> A vot’bon coeur
>
> ** **
>
> ** **
>
> *Denis HELFER*
>
> *Chargé d’études géomatiques*
>
> *Correspondant SI*
>
> *03 88 23 95 58 *
>
> [image: Description : Description : D:\Documents and
> Settings\asieffert\Mes documents\Mes images\Photos\RFF_sign_Alsace.JPG]***
> *
>
> ** **
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
ab_fab 
"Il n'y a pas de pas perdus", Nadja
<>___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osrm ferroviaire ?

[HELFER Denis]

Oui Christian tu as raison : entre les traversée jonction simple, les doubles, 
les bifurcations droite, gauche, les voies uniques, les voies à sens unique, 
les voies à double sens, etc. Tous ceci est hors de portée du contributeur 
moyen (simplement parce que c’est indétectable sur une simple ortho 
fusse-t-elle celle de Nancy ;-).
En fait, le nœud du problème est de convertir la base OSM actuelle en graphe 
gare-tronçon ferré à l’échelle européenne.
A noter que je me fous des lignes commerciales (pour le calcul d’itinéraire 
tout au moins).

De : Christian Quest [mailto:cqu...@openstreetmap.fr]
Envoyé : jeudi 19 septembre 2013 17:15
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] osrm ferroviaire ?

Il y a des choses qu'il faudra sûrement traiter en plus qu'un simple rail.lua

Les voies ferrées sont tracées mais les aiguillages sont rarement renseignés, 
or lorsque 2 voies se croisent il n'y a pas forcément d'aiguillage, ça peut 
être un simple croisement. Les trains ne peuvent pas non plus faire des virages 
n'importe comment même si les way sont connectés... un beau casse tête en 
perspective où il faudrait déterminer le graphe aussi en se basant sur la 
géométrie des intersections...

Le 19 septembre 2013 17:06, Ab_fab 
mailto:gamma@gmail.com>> a écrit :
Est-ce que cela peut se "résumer" à la bidouille d'un nouveau profil rail.lua ?
https://github.com/DennisOSRM/Project-OSRM/tree/master/profiles

Ca a l'air d'être la conclusion de la discussion ici :
https://github.com/DennisOSRM/Project-OSRM/issues/90

Le 19 septembre 2013 16:56, HELFER Denis 
mailto:denis.hel...@rff.fr>> a écrit :
Bonjour à tous,

Je suis confronté à un problème pour l’heure insoluble. Je cherche à calculer 
la distance d’itinéraires entre deux gares ferroviaires quelconques au niveau 
européen. Pas de problème pour le routier, tout le monde sait faire. Pas de 
problème non plus pour le temps de trajet ferroviaire entre une origine et une 
destination, mais point de kilométrage.
Il existe bien des tables issues de la SNCF, mais elles sont soit anciennes 
(pas de LGV, par exemple) soit partielle (ou les deux).
Des pistes sur des ressources existantes que j’aurai manqué ?
La question subsidiaire (j’ai déjà pas mal fouillé le web sans succès) : quel 
serait la méthode et le cout (technique/financier) pour adapter osrm à du 
routing ferroviaire. J’ai déjà lu ceci : 
https://help.openstreetmap.org/questions/22927/how-to-begin-routing-rail-lines

A vot’bon coeur


Denis HELFER
Chargé d’études géomatiques
Correspondant SI
03 88 23 95 58
[Description : Description : D:\Documents and Settings\asieffert\Mes 
documents\Mes images\Photos\RFF_sign_Alsace.JPG]


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



--
ab_fab
"Il n'y a pas de pas perdus", Nadja

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://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
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?

[Pieren]

2013/9/19 Pieren :

Et si on va dans la consolidation, on peut aussi rétablir tous les
"is_in" qui ont été injustement supprimés. Et mettre des
"addr:country=France" sur toutes les adresses en France. Parce qu'il y
aura toujours quelqu'un qui trouvera ça plus pratique pour lui. Et
pis, ça consolide et on pourra mieux détecter les incohérences.

Pieren

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

Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?

[Frédéric Rodrigo]

Mon avis est que les relations apportent un aspect plus sémantique à la
structure des données. De plus OSM est par essence en construction. Les
limites peuvent être ouvertes ou incomplètes. Les relations offrent donc un
autre point d'entré. Même si la redondance crée des problèmes, elle
consolide l'ensemble.

Par exemple les relations sur les cours d'eau (aux qu'elles j'ai activement
participé) permettent de suivre les cours d'eau même s'il sont incomplet ou
changent de nom en cours de route.



Le 19 septembre 2013 15:54, Pieren  a écrit :

> 2013/9/19 Christian Quest :
>
> > J'aime aussi cet ajout de redondance qui permet de détecter les
> > incohérences.
>
>
> Non (snip) Il faut écouter les vieux routiers des bdd : la
> redondance ne détecte pas les incohérences, elle les créer ! Encore
> plus dans un projet comme OSM où chaque entité peut être modifiée
> séparément et sans contrôle.
> Les relations boundary sont déjà très difficiles à maintenir. Vous
> allez doubler le travail sur 36000 communes, 100 départements et 22
> régions, doublez le nombre de relations (ou leur taille); tout ça pour
> éviter que quelques personnes remplissent une base spatiale avec
> osm2pgsql...
>
> Pieren
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Des nouvelles de X-Plane

[Ab_fab]

Vu sur le forum de la communauté française.
http://www.x-plane.fr/thread52179.html

Les données OpenStreetMap vont de nouveau être intégrées aux scènes du
simulateur de vol X-Plane. Avec une date butoir qui approche.
Les utilisateurs de la simulation ont donc tout intérêt à améliorer
l'existant, et c'est l'objet du fil de discussion

Un bel exemple de bénéfice partagé entre les deux communautés

Bonne journée

-- 
ab_fab 
"Il n'y a pas de pas perdus", Nadja
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?

[Philippe Verdy]

Pus lisible deu modèles dans des relations séparées ? Pas du tout ! Et cela
complique tout en fait en ne sachant plus quelle relation utiliser, on va
dénormaliser ennore plus les attributs.

Regarde effectivement l'Espagne ou la Belgique et prétend que ce n'est pas
lisible ! Et pourtant cela demande peu de membres dans les relations, qu
sont classés à part avec des rôles clairement séparés qui ne gênent en rien
la lisibilité des lites de chemins membres (qui elles sont carrément
bordéliques, et le mot est faible, et totalement illisibles sans outils
pour vérifier qu'on n'a pas pris par erreur un morceau de commune voisine
ni oublié une petite enclave ou une ile exclavée qui fait échouer toute
requête purement géométrique...).



Le 19 septembre 2013 15:34, V de Chateau-Thierry  a écrit
:

>
> > De : "Christian Quest"
> >
> Bien sûr, si l'on ne définissait les limites administratives que par un
> modèle
> surfacique, il faudrait revoir le fonctionnement d'osm2pgsql et de
> sûrement pas mal
> d'autres outils, mais je ne pense pas que quelqu'un propose un changement
> aussi radical.
>
> >
> Le double modèle par contre peut avoir du sens. Il est en effet
> relativement difficile
> aujourd'hui d'utiliser les données OSM avec une vue hiérarchique sans
> créer ces
> géométries.
>
> >
> Je viens d'extraire par exemple des listes de lieux (communes) sur
> différents pays avec
> la hiérarchie des découpages administratifs* et j'ai dû m'appuyer sur une
> base osm2pgsql
> pour sortir ça car il n'y a pas d'autre moyen pour le faire à par le is_in
> très mal
> renseigné et d'un format très aléatoire car textuel et non véritable
> structuré.
>
> >
> J'aime aussi cet ajout de redondance qui permet de détecter les
> incohérences.
>
> >
> A mon avis, au fur et à mesure qu'on a des zones complètes on devrait
> pouvoir ajouter les
> subarea en rôle supplémentaires dans les relations de découpages
> administratifs. Les
> outils ne sachant pas les exploiter les ignoreront tout simple comme il le
> font jusqu'à
> maintenant. L'Espagne fonctionne comme ça et à ma connaissance ça ne pose
> aucun problème.
>
> Oui il y a déjà largement de quoi tester ce modèle. Mais je continue de
> plaider
> (comme 2 ans en arrière...[1]) pour l'utilisation de relations séparées.
> C'est plus
> lisible, et surtout, le type de ces relations ne peut pas être "boundary",
> ça mérite un type en propre, qui désigne ce que c'est sans ambiguïté :
> nested_areas ou
> quoi que ce soit qui évoque la récursivité et la notion de surface. Mais
> pas
> type=boundary : on ne parle pas de limites, ici. A creuser...
>
> vincent
>
> [1] :
> https://lists.openstreetmap.org/pipermail/talk-fr/2012-January/039636.html
>
> 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
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?

[Pieren]

2013/9/19 Christian Quest :

> J'aime aussi cet ajout de redondance qui permet de détecter les
> incohérences.


Non (snip) Il faut écouter les vieux routiers des bdd : la
redondance ne détecte pas les incohérences, elle les créer ! Encore
plus dans un projet comme OSM où chaque entité peut être modifiée
séparément et sans contrôle.
Les relations boundary sont déjà très difficiles à maintenir. Vous
allez doubler le travail sur 36000 communes, 100 départements et 22
régions, doublez le nombre de relations (ou leur taille); tout ça pour
éviter que quelques personnes remplissent une base spatiale avec
osm2pgsql...

Pieren

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

Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?

[Philippe Verdy]

Le 19 septembre 2013 13:15, Pieren  a écrit :

> 2013/9/19 Vincent de Château-Thierry :
>
> > Ce constat reste encore valable pour quelques mois, tant qu'on n'aura
> > pas terminé le tracé complet des limites de communes.
>
>
> Si ça, ça ressemble pas à un appel à terminer les limites communales,
> je me fais moine ^^
>
> Ilya surtour que l'argumentcité est totalement faux, je dis bien
totalement car il s'agit de mauvaise foi manifeste car une énumération des
composantes filles d'une surface peut avoir lieu ***même si*** on n'a pas
encore tout tracé, et si on n'a pas la précision complète suffisante.

L'énumération des filles demande très peu de données dans la base : 1 seul
membre à ajouter par fille dans sa relation parente, donc en tout pour le
niveau adminstratif des communes, autant que de communes (alors que pour
les chemins membres des relation communales on monte facilement = une
moyene de l'ordre de 6 à 12 de membres par commune, et en tout de l'ordre
du quart de million de chemins membres pour les communes françaises.,
contre 36000 membres en tout pour les énumérations de communes filles
membres du niveau admin supérieur..). Cela fait très longtemps que ces
onnées auraient été terminées et de façon exhaustive et stable.

De plus l'opposition n'est absolument pas entre représentation des
frontières ou des surfaces car en fait en stockant des ways membres
uniquement on réalise les deux simultanément, les chemins membres étant
obligatoirement tous des anneaux fermés. Jamais il n'y a eu opposition
entre partisan du modèle surfacique et celui du modèle par frontière car
c'est exactement la même chose ici avec les mêmes données.

La différence n'est pas du tout entre surface et par frontières, mais entre
ces derniers (totalement équivalents entre eux) et la représentation
parsous-ensembles (qui n'est pas une représentation "relationnelle" non
plus, car un modèle "relationnel", au sens SQL du terme, ne peut pas
accepter les récursions d'un type d'objet vers lui-même : si on veut faire
une requête relationnelle, le système imposerait de dénormaliser ces
ensembles et sous-ensembles pour inclure dans le parent non seulement ses
filles,mais aussi ses petites filles et tous les niveaux descendants, ce
qui n'est absolument pas optimal ; ce type de requête nécessite un type de
requête SQL particulier, certes ,mais pas plus particulier ni plus
compliqué que les requêtes géométriques qui sont extrêmement fragiles et
très compliquées et lourdes à réaliser car il faut comparer non seulemetn
des listes de chemins membres très longues, mais aussi descendre jus'au
niveau de leurs noeuds et aire des calculs de projection sur un axe à
partir d'un point pour savori où se situe l'intérieur et l'extérieur et
déterminer s'il y a untersection ou non; la requête ne permettant pas non
plus de répondre quand une intersection existe mais n'est pas complète
d'une surface dans l'autre, car il y a un peu partout des anomalies
fréquentes avec des chemins oubliés oupas encore tracés non plus...).

Je ne dis pas qu'on doit utiliser le modèle ensembliste (relations membres)
à la place du modèle actuel surfaço-linéaire (utilisant des chemins
membres, ou bientôt des anneaux membres fermés avec l'introduction attendue
de la primitive 'surfacique" qui enfait va être une primitive d'anneaux
fermés), mais que les deux se complètent utilement et se renforcent
mutuellement pour permettre d'alléger de très nombreuses analyses et
exploitation des données. Le modèle ensembliste est en effet totalement
indépendant de la précision géométrique, il nécessaite très peu de données,
il est stable, documenté, facilement vérifiable et facile à garder stable
et complet. De plus il renforce énormément le système surfaço-linéaire en
évitant des tas d'accidents d'éditions (liés à l'oubli fréquent de
télécharger TOUTES les relations utilisant chaque noeud ou chemin donné
avant de le modifier).

Il suffit de voir comment très souvent les relations sont cassées en
France, et la difficulté constante pour les réparer (car cela demande de
télécharger énormément de données pour retrouver tous les chemins
nécessaires) ! En comparaison si on a une liste e filles dans la relation
parente, la réparation est évidente et ne nécessite pas de longues
recherches et très peu de données demandées au serveur. Tout est plus
efficace. pour naviguer dans les données. Regardez avec quelle faciliité
déconcertante on navigue en Espagne ou en Belgique et comment ces pays sont
TRES stables dans la base, le moindre accident étant très vite réparé et
facile à vérifier... Et même si on ne télécharge JAMAIS les remations
parentes, c'est le système qui s'en charge AUTOMATIQUEMENT partout (ce qui
n'est pas le cas avec le modèle surfaço-linéaire) : les oublis n'ont plsu
aucune excuse car cela ne peut provenir que 'd'une suppression volontaire
de données et non d'un accident lié à la fusion ou la scission d'un
chemin.en plusieurs.

Je voudrais donc qu'on arrêt d'opposer les deux modèles alors

Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?

[Christian Quest]

Il ne faut pas prendre "boundary" au pied de la lettre...

Avec 2 relations, on se retrouvera à devoir recopier les tags sur les deux
à moins que l'on pointe de l'un vers l'autre et on va avoir le choix de
pointer d'un sens vers l'autre ou l'inverse (donc le débat et le bazar qui
va avec).

En quoi est-ce que ça gêne plus d'avoir des relations membres avec un rôle
subarea que d'avoir déjà actuellement des nœuds admin_centre ou label ?

Je préfère un seul objet OSM pour représenter une unique entité sur le
terrain (la région machinchose, le département trucmuche).
Ne serait-ce pas ton point de vue de géomaticien qui tique avec un objet
représentant en même temps une surface et un linéaire ? ;)


Le 19 septembre 2013 15:34, V de Chateau-Thierry  a écrit
:

>
> Oui il y a déjà largement de quoi tester ce modèle. Mais je continue de
> plaider
> (comme 2 ans en arrière...[1]) pour l'utilisation de relations séparées.
> C'est plus
> lisible, et surtout, le type de ces relations ne peut pas être "boundary",
> ça mérite un type en propre, qui désigne ce que c'est sans ambiguïté :
> nested_areas ou
> quoi que ce soit qui évoque la récursivité et la notion de surface. Mais
> pas
> type=boundary : on ne parle pas de limites, ici. A creuser...
>
> vincent
>
> [1] :
> https://lists.openstreetmap.org/pipermail/talk-fr/2012-January/039636.html



-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?

[V de Chateau-Thierry]

> De : "Christian Quest"
>
Bien sûr, si l'on ne définissait les limites administratives que par un modèle 
surfacique, il faudrait revoir le fonctionnement d'osm2pgsql et de sûrement pas 
mal 
d'autres outils, mais je ne pense pas que quelqu'un propose un changement aussi 
radical.

>
Le double modèle par contre peut avoir du sens. Il est en effet relativement 
difficile 
aujourd'hui d'utiliser les données OSM avec une vue hiérarchique sans créer ces 
géométries.

>
Je viens d'extraire par exemple des listes de lieux (communes) sur différents 
pays avec 
la hiérarchie des découpages administratifs* et j'ai dû m'appuyer sur une base 
osm2pgsql 
pour sortir ça car il n'y a pas d'autre moyen pour le faire à par le is_in très 
mal 
renseigné et d'un format très aléatoire car textuel et non véritable structuré.

>
J'aime aussi cet ajout de redondance qui permet de détecter les incohérences.

>
A mon avis, au fur et à mesure qu'on a des zones complètes on devrait pouvoir 
ajouter les 
subarea en rôle supplémentaires dans les relations de découpages 
administratifs. Les 
outils ne sachant pas les exploiter les ignoreront tout simple comme il le font 
jusqu'à 
maintenant. L'Espagne fonctionne comme ça et à ma connaissance ça ne pose aucun 
problème.

Oui il y a déjà largement de quoi tester ce modèle. Mais je continue de plaider
(comme 2 ans en arrière...[1]) pour l'utilisation de relations séparées. C'est 
plus
lisible, et surtout, le type de ces relations ne peut pas être "boundary",
ça mérite un type en propre, qui désigne ce que c'est sans ambiguïté : 
nested_areas ou
quoi que ce soit qui évoque la récursivité et la notion de surface. Mais pas 
type=boundary : on ne parle pas de limites, ici. A creuser...

vincent

[1] : https://lists.openstreetmap.org/pipermail/talk-fr/2012-January/039636.html

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
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?

[Christian Quest]

osm2pgsql ne fiche de la hiérarchie logique qu'il peut y avoir entre les
différents objets OSM. Son objectif est de créer les géométries (point,
lignes, polygones) correspond aux objets OSM (noeuds, chemins, relations).

Bien sûr, si l'on ne définissait les limites administratives que par un
modèle surfacique, il faudrait revoir le fonctionnement d'osm2pgsql et de
sûrement pas mal d'autres outils, mais je ne pense pas que quelqu'un
propose un changement aussi radical.

Le double modèle par contre peut avoir du sens. Il est en effet
relativement difficile aujourd'hui d'utiliser les données OSM avec une vue
hiérarchique sans créer ces géométries.

Je viens d'extraire par exemple des listes de lieux (communes) sur
différents pays avec la hiérarchie des découpages administratifs* et j'ai
dû m'appuyer sur une base osm2pgsql pour sortir ça car il n'y a pas d'autre
moyen pour le faire à par le is_in très mal renseigné et d'un format très
aléatoire car textuel et non véritable structuré.

J'aime aussi cet ajout de redondance qui permet de détecter les
incohérences.

A mon avis, au fur et à mesure qu'on a des zones complètes on devrait
pouvoir ajouter les subarea en rôle supplémentaires dans les relations de
découpages administratifs. Les outils ne sachant pas les exploiter les
ignoreront tout simple comme il le font jusqu'à maintenant. L'Espagne
fonctionne comme ça et à ma connaissance ça ne pose aucun problème.

* voir ici: http://osm13.openstreetmap.fr/~cquest/places/



Le 19 septembre 2013 12:32, Vincent de Château-Thierry  a
écrit :

> Amis spatialistes et relationistes bonjour :-)
>
> Le 19/09/2013 11:13, Frédéric Rodrigo a écrit :
>
>> Le 19 septembre 2013 11:01, Fionn Halleman
>> 
>> >
>> a écrit :
>>
>>
>> Est-ce quelque chose qu'il serait intéressant de modéliser (pour
>> d'autres personnes que pour moi, j'entends) ? Y a-t-il des cas où
>> c'est déjà fait ?
>>
>>
>> C'est un grand sujet de discutions qui oppose les spatialises (pas
>> besoin de faire plus on peut le retrouver l’information par requête
>> spatiale) et aux relationniste (on ajoute de la sécurité et de la
>> sémantique avec des relations (ma vision perso)).
>>
>> Le modèle de zone administrative en France est construit sur des
>> relations type=boundary, en Allemagne c'est avec des type=multipolygon,
>> mais avec la même façon de faire : ces relations regroupent la limite
>> extérieurs.
>> Par contre en Espagne le principe est le même, mais il y en plus
>> l'aspect "surfacique" dans les relation, c'est à dire que les relations
>> des entités administratives filles sont également présente dans la
>> relation.
>>
>
> Il y a surtout, jusque là, quelques arguments pour utiliser le modèle
> par limites, arguments bêtement pragmatiques :
> - ce modèle, contrairement au "surfacique", permet de définir un niveau
> sans disposer de l'intégralité des surfaces à un niveau plus fin. Avec
> le modèle par surface, encore aujourd'hui, on ne saurait pas tracer
> certains départements français, qui seraient troués ou rognés sur les
> bords.
> Concrètement, voilà à quoi ressemblerait le département des Ardennes en
> mode surfacique (ne regarder que ce qui est en vert) :
> http://layers.openstreetmap.**fr/?zoom=9&lat=49.6&lon=4.8&**
> layers=000B0FFTFT
> Ce constat reste encore valable pour quelques mois, tant qu'on n'aura
> pas terminé le tracé complet des limites de communes.
> - pour la modélisation par surface, il faudrait, côté exploitation des
> données, des moyens de digérer les relations récursives. On doit bien
> pouvoir trouver quelques bouts de code là-dessus, mais autant que je
> sache ça n'est pas disponible dans les outils de manipulation de
> données OSM brutes les plus populaires, notamment osm2pgsql.
>
> A contrario, la modélisation par surface, en référençant dans une
> relation ses relations filles, offre une manière puissante de naviguer
> dans l’arborescence des zones. Il y a des bénéfices à en tirer,
> j'imagine tout à fait qu'on modélise ça un jour prochain.
>
> vincent
>
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://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
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?

[V de Chateau-Thierry]

> De : "Pieren"
>
> 2013/9/19 Vincent de Château-Thierry :
>
> > Ce constat reste encore valable pour quelques mois, tant qu'on n'aura
> > pas terminé le tracé complet des limites de communes.
>
>
> Si ça, ça ressemble pas à un appel à terminer les limites communales,
> je me fais moine ^^

ça s'est vu tant que ça ? ;-)))

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
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Plugin cadastre-fr, version 29829 (2.5)

[V de Chateau-Thierry]

> De : "Stéphane Péneau"
>
> Me retrouvant à manger du mapcraft de la dordogne, je me retrouve avec
> un paquet de communes dont les planches sont sans croisillons. J'ai
> plusieurs fois rencontré le cas de ces planches sans repères, mais qui
> étaient géoréférencées.
> La version actuelle du plugin ne pouvant récupérer ce géoréférencement,
> je me demandais s'il y avait tout de même un moyen de le savoir. Auquel
> cas, je mettrais ces planches de côté en attendant une nouvelle version.

Si un géoréférencement existe, il sera visible sur le site du cadastre. En 
cherchant la
commune qui t'intéresse ici :
http://www.cadastre.gouv.fr/
puis en affichant une de ses planches, s'il y a géoréférencement, il apparaît 
en bas de
la fenêtre à la ligne "Coordonnées en projection". Si tu vois comme intitulé 
"métrique
locale" ça veut dire... qu'il n'y a rien à attendre comme aide, la planche 
n'est pas
géoréférencée. Mais si tu vois "Lambert xxx" ou "RGF93CCxxx" là c'est bon signe.

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
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Plugin cadastre-fr, version 29829 (2.5)

[Stéphane Péneau]

Hello,

Me retrouvant à manger du mapcraft de la dordogne, je me retrouve avec 
un paquet de communes dont les planches sont sans croisillons. J'ai 
plusieurs fois rencontré le cas de ces planches sans repères, mais qui 
étaient géoréférencées.
La version actuelle du plugin ne pouvant récupérer ce géoréférencement, 
je me demandais s'il y avait tout de même un moyen de le savoir. Auquel 
cas, je mettrais ces planches de côté en attendant une nouvelle version.


Sinon, un petit bug peut-être déjà remonté :
- Récupérer une planche, par exemple le TA d'une commune.
- Demander le TA d'une autre commune en tapant n'importe quoi comme nom 
(qsdfvgzs). Le plugin ne trouve rien et. le TA de la commune 
précédemment chargé disparait.


Stf

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

Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?

[Pieren]

2013/9/19 Vincent de Château-Thierry :

> Ce constat reste encore valable pour quelques mois, tant qu'on n'aura
> pas terminé le tracé complet des limites de communes.


Si ça, ça ressemble pas à un appel à terminer les limites communales,
je me fais moine ^^

Pieren

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

Re: [OSM-talk-fr] Outil d'intégration des adresses à nouveau disponible

[Pieren]

2013/9/19 Bruno Cortial :

> on verra si tu es aussi endurant au clavier que derrière une chopine.

et inversement

Pieren

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

Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?

[Vincent de Château-Thierry]

Amis spatialistes et relationistes bonjour :-)

Le 19/09/2013 11:13, Frédéric Rodrigo a écrit :

Le 19 septembre 2013 11:01, Fionn Halleman
mailto:fionn.halle...@valeurs-mobiles.fr>> a écrit :

Est-ce quelque chose qu'il serait intéressant de modéliser (pour
d'autres personnes que pour moi, j'entends) ? Y a-t-il des cas où
c'est déjà fait ?


C'est un grand sujet de discutions qui oppose les spatialises (pas
besoin de faire plus on peut le retrouver l’information par requête
spatiale) et aux relationniste (on ajoute de la sécurité et de la
sémantique avec des relations (ma vision perso)).

Le modèle de zone administrative en France est construit sur des
relations type=boundary, en Allemagne c'est avec des type=multipolygon,
mais avec la même façon de faire : ces relations regroupent la limite
extérieurs.
Par contre en Espagne le principe est le même, mais il y en plus
l'aspect "surfacique" dans les relation, c'est à dire que les relations
des entités administratives filles sont également présente dans la relation.


Il y a surtout, jusque là, quelques arguments pour utiliser le modèle
par limites, arguments bêtement pragmatiques :
- ce modèle, contrairement au "surfacique", permet de définir un niveau
sans disposer de l'intégralité des surfaces à un niveau plus fin. Avec
le modèle par surface, encore aujourd'hui, on ne saurait pas tracer
certains départements français, qui seraient troués ou rognés sur les
bords.
Concrètement, voilà à quoi ressemblerait le département des Ardennes en
mode surfacique (ne regarder que ce qui est en vert) :
http://layers.openstreetmap.fr/?zoom=9&lat=49.6&lon=4.8&layers=000B0FFTFT
Ce constat reste encore valable pour quelques mois, tant qu'on n'aura
pas terminé le tracé complet des limites de communes.
- pour la modélisation par surface, il faudrait, côté exploitation des
données, des moyens de digérer les relations récursives. On doit bien
pouvoir trouver quelques bouts de code là-dessus, mais autant que je
sache ça n'est pas disponible dans les outils de manipulation de
données OSM brutes les plus populaires, notamment osm2pgsql.

A contrario, la modélisation par surface, en référençant dans une
relation ses relations filles, offre une manière puissante de naviguer
dans l’arborescence des zones. Il y a des bénéfices à en tirer,
j'imagine tout à fait qu'on modélise ça un jour prochain.

vincent

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

Re: [OSM-talk-fr] Outil d'intégration des adresses à nouveau disponible

[Bruno Cortial]

Le 19 septembre 2013 11:49, Philippe Verdy  a écrit :

> Le rendu carto a quelques problèmes de bloquage dans son javascript (avec
> un comportement étrange du zoom, et une suraccélération de la souris).
> Les tuiles ne se raffraichissent pas correctement, leur position ne
> correspond pas au glissement du curseur. On dirait un paramètre incorrect
> pour ajuster les zooms dans l'intégration javascript, ou bien un type de
> projection incorrect.
>
>
Toute cette m* de javascript est mon chef-d’œuvre de grand débutant JS,
et comme telle restera inachevé (par moi) si aucun bug bloquant n'est
remonté.Traduction: Ca juste marche !

Plus sérieusement, c'est où le pb, quelle ville ? Pas la peine d'envoyer un
permalink, çà marche pas ;-)

Sinon, Philippe, si tu passes par Nantes ou Pornic, contactes-moi. On
discutera calmement OSM, et on verra si tu es aussi endurant au clavier que
derrière une chopine.

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

Re: [OSM-talk-fr] Outil d'intégration des adresses à nouveau disponible

[Philippe Verdy]

Le rendu carto a quelques problèmes de bloquage dans son javascript (avec
un comportement étrange du zoom, et une suraccélération de la souris).
Les tuiles ne se raffraichissent pas correctement, leur position ne
correspond pas au glissement du curseur. On dirait un paramètre incorrect
pour ajuster les zooms dans l'intégration javascript, ou bien un type de
projection incorrect.


Le 19 septembre 2013 11:42, Romain MEHUT  a écrit :

> Le 19 septembre 2013 11:19, Frédéric Rodrigo  a
> écrit :
>
>
>> Il y surement d’autres villes qui ont mise à disposition leur données
>> adresses depuis. Si vous en connaissait vous pouvez le signaler.
>>
>
> Oui j'avais déjà signalé le Grand Nancy: http://opendata.grand-nancy.org
>
> Merci pour l'ajout.
>
> Romain
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Outil d'intégration des adresses à nouveau disponible

[Romain MEHUT]

Le 19 septembre 2013 11:19, Frédéric Rodrigo  a
écrit :


> Il y surement d’autres villes qui ont mise à disposition leur données
> adresses depuis. Si vous en connaissait vous pouvez le signaler.
>

Oui j'avais déjà signalé le Grand Nancy: http://opendata.grand-nancy.org

Merci pour l'ajout.

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

Re: [OSM-talk-fr] Outil d'intégration des adresses à nouveau disponible

[Bruno Cortial]

Le 19 septembre 2013 11:19, Frédéric Rodrigo  a
écrit :

> Le service d’aide à l’intégration des données adresses OpenData est à
> nouveau disponible.
>
> http://addr.openstreetmap.fr/
>
> Frédéric.
>
>

Super, merci !
Bruno
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?

[Ab_fab]

Les recherches area-query dans une relation ou à l'intérieur d'un polygone
ne marchent que pour les noeuds.
C'est une limitation de l'outil Overpass API

Le 19 septembre 2013 11:13, Frédéric Rodrigo  a
écrit :

> Le 19 septembre 2013 11:01, Fionn Halleman <
> fionn.halle...@valeurs-mobiles.fr> a écrit :
>
> Merci Christian pour le tuyau sur les area-query. J'ai essayé sans grand
>> succès : si j'en crois une discussion vue depuis, les area-query=* ne
>> fonctionnent pas parce que les boundary=local_authority (
>> https://lists.openstreetmap.org/pipermail/talk-fr/2013-January/053027.html)
>> ne sont pas reconnus par Overpass.
>>
>
> J'ai moi même aussi essayé l'exercice et j'en suis arrive à la même
> conclusion.
>
>
> C'est un grand sujet de discutions qui oppose les spatialises (pas besoin
> de faire plus on peut le retrouver l’information par requête spatiale) et
> aux relationniste (on ajoute de la sécurité et de la sémantique avec des
> relations (ma vision perso)).
>
> Le modèle de zone administrative en France est construit sur des relations
> type=boundary, en Allemagne c'est avec des type=multipolygon, mais avec la
> même façon de faire : ces relations regroupent la limite extérieurs.
> Par contre en Espagne le principe est le même, mais il y en plus l'aspect
> "surfacique" dans les relation, c'est à dire que les relations des entités
> administratives filles sont également présente dans la relation.
>
>
> Le 13 septembre 2013 19:07, Fionn Halleman <
>> fionn.halle...@valeurs-mobiles.fr> a écrit :
>>
>>> Bonsoir,
>>>
>>> Je me suis un peu cassé les dents sur cette question sans doute assez
>>> bête. Je veux sortir la liste des communes appartenant à un EPCI (la CUB),
>>> ainsi que les zones correspondantes.
>>>
>>>
>>> J'arrive à obtenir le contour de la CUB :
>>>
>>> 
>>>   
>>> 
>>> 
>>> 
>>>
>>>   
>>>   
>>> 
>>> 
>>>   
>>>   
>>> 
>>>
>>> Voire le contours pour chacune des communautés urbaines en France :
>>>
>>> 
>>>   
>>> 
>>> 
>>> 
>>>
>>>   
>>>   
>>> 
>>> 
>>>   
>>>   
>>> 
>>>
>>> Mais je n'arrive pas vraiment à avoir la liste exacte des communes
>>> appartenant à ces EPCI : quand j'en ai, j'en ai toujours trop ou pas assez.
>>> Des idées ?
>>>
>>> Merci,
>>>
>>> Fionn
>>>
>>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> Le 19 septembre 2013 11:01, Fionn Halleman <
> fionn.halle...@valeurs-mobiles.fr> a écrit :
>
>> Merci Christian pour le tuyau sur les area-query. J'ai essayé sans grand
>> succès : si j'en crois une discussion vue depuis, les area-query=* ne
>> fonctionnent pas parce que les boundary=local_authority (
>> https://lists.openstreetmap.org/pipermail/talk-fr/2013-January/053027.html)
>> ne sont pas reconnus par Overpass.
>>
>> Mais même si ça marchait, j'ai le sentiment que ça ne permettrait de
>> toutes les façons pas de répondre à la question "quelles communes
>> appartiennent à la CUB, ou au Grand Lyon ?" ou encore, "extrayez-moi les
>> limites des communes du département 73" ?
>>
>> Je crois voir que c'est parce que ce type de relation n'est tout
>> simplement pas dans la base : ainsi, la relation "CUB" (
>> http://www.openstreetmap.org/browse/relation/905682) n'a apparemment pas
>> de lien avec la relation Bordeaux ("
>> http://www.openstreetmap.org/browse/relation/105270), pas plus que
>> Bordeaux ne semble être tagué logiquement comme étant en Gironde (il l'est
>> spatialement, mais c'est plus fragile comme relation)...
>>
>> Est-ce quelque chose qu'il serait intéressant de modéliser (pour d'autres
>> personnes que pour moi, j'entends) ? Y a-t-il des cas où c'est déjà fait ?
>>
>> Fionn
>>
>>
>>
>>
>> Le 13 septembre 2013 19:07, Fionn Halleman <
>> fionn.halle...@valeurs-mobiles.fr> a écrit :
>>
>>> Bonsoir,
>>>
>>> Je me suis un peu cassé les dents sur cette question sans doute assez
>>> bête. Je veux sortir la liste des communes appartenant à un EPCI (la CUB),
>>> ainsi que les zones correspondantes.
>>>
>>>
>>> J'arrive à obtenir le contour de la CUB :
>>>
>>> 
>>>   
>>> 
>>> 
>>> 
>>>
>>>   
>>>   
>>> 
>>> 
>>>   
>>>   
>>> 
>>>
>>> Voire le contours pour chacune des communautés urbaines en France :
>>>
>>> 
>>>   
>>> 
>>> 
>>> 
>>>
>>>   
>>>   
>>> 
>>> 
>>>   
>>>   
>>> 
>>>
>>> Mais je n'arrive pas vraiment à avoir la liste exacte des communes
>>> appartenant à ces EPCI : quand j'en ai, j'en ai toujours trop ou pas assez.
>>> Des idées ?
>>>
>>> Merci,
>>>
>>> Fionn
>>>
>>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
ab_fab 

[OSM-talk-fr] Outil d'intégration des adresses à nouveau disponible

[Frédéric Rodrigo]

Le service d’aide à l’intégration des données adresses OpenData est à
nouveau disponible. Malheureusement la base de données précédemment utilisé
sur feu osm7 n’était pas sauvegardé. On a donc perdu le statuts des
imports, heureusement il n’y en avait pas beaucoup (sauf sur une des
villes). Si besoin on peut reconstruire ces statuts depuis les données OSM
(si quelqu’un le demande, ou encore mieux en donne la liste).

Il y surement d’autres villes qui ont mise à disposition leur données
adresses depuis. Si vous en connaissait vous pouvez le signaler.

http://addr.openstreetmap.fr/

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

Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?

[Ab_fab]

Bonjour,

Une idée :

   1. Utiliser la référence de la relation englobant l'intercommunalité
   dans l'outil de génération de polygones simplifiés de Jocelyn :
   http://osm102.openstreetmap.fr/~jocelyn/polygons/index.py

   (l'url polygon.openstreetmap.fr ne fonctionne pas)

   2. Faire une requête Overpass API pour récupérer les *noeuds* place
   correspondant aux communes incluses dans ce polygone

   
http://wiki.openstreetmap.org/wiki/Overpass_API/Language_Guide#Select_Region_by_Polygon

Il y a quelques mois j'avais fait l'exercice [*] de récupérer les limites
de communes d'une intercommunalité, mais il fallait au préalable établir la
liste des codes INSEE des communes qui la composaient.

Cela ne colle donc pas à ton besoin, à moins que la méthode plus haut soit
le bon préalable.

Bonne journée

[*]
https://lists.openstreetmap.org/pipermail/talk-fr/2011-December/038283.html


Le 19 septembre 2013 11:01, Fionn Halleman <
fionn.halle...@valeurs-mobiles.fr> a écrit :

> Merci Christian pour le tuyau sur les area-query. J'ai essayé sans grand
> succès : si j'en crois une discussion vue depuis, les area-query=* ne
> fonctionnent pas parce que les boundary=local_authority (
> https://lists.openstreetmap.org/pipermail/talk-fr/2013-January/053027.html)
> ne sont pas reconnus par Overpass.
>
> Mais même si ça marchait, j'ai le sentiment que ça ne permettrait de
> toutes les façons pas de répondre à la question "quelles communes
> appartiennent à la CUB, ou au Grand Lyon ?" ou encore, "extrayez-moi les
> limites des communes du département 73" ?
>
> Je crois voir que c'est parce que ce type de relation n'est tout
> simplement pas dans la base : ainsi, la relation "CUB" (
> http://www.openstreetmap.org/browse/relation/905682) n'a apparemment pas
> de lien avec la relation Bordeaux ("
> http://www.openstreetmap.org/browse/relation/105270), pas plus que
> Bordeaux ne semble être tagué logiquement comme étant en Gironde (il l'est
> spatialement, mais c'est plus fragile comme relation)...
>
> Est-ce quelque chose qu'il serait intéressant de modéliser (pour d'autres
> personnes que pour moi, j'entends) ? Y a-t-il des cas où c'est déjà fait ?
>
> Fionn
>
>
>
>
> Le 13 septembre 2013 19:07, Fionn Halleman <
> fionn.halle...@valeurs-mobiles.fr> a écrit :
>
>> Bonsoir,
>>
>> Je me suis un peu cassé les dents sur cette question sans doute assez
>> bête. Je veux sortir la liste des communes appartenant à un EPCI (la CUB),
>> ainsi que les zones correspondantes.
>>
>>
>> J'arrive à obtenir le contour de la CUB :
>>
>> 
>>   
>> 
>> 
>> 
>>
>>   
>>   
>> 
>> 
>>   
>>   
>> 
>>
>> Voire le contours pour chacune des communautés urbaines en France :
>>
>> 
>>   
>> 
>> 
>> 
>>
>>   
>>   
>> 
>> 
>>   
>>   
>> 
>>
>> Mais je n'arrive pas vraiment à avoir la liste exacte des communes
>> appartenant à ces EPCI : quand j'en ai, j'en ai toujours trop ou pas assez.
>> Des idées ?
>>
>> Merci,
>>
>> Fionn
>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
ab_fab 
"Il n'y a pas de pas perdus", Nadja
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?

[Frédéric Rodrigo]

Le 19 septembre 2013 11:01, Fionn Halleman <
fionn.halle...@valeurs-mobiles.fr> a écrit :

> Merci Christian pour le tuyau sur les area-query. J'ai essayé sans grand
> succès : si j'en crois une discussion vue depuis, les area-query=* ne
> fonctionnent pas parce que les boundary=local_authority (
> https://lists.openstreetmap.org/pipermail/talk-fr/2013-January/053027.html)
> ne sont pas reconnus par Overpass.
>

J'ai moi même aussi essayé l'exercice et j'en suis arrive à la même
conclusion.


> Mais même si ça marchait, j'ai le sentiment que ça ne permettrait de
> toutes les façons pas de répondre à la question "quelles communes
> appartiennent à la CUB, ou au Grand Lyon ?" ou encore, "extrayez-moi les
> limites des communes du département 73" ?
>
> Je crois voir que c'est parce que ce type de relation n'est tout
> simplement pas dans la base : ainsi, la relation "CUB" (
> http://www.openstreetmap.org/browse/relation/905682) n'a apparemment pas
> de lien avec la relation Bordeaux ("
> http://www.openstreetmap.org/browse/relation/105270), pas plus que
> Bordeaux ne semble être tagué logiquement comme étant en Gironde (il l'est
> spatialement, mais c'est plus fragile comme relation)...
>
> Est-ce quelque chose qu'il serait intéressant de modéliser (pour d'autres
> personnes que pour moi, j'entends) ? Y a-t-il des cas où c'est déjà fait ?
>

C'est un grand sujet de discutions qui oppose les spatialises (pas besoin
de faire plus on peut le retrouver l’information par requête spatiale) et
aux relationniste (on ajoute de la sécurité et de la sémantique avec des
relations (ma vision perso)).

Le modèle de zone administrative en France est construit sur des relations
type=boundary, en Allemagne c'est avec des type=multipolygon, mais avec la
même façon de faire : ces relations regroupent la limite extérieurs.
Par contre en Espagne le principe est le même, mais il y en plus l'aspect
"surfacique" dans les relation, c'est à dire que les relations des entités
administratives filles sont également présente dans la relation.


Le 13 septembre 2013 19:07, Fionn Halleman <
> fionn.halle...@valeurs-mobiles.fr> a écrit :
>
>> Bonsoir,
>>
>> Je me suis un peu cassé les dents sur cette question sans doute assez
>> bête. Je veux sortir la liste des communes appartenant à un EPCI (la CUB),
>> ainsi que les zones correspondantes.
>>
>>
>> J'arrive à obtenir le contour de la CUB :
>>
>> 
>>   
>> 
>> 
>> 
>>
>>   
>>   
>> 
>> 
>>   
>>   
>> 
>>
>> Voire le contours pour chacune des communautés urbaines en France :
>>
>> 
>>   
>> 
>> 
>> 
>>
>>   
>>   
>> 
>> 
>>   
>>   
>> 
>>
>> Mais je n'arrive pas vraiment à avoir la liste exacte des communes
>> appartenant à ces EPCI : quand j'en ai, j'en ai toujours trop ou pas assez.
>> Des idées ?
>>
>> Merci,
>>
>> Fionn
>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


Le 19 septembre 2013 11:01, Fionn Halleman <
fionn.halle...@valeurs-mobiles.fr> a écrit :

> Merci Christian pour le tuyau sur les area-query. J'ai essayé sans grand
> succès : si j'en crois une discussion vue depuis, les area-query=* ne
> fonctionnent pas parce que les boundary=local_authority (
> https://lists.openstreetmap.org/pipermail/talk-fr/2013-January/053027.html)
> ne sont pas reconnus par Overpass.
>
> Mais même si ça marchait, j'ai le sentiment que ça ne permettrait de
> toutes les façons pas de répondre à la question "quelles communes
> appartiennent à la CUB, ou au Grand Lyon ?" ou encore, "extrayez-moi les
> limites des communes du département 73" ?
>
> Je crois voir que c'est parce que ce type de relation n'est tout
> simplement pas dans la base : ainsi, la relation "CUB" (
> http://www.openstreetmap.org/browse/relation/905682) n'a apparemment pas
> de lien avec la relation Bordeaux ("
> http://www.openstreetmap.org/browse/relation/105270), pas plus que
> Bordeaux ne semble être tagué logiquement comme étant en Gironde (il l'est
> spatialement, mais c'est plus fragile comme relation)...
>
> Est-ce quelque chose qu'il serait intéressant de modéliser (pour d'autres
> personnes que pour moi, j'entends) ? Y a-t-il des cas où c'est déjà fait ?
>
> Fionn
>
>
>
>
> Le 13 septembre 2013 19:07, Fionn Halleman <
> fionn.halle...@valeurs-mobiles.fr> a écrit :
>
>> Bonsoir,
>>
>> Je me suis un peu cassé les dents sur cette question sans doute assez
>> bête. Je veux sortir la liste des communes appartenant à un EPCI (la CUB),
>> ainsi que les zones correspondantes.
>>
>>
>> J'arrive à obtenir le contour de la CUB :
>>
>> 
>>   
>> 
>> 
>> 
>>
>>   
>>   
>> 
>> 
>>   
>>   
>> 
>>
>> Voire le contours pour chacune des communautés urbaines en France :
>>
>> 
>>   
>> 
>> 
>> 
>>
>>   
>>   
>> 
>> 
>>   
>>   
>> 
>>
>> Mais je n'arrive pas vraiment à avoir la liste exacte des communes
>> appartenant à ces EPCI : quand j'en 

Re: [OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?

[Fionn Halleman]

Merci Christian pour le tuyau sur les area-query. J'ai essayé sans grand
succès : si j'en crois une discussion vue depuis, les area-query=* ne
fonctionnent pas parce que les boundary=local_authority (
https://lists.openstreetmap.org/pipermail/talk-fr/2013-January/053027.html)
ne sont pas reconnus par Overpass.

Mais même si ça marchait, j'ai le sentiment que ça ne permettrait de toutes
les façons pas de répondre à la question "quelles communes appartiennent à
la CUB, ou au Grand Lyon ?" ou encore, "extrayez-moi les limites des
communes du département 73" ?

Je crois voir que c'est parce que ce type de relation n'est tout simplement
pas dans la base : ainsi, la relation "CUB" (
http://www.openstreetmap.org/browse/relation/905682) n'a apparemment pas de
lien avec la relation Bordeaux ("
http://www.openstreetmap.org/browse/relation/105270), pas plus que Bordeaux
ne semble être tagué logiquement comme étant en Gironde (il l'est
spatialement, mais c'est plus fragile comme relation)...

Est-ce quelque chose qu'il serait intéressant de modéliser (pour d'autres
personnes que pour moi, j'entends) ? Y a-t-il des cas où c'est déjà fait ?

Fionn




Le 13 septembre 2013 19:07, Fionn Halleman <
fionn.halle...@valeurs-mobiles.fr> a écrit :

> Bonsoir,
>
> Je me suis un peu cassé les dents sur cette question sans doute assez
> bête. Je veux sortir la liste des communes appartenant à un EPCI (la CUB),
> ainsi que les zones correspondantes.
>
>
> J'arrive à obtenir le contour de la CUB :
>
> 
>   
> 
> 
> 
>
>   
>   
> 
> 
>   
>   
> 
>
> Voire le contours pour chacune des communautés urbaines en France :
>
> 
>   
> 
> 
> 
>
>   
>   
> 
> 
>   
>   
> 
>
> Mais je n'arrive pas vraiment à avoir la liste exacte des communes
> appartenant à ces EPCI : quand j'en ai, j'en ai toujours trop ou pas assez.
> Des idées ?
>
> Merci,
>
> Fionn
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr