Re: [OSM-talk-fr] Ç'ui-la, je l'comprends pas…
Le 11 octobre 2012 07:55, JB jb...@mailoo.org 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
Re: [OSM-talk-fr] Ç'ui-la, je l'comprends pas…
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=frloc=45.132560,5.700540loc=45.133260,5.700770z=18center=45.131850,5.699726alt=0df=0re=0) JB Le 11.10.2012 08:47, Etienne Trimaille a écrit : Le 11 octobre 2012 07:55, JB jb...@mailoo.orga é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…
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 etienne.trimai...@gmail.com a écrit : Le 11 octobre 2012 07:55, JB jb...@mailoo.org 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
Bonjour, Je viens de voir qu'il est possible d'intégrer, directement depuis osmose via le lien josm_fixhttp://osmose.openstreetmap.fr/map/?item=8060level=1,2,3, 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
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/10 Vincent de Chateau-Thierry v...@laposte.net: 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?
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.
Les limites des communes sont ok, donc pas merdé ou alors tu l'a bien caché ;) Le 11 octobre 2012 07:32, Marc o...@framboisier.fr 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
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 windu...@gmail.com 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 Romain MEHUT romain.me...@gmail.com: 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 Pieren pier...@gmail.com 2012/10/11 Romain MEHUT romain.me...@gmail.com: 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?
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 romain.me...@gmail.com a écrit : 2012/10/11 Pieren pier...@gmail.com 2012/10/11 Romain MEHUT romain.me...@gmail.com: 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?
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 romain.me...@gmail.com 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 romain.me...@gmail.com a écrit : 2012/10/11 Pieren pier...@gmail.com 2012/10/11 Romain MEHUT romain.me...@gmail.com: 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
Le 11 octobre 2012 10:21, Francescu GAROBY windu...@gmail.com 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.
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 cqu...@openstreetmap.fr 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 o...@framboisier.fr 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
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
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) li...@letuffe.org 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
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
Le 11 octobre 2012 12:46, Christian Quest cqu...@openstreetmap.fr 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
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 verd...@wanadoo.fr Le 11 octobre 2012 12:46, Christian Quest cqu...@openstreetmap.fr 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
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
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
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-frhttp://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
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...
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
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 windu...@gmail.com À: Discussions sur OSM en français talk-fr@openstreetmap.org 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
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] parking entouré d'une barrière
2012/10/11 Francescu GAROBY windu...@gmail.com: 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
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
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
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
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 stephane.pen...@wanadoo.fr 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.htmlhttp://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-frhttp://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
Le 11 octobre 2012 15:00, Stéphane Péneau stephane.pen...@wanadoo.fr 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
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
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
Le 11 octobre 2012 15:00, Stéphane Péneau stephane.pen...@wanadoo.fr 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
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 publiquehttp://legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT00339241. 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 Nanteshttp://www.linux-nantes.org/wws/arc/openstreetmap-nantes/2012-10/msg9.html, 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 stephane.pen...@wanadoo.fr 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-frhttp://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
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
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
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
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
Le 11 octobre 2012 14:21, Club Informatique Inter Communes / C2IC cont...@c2ic.net 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 Bruno Cortial bruno.cort...@laposte.net: (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
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 ista...@gmail.com À : Discussions sur OSM en français talk-fr@openstreetmap.org 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 Claire Libertic claire.liber...@gmail.com: 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
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 pier...@gmail.com a écrit : 2012/10/11 Francescu GAROBY windu...@gmail.com: 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
Le 11 octobre 2012 14:59, sly (sylvain letuffe) li...@letuffe.org 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
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 pier...@gmail.com a écrit : 2012/10/11 Claire Libertic claire.liber...@gmail.com: 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
+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
Le 11 octobre 2012 16:54, Christian Quest cqu...@openstreetmap.fr 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...
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...
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
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
C'est pour passer de l'oral à l'écrit... surtout pour la réponse (positive) ;) Le 11 octobre 2012 16:59, Romain MEHUT romain.me...@gmail.com a écrit : Le 11 octobre 2012 16:54, Christian Quest cqu...@openstreetmap.fr 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
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 samy.mez...@wanadoo.fr 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 sly (sylvain letuffe) li...@letuffe.org: 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
Le 11 octobre 2012 16:38, Pieren pier...@gmail.com a écrit : 2012/10/11 Bruno Cortial bruno.cort...@laposte.net: (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
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 cqu...@openstreetmap.fr 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 pier...@gmail.com a écrit : 2012/10/11 Francescu GAROBY windu...@gmail.com: 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
J'ai finalement retenu cette solution. Merci à tous Francescu Le 11 octobre 2012 17:47, Etienne Trimaille etienne.trimai...@gmail.com 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 cqu...@openstreetmap.fr 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 pier...@gmail.com a écrit : 2012/10/11 Francescu GAROBY windu...@gmail.com: 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
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 ista...@gmail.com À : Discussions sur OSM en français talk-fr@openstreetmap.org 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
Le 11 octobre 2012 16:32, Pieren pier...@gmail.com 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
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 ista...@gmail.com À : Discussions sur OSM en français talk-fr@openstreetmap.org 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 pier...@gmail.com 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
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...
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
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.
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 o...@framboisier.fr 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
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%27eauxtcr=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.
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.
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
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.574197lon=4.712831zoom=18layers=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
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 jocelyn.jaub...@gmail.com 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...
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 v...@laposte.net 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