Re: [OSM-talk-fr] Ç'ui-la, je l'comprends pas…

2012-10-11 Par sujet JB
 

Après vérification, les données d'OSRM ont l'air à jour, une
nouvelle voie que j'ai tracée le 9 octobre est déjà prise en
considération
(http://map.project-osrm.org/?hl=fr&loc=45.132560,5.700540&loc=45.133260,5.700770&z=18¢er=45.131850,5.699726&alt=0&df=0&re=0)


JB 

Le 11.10.2012 08:47, Etienne Trimaille a écrit : 

> Le 11
octobre 2012 07:55, JB a écrit : 
> 
>> (tiens, le
bouton permalink a disparu ? Chez vous aussi ?).
> 
> Non non. Dans la
description de ton itinéraire, clique sur "générer un lien".
>
http://osrm.at/1vx [2]
> 
> Dans OSRM, tu peux aussi afficher les
smallcomponents dans la liste des calques. C'est à mon avis le même
calque que sur geofabrik.
> 
> Je pense que les données d'OSRM ne sont
pas à jour car le tracé de la route au nord du marqueur vert ne
correspond pas à mapnik.
> Par contre pour géofabrik, les données sont
d'hier normalement. Je ne comprends pas l'erreur ... :/ 
> 
>
___
> Talk-fr mailing list
>
Talk-fr@openstreetmap.org
>
http://lists.openstreetmap.org/listinfo/talk-fr [1]




Links:
--
[1] http://lists.openstreetmap.org/listinfo/talk-fr
[2]
http://osrm.at/1vx
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Ç'ui-la, je l'comprends pas…

2012-10-11 Par sujet Sylvain Maillard
Ca doit être un problème dans les données OSMR, mapquest n'a pas de souci
pour faire passer une voiture par ce virage http://mapq.st/Ppf2wY

j'avais remarqué il y a quelques mois que sur un même service les bases de
données de calcul des tuiles et du routage ne sont pas forcément mises à
jour à la même fréquence (escalier mis à jour sur l'affichage de mapquest,
mais pas dans leur moteur de routage), c'est peut-etre juste ça ...


Sylvain


Le 11 octobre 2012 08:47, Etienne Trimaille  a
écrit :

> Le 11 octobre 2012 07:55, JB  a écrit :
>
>> (tiens, le bouton permalink a disparu ? Chez vous aussi ?).
>>
>
> Non non. Dans la description de ton itinéraire, clique sur "générer un
> lien".
> http://osrm.at/1vx
>
> Dans OSRM, tu peux aussi afficher les smallcomponents dans la liste des
> calques. C'est à mon avis le même calque que sur geofabrik.
>
> Je pense que les données d'OSRM ne sont pas à jour car le tracé de la
> route au nord du marqueur vert ne correspond pas à mapnik.
> Par contre pour géofabrik, les données sont d'hier normalement. Je ne
> comprends pas l'erreur ... :/
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


[OSM-talk-fr] Osmose et l'intégration des passages à niveau

2012-10-11 Par sujet Francescu GAROBY
Bonjour,
Je viens de voir qu'il est possible d'intégrer, directement depuis osmose
via le lien 
"josm_fix",
les passages à niveau non intégré.
Or, ces points sont très mal placés ! Je viens d'en regarder quelques-uns,
tant en "ville" qu'en rase campagne : ils sont placés à plusieurs (dizaines
de) mètres du croisement route/chemin de fer le plus proche !

Jusqu'à présent, je trouvais que les "josm_fix" étaient très pratiques
quand il s'agissait de corriger une info déjà existante, et ne nécessitant
pas d'être placée géographiquement (typiquement, une erreur dans un tag,
tel que l'absence de trait d'union après "saint(e)"), mais là je dois dire
que ça me parait très dangereux : c'est un coup à ce que quelqu'un ne fasse
pas gaffe et importe des points placés sur aucune way !

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


[OSM-talk-fr] [forum-osm-fr] Evènement ponctuel

2012-10-11 Par sujet forum
Le message suivant de jerome:
##
Bonjour, 



On m'a dis qu'il était possible de créer un "évènement ponctuel" sur OSM mais 
je ne trouve pas comment...



Par exemple : "[i]Fête du livre à la salle des fêtes de A le 14 novembre 
2012 de 14h00 à 17h00[/i]".



Et que cet évènement disparaîtrait tout seul sitôt la date de fin entrée passée.



Pourriez-vous m'indiquez la marche à suivre ?



Merci d'avance à tous.

a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=2
Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part
Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une 
concertation sur la liste avant de recopier 
la/les meilleurs réponses sur le forum.
Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre.
--
Les questions sur ce robot de transfert forum->liste
peuvent être posées à sylvainaletuffe.org

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


Re: [OSM-talk-fr] Chef-lieu de commune...

2012-10-11 Par sujet Pieren
2012/10/10 Vincent de Chateau-Thierry :

> Si c'est juste pour fixer l'organisation administrative et organiser des
> relations d'inclusions sans géométrie, personnellement je pencherais plus
> pour des relations imbriquées que pour le recours au tag is_in et à ses
> déclinaisons, pour plusieurs raisons :

Bon, je vais donner ma liste des contre-arguments:
- les relations, ça se casse aussi (vs fiabilité des "is_in"). Ca
arrive presque tous les jours sur les boundaries français. Bon, c'est
vrai que les noeuds "place" sont moins souvent manipulés que les
frontières. Mais c'est la même chose avec les places dans "is_in" qui
sont rarement modifiés.
- le schema "is_in" est l'ancien schéma qui existait avant la création
des "boundaries". C'est aussi pour ça qu'il est déjà supporté par des
outils comme Nominatim contrairement à toute nouvelle relation qui,
dans le meilleur des cas, ne sera pas supporté avant des mois (2 ans
pour que nominatim tienne compte de admin_centre) ou dans le pire des
cas, ne soit jamais pris en compte par aucun outil (le plus probable).
- de toute façon, les limites administratives seront tôt ou tard
ajoutées. La solution à mettre en place ne sera donc que temporaire.
Difficile de mobiliser les gens sur quelque chose qui va disparaitre.

Pieren

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


[OSM-talk-fr] Site de visualisation des nouveaux contributeurs en rade?

2012-10-11 Par sujet Romain MEHUT
Bonjour,

J'utilisais ce site http://hdyc.neis-one.org/newestosm.php pour visualiser
les nouveaux contributeurs et cela fait quelques jours qu'il ne fonctionne
plus.

Quelqu'un aurait-il une info à son sujet?

Vous allez me dire qu'il existe aussi
http://neis-one.org/2012/07/new-contributor-feed/ mais ce n'est pas tout à
fait pareil.

Merci.

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


Re: [OSM-talk-fr] Séparation commune et Landuse : demande vérification.

2012-10-11 Par sujet Christian Quest
Les limites des communes sont ok, donc pas merdé ou alors tu l'a bien caché ;)

Le 11 octobre 2012 07:32, Marc  a écrit :
> Bonjour,
>
> Ayant le sentiment que les limites administratives sont des trucs fragiles,
> je viens demander une vérification sur ma séparation du Landuse residential
> de la limite administrative.
> La frontière entre Médan et Villenes était intégrée au multipolygone  de
> zone résidentiel de Villenes.
> J'ai
> - dupliqué les points à chaque extrémité (obtenu trois points) et deplacé
> ceux des ways dédié landuse,
> - prolongé le way landuse pour fermer le multipolygone,
> - refusionnés les points dupliqués (ceux resté en double sur les ways limite
> administrative)
> - supprimé de la relation landuse les ways de la limite administrative.
>
> Le changeset correspondant est là:
> http://www.openstreetmap.org/browse/changeset/13449892
>
> Ai-je merdé ?
>
> Cordialement.
>
> --
> 
> Marc http://www.openstreetmap.org/user/plonk/
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr



-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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


Re: [OSM-talk-fr] Osmose et l'intégration des passages à niveau

2012-10-11 Par sujet Christian Quest
Il y a d'autres infos utiles à conserver comme le numéro de ligne RFF,
qui permet de reconstituer ces lignes par des relations
route=railway...


Le 11 octobre 2012 10:21, Francescu GAROBY  a écrit :
> Bonjour,
> Je viens de voir qu'il est possible d'intégrer, directement depuis osmose
> via le lien "josm_fix", les passages à niveau non intégré.
> Or, ces points sont très mal placés ! Je viens d'en regarder quelques-uns,
> tant en "ville" qu'en rase campagne : ils sont placés à plusieurs (dizaines
> de) mètres du croisement route/chemin de fer le plus proche !
>
> Jusqu'à présent, je trouvais que les "josm_fix" étaient très pratiques quand
> il s'agissait de corriger une info déjà existante, et ne nécessitant pas
> d'être placée géographiquement (typiquement, une erreur dans un tag, tel que
> l'absence de trait d'union après "saint(e)"), mais là je dois dire que ça me
> parait très dangereux : c'est un coup à ce que quelqu'un ne fasse pas gaffe
> et importe des points placés sur aucune way !
>
> --
> Cordialement,
> Francescu GAROBY
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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


Re: [OSM-talk-fr] Site de visualisation des nouveaux contributeurs en rade?

2012-10-11 Par sujet Pieren
2012/10/11 Romain MEHUT :

> Quelqu'un aurait-il une info à son sujet?

Non. Mais voici l'adresse où tu peux demander:

pas...@neis-one.org

Pieren

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


Re: [OSM-talk-fr] Site de visualisation des nouveaux contributeurs en rade?

2012-10-11 Par sujet Romain MEHUT
2012/10/11 Pieren 

> 2012/10/11 Romain MEHUT :
>
> > Quelqu'un aurait-il une info à son sujet?
>
> Non. Mais voici l'adresse où tu peux demander:
>

Merci, je viens de le faire


> pas...@neis-one.org
>
> Pieren
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Site de visualisation des nouveaux contributeurs en rade?

2012-10-11 Par sujet Romain MEHUT
La réponse est que le site a changé d'adresse:
http://resultmaps.neis-one.org/newestosm.php

Romain

Le 11 octobre 2012 11:57, Romain MEHUT  a écrit :

> 2012/10/11 Pieren 
>
>> 2012/10/11 Romain MEHUT :
>>
>> > Quelqu'un aurait-il une info à son sujet?
>>
>> Non. Mais voici l'adresse où tu peux demander:
>>
>
> Merci, je viens de le faire
>
>
>> pas...@neis-one.org
>>
>> Pieren
>>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Site de visualisation des nouveaux contributeurs en rade?

2012-10-11 Par sujet Romain MEHUT
Et Pascal m'a donné un autre lien
http://resultmaps.neis-one.org/newestosmlist.php que je ne connaissais pas.
Ce sont des statistiques des nouveaux contributeurs par pays des 2 et 7
derniers jours.

Romain

Le 11 octobre 2012 12:00, Romain MEHUT  a écrit :

> La réponse est que le site a changé d'adresse:
> http://resultmaps.neis-one.org/newestosm.php
>
> Romain
>
> Le 11 octobre 2012 11:57, Romain MEHUT  a écrit :
>
> 2012/10/11 Pieren 
>>
>>> 2012/10/11 Romain MEHUT :
>>>
>>> > Quelqu'un aurait-il une info à son sujet?
>>>
>>> Non. Mais voici l'adresse où tu peux demander:
>>>
>>
>> Merci, je viens de le faire
>>
>>
>>> pas...@neis-one.org
>>>
>>> Pieren
>>>
>>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Osmose et l'intégration des passages à niveau

2012-10-11 Par sujet Philippe Verdy
Le 11 octobre 2012 10:21, Francescu GAROBY  a écrit :
> Bonjour,
> Je viens de voir qu'il est possible d'intégrer, directement depuis osmose
> via le lien "josm_fix", les passages à niveau non intégré.
> Or, ces points sont très mal placés ! Je viens d'en regarder quelques-uns,
> tant en "ville" qu'en rase campagne : ils sont placés à plusieurs (dizaines
> de) mètres du croisement route/chemin de fer le plus proche !
>
> Jusqu'à présent, je trouvais que les "josm_fix" étaient très pratiques quand
> il s'agissait de corriger une info déjà existante, et ne nécessitant pas
> d'être placée géographiquement (typiquement, une erreur dans un tag, tel que
> l'absence de trait d'union après "saint(e)"), mais là je dois dire que ça me
> parait très dangereux : c'est un coup à ce que quelqu'un ne fasse pas gaffe
> et importe des points placés sur aucune way !

Osmose a raison de mentionner la présence de quelquechose qui manque.
Cela ne veut pas dire qu'on doit accepter les données proposées telles
qu'elles se présentent, le travail à faire c'est de l'intégration : la
localisation ou la géométrie peut être approximative, mais au moins
cela situe la zone où chercher, et cela précise les données de
liaisons à ajouter sur le point **intégré** qui aura été ajouter, et
comment le lier au reste.

Je ne vois pas cela comme une anomalie d'Osmose. C'est même très bien
de savoir qu'on a sans doute des éléments utiles à répertorier dans la
base OSM, pour l'enrichir.

De plus un nœud ou un chemin correspondant peut déjà exister dans la
base OSM : il est seulement non intégré avec les autres données
proposées (si c'est un chemin, il est peut-être nécessaire de le
scinder en plusieurs morceaux successifs : attention à préserver les
relations existantes dessus pour que les nouveaux fragments créés par
la scission se retrouvent dans toutes ces relations, donc CTRL+ALT+D
sur le chemin à scinder si la scission se fait dans JOSM et non
Potlatch, et attention dans Potlatch de bien attendre que les
relations référentes se chargent toutes sur le chemin : on doit
surveiller l'icône de la flèche qui tourne avant de faire la
scission).

Mais pour tout dire, toutes les données manquantes (provenant d'autres
bases de données sous licence libre compatible) et répertoriées par
Osmose et non encore intégrées ne devraient pas être considérées comme
des erreurs, elles n'ont aucun caractère d'urgence puisque de toute
façon elles ne sont pas dans la base et ne posent pas de problème
dedans. Leur sévérité/priorité est donc faible.

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


Re: [OSM-talk-fr] Séparation commune et Landuse : demande vérification.

2012-10-11 Par sujet Philippe Verdy
Aucun problème puisqu'il n'a modifié aucune relation ni aucun chemin
utilisé par ces relations existantes (même si ici cela crée des
segments et nœuds superposés, ce qui n'est pas génial non plus pour
les modifications ultérieures quand on ne sait plus à quel noeud ou
segment superposé se rattacher).

Il me semble que chaque fois on devrait éviter ces superpositions
quand elles n'ont pas lieu d'être : il est très rare qu'un landuse
suive exactement une limite administrative, et je pense que dans ce
cas il vaut mieux avoir que le landuse suive un chemin parallèle
proche de la limite administrative, et du bon côté de celle-ci :

 * il y a généralement un autre objet réel linéaire, non surfacique
comme les landuse=* ou natural=*, qui suit la ligne administrative :
le plus souvent une rue, un chemin ou sentier ou piste, un fossé,
voire un mur ou une clôture, parfois privé et séparant les parcelles :
pas besoin de superposer deux chemins, les deux objets linéaires
peuvent combiner leurs attributs (dans pratiquement tous les cas, les
ambiguïtés possibles pouvant survenir sur un tag dont on ne sait pas
laquelle des valeurs est à garder, mais étant résolues dans les
relations qui utilisent le chemin ou le nœud) ;

 * sauf le plus souvent pour les limites administratives qui traverse
un champ agricole remembré, où le seul objet de séparation qui
persiste est la ligne "virtuelle" de limitation administrative entre
les parcelles réunies (et dans ce cas aussi il n'y a aucune
superposition de nœuds ou de segment à garder : il n'y a pas deux
champs, mais un seul à garder dans le même polygone landuse — qu'on
ira fragmenter ailleurs, si nécessaire, sur une autre ligne réelle
plus adéquate que la limite administrative).

Le 11 octobre 2012 11:21, Christian Quest  a écrit :
> Les limites des communes sont ok, donc pas merdé ou alors tu l'a bien caché ;)
>
> Le 11 octobre 2012 07:32, Marc  a écrit :
>> Bonjour,
>>
>> Ayant le sentiment que les limites administratives sont des trucs fragiles,
>> je viens demander une vérification sur ma séparation du Landuse residential
>> de la limite administrative.
>> La frontière entre Médan et Villenes était intégrée au multipolygone  de
>> zone résidentiel de Villenes.
>> J'ai
>> - dupliqué les points à chaque extrémité (obtenu trois points) et deplacé
>> ceux des ways dédié landuse,
>> - prolongé le way landuse pour fermer le multipolygone,
>> - refusionnés les points dupliqués (ceux resté en double sur les ways limite
>> administrative)
>> - supprimé de la relation landuse les ways de la limite administrative.
>>
>> Le changeset correspondant est là:
>> http://www.openstreetmap.org/browse/changeset/13449892
>>
>> Ai-je merdé ?
>>
>> Cordialement.
>>
>> --
>> 
>> Marc http://www.openstreetmap.org/user/plonk/
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> --
> Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

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


Re: [OSM-talk-fr] Limites communales dans les DOM

2012-10-11 Par sujet sly (sylvain letuffe)
On mercredi 10 octobre 2012, Pierre Touzard wrote:
> Bonsoir à tous,

Salut,

> Quel dommage que l'on ne puisse pas trouver ici
> (http://export.openstreetmap.fr/contours-administratifs/export-communes/)
> les limites communales sur les DOM...

C'est moi qui m'occupe de cette exportation, et je veux bien ajouter les 
limites de communes des DOM si cela peut se faire assez simplement.
En théorie, si c'est fait pareil que pour les départements de métropoles, vu 
que j'ai accès à la base mondiale, il ne devrait pas y avoir de problème... 
mais...

> Il manque :
> 971 : Guadeloupe (cadastre entièrement vectorisé)
> 972 : Martinique (cadastre entièrement vectorisé)
> 973 : Guyane (cadastre récemment entièrement vectorisé mais pas diffusé sur
> cadastre.gouv.fr)
> 974 : Réunion (cadastre entièrement vectorisé)
> 976 : Mayotte (cadastre entièrement vectorisé mais pas diffusé sur
> cadastre.gouv.fr)

Je cherche dans la base ses départements mais ne les trouvent point :
=> select name from planet_osm_polygon where ref='974' and admin_level='6';
 name
--
(0 rows)
=> select name from planet_osm_polygon where ref='74' and admin_level='6';
 name
--
 Haute-Savoie
(1 row)

Y'a un truc que j'ai loupé ? quelqu'un peut me montrer une relation d'un de 
ces départements ? Est-ce que les DOM sont encodés d'une façon différente ? 
Y-a-t-il une raison pour laquelle ce n'est pas homogène avec les autres 
département français ? Est-ce juste une erreur temporaire ?

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

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


Re: [OSM-talk-fr] Limites communales dans les DOM

2012-10-11 Par sujet Christian Quest
J'ai regardé la réunion, c'est admin_level=4 car c'est un département
ET une région...

Il manque peut être la relation admin_level=6 correspondante même si
elle est identique au niveau topologique.
C'est sûrement pareil pour les autres (pas regardé).


Le 11 octobre 2012 12:34, sly (sylvain letuffe)  a écrit :
> On mercredi 10 octobre 2012, Pierre Touzard wrote:
>> Bonsoir à tous,
>
> Salut,
>
>> Quel dommage que l'on ne puisse pas trouver ici
>> (http://export.openstreetmap.fr/contours-administratifs/export-communes/)
>> les limites communales sur les DOM...
>
> C'est moi qui m'occupe de cette exportation, et je veux bien ajouter les
> limites de communes des DOM si cela peut se faire assez simplement.
> En théorie, si c'est fait pareil que pour les départements de métropoles, vu
> que j'ai accès à la base mondiale, il ne devrait pas y avoir de problème...
> mais...
>
>> Il manque :
>> 971 : Guadeloupe (cadastre entièrement vectorisé)
>> 972 : Martinique (cadastre entièrement vectorisé)
>> 973 : Guyane (cadastre récemment entièrement vectorisé mais pas diffusé sur
>> cadastre.gouv.fr)
>> 974 : Réunion (cadastre entièrement vectorisé)
>> 976 : Mayotte (cadastre entièrement vectorisé mais pas diffusé sur
>> cadastre.gouv.fr)
>
> Je cherche dans la base ses départements mais ne les trouvent point :
> => select name from planet_osm_polygon where ref='974' and admin_level='6';
>  name
> --
> (0 rows)
> => select name from planet_osm_polygon where ref='74' and admin_level='6';
>  name
> --
>  Haute-Savoie
> (1 row)
>
> Y'a un truc que j'ai loupé ? quelqu'un peut me montrer une relation d'un de
> ces départements ? Est-ce que les DOM sont encodés d'une façon différente ?
> Y-a-t-il une raison pour laquelle ce n'est pas homogène avec les autres
> département français ? Est-ce juste une erreur temporaire ?
>
> --
> sly
> qui suis-je : http://sly.letuffe.org
> email perso : sylvain chez letuffe un point org
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr



-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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


Re: [OSM-talk-fr] Limites communales dans les DOM

2012-10-11 Par sujet Philippe Verdy
Il me semble que les DOM/ROM et COM sont limités par des frontières
internationales (niveau 2, et non 4 et/ou 6 sur leurs chemins).

Seules les relations territoriales des DOM/ROM et COM ont les niveaux
4 et/ou 6 (le plus souvent actuellement elles sont limitées sur leur
frontière internationale maritime des eaux territoriales et non leur
ligne de côte (ce seraient d'autres relations supplémentaires de
type=land_area pour les "(terres)" en français ou "(land mass)" en
anglais dans les noms qualifiés donnés à ces relations, et non
type=boundary et boundary=administrative pour les noms non qualifiés
des territoires)

> Je cherche dans la base ses départements mais ne les trouvent point :
> => select name from planet_osm_polygon where ref='974' and admin_level='6';
>  name
> --
> (0 rows)
> => select name from planet_osm_polygon where ref='74' and admin_level='6';
>  name
> --
>  Haute-Savoie
> (1 row)
>
> Y'a un truc que j'ai loupé ? quelqu'un peut me montrer une relation d'un de
> ces départements ? Est-ce que les DOM sont encodés d'une façon différente ?
> Y-a-t-il une raison pour laquelle ce n'est pas homogène avec les autres
> département français ? Est-ce juste une erreur temporaire ?

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


Re: [OSM-talk-fr] Limites communales dans les DOM

2012-10-11 Par sujet Philippe Verdy
Le 11 octobre 2012 12:46, Christian Quest  a écrit :
> J'ai regardé la réunion, c'est admin_level=4 car c'est un département
> ET une région...
>
> Il manque peut être la relation admin_level=6 correspondante même si
> elle est identique au niveau topologique.

Pas partout : oui pour les DOM/ROM, mais pas forcément si c'est la
même collectivité légalement, comme à Mayotte dont la même
collectivité locale a les compétences combinées d'un département et
d'une région, avec une assemblée unique et un budget unique.

Pas forcément non plus pour les COM (toutes aussi des collectivités
uniques qui parfois ont aussi les compétences de la commune, par
exemple à Saint-Martin ou Saint-Barthélemy. Leur niveau administratif
reste alors uniquement 4, par assimilation aux autres régions
françaises (comme on le fait aussi en métropole pour la Corse, même si
le statut légal est un peu différent des autres régions
métropolitaines).

> C'est sûrement pareil pour les autres (pas regardé).

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


Re: [OSM-talk-fr] Limites communales dans les DOM

2012-10-11 Par sujet Arnaud Vandecasteele
Salut à tous,

Concernant les limites communales de la Réunion, celles-ci sont disponibles
ici :
http://www.osm974.re/osm-shp/

Si besoin, je peux fournir la requête SQL.

Arnaud

2012/10/11 Philippe Verdy 

> Le 11 octobre 2012 12:46, Christian Quest  a
> écrit :
> > J'ai regardé la réunion, c'est admin_level=4 car c'est un département
> > ET une région...
> >
> > Il manque peut être la relation admin_level=6 correspondante même si
> > elle est identique au niveau topologique.
>
> Pas partout : oui pour les DOM/ROM, mais pas forcément si c'est la
> même collectivité légalement, comme à Mayotte dont la même
> collectivité locale a les compétences combinées d'un département et
> d'une région, avec une assemblée unique et un budget unique.
>
> Pas forcément non plus pour les COM (toutes aussi des collectivités
> uniques qui parfois ont aussi les compétences de la commune, par
> exemple à Saint-Martin ou Saint-Barthélemy. Leur niveau administratif
> reste alors uniquement 4, par assimilation aux autres régions
> françaises (comme on le fait aussi en métropole pour la Corse, même si
> le statut légal est un peu différent des autres régions
> métropolitaines).
>
> > C'est sûrement pareil pour les autres (pas regardé).
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 

Arnaud Vandecasteele
Mines Paris Tech - CRC
Sophia-Antipolis
0698 24 25 29
SIG - WebMapping - Spatial Ontology - GeoCollaboration

Web Site
http://perso.crc.mines-paristech.fr/~arnaud.van_de_casteele/
http://geotribu.net/
http://www.i2c.eu/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


[OSM-talk-fr] parking entouré d'une barrière

2012-10-11 Par sujet Francescu GAROBY
Bonjour,
En tagguant des parkings, délimités par des grillages et dont l'entrée et
la sortie sont régies par des barrières , m'est venue la question suivante
: vous parait-il correct de rajouter un tag barrier=fence (et
barrier=lift_gate aux points d'entrée/sortie), sur le way délimitant le
parking, et passant à l'emplacement du grillage, plutôt que de tracer une
way pour le grillage+ une surface (donc une way) pour délimiter la surface
du parking ?

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


Re: [OSM-talk-fr] parking entouré d'une barrière

2012-10-11 Par sujet teuxe
Bonjour,

Mon usage personnel tend à tracer un way spécifique pour les barrières, murs, 
etc. autour des surfaces, et pas seulement parce qu'on peut rencontrer un bout 
de mur et un bout de barrière sur un contour.

C'est plutôt d'un point de vue conceptuel. On peut se dire que le way fermé 
("area") représente une surface qui sert de parking ; à l'opposé, la barrière, 
même si elle couvre tout le périmètre du parking, n'en reste pas moins un 
linéaire et n'est pas une surface : n'étant pas de même nature, on ne peut pas 
associer les deux au même "objet".

Teuxe


- Mail original -
De: "Francescu GAROBY" 
À: "Discussions sur OSM en français" 
Envoyé: Jeudi 11 Octobre 2012 14:03:25
Objet: [OSM-talk-fr] parking entouré d'une barrière


Bonjour, 
En tagguant des parkings, délimités par des grillages et dont l'entrée et la 
sortie sont régies par des barrières , m'est venue la question suivante : vous 
parait-il correct de rajouter un tag barrier=fence (et barrier=lift_gate aux 
points d'entrée/sortie), sur le way délimitant le parking, et passant à 
l'emplacement du grillage, plutôt que de tracer une way pour le grillage+ une 
surface (donc une way) pour délimiter la surface du parking ? 

-- 
Cordialement, 
Francescu GAROBY 


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

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


Re: [OSM-talk-fr] parking entouré d'une barrière

2012-10-11 Par sujet Jean-Francois Nifenecker

Le 11/10/2012 14:03, Francescu GAROBY a écrit :

Bonjour,
En tagguant des parkings, délimités par des grillages et dont l'entrée
et la sortie sont régies par des barrières , m'est venue la question
suivante : vous parait-il correct de rajouter un tag barrier=fence (et
barrier=lift_gate aux points d'entrée/sortie), sur le way délimitant le
parking, et passant à l'emplacement du grillage, plutôt que de tracer
une way pour le grillage+ une surface (donc une way) pour délimiter la
surface du parking ?


Une seule surface suffit. Celle-ci comporte alors les tags 
amenity=parking et barrier=*

Au point d'entrée/sortie, un tag barrier=*

--
Jean-Francois Nifenecker, Bordeaux

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


Re: [OSM-talk-fr] parking entouré d'une barrière

2012-10-11 Par sujet Francescu GAROBY
2 réponses en 2 minutes : merci pour la réactivité !
Manque de chance, elles sont contradictoires ! :-D

Francescu

Le 11 octobre 2012 14:18, Jean-Francois Nifenecker <
jean-francois.nifenec...@laposte.net> a écrit :

> Le 11/10/2012 14:03, Francescu GAROBY a écrit :
>
>  Bonjour,
>> En tagguant des parkings, délimités par des grillages et dont l'entrée
>> et la sortie sont régies par des barrières , m'est venue la question
>> suivante : vous parait-il correct de rajouter un tag barrier=fence (et
>> barrier=lift_gate aux points d'entrée/sortie), sur le way délimitant le
>> parking, et passant à l'emplacement du grillage, plutôt que de tracer
>> une way pour le grillage+ une surface (donc une way) pour délimiter la
>> surface du parking ?
>>
>
> Une seule surface suffit. Celle-ci comporte alors les tags amenity=parking
> et barrier=*
> Au point d'entrée/sortie, un tag barrier=*
>
> --
> Jean-Francois Nifenecker, Bordeaux
>
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr
>



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


[OSM-talk-fr] Intégration des cours d'eau

2012-10-11 Par sujet Club Informatique Inter Communes / C2IC
Bonjour à tous

Voulant me pencher sur l'intégration des cours d'eau dans mon secteur
(Pays du Roi Morvan en Bretagne) j'ai opté pour l'imagerie issue du
SANDRE pour avoir les éléments (voir
http://www.openstreetmap.org/user/1piedsurTerre/diary/17869).

Mais les remarques de BrunoC et de Pieren m'ont gentiment alerté sur
l'incompatibilité de licence entre OSM et le SANDRE.

D'où ma question du jour : quid de mes contributions d'hier soir et de
ce matin ?

Les changesets sont les suivants :
http://www.openstreetmap.org/browse/changeset/13446545 /
http://www.openstreetmap.org/browse/changeset/13450822 et
http://www.openstreetmap.org/browse/changeset/13450951

Je supprime tout et je recommence avec l'imagerie ?

Merci de vos éclairages !

Lionel / 1piedsurTerre

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


Re: [OSM-talk-fr] Chef-lieu de commune...

2012-10-11 Par sujet Vincent de Chateau-Thierry

> De : "Pieren" 

> 2012/10/10 Vincent de Chateau-Thierry :
> 
> > Si c'est juste pour fixer l'organisation administrative et organiser des
> > relations d'inclusions sans géométrie, personnellement je pencherais plus
> > pour des relations imbriquées que pour le recours au tag is_in et à ses
> > déclinaisons, pour plusieurs raisons :
> 
> Bon, je vais donner ma liste des contre-arguments:
> - les relations, ça se casse aussi (vs fiabilité des "is_in"). Ca
> arrive presque tous les jours sur les boundaries français. Bon, c'est
> vrai que les noeuds "place" sont moins souvent manipulés que les
> frontières. Mais c'est la même chose avec les places dans "is_in" qui
> sont rarement modifiés.
> - le schema "is_in" est l'ancien schéma qui existait avant la création
> des "boundaries". C'est aussi pour ça qu'il est déjà supporté par des
> outils comme Nominatim contrairement à toute nouvelle relation qui,
> dans le meilleur des cas, ne sera pas supporté avant des mois (2 ans
> pour que nominatim tienne compte de admin_centre) ou dans le pire des
> cas, ne soit jamais pris en compte par aucun outil (le plus probable).
> - de toute façon, les limites administratives seront tôt ou tard
> ajoutées. La solution à mettre en place ne sera donc que temporaire.
> Difficile de mobiliser les gens sur quelque chose qui va disparaitre.
> 

Au tout début de ma proposition, il y a une question pour Eric :
"Je ne sais pas si tu as un usage en tête pour ce que tu vas modéliser ?"
De sa réponse dépend pas mal le choix à faire, à mon avis. 
Si le but premier est de s'inscrire dans les outils existants (principalement
Nominatim) alors oui, bien sûr, l'exercice doit consister à entrer dans un
moule connu de Nominatim. Si le mode "is_in" est reconnu, alors pas de question
à se poser, il faut l'utiliser.
Dans ce que je proposais hier, je m'affranchissais de ce besoin (parler la 
langue
de Nominatim ou d'une autre appli bien établie), je cherchais plutôt la 
modélisation
qui me paraît la plus pratique pour organiser une organisation arborescente et
la manipuler, mais en faisant l'hypothèse qu'Eric a la maîtrise des outils qui 
la
manipuleront. Typiquement : il charge ces données dans une base relationnelle et
a besoin de connaître des relations entre entités administratives. Dans ce cas, 
les
propriétés d'inclusion dans une relation avec un rôle sont bien plus pratique 
pour
lier les objets, que la valeur du tag is_in.
D'accord sur un point, comme tu le rappelles : tout ceci est un exercice 
temporaire,
la cible étant de pouvoir embrayer sur une modélisation type boundary lorsque 
les
données (géométriques) seront disponibles. Et c'est ce côté temporaire qui me 
fait
proposer sans trop de scrupules des tags pas forcément établis ni reconnus 
(typiquement
le rôle "commune" ou "village").

vincent

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

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


Re: [OSM-talk-fr] parking entouré d'une barrière

2012-10-11 Par sujet teuxe
Les contradictions permettent de lever des loups et de réfléchir ensemble à la 
meilleure technique à adopter. Merci d'avoir ouvert le sujet ;)

Teuxe

- Mail original -
De: "Francescu GAROBY" 
À: "Discussions sur OSM en français" 
Envoyé: Jeudi 11 Octobre 2012 14:20:49
Objet: Re: [OSM-talk-fr]parking entouré d'une barrière


2 réponses en 2 minutes : merci pour la réactivité ! 
Manque de chance, elles sont contradictoires ! :-D 

Francescu 


Le 11 octobre 2012 14:18, Jean-Francois Nifenecker < 
jean-francois.nifenec...@laposte.net > a écrit : 


Le 11/10/2012 14:03, Francescu GAROBY a écrit : 




Bonjour, 
En tagguant des parkings, délimités par des grillages et dont l'entrée 
et la sortie sont régies par des barrières , m'est venue la question 
suivante : vous parait-il correct de rajouter un tag barrier=fence (et 
barrier=lift_gate aux points d'entrée/sortie), sur le way délimitant le 
parking, et passant à l'emplacement du grillage, plutôt que de tracer 
une way pour le grillage+ une surface (donc une way) pour délimiter la 
surface du parking ? 

Une seule surface suffit. Celle-ci comporte alors les tags amenity=parking et 
barrier=* 
Au point d'entrée/sortie, un tag barrier=* 

-- 
Jean-Francois Nifenecker, Bordeaux 



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



-- 
Cordialement, 
Francescu GAROBY 


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

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


Re: [OSM-talk-fr] Limites communales dans les DOM

2012-10-11 Par sujet Jocelyn Jaubert
On Thu, Oct 11, 2012 at 12:34:41PM +0200, sly (sylvain letuffe) wrote:
> Y'a un truc que j'ai loupé ? quelqu'un peut me montrer une relation d'un de 
> ces départements ? Est-ce que les DOM sont encodés d'une façon différente ? 
> Y-a-t-il une raison pour laquelle ce n'est pas homogène avec les autres 
> département français ? Est-ce juste une erreur temporaire ?

Normalement, la page de wiki suivante est à jour, et contient la liste de
toutes les relations utilisées pour les DOM-ROM, et territoires d'outre-mer:

http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives#Ce_qui_existe_d.C3.A9j.C3.A0.2C_qui_travaille_o.C3.B9

Et la relation France globale (11980) devrait contenir toutes ces relations.

-- 
Jocelyn

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


Re: [OSM-talk-fr] Osmose et l'intégration des passages à niveau

2012-10-11 Par sujet teuxe
J'ajoute que si OsmOse peut déterminer les endroits où les routes et les voies 
ferrées se coupent, il ne peut pas en déduire qu'il y a là un passage à niveau. 
On trouve souvent des ponts ou des mini-tunnels ; et même si un passage à 
niveau se trouve effectivement là, il peut être protégé ou pas, et par exemple 
limiter la traversée aux piétons et vélos...

D'autant que si le "point d'intersection" est très mal localisé, c'est sûrement 
que le secteur est tracé à la va-vite depuis les vues aériennes et que beaucoup 
de détails peuvent avoir besoin d'être relevés sur place. D'accord pour dire 
que le josm_fix peut être utile pour accélérer les choses, mais l'usage ne doit 
pas être automatique. Mais bon... ça ressemble à une autre discussion sur 
l'usage des outils par les débutants qui sont plus enclins à faire des erreurs.

Teuxe


- Mail original -
De: "Philippe Verdy" 
À: "Discussions sur OSM en français" 
Envoyé: Jeudi 11 Octobre 2012 12:15:11
Objet: Re: [OSM-talk-fr]Osmose et l'intégration des passages à niveau

Le 11 octobre 2012 10:21, Francescu GAROBY  a écrit :
> Bonjour,
> Je viens de voir qu'il est possible d'intégrer, directement depuis osmose
> via le lien "josm_fix", les passages à niveau non intégré.
> Or, ces points sont très mal placés ! Je viens d'en regarder quelques-uns,
> tant en "ville" qu'en rase campagne : ils sont placés à plusieurs (dizaines
> de) mètres du croisement route/chemin de fer le plus proche !
>
> Jusqu'à présent, je trouvais que les "josm_fix" étaient très pratiques quand
> il s'agissait de corriger une info déjà existante, et ne nécessitant pas
> d'être placée géographiquement (typiquement, une erreur dans un tag, tel que
> l'absence de trait d'union après "saint(e)"), mais là je dois dire que ça me
> parait très dangereux : c'est un coup à ce que quelqu'un ne fasse pas gaffe
> et importe des points placés sur aucune way !

Osmose a raison de mentionner la présence de quelquechose qui manque.
Cela ne veut pas dire qu'on doit accepter les données proposées telles
qu'elles se présentent, le travail à faire c'est de l'intégration : la
localisation ou la géométrie peut être approximative, mais au moins
cela situe la zone où chercher, et cela précise les données de
liaisons à ajouter sur le point **intégré** qui aura été ajouter, et
comment le lier au reste.

Je ne vois pas cela comme une anomalie d'Osmose. C'est même très bien
de savoir qu'on a sans doute des éléments utiles à répertorier dans la
base OSM, pour l'enrichir.

De plus un nœud ou un chemin correspondant peut déjà exister dans la
base OSM : il est seulement non intégré avec les autres données
proposées (si c'est un chemin, il est peut-être nécessaire de le
scinder en plusieurs morceaux successifs : attention à préserver les
relations existantes dessus pour que les nouveaux fragments créés par
la scission se retrouvent dans toutes ces relations, donc CTRL+ALT+D
sur le chemin à scinder si la scission se fait dans JOSM et non
Potlatch, et attention dans Potlatch de bien attendre que les
relations référentes se chargent toutes sur le chemin : on doit
surveiller l'icône de la flèche qui tourne avant de faire la
scission).

Mais pour tout dire, toutes les données manquantes (provenant d'autres
bases de données sous licence libre compatible) et répertoriées par
Osmose et non encore intégrées ne devraient pas être considérées comme
des erreurs, elles n'ont aucun caractère d'urgence puisque de toute
façon elles ne sont pas dans la base et ne posent pas de problème
dedans. Leur sévérité/priorité est donc faible.

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

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


Re: [OSM-talk-fr] parking entouré d'une barrière

2012-10-11 Par sujet Pieren
2012/10/11 Francescu GAROBY :

> Manque de chance, elles sont contradictoires ! :-D

Elles sont différentes. Mais les deux solutions sont correctes. Sauf
que tracer deux ways qui se superposent exactement n'est pas pratique.
Il y a un gros risque que les contributeurs peu habitués n'en voit
qu'un seul. A toi de peser les pour et les contre. Moi, je suis
partisan du moindre effort donc un seul way ;-) Y en a qui vont
sûrement te proposer une 3e solution : utiliser des relations !

Pieren

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


Re: [OSM-talk-fr] Limites communales dans les DOM - tags pour les DOM/TOM

2012-10-11 Par sujet sly (sylvain letuffe)
On jeudi 11 octobre 2012, Christian Quest wrote:
> J'ai regardé la réunion, c'est admin_level=4 car c'est un département
> ET une région...

Ha bon, moi qui croyait que le "D" de DOM voulait dire Département ;-)
Bon, ça ne marche pas mieux avec admin_level=4, j'ai regardé un peu plus en 
détail, voici donc la relation pour la réunion (commençons par là, inutile de 
se disperser) :
http://www.openstreetmap.org/browse/relation/77601

Ce qui me manque c'est aussi le code département comme les autres ref=974

J'ai donc compris que la réunion était donc un département (DOM) de code 
département 974, qui était contenu par une région de code inconnu ne 
contenant qu'un seul département, elle-même en terme de surface. 

Ma proposition alors, (sans tenir compte du fait que ça m'arrangerait bien 
pour mon programme ;-) ) serait de :
créér deux relations :
* a) une pour le département avec admin_level=6 et ref=974 contenant les 
membres qui forment le contour de l'île
* b) une autre pour la région avec admin_level=4 (pas de ref, sauf s'il en 
existe une pour la réunion en tant que région) contenant comme unique membre 
la précédente

Remontant d'un cran au dessus, la relation "France: Régions d'outre-mer" : 
http://www.openstreetmap.org/browse/relation/1263863
pourrait alors contenir directement la a) (comme c'est aujourd'hui)


> C'est sûrement pareil pour les autres (pas regardé).
Pour la guadeloupe c'est un admin_level=2 on dirait, et sous la forme d'une 
pyramide qui semble, je dis bien semble, faire usage d'un mécanisme à la 
subarea
Pour la martinique, je ne la trouve pas, ou alors si, mais uniquement les eaux 
territoriales, mystère...
Guyanne, mayotte : admin_level=2

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

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


[OSM-talk-fr] Antennes téléphonie mobile en france

2012-10-11 Par sujet Stéphane Péneau

Hello,

Je crois qu'il a déjà été question de l'intégration des antennes de 
téléphonie mobile dans osm, mais je ne sais plus où.


Le site lebonforfait.fr les répertorie avec pas mal de détails :
http://www.lebonforfait.fr/antennes-mobiles.html

Sur son compte twitter, il parle d'un fichier cvs les recensant. 
Quelqu'un est au courant de ça ?



Stéphane


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


Re: [OSM-talk-fr] Limites communales dans les DOM

2012-10-11 Par sujet sly (sylvain letuffe)
On jeudi 11 octobre 2012, Jocelyn Jaubert wrote:
> Normalement, la page de wiki suivante est à jour, et contient la liste de
> toutes les relations utilisées pour les DOM-ROM, et territoires d'outre-mer:
> 
> 
http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives#Ce_qui_existe_d.C3.A9j.C3.A0.2C_qui_travaille_o.C3.B9

Je ne connaissais pas (j'utilisais plutôt les relations en pyramides), mais 
c'était une bonne idée, sinon je n'aurais jamais retrouvé la martinique :

Pouf la martinique :
http://www.openstreetmap.org/browse/relation/1260552

Je ne touche à rien, je ne sais pas si c'est voulu ou non par la 
sous-communauté fr des îles ;-)


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

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


Re: [OSM-talk-fr] Antennes téléphonie mobile en france

2012-10-11 Par sujet Francescu GAROBY
Plus que les données, c'est surtout la licence qu'il faudrait connaitre,
pour pouvoir intégrer les données dans OSM.
sur la carte que tu cites, il est indiqué (en bas à gauche) que les données
sont publiées par l'ANFR, laquelle indique les conditions d'utilisation de
ses données, sur cette page : http://www.anfr.fr/fr/mentions-legales.html
Je ne suis pas assez calé pour dire si c'est compatible avec une licence
libre, mais le point interdisant d'altérer ou de modifier les données me
fait penser que non.

Francescu

Le 11 octobre 2012 15:00, Stéphane Péneau  a
écrit :

> Hello,
>
> Je crois qu'il a déjà été question de l'intégration des antennes de
> téléphonie mobile dans osm, mais je ne sais plus où.
>
> Le site lebonforfait.fr les répertorie avec pas mal de détails :
> http://www.lebonforfait.fr/**antennes-mobiles.html
>
> Sur son compte twitter, il parle d'un fichier cvs les recensant. Quelqu'un
> est au courant de ça ?
>
>
> Stéphane
>
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr
>



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


Re: [OSM-talk-fr] Antennes téléphonie mobile en france

2012-10-11 Par sujet Fabien
Le 11 octobre 2012 15:00, Stéphane Péneau  a écrit :
> Hello,
>
> Je crois qu'il a déjà été question de l'intégration des antennes de
> téléphonie mobile dans osm, mais je ne sais plus où.
>
> Le site lebonforfait.fr les répertorie avec pas mal de détails :
> http://www.lebonforfait.fr/antennes-mobiles.html
>
> Sur son compte twitter, il parle d'un fichier cvs les recensant. Quelqu'un
> est au courant de ça ?
>
>
> Stéphane
>
>

Il fait référence aux données de l'ANFR qui donne ceci comme terme
d'utilisation : http://www.anfr.fr/fr/mentions-legales.html
Propriété intellectuelle

Le site de l’ANFR est une œuvre de création, propriété exclusive de
l’ANFR, protégé par la législation française et internationale sur le
droit de la propriété intellectuelle. Aucune reproduction ou
représentation ne peut être réalisée en contravention avec les droits
de l’ANFR issus des législations susvisées.
Informations publiques et droit de reproduction

Le site ANFR.FR et notamment l'application Cartoradio (marque déposée)
contiennent des informations publiques au sens de la loi n° 78-753 du
17 juillet 1978 modifiée portant diverses mesures d'amélioration des
relations entre l'administration et le public et diverses dispositions
d'ordre administratif, social et fiscal.

Ces informations sont protégées par la Convention de Berne sur la
Protection des œuvres littéraires et artistiques, par d'autres
conventions internationales et par les législations nationales sur le
droit d'auteur et les droits dérivés.

Elles peuvent être reproduites sous réserve de :

n'être ni altérées ni modifiées,
comporter la mention du nom de l'ANFR en tant que source
préciser la date de leur mise à jour,
faire figurer un lien renvoyant vers la page originale ou le
document diffusé sur le site ANFR.FR.

Toute information provenant du site Internet de l'ANFR doit être
reprise intégralement, sans modification ni ajout, sans adjonction
publicitaire et doit être téléchargeable gratuitement. A aucun moment,
la réutilisation des données ne doit donner l'impression que l'ANFR
participe à ou cautionne l'action de l'utilisateur.

Un juriste pour dire si on peut s'en servir ?

Fabien

PS : le temps de répondre on a aussi répondu la même chose...

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


Re: [OSM-talk-fr] Antennes téléphonie mobile en france

2012-10-11 Par sujet Stéphane Péneau
Vous dégainez plus vite que moi qui suit en ce moment sur le site de 
l'anfr.


Je suis aussi assez surpris par un point :
"03. Pourquoi ne retrouve-t-on pas le nom des opérateurs dans les 
données exportées ?


Conformément à un avis de l'Autorité de la concurrence du 15 décembre 
2011, et afin d'éviter de dévoiler la stratégie de déploiement des 
opérateurs au niveau national, cette information a été retirée dans les 
exportations. Elle reste néanmoins accessible à l'écran pour les zones 
et supports consultés."


Pourtant, tout est indiqué sur lebonforfait.

Stf


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


Re: [OSM-talk-fr] Antennes téléphonie mobile en france

2012-10-11 Par sujet Jean-Marc Liotier

On 11/10/2012 15:00, Stéphane Péneau wrote:

Le site lebonforfait.fr les répertorie avec pas mal de détails :
http://www.lebonforfait.fr/antennes-mobiles.html
Ce site ne répertorie pas des antennes mais des sites radio - qui ont 
généralement chacun plusieurs antennes et dont la localisation à une 
adresse ne donne qu'une vague idée de l'implantation physique. Ce ne 
sont donc sûrement pas des données à importer.


Un site comprend une ou plusieurs locaux hébergeant des équipements - 
parfois dans un simple container à l'air libre, parfois dans une salle 
remplie de baies ronronnantes. Ce local est localisée à une adresse et 
sa présence est généralement insoupçonnable depuis l'extérieur. Si la 
présence du local n'est pas vérifiable sur le terrain, il n'a pas lieu 
d'être référencé dans OSM.


La position des antennes peut par contre être vérifiée sur le terrain et 
éventuellement reportée dans OSM - de la même manière que les caméras de 
vidéosurveillance. Mais pour chacun des points à l'adresse mentionnée 
par Stéphane, il y a probablement au moins une demie-douzaine d'antennes 
de différents types - positionnées par exemple tout autour du bâtiment 
où se trouve le site.



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


Re: [OSM-talk-fr] Antennes téléphonie mobile en france

2012-10-11 Par sujet Bruno Cortial
Le 11 octobre 2012 15:00, Stéphane Péneau  a
écrit :

> Hello,
>
> Je crois qu'il a déjà été question de l'intégration des antennes de
> téléphonie mobile dans osm, mais je ne sais plus où.
>

Bonjour
Claire 'Liberbic' à lancé le sujet sur la liste nantaise
http://www.linux-nantes.org/wws/arc/openstreetmap-nantes/2012-09/msg00026.html

(on dirai qu'on a perdu une partie des archives car une discussion c'est
engagé sur une cartopartie "antenne" basée sur les données ANFR)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Antennes téléphonie mobile en france

2012-10-11 Par sujet Claire Libertic
Bonjour,

Pour avoir rencontré l'ANFR et envisagé l'intégration dans OSM avec un
représentant, ils n'y voyaient aucun inconvénient et indiquaient que leur
licence était faite pour. (ce commentaire n'est pas une garantie juridique)

Par contre, quand vous évoquez la non-dénaturation, il s'agit simplement de
la retranscription de l'article 12 de la loi francaise sur le droit d'accès
à l'information
publique.
Leur licence est une retranscription de cette loi qui s'impose aux
documents publiques.

A savoir: Même les données publiques mises à disposition sous licences
ouvertes ou ODbL ne sont réutilisables en toute légalité qu'en respectant
ces critères inscrit dans la loi. Tout simplement parce que ces deux
licences libres ne se substituent pas mais s’additionnent à la loi
française. Cela n'a pourtant pas empêché l'intégration de données sous ces
licences.

En conclusion, il doit être possible de les intégrer mais en enlevant la
mention des opérateurs qui apparaît en effet sur la Base.
Attention cependant : après des échanges sur la liste de
Nantes,
il a été constaté que la base ANFR n'était pas à jour. Un relevé terrain
s'impose.
On se posait justement la question : carto ou import...

Claire
@libertic


Le 11 octobre 2012 15:17, Stéphane Péneau  a
écrit :

> Vous dégainez plus vite que moi qui suit en ce moment sur le site de
> l'anfr.
>
> Je suis aussi assez surpris par un point :
> "03. Pourquoi ne retrouve-t-on pas le nom des opérateurs dans les données
> exportées ?
>
> Conformément à un avis de l'Autorité de la concurrence du 15 décembre
> 2011, et afin d'éviter de dévoiler la stratégie de déploiement des
> opérateurs au niveau national, cette information a été retirée dans les
> exportations. Elle reste néanmoins accessible à l'écran pour les zones et
> supports consultés."
>
> Pourtant, tout est indiqué sur lebonforfait.
>
> Stf
>
>
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


[OSM-talk-fr] Imbrication des noms dans les résultats de recherche

2012-10-11 Par sujet Ista Pouss
Bonjour,

Si avec osm je fais une recherche de n'importe quel nom sur saint etienne,
j'obtiens quasi toujours "le nom, Technopole, Saint Etienne, Loire,
Rhônes-Alpes, le code postal, France.

Par exemple, si je demande "Place Dorian, Saint Etienne", Nominatim me
renvoie "Place Dorian, Technopôle, Saint-Étienne, Loire, Rhône-Alpes,
42270, France" (http://osm.org/go/0ApD~eLB1--).

Mais une telle organisation est fausse pour "Technopole", étonnante pour
"42270".

Technopole est une zone industrielle à Saint Etienne, bien située par osm (
http://osm.org/go/0ApMFEL0). Comment se fait-il qu'elle englobe toutes les
rues de la ville ?

Et pour le 42270, moi j'aurais vu quelque chose comme "...Place Dorian,
42270, Saint Etienne, Loire..." Le 42270 désignant une zone postale (je
crois) dans st etienne, elle devrait venir entre la rue et la ville, et non
entre la région et le pays.

Qu'en pensez-vous ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Antennes téléphonie mobile en france

2012-10-11 Par sujet Rainer Kluge

Am 11.10.2012 15:39, schrieb Jean-Marc Liotier:

Ce site ne répertorie pas des antennes mais des sites radio - qui ont
généralement chacun plusieurs antennes et dont la localisation à une adresse ne
donne qu'une vague idée de l'implantation physique.


Ce site, ainsi que les sites de l'ANFR, ne répertorie pas les sites non plus. Il 
répertorie les supports, c'est à dire les mâts qui eux portent les antennes. Il 
peut y avoir plusieurs supports sur un même site.


Ce qu'on peut mapper dans OSM sont donc les bâtiments techniques et les mâts. Le 
fait qu'on tague les mâts avec man_made=antenna est un peu trompeur et 
techniquement incorrect. En ce qui concerne ses antennes proprement dites, il 
existe une proposition [1] qui à mon avis ne règle pas tous les cas de figure, 
par example, celui d'un mât portant plusieurs antennes UMTS d'operateurs 
différents.


Rainer


[1] 
http://wiki.openstreetmap.org/wiki/Proposed_features/Telecommunications_tower


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


Re: [OSM-talk-fr] Antennes téléphonie mobile en france

2012-10-11 Par sujet Stéphane Péneau
Merci Bruno, tu me confirmes que je ne suis pas fou, et que j'avais 
bien déjà vu une discussion à ce sujet quelque part. Par contre, 
puisque la discussion date seulement d'une dizaine de jours, à défaut 
d'être fou, j'ai une mémoire de poisson rouge...


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


Re: [OSM-talk-fr] Imbrication des noms dans les résultats de recherche

2012-10-11 Par sujet Pieren
>
> Qu'en pensez-vous ?
>

Pour ce genre de chose, il faut cliquer sur nominatim et relancer la
recherche puis voir la page des détails:
http://nominatim.openstreetmap.org/details.php?place_id=50520945

On voit que "Technopole" est identifié par un place=suburb:
http://www.openstreetmap.org/browse/node/1642937485

Comme il n'y a pas de polygone mais un simple noeud, nominatim va
extrapoler avec plus ou moins de chance la couverture de ce suburb:
http://nominatim.openstreetmap.org/details.php?place_id=18296209
(c'est probablement le "suburb" le plus proche de cette place)

Comme ce technopole ne fait pas partie de la liste des quartiers de
st-etienne (http://fr.wikipedia.org/wiki/Quartiers_de_Saint-%C3%89tienne),
il faudrait changer le tag. Idéalement tracer un polygone avec
landuse+name.

Pieren

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


Re: [OSM-talk-fr] Intégration des cours d'eau

2012-10-11 Par sujet Christian Quest
Le 11 octobre 2012 14:21, Club Informatique Inter Communes / C2IC
 a écrit :
> Bonjour à tous
>
> Voulant me pencher sur l'intégration des cours d'eau dans mon secteur
> (Pays du Roi Morvan en Bretagne) j'ai opté pour l'imagerie issue du
> SANDRE pour avoir les éléments (voir
> http://www.openstreetmap.org/user/1piedsurTerre/diary/17869).
>
> Mais les remarques de BrunoC et de Pieren m'ont gentiment alerté sur
> l'incompatibilité de licence entre OSM et le SANDRE.
>

Et oui la licence c'est la première question à se poser, avant toute
considération technique...


> D'où ma question du jour : quid de mes contributions d'hier soir et de
> ce matin ?
>
> Les changesets sont les suivants :
> http://www.openstreetmap.org/browse/changeset/13446545 /
> http://www.openstreetmap.org/browse/changeset/13450822 et
> http://www.openstreetmap.org/browse/changeset/13450951
>
> Je supprime tout et je recommence avec l'imagerie ?
>

Si ces données ne sont pas issues d'une source libre ou autorisée,
oui, à supprimer et recréer à partir d'une source libre ou autorisée.

-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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


Re: [OSM-talk-fr] Antennes téléphonie mobile en france

2012-10-11 Par sujet Pieren
2012/10/11 Bruno Cortial :

> (on dirai qu'on a perdu une partie des archives car une discussion c'est
> engagé sur une cartopartie "antenne" basée sur les données ANFR)

Tu es sûr que ça n'est pas juste une histoire de page 1/page 2 ?

Pieren, qui tourne la page

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


Re: [OSM-talk-fr] Imbrication des noms dans les résultats de recherche

2012-10-11 Par sujet Pierre Béland
Ista,

Vois le résultat retourné lorsque nous faisons une recherche nominatim.
http://nominatim.openstreetmap.org/details.php?place_id=18296209

Ce que je comprends du fonctionnnement de Nominatim, c'est que lorsu'il 
rencontre un tag place (ici place=suburb pour Technopole), il calcule une 
circonférence autour de ce point et relie ces rues à cette place.

Idéalement, il faudrait définir une relation de type boundary plutôt qu'une 
simple node avec le tag place.

À moins que quelqu'un connaisse une solution plus élégante.
 

Pierre 



>
> De : Ista Pouss 
>À : Discussions sur OSM en français  
>Envoyé le : Jeudi 11 octobre 2012 10h00
>Objet : [OSM-talk-fr] Imbrication des noms dans les résultats de recherche
> 
>
>Bonjour,
>
>Si avec osm je fais une recherche de n'importe quel nom sur saint etienne, 
>j'obtiens quasi toujours "le nom, Technopole, Saint Etienne, Loire, 
>Rhônes-Alpes, le code postal, France.
>
>Par exemple, si je demande "Place Dorian, Saint Etienne", Nominatim me renvoie 
>"Place Dorian, Technopôle, Saint-Étienne, Loire, Rhône-Alpes, 42270, France" 
>(http://osm.org/go/0ApD~eLB1--).
>
>Mais une telle organisation est fausse pour "Technopole", étonnante pour 
>"42270".
>
>Technopole est une zone industrielle à Saint Etienne, bien située par osm 
>(http://osm.org/go/0ApMFEL0). Comment se fait-il qu'elle englobe toutes les 
>rues de la ville ?
>
>Et pour le 42270, moi j'aurais vu quelque chose comme "...Place Dorian, 42270, 
>Saint Etienne, Loire..." Le 42270 désignant une zone postale (je crois) dans 
>st etienne, elle devrait venir entre la rue et la ville, et non entre la 
>région et le pays.
>
>Qu'en pensez-vous ?
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>http://lists.openstreetmap.org/listinfo/talk-fr
>
>
>___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Antennes téléphonie mobile en france

2012-10-11 Par sujet Pieren
2012/10/11 Claire Libertic :

> Par contre, quand vous évoquez la non-dénaturation, il s'agit simplement de
> la retranscription de l'article 12 de la loi francaise sur le droit d'accès
> à l'information publique. Leur licence est une retranscription de cette loi
> qui s'impose aux documents publiques.

On s'était posé la même question sur les données Corine Land Cover de
l'ifen qui contenait la même restriction. Pour lever les doutes, on a
préféré attendre une confirmation écrite qu'il n'y avait pas de
problème à import Corine dans OSM.

Pieren

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


Re: [OSM-talk-fr] parking entouré d'une barrière

2012-10-11 Par sujet Christian Quest
Deux ways superposés: bof bof bof
Deux ways séparés: on rentre dans le micro-mapping, pourquoi pas, mais
est-ce bien utile ?
Un seul way avec amenity=parking + barrier=fence me semble suffisant
dans bien des cas + les nodes pour les entrées bien sûr... sinon les
algo de routage penseront que le parking est inaccessible.

Le relation... je trouve que ça relève du TOC (Trouble Obsessionnel
Cartographique) pour un tel cas.


Le 11 octobre 2012 14:50, Pieren  a écrit :
> 2012/10/11 Francescu GAROBY :
>
>> Manque de chance, elles sont contradictoires ! :-D
>
> Elles sont différentes. Mais les deux solutions sont correctes. Sauf
> que tracer deux ways qui se superposent exactement n'est pas pratique.
> Il y a un gros risque que les contributeurs peu habitués n'en voit
> qu'un seul. A toi de peser les pour et les contre. Moi, je suis
> partisan du moindre effort donc un seul way ;-) Y en a qui vont
> sûrement te proposer une 3e solution : utiliser des relations !
>
> Pieren
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr



-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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


Re: [OSM-talk-fr] Limites communales dans les DOM - tags pour les DOM/TOM

2012-10-11 Par sujet Christian Quest
Le 11 octobre 2012 14:59, sly (sylvain letuffe)  a écrit :
> On jeudi 11 octobre 2012, Christian Quest wrote:
>> J'ai regardé la réunion, c'est admin_level=4 car c'est un département
>> ET une région...
>
> Ha bon, moi qui croyait que le "D" de DOM voulait dire Département ;-)
> Bon, ça ne marche pas mieux avec admin_level=4, j'ai regardé un peu plus en
> détail, voici donc la relation pour la réunion (commençons par là, inutile de
> se disperser) :
> http://www.openstreetmap.org/browse/relation/77601
>
> Ce qui me manque c'est aussi le code département comme les autres ref=974
>
> J'ai donc compris que la réunion était donc un département (DOM) de code
> département 974, qui était contenu par une région de code inconnu ne
> contenant qu'un seul département, elle-même en terme de surface.
>
> Ma proposition alors, (sans tenir compte du fait que ça m'arrangerait bien
> pour mon programme ;-) ) serait de :
> créér deux relations :
> * a) une pour le département avec admin_level=6 et ref=974 contenant les
> membres qui forment le contour de l'île
> * b) une autre pour la région avec admin_level=4 (pas de ref, sauf s'il en
> existe une pour la réunion en tant que région) contenant comme unique membre
> la précédente
>

+1, j'ai faillit le faire en regardant tout à l'heure ;)

Je pense que tout DOM devrait avoir une relation admin_level=6
correspondant pour être cohérent avec la métropole.


> Remontant d'un cran au dessus, la relation "France: Régions d'outre-mer" :
> http://www.openstreetmap.org/browse/relation/1263863
> pourrait alors contenir directement la a) (comme c'est aujourd'hui)
>
>

C'est logique.

>> C'est sûrement pareil pour les autres (pas regardé).
> Pour la guadeloupe c'est un admin_level=2 on dirait, et sous la forme d'une
> pyramide qui semble, je dis bien semble, faire usage d'un mécanisme à la
> subarea
> Pour la martinique, je ne la trouve pas, ou alors si, mais uniquement les eaux
> territoriales, mystère...
> Guyanne, mayotte : admin_level=2
>

Relations à créer pour cohérence là aussi ?

-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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


Re: [OSM-talk-fr] Antennes téléphonie mobile en france

2012-10-11 Par sujet Christian Quest
Ca me semble la meilleure approche lorsque les mentions légales sont borderline.

Qui a un contact à l'ANFR pour faire une demande officielle sur
l'intégration de ces données dans OSM ?


Le 11 octobre 2012 16:39, Pieren  a écrit :
> 2012/10/11 Claire Libertic :
>
>> Par contre, quand vous évoquez la non-dénaturation, il s'agit simplement de
>> la retranscription de l'article 12 de la loi francaise sur le droit d'accès
>> à l'information publique. Leur licence est une retranscription de cette loi
>> qui s'impose aux documents publiques.
>
> On s'était posé la même question sur les données Corine Land Cover de
> l'ifen qui contenait la même restriction. Pour lever les doutes, on a
> préféré attendre une confirmation écrite qu'il n'y avait pas de
> problème à import Corine dans OSM.
>
> Pieren
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr



-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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


Re: [OSM-talk-fr] Limites communales dans les DOM - tags pour les DOM/TOM

2012-10-11 Par sujet sly (sylvain letuffe)

> +1, j'ai faillit le faire en regardant tout à l'heure ;)

Bon, c'est fait, voyons comment ça s'en sort. Et si des gens viennent crier, 
je reviendrais en arrière (ça n'a rien de compliqué, 2 tags et une relation 
de plus)



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

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


Re: [OSM-talk-fr] Antennes téléphonie mobile en france

2012-10-11 Par sujet Romain MEHUT
Le 11 octobre 2012 16:54, Christian Quest  a écrit
:

> Ca me semble la meilleure approche lorsque les mentions légales sont
> borderline.
>
> Qui a un contact à l'ANFR pour faire une demande officielle sur
> l'intégration de ces données dans OSM ?
>

Claire de LiberTIC l'a déjà fait par oral.

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


Re: [OSM-talk-fr] Chef-lieu de commune...

2012-10-11 Par sujet Eric Sibert

Au tout début de ma proposition, il y a une question pour Eric :
"Je ne sais pas si tu as un usage en tête pour ce que tu vas modéliser ?"


Désolé. A force de voir passer de gros messages indigestes qui ne  
répondent pas trop à mes questions, je finis par oublier de répondre  
aux bonnes questions.


Mon but premier est d'organiser les données administratives et le  
suivi de leur saisie. But secondaire, structurer le territoire et  
avoir des points de repères sur l'ensemble du territoire (pour aider  
le boulot de carto entre autre).



Si le but premier est de s'inscrire dans les outils existants (principalement
Nominatim)


Non. Ou alors seulement pour le but secondaire mais sans faire  
d'efforts de codage dans ce sens.



Dans ce que je proposais hier, [...] je cherchais plutôt la modélisation
qui me paraît la plus pratique pour organiser une organisation  
arborescente et
la manipuler, mais en faisant l'hypothèse qu'Eric a la maîtrise des  
outils qui la

manipuleront.


S'il me manque des outils, j'appellerai à l'aide ;-)


Typiquement : il charge ces données dans une base relationnelle et
a besoin de connaître des relations entre entités administratives.  
Dans ce cas, les
propriétés d'inclusion dans une relation avec un rôle sont bien plus  
pratique pour

lier les objets, que la valeur du tag is_in.


Et ça limite la redondance d'information et les erreurs qui vont avec.

Donc, dans l'hypothèse relation, je pars quand même sur type=boundary?  
Avec des rôles admin_centre. Et des rôles communes pour regrouper les  
communes. Pour les différents villages/hameaux d'une commune, un rôle  
"village".


D'accord sur un point, comme tu le rappelles : tout ceci est un  
exercice temporaire,
la cible étant de pouvoir embrayer sur une modélisation type  
boundary lorsque les

données (géométriques) seront disponibles.


Ma connaissance du pays me fait craindre que la transition ne dure  
longtemps. Grosso modo, c'est soit on trouve un organisme qui fournit  
les limites communales libres de droit, soit c'est mort. Sauf cas  
particulier, il n'y a pas de cadastre à la campagne. Sur le terrain,  
ils ne savent pas nécessairement où sont les limites. Ils savent  
surtout quels villages/hameaux appartiennent à la commune.



Et c'est ce côté temporaire qui me fait
proposer sans trop de scrupules des tags pas forcément établis ni  
reconnus (typiquement

le rôle "commune" ou "village").


Je vais essayer d'explorer un peu plus les rôles exotiques utilisés  
dans les relations boundary pour voir si je peux m'en inspirer.


Eric


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


Re: [OSM-talk-fr] Chef-lieu de commune...

2012-10-11 Par sujet sly (sylvain letuffe)
> Sur le terrain,  
> ils ne savent pas nécessairement où sont les limites. Ils savent  
> surtout quels villages/hameaux appartiennent à la commune.

Voronoi ?

Le moto d'osm (que j'invente un peu), c'est "on fait avec ce qu'on a avant 
d'avoir mieux", alors fais un damier avec des communes à 4 points et ça te 
permettra d'avoir le même modèle qu'ailleurs, sans non plus y passer trop de 
temps et en plus ça fera marcher plein d'ago déjà existant.
En plus, avec un peu de chance, ce sera juste dans 90% des cas ;-)

Bien sûr, un fixme=taillé à l'américaine avec les moyens du bord
est de mise ;-)
-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

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


[OSM-talk-fr] [HS] HydrOO : outil interactif pour la gestion des données sur l'eau

2012-10-11 Par sujet Samy Mezani

Bonjour,

Pour info, vu sur http://www.hydroo.fr/.

###

HydrOO La Ressource en eau

Le premier réseau communautaire d'informations géolocalisées sur l'eau 
et consultable depuis un téléphone mobile ou votre ordinateur. [...]


Rejoignez-nous et contribuez activement à l'amélioration de la 
connaissance scientifique de l'eau.


Certains passent 365 jours dans les rivières, ils sont les ambassadeurs 
d'HydrOO.
Les professionnels comme les hydroélectriciens, pisciculteurs, pêcheurs 
professionnels... et usagers comme les pêcheurs, kayakistes... sont des 
témoins de première ligne. L'application gratuite pour téléphone mobile 
Iphone/Androïd permet à ces usagers d'envoyer instantanément des images 
géolocalisées sur le réseau communautaire HydrOO.
Chacun devient acteur de l'amélioration de la connaissance et qualité de 
l'eau.


###

Je me demande sous quelle licence seront les données collectées par les 
utilisateurs ?
Ah s'ils pouvaient collaborer à l'amélioration des données sur les 
rivières dans OSM...


Samy

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


Re: [OSM-talk-fr] Antennes téléphonie mobile en france

2012-10-11 Par sujet Christian Quest
C'est pour passer de l'oral à l'écrit... surtout pour la réponse (positive) ;)

Le 11 octobre 2012 16:59, Romain MEHUT  a écrit :
> Le 11 octobre 2012 16:54, Christian Quest  a écrit
> :
>
>> Ca me semble la meilleure approche lorsque les mentions légales sont
>> borderline.
>>
>> Qui a un contact à l'ANFR pour faire une demande officielle sur
>> l'intégration de ces données dans OSM ?
>
>
> Claire de LiberTIC l'a déjà fait par oral.
>
> Romain
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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


Re: [OSM-talk-fr] [HS] HydrOO : outil interactif pour la gestion des données sur l'eau

2012-10-11 Par sujet Christian Quest
Quand je vois un fond de carte Google dès la page d'accueil, je me dit
qu'il y a du boulot !

Je ne vois pas de mentions légales... qui est derrière ce site/cette
appli pour smartphone ?

whois hydroo.fr n'est pas plus causant...

L'onglet contact du site renvoie vers un prestataire: Actitel à Tarbes



Le 11 octobre 2012 17:11, Samy Mezani  a écrit :
> Bonjour,
>
> Pour info, vu sur http://www.hydroo.fr/.
>
> ###
>
> HydrOO La Ressource en eau
>
> Le premier réseau communautaire d'informations géolocalisées sur l'eau et
> consultable depuis un téléphone mobile ou votre ordinateur. [...]
>
> Rejoignez-nous et contribuez activement à l'amélioration de la connaissance
> scientifique de l'eau.
>
> Certains passent 365 jours dans les rivières, ils sont les ambassadeurs
> d'HydrOO.
> Les professionnels comme les hydroélectriciens, pisciculteurs, pêcheurs
> professionnels... et usagers comme les pêcheurs, kayakistes... sont des
> témoins de première ligne. L'application gratuite pour téléphone mobile
> Iphone/Androïd permet à ces usagers d'envoyer instantanément des images
> géolocalisées sur le réseau communautaire HydrOO.
> Chacun devient acteur de l'amélioration de la connaissance et qualité de
> l'eau.
>
> ###
>
> Je me demande sous quelle licence seront les données collectées par les
> utilisateurs ?
> Ah s'ils pouvaient collaborer à l'amélioration des données sur les rivières
> dans OSM...
>
> Samy
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr



-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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


Re: [OSM-talk-fr] Chef-lieu de commune...

2012-10-11 Par sujet Pieren
2012/10/11 sly (sylvain letuffe) :

Tu peux peut-être aussi chercher du côté des vieilles cartes libres de
droit (50 ou 75 ans, c'est selon). C'est toujours mieux que rien ou un
relevé pifométrique avec des carrés à la Sly :-)

Pieren

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


Re: [OSM-talk-fr] Antennes téléphonie mobile en france

2012-10-11 Par sujet Bruno Cortial
Le 11 octobre 2012 16:38, Pieren  a écrit :

> 2012/10/11 Bruno Cortial :
>
> > (on dirai qu'on a perdu une partie des archives car une discussion c'est
> > engagé sur une cartopartie "antenne" basée sur les données ANFR)
>
> Tu es sûr que ça n'est pas juste une histoire de page 1/page 2 ?
>
> Pieren, qui tourne la page
>
>
Y en a qui ont une mémoire de poisson rouge, d'autres sont aveugles...
bienvenu "à l'ouest' ;-)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] parking entouré d'une barrière

2012-10-11 Par sujet Etienne Trimaille
Je suis aussi partisan pour un seul way avec les tags :
http://www.openstreetmap.org/browse/way/134138153

Le tag parking fait référence à la surface et le tag barrier pour le
linéaire donc pas de soucis.

Le 11 octobre 2012 16:40, Christian Quest  a écrit
:

> Deux ways superposés: bof bof bof
> Deux ways séparés: on rentre dans le micro-mapping, pourquoi pas, mais
> est-ce bien utile ?
> Un seul way avec amenity=parking + barrier=fence me semble suffisant
> dans bien des cas + les nodes pour les entrées bien sûr... sinon les
> algo de routage penseront que le parking est inaccessible.
>
> Le relation... je trouve que ça relève du TOC (Trouble Obsessionnel
> Cartographique) pour un tel cas.
>
>
> Le 11 octobre 2012 14:50, Pieren  a écrit :
> > 2012/10/11 Francescu GAROBY :
> >
> >> Manque de chance, elles sont contradictoires ! :-D
> >
> > Elles sont différentes. Mais les deux solutions sont correctes. Sauf
> > que tracer deux ways qui se superposent exactement n'est pas pratique.
> > Il y a un gros risque que les contributeurs peu habitués n'en voit
> > qu'un seul. A toi de peser les pour et les contre. Moi, je suis
> > partisan du moindre effort donc un seul way ;-) Y en a qui vont
> > sûrement te proposer une 3e solution : utiliser des relations !
> >
> > Pieren
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> --
> Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] parking entouré d'une barrière

2012-10-11 Par sujet Francescu GAROBY
J'ai finalement retenu cette solution.
Merci à tous

Francescu

Le 11 octobre 2012 17:47, Etienne Trimaille  a
écrit :

> Je suis aussi partisan pour un seul way avec les tags :
> http://www.openstreetmap.org/browse/way/134138153
>
> Le tag parking fait référence à la surface et le tag barrier pour le
> linéaire donc pas de soucis.
>
> Le 11 octobre 2012 16:40, Christian Quest  a
> écrit :
>
> Deux ways superposés: bof bof bof
>> Deux ways séparés: on rentre dans le micro-mapping, pourquoi pas, mais
>> est-ce bien utile ?
>> Un seul way avec amenity=parking + barrier=fence me semble suffisant
>> dans bien des cas + les nodes pour les entrées bien sûr... sinon les
>> algo de routage penseront que le parking est inaccessible.
>>
>> Le relation... je trouve que ça relève du TOC (Trouble Obsessionnel
>> Cartographique) pour un tel cas.
>>
>>
>> Le 11 octobre 2012 14:50, Pieren  a écrit :
>> > 2012/10/11 Francescu GAROBY :
>> >
>> >> Manque de chance, elles sont contradictoires ! :-D
>> >
>> > Elles sont différentes. Mais les deux solutions sont correctes. Sauf
>> > que tracer deux ways qui se superposent exactement n'est pas pratique.
>> > Il y a un gros risque que les contributeurs peu habitués n'en voit
>> > qu'un seul. A toi de peser les pour et les contre. Moi, je suis
>> > partisan du moindre effort donc un seul way ;-) Y en a qui vont
>> > sûrement te proposer une 3e solution : utiliser des relations !
>> >
>> > Pieren
>> >
>> > ___
>> > Talk-fr mailing list
>> > Talk-fr@openstreetmap.org
>> > http://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>>
>> --
>> Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>


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


Re: [OSM-talk-fr] Imbrication des noms dans les résultats de recherche

2012-10-11 Par sujet Pierre Béland
Ista,

Est-ce que le Technopole est un simple établissement plutôt qu'un quartier 
complet?  Si c'est un simple établissement, il est inapproprié d'uliser le tag 
place pour le rendu.


 
Pierre 



>
> De : Ista Pouss 
>À : Discussions sur OSM en français  
>Envoyé le : Jeudi 11 octobre 2012 10h00
>Objet : [OSM-talk-fr] Imbrication des noms dans les résultats de recherche
> 
>
>Bonjour,
>
>Si avec osm je fais une recherche de n'importe quel nom sur saint etienne, 
>j'obtiens quasi toujours "le nom, Technopole, Saint Etienne, Loire, 
>Rhônes-Alpes, le code postal, France.
>
>Par exemple, si je demande "Place Dorian, Saint Etienne", Nominatim me renvoie 
>"Place Dorian, Technopôle, Saint-Étienne, Loire, Rhône-Alpes, 42270, France" 
>(http://osm.org/go/0ApD~eLB1--).
>
>Mais une telle organisation est fausse pour "Technopole", étonnante pour 
>"42270".
>
>Technopole est une zone industrielle à Saint Etienne, bien située par osm 
>(http://osm.org/go/0ApMFEL0). Comment se fait-il qu'elle englobe toutes les 
>rues de la ville ?
>
>Et pour le 42270, moi j'aurais vu quelque chose comme "...Place Dorian, 42270, 
>Saint Etienne, Loire..." Le 42270 désignant une zone postale (je crois) dans 
>st etienne, elle devrait venir entre la rue et la ville, et non entre la 
>région et le pays.
>
>Qu'en pensez-vous ?
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>http://lists.openstreetmap.org/listinfo/talk-fr
>
>
>___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Imbrication des noms dans les résultats de recherche

2012-10-11 Par sujet Ista Pouss
Le 11 octobre 2012 16:32, Pieren  a écrit :

>
> Comme ce technopole ne fait pas partie de la liste des quartiers de
> st-etienne (http://fr.wikipedia.org/wiki/Quartiers_de_Saint-%C3%89tienne),
> il faudrait changer le tag. Idéalement tracer un polygone avec
> landuse+name.
>
>
Pourtant l'usage du tag dans ce cas correspond assez bien à la description
du wiki (http://wiki.openstreetmap.org/wiki/Tag:place%3Dsuburb).

J'ai l'impression qu'en fait il n'y a aucun quartier d'indiqué à St
Etienne, à part celui là (qui n'est, à ma connaissance, qu'une sorte de
zone industrielle) (sans penser à médire). C'est peut être pour ça que
nominatim raccorde tout à ce quartier ?

Je vais mettre dans ma liste de todo "rajouter les quartiers de st
etienne". Merci.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Imbrication des noms dans les résultats de recherche

2012-10-11 Par sujet Pierre Béland
ll serait donc possible, si c'est une zone industrielle, de créer une relation 
boundary qui en délimite les contours. De cette façon, ça règlerait les 
problèmes avec Nominatim pour Saint-Étienne.
 

Pierre 



>
> De : Ista Pouss 
>À : Discussions sur OSM en français  
>Envoyé le : Jeudi 11 octobre 2012 13h11
>Objet : Re: [OSM-talk-fr] Imbrication des noms dans les résultats de recherche
> 
>
>Le 11 octobre 2012 16:32, Pieren  a écrit :
>
>
>>Comme ce technopole ne fait pas partie de la liste des quartiers de
>>st-etienne (http://fr.wikipedia.org/wiki/Quartiers_de_Saint-%C3%89tienne),
>>il faudrait changer le tag. Idéalement tracer un polygone avec
>>landuse+name.
>>
>>
>
>Pourtant l'usage du tag dans ce cas correspond assez bien à la description  du 
>wiki (http://wiki.openstreetmap.org/wiki/Tag:place%3Dsuburb).
>
>J'ai l'impression qu'en fait il n'y a aucun quartier d'indiqué à St Etienne, à 
>part celui là (qui n'est, à ma connaissance, qu'une sorte de zone 
>industrielle) (sans penser à médire). C'est peut être pour ça que nominatim 
>raccorde tout à ce quartier ?
>
>Je vais mettre dans ma liste de todo "rajouter les quartiers de st etienne". 
>Merci.
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>http://lists.openstreetmap.org/listinfo/talk-fr
>
>
>___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Limites communales dans les DOM

2012-10-11 Par sujet sly (sylvain letuffe)
On mercredi 10 octobre 2012, Pierre Touzard wrote:
> Bonsoir à tous,
> 
> Quel dommage que l'on ne puisse pas trouver ici
> (http://export.openstreetmap.fr/contours-administratifs/export-communes/)
> les limites communales sur les DOM...

Après quelques modifications de mon logiciel qui gère cette exportation, ainsi 
que le suivi des communes, voilà que maintenant sont pris en compte les 
départements 
971 : Guadeloupe
972 : Martinique
973 : Guyane
974 : Réunion
ici :
http://export.openstreetmap.fr/contours-administratifs/export-communes/
et là :
http://suivi.openstreetmap.fr/communes/communes.csv.txt

Mayotte n'est pas dedans car le cadastre http://www.cadastre.gouv.fr n'a rien 
pour elle.

En outre, ça ne marche pas (encore) pour guadeloupe et guyane car il faudrait 
d'abord se fixer sur un choix des tags+mode de saisie
Pour Martinique, ça ne marche pas non plus car un contributeur a décidé de 
zigouiller la relation des côtes.

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

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


Re: [OSM-talk-fr] Chef-lieu de commune...

2012-10-11 Par sujet Eric SIBERT

Le 11/10/2012 17:19, Pieren a écrit :

Tu peux peut-être aussi chercher du côté des vieilles cartes libres de
droit (50 ou 75 ans, c'est selon).


C'est une idée. Pour les cartes, d'après la convention de Berne que 
Madagascar a ratifié, c'est 70 ans après la première publication. Après 
consultation des cartes topographiques détaillées (1/100.000) en ma 
possession (achats récents), il apparaît deux périodes d'éditions. 
Celles de la fin des années 50 qui n'ont pas de limites communales. 
Celles des années 60 possèdent les limites de communes. Il n'y a qu'à 
attendre les années 2030 ;-) Et encore, ça ne couvrira pas tout Madagascar.


Éric

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


Re: [OSM-talk-fr] Limites communales dans les DOM

2012-10-11 Par sujet Jocelyn Jaubert
Le 11 octobre 2012, sly (sylvain letuffe) a écrit :
> Pouf la martinique :
> http://www.openstreetmap.org/browse/relation/1260552
> 
> Je ne touche à rien, je ne sais pas si c'est voulu ou non par la 
> sous-communauté fr des îles ;-)

Mouais, c'est dommage de supprimer des relations comme ça. En plus, les
relations côtières et maritimes ne font pas doublon :(

J'hésite à recréer la relation, parce qu'elle risque d'être supprimée à
nouveau...


-- 
Jocelyn

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


Re: [OSM-talk-fr] Séparation commune et Landuse : demande vérification.

2012-10-11 Par sujet Marc

Le 11/10/2012 11:21, Christian Quest a écrit :

Les limites des communes sont ok, donc pas merdé ou alors tu l'a bien caché ;)

Le 11 octobre 2012 07:32, Marc  a écrit :

Merci pour le contrôle.


--

Marc http://www.openstreetmap.org/user/plonk/


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


Re: [OSM-talk-fr] Intégration des cours d'eau

2012-10-11 Par sujet PierreV
tiens j'en profite que le sujet est relancé...
Je vois que certains sont certains que le Sandre n'est pas compatible avec
OSM... mais lorsque le portail d'Etalab etait sorti j'avais tout de suite
remarqué que des jeux de données SHP sur les cours d'eau etaient dispo...
J'avais demandé a quelqu'un d'ici (je ne sais plus qui...) de me faire une
"visualisation" de ses données... et qui se ressemble BEAUCOUP de ce que
l'on peut obtenir sur le portail Sandre...

Aussi quand on va sur le portail data.gouv.fr, comme par hasard les jeux de
données correspondant à la recherche "cours d'eau" et format SHP redirigent
le téléchargement sur "eaufrance.fr"...
(http://www.data.gouv.fr/donnees/view/Couche-SIG-des-caract%C3%A9ristiques-des-bassins-2010-%3A-eaux-de-surfaceLoire-Bretagne-30381904?xtmc=cours+d%27eau&xtcr=8)
Malheureusement le lien n'est plus correct...
Mais apparemment ca fonctionne pour le bassin de la Garonne...

Bref, en attendant que l'on retrouve l'intégrité des données de la France,
si quelqu'un veut bien essayer de faire un petit serveur de "visualisation"
des données provenant d'Etalab (comme le fait le site xapiviewer) ca serait
sympa?

Merci d'avance pour vos réponses qui pourraient m'éclairer dans ma "première
analyse"...



--
View this message in context: 
http://gis.19327.n5.nabble.com/Integration-des-cours-d-eau-tp5729958p5730028.html
Sent from the France mailing list archive at Nabble.com.

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


Re: [OSM-talk-fr] Séparation commune et Landuse : demande vérification.

2012-10-11 Par sujet Marc

Le 11/10/2012 12:29, Philippe Verdy a écrit :

Aucun problème puisqu'il n'a modifié aucune relation ni aucun chemin
utilisé par ces relations existantes (même si ici cela crée des
segments et nœuds superposés, ce qui n'est pas génial non plus pour
les modifications ultérieures quand on ne sait plus à quel noeud ou
segment superposé se rattacher).

Merci pour le contrôle, mais je ne vois pas où j'ai créé des nœuds ou 
segments superposés. Pour affiner j'aurai pu fusionné des segments, ce 
qui réduirait le nombre de ways des relations frontières.
Quelle est la limite raisonnable en nombre noeuds pour un way ? 
Proposition de réponse :

[ ] 50
[ ] 100
[ ] 200
[ ] 500
[ ] 1000
[ ] 2000

Marc.

--

Marchttp://www.openstreetmap.org/user/plonk/


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


Re: [OSM-talk-fr] Séparation commune et Landuse : demande vérification.

2012-10-11 Par sujet Marc

Le 11/10/2012 12:29, Philippe Verdy a écrit :

Aucun problème puisqu'il n'a modifié aucune relation ni aucun chemin
utilisé par ces relations existantes (même si ici cela crée des
segments et nœuds superposés, ce qui n'est pas génial non plus pour
les modifications ultérieures quand on ne sait plus à quel noeud ou
segment superposé se rattacher).

Merci pour le contrôle, mais je ne vois pas où j'ai créé des nœuds ou 
segments superposés. Pour affiner j'aurai pu fusionné des segments, ce 
qui réduirait le nombre de ways des relations frontières.
Quelle est la limite raisonnable en nombre noeuds pour un way ? 
Proposition de réponse :

[ ] 50
[ ] 100
[ ] 200
[ ] 500
[ ] 1000
[ ] 2000

Marc.

--

Marc http://www.openstreetmap.org/user/plonk/


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


Re: [OSM-talk-fr] Alignement cadastre

2012-10-11 Par sujet Sébastien Dinot
Bonsoir,

Jean-Francois Nifenecker a écrit :
> Quelles sont vos expériences ?

Très variées d'un coin à l'autre ! Ça va de l'harmonie parfaite entre
Bing, le cadastre et mes relevés GPS jusqu'à la cacophonie la plus
complète. Il m'est arrivé d'avoir dans les gorges de l'Aveyron un
cadastre mal calé, une image Bing baveuse et mal orthorectifiée et des
traces GPS que je prenais avec circonspection car j'étais en zone
accidentée.

Pour parler des mauvaises expériences, j'ai été très surpris la semaine
dernière encore en constatant sur les communes périphériques de Toulouse
des décalages variables similaires à ceux que tu décris. Sur une
commune - Gragnague il me semble - j'ai trouvé des zones parfaitement
calées et d'autres plus ou moins décalées. Je ne sais pas comment
travaillent la DGFiP et ses prestataires mais j'ai eu l'impression que
les zones les mieux calées correspondaient à des lotissements récents et
les zones les moins bien calées à du bâti plus ancien. Je me suis donc
laissé dire que les saisies n'avaient pas été réalisées à la même époque
et que les plus récentes bénéficiaient d'outils plus précis et de
méthodes plus rigoureuses. Mais c'est de la pure supputation de ma part.

En terme d'expérience directe, le pire décalage constaté a été sur la
commune de Givors, dans les zones accidentées où le décalage allait de
20 à 35 mètres. On le voit sur le montage que j'avais réalisé
à l'époque :

http://sebastien.dinot.free.fr/osm/Fusion_Saint-Romain-en-Gier_Givors.png

Ce montage correspond au coin suivant :

http://www.openstreetmap.org/?lat=45.574197&lon=4.712831&zoom=18&layers=M

Sur la partie Sud-Ouest, la commune de Saint-Romain-en-Gier est bien
calée. Les traces GPS et la route qui apparait sur le cadastre se
superposent (tout comme la voie tracée sur OSM). Mais sur la partie
Nord-Est, la commune de Givors est décalée à cet endroit de 35 mètres
dans la direction Ouest-Nord-Ouest. La route qui apparaît sur le
cadastre ne colle plus du tout avec les traces GPS...

Je viens de vérifier à l'instant cette zone. Le problème a été corrigé ;
le cadastre et les images de Bing se superposent plutôt bien maintenant.
Mais du coup, pas mal d'éléments sur OSM (notamment le bâti mais aussi
des routes) sont mal localisés dès que l'on arrive sur la commune de
Givors. Il va falloir corriger cela.

> Comment gérez-vous la rotation sous JOSM ?

À la main. :(

Sébastien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

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


Re: [OSM-talk-fr] Limites communales dans les DOM

2012-10-11 Par sujet Philippe Verdy
C'est vrai que deux relations administratives c'était trop.

Mais supprimer celle suivant les lignes de côte était la mauvaise idée
: il suffisait de la changer de "type=boundary ;
boundary=administrative" en "type=land_area"... en lisant le wiki !

Bref relation côtière à restaurer en changeant ses tags !

Le 11 octobre 2012 21:24, Jocelyn Jaubert  a écrit :
> Le 11 octobre 2012, sly (sylvain letuffe) a écrit :
>> Pouf la martinique :
>> http://www.openstreetmap.org/browse/relation/1260552
>>
>> Je ne touche à rien, je ne sais pas si c'est voulu ou non par la
>> sous-communauté fr des îles ;-)
>
> Mouais, c'est dommage de supprimer des relations comme ça. En plus, les
> relations côtières et maritimes ne font pas doublon :(
>
> J'hésite à recréer la relation, parce qu'elle risque d'être supprimée à
> nouveau...
>
>
> --
> Jocelyn
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

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


Re: [OSM-talk-fr] Chef-lieu de commune...

2012-10-11 Par sujet Philippe Verdy
Il me semble que Nominatim n'utilise plus is_in depuis longtemps
(beaucoup trop d'erreurs) mais plutôt les frontières. Sauf en dernier
recours quand il ne parvient pas à fermer une frontière ni calculer un
centroïde.

Je l'ai déjà vu assez souvent quand la frontière bretonne était cassée
: Rennes apparaissait alors en Loire-Atlantique dans Nominatim, malgré
ses tags is_in qui sont là depuis longtemps, car Nominatim utilisait
visiblement un calcul basé sur la distance entre les centroïdes
calculés des régions (Nominatim peut calculer un centroïde même sur
des frontières cassées, en utilisant apparemment soit les noeuds des
chemins qui restent soit ceux de la bounding box).

Cela a pu changer encore étant donné la fragilité aussi de
l'heuristique des centroïdes.

Mais dans tous les pays sauf la France où ils ne sont pas utilisés,
Nominatim ne se trompe jamais avec les membres de rôle subarea, qui
sont très stables et très peu fragiles.

Le 11 octobre 2012 14:26, Vincent de Chateau-Thierry
 a écrit :
>
>> De : "Pieren"
>
>> 2012/10/10 Vincent de Chateau-Thierry :
>>
>> > Si c'est juste pour fixer l'organisation administrative et organiser des
>> > relations d'inclusions sans géométrie, personnellement je pencherais plus
>> > pour des relations imbriquées que pour le recours au tag is_in et à ses
>> > déclinaisons, pour plusieurs raisons :
>>
>> Bon, je vais donner ma liste des contre-arguments:
>> - les relations, ça se casse aussi (vs fiabilité des "is_in"). Ca
>> arrive presque tous les jours sur les boundaries français. Bon, c'est
>> vrai que les noeuds "place" sont moins souvent manipulés que les
>> frontières. Mais c'est la même chose avec les places dans "is_in" qui
>> sont rarement modifiés.
>> - le schema "is_in" est l'ancien schéma qui existait avant la création
>> des "boundaries". C'est aussi pour ça qu'il est déjà supporté par des
>> outils comme Nominatim contrairement à toute nouvelle relation qui,
>> dans le meilleur des cas, ne sera pas supporté avant des mois (2 ans
>> pour que nominatim tienne compte de admin_centre) ou dans le pire des
>> cas, ne soit jamais pris en compte par aucun outil (le plus probable).
>> - de toute façon, les limites administratives seront tôt ou tard
>> ajoutées. La solution à mettre en place ne sera donc que temporaire.
>> Difficile de mobiliser les gens sur quelque chose qui va disparaitre.
>>
>
> Au tout début de ma proposition, il y a une question pour Eric :
> "Je ne sais pas si tu as un usage en tête pour ce que tu vas modéliser ?"
> De sa réponse dépend pas mal le choix à faire, à mon avis.
> Si le but premier est de s'inscrire dans les outils existants (principalement
> Nominatim) alors oui, bien sûr, l'exercice doit consister à entrer dans un
> moule connu de Nominatim. Si le mode "is_in" est reconnu, alors pas de 
> question
> à se poser, il faut l'utiliser.
> Dans ce que je proposais hier, je m'affranchissais de ce besoin (parler la 
> langue
> de Nominatim ou d'une autre appli bien établie), je cherchais plutôt la 
> modélisation
> qui me paraît la plus pratique pour organiser une organisation arborescente et
> la manipuler, mais en faisant l'hypothèse qu'Eric a la maîtrise des outils 
> qui la
> manipuleront. Typiquement : il charge ces données dans une base relationnelle 
> et
> a besoin de connaître des relations entre entités administratives. Dans ce 
> cas, les
> propriétés d'inclusion dans une relation avec un rôle sont bien plus pratique 
> pour
> lier les objets, que la valeur du tag is_in.
> D'accord sur un point, comme tu le rappelles : tout ceci est un exercice 
> temporaire,
> la cible étant de pouvoir embrayer sur une modélisation type boundary lorsque 
> les
> données (géométriques) seront disponibles. Et c'est ce côté temporaire qui me 
> fait
> proposer sans trop de scrupules des tags pas forcément établis ni reconnus 
> (typiquement
> le rôle "commune" ou "village").
>
> vincent
>
> Une messagerie gratuite, garantie à vie et des services en plus, ça vous 
> tente ?
> Je crée ma boîte mail www.laposte.net
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

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


[OSM-talk-fr] Pnorman => Spam

2012-10-11 Par sujet partir-en-vtt
Bonjour,

On bosse dur avec mon collègue sur le haut Doubs et ce matin j'ai eu
l'agréable surprise d'avoir un message de notre amis Pnorman.

Pas de chance pour lui, je ne comprends absolument pas l'Anglais.

"Hello

I noticed you conducting an import with

http://www.openstreetmap.org/browse/changeset/13454578

The import guidelines require that imports be done from a dedicated account,
after consultation with the local community and be documented on the wiki.

These imports were not done from a dedicated account.

I would suggest that the dedicated account

have a link to your main account for contact purposes

and

have a listing of any imports you have done on it with links to the
entries in the import catalogue

As a general reminder, the other import guidelines can be found on the wiki.
These include

appropriate documentation

consultation with the local community and the imports@ mailing list

having a plan to fix an mistakes in case of a broken upload

other technical requirements

Ignoring this and continuing to import from your main account may lead to a
block.

To contact me you can send a message or email the data working group

Paul Norman
for the Data Working Group"

Personnellement, je ne compte pas changer de pratique et je continuerai a
envoyer le bâtiment tout en faisant bien-sûr les routes et chemins.

Signé, un mappeur énervé.





--
View this message in context: 
http://gis.19327.n5.nabble.com/Pnorman-Spam-tp5730049.html
Sent from the France mailing list archive at Nabble.com.

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