Re: [OSM-talk-fr] Contact sur Poitiers ?
Salut Christian (et la liste talk-fr), Je transmets ta demande à l’APP3L (/http://www.app3l.org/[1] - GULL de Poitiers, dont je fais partie). C’est un sujet (contacter le SIG) qui nous intéresse ! Librement, -- Mikaël Cordon Le vendredi 6 juin 2014, 12:03:38 Christian Quest a écrit : Est-ce que quelqu'un de Poitiers est disponible pour établir un contact avec le SIG de la Ville que je viens de rencontrer lors des rencontres de l'Afigéo ? Je leur ai laissé ma carte donc à suivre dans les semaines qui viennent... [1] http://www.app3l.org signature.asc Description: This is a digitally signed message part. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Smartphone Android avec GPS rapide?
Salut, Personnellement, j’ai un LG Nexus 4, et le GPS m’impressionne (par rapport à mon précédent smartphone), il fixe rapidement les satellites (je dirais pas plus de 10-15 sec selon les conditions en extérieur) et utilise beaucoup de satellites (toujours par rapport à mon précédent) ! Pour une précision de 2,5m selon OSMTracker et les conditions. Cordialement, -- Mikaël Cordon, mickey86 Le 12 septembre 2013 01:12, Shohreh codecompl...@free.fr a écrit : OSMTracker est l'appli Android recommandée comme moyen simple et rapide d'ajouter/corriger des données dans OSM, sur place ou une fois connecté à un ordi? https://code.google.com/p/osmtracker-android/ -- View this message in context: http://gis.19327.n5.nabble.com/Smartphone-Android-avec-GPS-rapide-tp5777133p5777242.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu FR dans OSMand
+1000 ! :) Cordialement, -- Mikaël Cordon, mickey86 Le 12 juillet 2013 15:44, Yoann Cornec yoanncor...@gmail.com a écrit : Bonjour à tous, Est-il possible d'utiliser le rendu FR dans OSMand ? Au mieux, dans le rendu vectoriel, sinon en se connectant au tile server FR ou avec des tuiles offline. C'est peut-être récurrent comme question, mais je n'ai trouvé que celle-ci, apparemment restée sans réponse : http://lists.openstreetmap.org/pipermail/talk-fr/2013-May/058688.html Merci d'avance :-) ___ 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] Les access par défaut pour les highway=track en France
Je n'ai pu vérifier ledit tableau (le wiki est inaccessible pour le moment), mais je suis d'accord sur le principe. Cordialement, -- Mikaël Cordon, mickey86 Le 10 juil. 2013 16:11, Pieren pier...@gmail.com a écrit : Bonjour, Etes-vous d'accord pour ajouter highway=track dans ce tableau du wiki qui définit les accès par défaut sur les highways par pays: http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#France en le mettant dans la ligne des primary, secondary, etc,, c.à.d. avec yes sur tous les moyens de locomotion (y compris hgv et psv, du moins, du point de vue légal) Pieren ___ 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] Privé/public (était: Ajouts des adresses du cadastre...)
En fait, je me pose la question… À l’heure où on pointe du doigt plus que jamais la collecte de données privées (Google, Facebook, Apple, etc…), peut-être devrions-nous connaître la/une limite acceptable ? Attention, malgré que nous sommes vendredi, ceci n’est pas un troll, mais bien une question légitime :) Cordialement, -- Mikaël Cordon Le 28 juin 2013 08:32, Jean-Marc Liotier j...@liotier.org a écrit : On 06/28/2013 08:17 AM, Pierre-Alain Dorange wrote: pourquoi pas les allées sur les terrains privés Ne t'inquiètes pas, je les cartographie aussi: higway=service access=private Tout ce qui est visible et qui peut potentiellement servir de point de repère pour la navigation est à mon avis un objet cartographique légitime. ___ 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] Ajouts des adresses du cadastre : faisons mieux que simplement importer
C'est également ma façon de faire : rapport à la frontière public/privée. D'autant que si le privé interdit d'entrer sur sa parcelle, on ne pourra pas accéder jusqu'au bâtiment... Cordialement, -- Mikaël Cordon, mickey86 Le 26 juin 2013 18:49, Pierre-Alain Dorange pdora...@mac.com a écrit : Pieren pier...@gmail.com wrote: Entièrement d'accord avec ça. En centre-ville, c'est pertinent de mettre le point d'adresse sur un noeud du building. Par contre, en zone résidentielle, bon nombre de maisons ne sont pas collées à la rue, et dans ce cas, il est, à mon sens, préférable d'avoir le numéro en bord de rue. C'est un peu hors-sujet. Mais avoir le numéro en bord de rue pose aussi des problèmes. Il y a de nombreux cas où il devient difficile, voir impossible, d'identifier le bâtiment du destinataire. Cette façon de faire n'est pas fausse. Mais avoir l'adresse sur le bâtiment lui-même est plus précis. Pensez aux piétons. Le noeud address devrait se situer près de l'entrée du bâtiment. C'est une discussion qui a déjà eut lieu plusieurs fois mais sans consensus. Mon point de vue et usage personnel est que (pour moi) le détail d'OSM s'arrête à la frontière entre le domaine public et le domaine privé. De même que je ne met pas les piscines privées, je place le point adresse sur la frontière de la propriété privée (l'entrée principale au domaine privé). J'estime que c'est suffisant pour le piéton qui en franchissant ce point entre dans le domaine privé. C'est parfois délicat, surtout si on va pas sur le terrain, mais le cadastre permet de voir clairement les parcelles et souvent les entrées et c'est là que je place le point adresse. Bien sur quand l'adresse n'a pas de terrain (en facade) le point adresse se retrouve sur le batiment (et bien évidement comme signalé il faut que ce point fasse parti du polygone du bâti), mais dans les autres cas (propriété avec terrain) le pont est sur la frontière de la parcelle cadastrale. -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ 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] Quelques statistiques sur notre liste de diffusion talk-fr
Bonjour, J'ai suivi ce fil, parce que j'y ai participé… Et peut-être parce que j'ai trouvé qu'il y avait des paroles qui semblaient un peu trop hautes à mon goût, je n'ai pas voulu re-rentrer dans le sujet à ce moment-là. Mais il me semble que le sujet a mûri. Je suis plutôt pour les méthodes douces, et dans ce sens je ne pense pas que virer quelqu'un de la communauté pour ces faits-là soit une bonne solution, en effet. Je suis aussi pour la discussion, ceci dit, ainsi qu'il l'a été remarqué, Philippe a été avisé de son « comportement débordant » et gênant plusieurs fois déjà, sans résultat. Mais je suis aussi de ceux qui trouvent que son comportement nuit d'une certaine manière et de manière certaine à la communauté, ne serait-ce que par cette présente discussion qui nous divise/irrite (rayer la mention inutile) ; ou encore par le fait que son imbuvable prose casse complètement la lecture des sujets en noyant les informations utiles. Comme dit précédemment, il a des idées qui ne sont pas toutes mauvaises (comme chaque contributeur), mais il serait mieux (à mon avis) qu'il les synthétise et attende qu'on demande des précisions avant d'approfondir les sujets… Non ? (ce paragraphe est à double emploi : question à la communauté et suggestion à Philippe, s'il nous écoute) Je veux bien continuer à faire preuve de patience, mais je pense que s'il continue insensiblement à déborder ainsi, le présent sujet reviendra sempiternellement… Cordialement, -- Mikaël Cordon, mickey86 Le 6 mai 2013 21:50, Vincent Pottier vpott...@gmail.com a écrit : Le 06/05/2013 16:27, Pierre-Alain Dorange a écrit : Franchement je supporte pas cet espèce de vendetta en public qui ne montre pas un beau visage de la communauté de cette liste. De plus beaucoup semble confondre, cette liste/forum et le projet OSM. @Pierre-Alain Moi non plus je n'aime pas ce ton. Je suppose et j'espère que personne, au bout du compte n'aime. Je crois que certains propos ont été excessifs. Mais je comprends, et partage en partie, l'exaspération de certains, même si, en effet, ces derniers jours, Philippe s'est plus contenu que de coutume... Ou est-ce parce que j'ai été très occupé par ailleurs et que je n'ai pas tout suivi. Mais je puis attester que nombre de remarques lui ont été faites en privé par moi et, je suppose, par d'autres. Remarques qui sont restées vaines. Voire même, remarques qui ont été détournées de leur sens. Il arrive à chacun, il m'est arrivé, de se faire remettre à sa place/corriger/recadrer... sur la liste. Habituellement, la personne concernée laisse entendre qu'elle a entendu, reconnaît son erreur. Et les choses en reste là. Hélas, il est une personne pour laquelle ce genre de remarque devient illico une injure, une attaque publique... Je ne suis pas grand technicien, mais oui, il y a eu moult fois où les affirmations de Philippe étaient fausses et ont été démontrées telles. Et il a bien fallu que certains répondent avec force pour ne pas laisser traîner des erreurs sur la liste. Il est arrivé aussi que, la communauté étant parvenue à établir certaines pratiques cohérentes dans la façon de cartographier des éléments, Philippe aille à l'encontre de celles-ci, et malgré des rappels, persiste. Il est arrivé que, malgré des signalements de grosses erreurs, celles-ci soient mal corrigées et qu'il faille passer derrière. Certes cela arrive de devoir prêter la main à un débutant pour corriger des erreurs. Celui-ci, en général, s'excuse pour les erreurs commises et progresse dans la façon de cartographier. Philippe un éternel débutant ? Qui en plus ne s'excuse pas (ou je n'ai jamais vu) mais au contraire se justifie... Non, le problème n'est pas que sur la liste. Il est aussi dans la cartographie. Certes, Philippe a apporté des éléments de discussion. Certes Philippe a apporté des éléments à la carte. Mais au prix de quel énervement pour la communauté ? Que cela vaille bannissement, je ne le crois pas. Il y a probablement des moyens intermédiaires. Oui, il y a eu des excès de ton, mais je comprend les agacements, l'exaspération. Vous connaissez l'histoire du gars sur l'autoroute qui s'exclame : Il sont tous tarés ! Ils roulent tous à contre-sens ! ? Non ? Je vous la raconte : Il était une fois un projet de cartographie communautaire et sa liste de discussion francophone... -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Quelques statistiques sur notre liste de diffusion talk-fr
Mes messages sont courts tant qu'on commence à ne pas y répondre par des messages encore plus longs et rajouter des propos qui virent à l'obsession personnelle contre moi. C’est ce qu’on appelle de la mauvaise foi, ou de l’inconscience, c’est selon : il arrive régulièrement que tu te laisses emporter dans des explications sans fin sur plusieurs messages d’affilée sur le même sujet ! Ce n’est pas la justesse de tes explications qui est critiquable, mais plutôt le fait de diluer l’information nécessaire dans un flot à haut débit ! Décourageant à lire : on cherche l’information utile dans tes messages, on se force à tout lire pour la débusquer. Totalement contre productif. Synthétise ! Si on a besoin d’informations plus détaillées on sait que tu pourras nous les fournir. Cordialement, -- Mikaël mickey86 Le 3 mai 2013 08:58, Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net a écrit : Bonjour Philippe, Le 03/05/2013 00:54, Philippe Verdy a écrit : Les grammes de CO2 ne se réduiront pas, quel que soit le volume, tant que cette liste existera. La plus grande partie vient de la seule[...] désolé, je n'avais pas mis mode humour on car je pensais que c'était évident... /o\ A+ -- Jean-Francois Nifenecker, Bordeaux ___ 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] Logo SNCF / aéroports sur rendu FR...
+1 Je n'ai pas su dire mieux :-) Mais je rajouterais que si la carte était privée ce rendu ne serait pas un problème, ou en tout cas pas celui de la communauté OSMFR. Seulement cette carte est accessible via le nom de domaine openstreetmap.fr Cordialement, -- Mikaël mickey86 Le 27 avr. 2013 09:39, Pierre-Alain Dorange pdora...@mac.com a écrit : Christian Rogel christian.ro...@club-internet.fr wrote: Je suis d'avis qu'il ne faut pas trop abuser des logos de marques sur les tuiles image. Pour quelle raison : politique? pratique? graphique? Que signifie ne pas trop abuser? Car, ou bien, on les met avec des règles ou on ne les met pas. A mon sens l'usage de logo de marque n'a pas sa place sur une carte libre. Juridiquement c'est déjà probablement limite (droit des marques) Politiquement (au sens commun et au sens surtout d'OSM) ça me semble pas être très raccord avec les notions de partage et de neutralité que nous véhiculons. Pratiquement ensuite, c'est bien trop visible, ça attire l'œil car c'est graphiquement pas raccord avec le reste de la carte. Et avec la dispariation des services publics, ça n'aura plus de sens dans quelques années... -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ 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] Logo SNCF / aéroports sur rendu FR...
Bonjour, +1, je suis aussi d’avis de laisser de côté les logos de marque… Même s’ils ont un effet esthétique certain (et je ne dis pas que c’est un bel effet ou non :P), je pense que le rendu français (même s’il n’incombe finalement au(x) gentil(s) développeur(s) qui s’en occupe(nt) de choisir) devrait rester neutre commercialement : quand je regarde cette carte on pourrait penser que la carte est sponsorisée par La Poste et la SNCF… De plus, je ne sais pas si ces deux entreprises ont donné leur accord pour utiliser leur logo de la sorte ; quel impact sur leur image le fait d’apparaître sur cette carte a ? Et quel impact sur notre image ces logos jouent-ils ? Quid des autres marques (autoroutes Vinci, centres commerciaux Auchan, Carrefour, Leclerc, etc…) ? Un logo distinctif du service rendu est probablement plus neutre et surtout plus simple à mettre en place, il me semble, car générique. Toutefois, cette carte reste un rendu personnel, une interprétation de la base OSM… Peut-être que légalement, il n’y a aucun sujet… Mais tout de même, je me pose des questions. Pour finir sur une note plus positive, je trouve quand même que ce rendu, ne serait-ce que par son niveau élevé de zoom et sa réactivité est très intéressant ! :) Le 26 avril 2013 08:18, David Crochet david.croc...@online.fr a écrit : Bonjour Il existe un panneau de signalisation signalant une gare, enfin plutôt un service de transport à la personne par rail ayant un traffic supérieur à 30 000 passager par an. Pourquoi ne pas utiliser ce logo. Peut-être trop proche d'une sybolique rapellant le TGV, mais les nouvelle rame y ressemble fortement maintenant. Réservons le logo SNCF Trancilien RATP aux services associés, c'est a dire les agences commerciales. Pour les aéroports, c'est la même choses. On y met pas les logo des transporteurs, mais du service rendu (qui peuvent être in situ). Les centres commerciaux, c'est pareil ? c'est bien le logo du service rendu ? Cordialement -- David Crochet ___ 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] Test de routage sous JOSM
Salut, Depuis quelques temps, je teste OSMAnd et le routage sur carte OSM, et je me rends compte que le routage n’est pas optimal… Je me demande s’il n’y a pas des problèmes d’interconnexion de routes… Je cherche a effectuer des tests de routage rapide, ou même du test d’interconnexion aux intersections dans JOSM… J’ai tenté plusieurs plugins, mais je n’ai pas trouvé convenance : ne fonctionne pas, ou pas pratique du tout. Il y a-t-il des outils pratiques pour tester la connectivité du réseau routier (tout véhicule et pédestre) sous JOSM ? Cordialement, -- Mikaël, mickey86 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Test de routage sous JOSM
J’avoue ne pas utiliser Osmose suffisamment… Ceci dit, ce n’est pas un problème de « syntaxe » ou « grammaire » de la carte, mais plutôt de la sémantique que je cherche à tester… Autrement dit, les problèmes de routage que je rencontre ne sont pas dû forcément à des erreurs de tags, osmose ne les voit pas… Concrètement, j’aimerais disposer d’un outil qui me permet de poser un point de départ, un point d’arrivée de part et d’autre d’un carrefour et visualiser rapidement s’il existe un chemin et lequel ! Particulièrement utile pour détecter les déconnexions et les restrictions de routage mal configurés… Le 26 avril 2013 09:52, Romain MEHUT romain.me...@gmail.com a écrit : Le 26 avril 2013 09:48, Mikaël Cordon mikael.cor...@gmail.com a écrit : Salut, Depuis quelques temps, je teste OSMAnd et le routage sur carte OSM, et je me rends compte que le routage n’est pas optimal… Je me demande s’il n’y a pas des problèmes d’interconnexion de routes… Je cherche a effectuer des tests de routage rapide, ou même du test d’interconnexion aux intersections dans JOSM… J’ai tenté plusieurs plugins, mais je n’ai pas trouvé convenance : ne fonctionne pas, ou pas pratique du tout. Il y a-t-il des outils pratiques pour tester la connectivité du réseau routier (tout véhicule et pédestre) sous JOSM ? Tu ne trouves pas ton bonheur via http://osmose.openstreetmap.fr ? Romain ___ 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] Test de routage sous JOSM
il y a http://tools.geofabrik.de/osmi/?view=routinglon=2.32952lat=48.87269zoom=11overlays=islands Effectivement, c’est un bon outil que je peux utiliser, mais il manque le test des routages mal configurés (sens interdits et interdictions de tourner, etc…). Et mieux, pour moi, serait exploitable dans JOSM. Cordialement, -- Mikaël Le 26 avril 2013 10:32, didier2020 didier2...@free.fr a écrit : Le vendredi 26 avril 2013 à 10:12 +0200, Mikaël Cordon a écrit : J’avoue ne pas utiliser Osmose suffisamment… Ceci dit, ce n’est pas un problème de « syntaxe » ou « grammaire » de la carte, mais plutôt de la sémantique que je cherche à tester… Autrement dit, les problèmes de routage que je rencontre ne sont pas dû forcément à des erreurs de tags, osmose ne les voit pas… Concrètement, j’aimerais disposer d’un outil qui me permet de poser un point de départ, un point d’arrivée de part et d’autre d’un carrefour et visualiser rapidement s’il existe un chemin et lequel ! Particulièrement utile pour détecter les déconnexions et les restrictions de routage mal configurés… il y a http://tools.geofabrik.de/osmi/?view=routinglon=2.32952lat=48.87269zoom=11overlays=islands Le 26 avril 2013 09:52, Romain MEHUT romain.me...@gmail.com a écrit : Le 26 avril 2013 09:48, Mikaël Cordon mikael.cor...@gmail.com a écrit : Salut, Depuis quelques temps, je teste OSMAnd et le routage sur carte OSM, et je me rends compte que le routage n’est pas optimal… Je me demande s’il n’y a pas des problèmes d’interconnexion de routes… Je cherche a effectuer des tests de routage rapide, ou même du test d’interconnexion aux intersections dans JOSM… J’ai tenté plusieurs plugins, mais je n’ai pas trouvé convenance : ne fonctionne pas, ou pas pratique du tout. Il y a-t-il des outils pratiques pour tester la connectivité du réseau routier (tout véhicule et pédestre) sous JOSM ? Tu ne trouves pas ton bonheur via http://osmose.openstreetmap.fr ? Romain ___ 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 ___ 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] Test de routage sous JOSM
Moi j'utilise souvent http://map.project-osrm.org/ pour tester les différents routage possible... c'est p-e un peu plus rapide que osmand... Effectivement, plutôt rapide, c’est ce que je cherche… à 90% : il faut attendre que la correction ait été prise en compte par OSMR pour tester la correction :) Je sais, je suis exigeant :p L’idéal serait cet outil directement dans JOSM… Mais en l’absence d’un plugin équivalent dans JOSM, c’est ce que j’utiliserai :) Merci ! Cordialement, -- Mikaël mickey86 Le 26 avril 2013 10:40, eMerzh merz...@gmail.com a écrit : Moi j'utilise souvent http://map.project-osrm.org/ pour tester les différents routage possible... c'est p-e un peu plus rapide que osmand... 2013/4/26 didier2020 didier2...@free.fr Le vendredi 26 avril 2013 à 10:12 +0200, Mikaël Cordon a écrit : J’avoue ne pas utiliser Osmose suffisamment… Ceci dit, ce n’est pas un problème de « syntaxe » ou « grammaire » de la carte, mais plutôt de la sémantique que je cherche à tester… Autrement dit, les problèmes de routage que je rencontre ne sont pas dû forcément à des erreurs de tags, osmose ne les voit pas… Concrètement, j’aimerais disposer d’un outil qui me permet de poser un point de départ, un point d’arrivée de part et d’autre d’un carrefour et visualiser rapidement s’il existe un chemin et lequel ! Particulièrement utile pour détecter les déconnexions et les restrictions de routage mal configurés… il y a http://tools.geofabrik.de/osmi/?view=routinglon=2.32952lat=48.87269zoom=11overlays=islands Le 26 avril 2013 09:52, Romain MEHUT romain.me...@gmail.com a écrit : Le 26 avril 2013 09:48, Mikaël Cordon mikael.cor...@gmail.com a écrit : Salut, Depuis quelques temps, je teste OSMAnd et le routage sur carte OSM, et je me rends compte que le routage n’est pas optimal… Je me demande s’il n’y a pas des problèmes d’interconnexion de routes… Je cherche a effectuer des tests de routage rapide, ou même du test d’interconnexion aux intersections dans JOSM… J’ai tenté plusieurs plugins, mais je n’ai pas trouvé convenance : ne fonctionne pas, ou pas pratique du tout. Il y a-t-il des outils pratiques pour tester la connectivité du réseau routier (tout véhicule et pédestre) sous JOSM ? Tu ne trouves pas ton bonheur via http://osmose.openstreetmap.fr ? Romain ___ 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 ___ 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Logo SNCF / aéroports sur rendu FR...
Personnellement, je n’attaque pas directement ton travail qui est apprécié et remarquable. En tant que contributeur OSM, habitué à voir des cartes officielles neutres commercialement, voir les logos de seules 2 compagnies m’a interloqué. Après comme je l’ai souligné, peut-être peut-on considérer ce rendu comme un travail privé, et dans ce cas tu peux oublier mes remarques. Mais dès lors que ce travail est disponible via le nom de domaine openstreetmap.fr, la carte revêt un caractère officiel… Mais peut-être me trompe-je ? Je ne suis pas toujours le plus fin, ni le plus mesuré… Je suis un passionné :) Cordialement, -- Mikaël mickey86 Le 26 avril 2013 13:22, Christian Quest cqu...@openstreetmap.fr a écrit : Tout dans la finesse et la mesure... je pense que je vais devoir m'auto-flageller en place publique pour faire pénitence pour l'inadmissible publicité faite à La Poste et la SNCF ! ___ 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] Test de routage sous JOSM
Si tu n'as pas peur de programmer toi-même un petit peu, j'ai déjà beaucoup réalisé avec le plugin scripting en Python: http://wiki.openstreetmap.org/wiki/Quality_control_with_Python_script_in_JOSM Jo Me reste cette option, étant déjà dans la programmation toute la journée au boulot, j’aime bien varier les plaisirs ^^… Mais j’y viendrai peut-être. Cordialement, -- Mikaël mickey86 Le 26 avril 2013 14:08, Jo winfi...@gmail.com a écrit : Si tu n'as pas peur de programmer toi-même un petit peu, j'ai déjà beaucoup réalisé avec le plugin scripting en Python: http://wiki.openstreetmap.org/wiki/Quality_control_with_Python_script_in_JOSM Jo 2013/4/26 Mikaël Cordon mikael.cor...@gmail.com Salut, Depuis quelques temps, je teste OSMAnd et le routage sur carte OSM, et je me rends compte que le routage n’est pas optimal… Je me demande s’il n’y a pas des problèmes d’interconnexion de routes… Je cherche a effectuer des tests de routage rapide, ou même du test d’interconnexion aux intersections dans JOSM… J’ai tenté plusieurs plugins, mais je n’ai pas trouvé convenance : ne fonctionne pas, ou pas pratique du tout. Il y a-t-il des outils pratiques pour tester la connectivité du réseau routier (tout véhicule et pédestre) sous JOSM ? Cordialement, -- Mikaël, mickey86 ___ 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Logo SNCF / aéroports sur rendu FR...
ne pas représenter les logos mais le nom des enseignes revient un peu au même non ? Ça revient un peu au même… Mais à la différence des logos, le nom des enseignes sont tous rendus de la même manière : je suppose évidemment que l’algorithme d’affichage (de filtrage) ne privilégie pas une enseigne par rapport à une autre. Cordialement, -- Mikaël mickey86 Le 26 avril 2013 14:16, Mikaël Cordon mikael.cor...@gmail.com a écrit : Personnellement, je n’attaque pas directement ton travail qui est apprécié et remarquable. En tant que contributeur OSM, habitué à voir des cartes officielles neutres commercialement, voir les logos de seules 2 compagnies m’a interloqué. Après comme je l’ai souligné, peut-être peut-on considérer ce rendu comme un travail privé, et dans ce cas tu peux oublier mes remarques. Mais dès lors que ce travail est disponible via le nom de domaine openstreetmap.fr, la carte revêt un caractère officiel… Mais peut-être me trompe-je ? Je ne suis pas toujours le plus fin, ni le plus mesuré… Je suis un passionné :) Cordialement, -- Mikaël mickey86 Le 26 avril 2013 13:22, Christian Quest cqu...@openstreetmap.fr a écrit : Tout dans la finesse et la mesure... je pense que je vais devoir m'auto-flageller en place publique pour faire pénitence pour l'inadmissible publicité faite à La Poste et la SNCF ! ___ 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] highway=turning_circle ou highway=* + area=yes?
Salut, À propos de « noexit=yes » au début ou à la fin d’une rue sans issue ou sur le chemin, j’attire votre attention sur le fait que lorsqu’on se retrouve dans la situation d’un branche avec des branchioles (une rue sans issue avec au moins une autre rue sans issue connectée à elle), mettre en début ou fin de rue n’est pas équivalent ! Je n’ai pas de préférence, sur la place du « noexit=yes », à vrai dire, je laisse la topologie décider de ce qui est une voie sans issue ou non : après tout on ne peut raisonnablement pas justifier toutes les vérités de la base par un tag supplémentaire ; il ne s’agit pas ici de toutes les vérités mais seulement les voies sans issues, mais tout de même, ça soulève la légitimité de ce tag, à mon sens. D’autre part, le concept de voie sans issue est délicat : – il dépend du mode de locomotion, une voie peut se révéler sans issue pour une voiture, mais pas pour un piéton ni un vélo – est une voie sans issue si le seul moyen de revenir à l’entrée de cette voie est de rebrousser chemin avec le même véhicule – une voie sans issue peut contenir des voies avec issue : une boucle dans une voie sans issue Je pense que mes remarques vont faire un peu débat, mais je les pense nécessaires. Cordialement, -- Mikaël Cordon, mickey86 Le 24 avril 2013 10:43, Vincent de Chateau-Thierry v...@laposte.net a écrit : Bonjour, De : Christian Quest C'est bien au nœud d'extremité que ce tag est le plus utile du côté réutilisation par les outils de contrôle qualité, les principaux (les seuls ?) à trouver une utilité à ce tag. Ce tag est aussi utile pour les moteurs de calcul d'itinéraire. Il permet simplement, en éliminant les _ways_ taggués noexit=yes, de construire un graphe de transit, allégé des voies strictement de destination. Maintenant, au vu des stats, il est nécessaire d'envisager les 2 configurations (sur le node de fin et sur le way) si on ne veut pas perdre une masse d'info au moment de l'exploiter. La relation entre un way et les nodes qui le constituent est connue, au moins via les schémas d'import classique (Osmosis, osm2pgsql). Donc pas besoin de se battre sur la meilleure modélisation, à mon avis, les deux se défendent, et aucune ne mène à une impasse (hum). 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
Re: [OSM-talk-fr] highway=turning_circle ou highway=* + area=yes?
Je rajouterai également que lorsqu’une voie sans issue devient une voie avec issue, il est important de remonter toute la branche (de mon exemple précédent) pour éliminer le tag « noexit=yes », là où il le faut… Une voie avec issue, marquée comme sans issue, ça ne le fait pas : un routeur qui manque un raccourci perd beaucoup de point face à la concurrence qui l’aura trouvé :) Cordialement, -- Mikaël Cordon, mickey86 Le 24 avril 2013 11:31, Mikaël Cordon mikael.cor...@gmail.com a écrit : Salut, À propos de « noexit=yes » au début ou à la fin d’une rue sans issue ou sur le chemin, j’attire votre attention sur le fait que lorsqu’on se retrouve dans la situation d’un branche avec des branchioles (une rue sans issue avec au moins une autre rue sans issue connectée à elle), mettre en début ou fin de rue n’est pas équivalent ! Je n’ai pas de préférence, sur la place du « noexit=yes », à vrai dire, je laisse la topologie décider de ce qui est une voie sans issue ou non : après tout on ne peut raisonnablement pas justifier toutes les vérités de la base par un tag supplémentaire ; il ne s’agit pas ici de toutes les vérités mais seulement les voies sans issues, mais tout de même, ça soulève la légitimité de ce tag, à mon sens. D’autre part, le concept de voie sans issue est délicat : – il dépend du mode de locomotion, une voie peut se révéler sans issue pour une voiture, mais pas pour un piéton ni un vélo – est une voie sans issue si le seul moyen de revenir à l’entrée de cette voie est de rebrousser chemin avec le même véhicule – une voie sans issue peut contenir des voies avec issue : une boucle dans une voie sans issue Je pense que mes remarques vont faire un peu débat, mais je les pense nécessaires. Cordialement, -- Mikaël Cordon, mickey86 Le 24 avril 2013 10:43, Vincent de Chateau-Thierry v...@laposte.net a écrit : Bonjour, De : Christian Quest C'est bien au nœud d'extremité que ce tag est le plus utile du côté réutilisation par les outils de contrôle qualité, les principaux (les seuls ?) à trouver une utilité à ce tag. Ce tag est aussi utile pour les moteurs de calcul d'itinéraire. Il permet simplement, en éliminant les _ways_ taggués noexit=yes, de construire un graphe de transit, allégé des voies strictement de destination. Maintenant, au vu des stats, il est nécessaire d'envisager les 2 configurations (sur le node de fin et sur le way) si on ne veut pas perdre une masse d'info au moment de l'exploiter. La relation entre un way et les nodes qui le constituent est connue, au moins via les schémas d'import classique (Osmosis, osm2pgsql). Donc pas besoin de se battre sur la meilleure modélisation, à mon avis, les deux se défendent, et aucune ne mène à une impasse (hum). 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
Re: [OSM-talk-fr] Opensnowmap.org
Salut, Merci les pistes de Cordon sont aussi dans le bon sens ! Et j'en suis tout à fait ravi :P Cordialement, -- Mikaël Cordon, mickey86 Le lundi 8 avril 2013 10:31:30, Fabien a écrit : Le 7 avril 2013 19:35, yvecai yve...@gmail.com a écrit : Les skieurs de Super-Besse peuvent maintenant prendre les remontées la tête en haut, et utiliser toute la largeur des pistes. Ils sont, semble-t-il, heureux de cette nouvelle situation. Merci les pistes de Cordon sont aussi dans le bon sens ! Fabien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr signature.asc Description: This is a digitally signed message part. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Demande d'informations
Le 8 février 2013 20:27, Pieren pier...@gmail.com a écrit : 2013/2/7 Mikaël Cordon mikael.cor...@gmail.com: Bonjour Monsieur, Madame, Bonsoir et bienvenue sur OpenStreetMap et votre soutient apporté au projet. Merci, Pour de la documentation, on peut en trouver dans le döpôt SVN d'osm.org mais il n'est pas de toute première fraicheur :( http://svn.openstreetmap.org/misc/pr_material Nous allons regarder cette documentation, et la mettrons à jour si on l’utilise et si nécessaire ! Sinon, il doit y avoir des choses dans les archives et certains lecteurs de cette présente liste de diffusion, actifs en matière de présentations, auront surement de la doc à mettre à disposition. Nous espérons aussi :) Nous reviendrons faire un petit retour sur cette cartopartie qui s’inscrit dans une manifestation plus grande à propos de l’open data sur Poitiers. Cordialement, -- Mikaël Cordon, Secrétaire de l’APP3L et mickey86, contributeur OSM Pieren ___ 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] Demande d'informations
Bonjour Monsieur, Madame, L'Association Poitevine Pour la Promotion de GNU/Linux et du Logiciel Libre est un groupe d'utilisateurs de logiciels libres basé à Poitiers. Parmi nos activités, nous organisons des cartoparties afin de sensibiliser le public sur l'utilisation et la contribution à Open Street Map. OSM étant un moyen grand public de montrer l'usage d'un logiciel libre en dehors de la sphère informatique (web, bureautique, ...) tout en gardant un aspect collaboratif, nous recherchons de la documentation (brochures...) à distribuer au public pour expliquer au mieux les buts d'OSM à l'image de celle qu'a réalisé Wikimédia France pour Wikipédia. Nos recherches sur le wiki d'OSM et sur le site http://www.openstreetmap.fr ne nous ont rien donné, peut-être que c'est quelques chose qui est en gestation au sein de votre association ? En vous remerciant d'avance de votre réponse, voyez aussi dans cette demande, le respect que notre association porte à vos actions. Cordialement, -- Mikaël Cordon, Secrétaire de l'APP3L pour Francis Ganteaume Vice-President de l'APP3L http://www.app3l.org cont...@app3l.org signature.asc Description: This is a digitally signed message part. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Numéro de rue ?
Je ne met des adresses sur les polygones que pour les bâtiments éloignés de la rue, par exemple dans une résidence avec plusieurs immeubles où le cadastre met justement un numéro au milieu du bâtiment et pas sur l'entrée. +1, sauf si une ruelle ou une allée mène au bâtiment :) Cordialement, -- Mikaël Cordon, mickey86 Le 3 janvier 2013 23:35, Christian Quest cqu...@openstreetmap.fr a écrit : Le 3 janvier 2013 22:14, Cyrille Giquello cyrill...@gmail.com a écrit : Je viens appuyer l'explication de Romain. Mettre le numéro de la rue au plus près de l'entrée du lieu et non pas sur le bâti. C'est plus facile à trouver et plus simple à mapper, surtout quand il y a plusieurs bâtiments pour la même adresse, ou que le bâti se trouve loin de l'entrée, ou ... Et ça évite des questions existentielles lorsqu'il y a plusieurs bâtiments à la même adresse... Je ne met des adresses sur les polygones que pour les bâtiments éloignés de la rue, par exemple dans une résidence avec plusieurs immeubles où le cadastre met justement un numéro au milieu du bâtiment et pas sur l'entré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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] relations boundary modifiées par Philippe Verdy – Tirets
Il me semble qu’on en était resté sur un statu quo ante bellum… Selon moi, pour résumer et sans vouloir relancer les hostilités, chaque camp a ses raisons que l’autre a compris (en tout cas je l’espère), et que globalement, utiliser ou non les différents traits d’union ou tirets ne change pas fondamentalement les choses : – utiliser ces fameux tirets spécifiques sont, certes, difficiles à saisir pour une majorité de contributeurs mais suppriment de nombreuses ambiguïtés ; – ne pas les utiliser, est trivial, mais introduisent des ambiguïtés qui ne peuvent pas être efficacement et systématiquement levées. Cordialement, -- Mikaël Cordon, mickey86 Le 28 décembre 2012 14:06, JB jb...@mailoo.org a écrit : ** C'est marrant, je ne me souviens pas avoir vu de majorité se dégager de la discussion sur les tirets et les trait d'union… Pieren avait certes sa majorité personnelle avant de lancer la discussion, mais ne semblait clairement pas majoritaire après les réponses. Sans qu'une majorité nette ne se distingue de l'autre coté non plus. Le 28.12.2012 14:00, Pieren a écrit : 2012/12/24 Hendrik Oesterlin hendrikmail2...@yahoo.de: Dans un premier temps je ne veux pas parler des erreurs avérées dans les langues qui lui sont étrangères, et pas non plus des tiret particuliers qu'il y ajoute Si, si. On en a parlé. Je pense qu'il y a une large majorité qui se dégage pour dire que ces tirets longs sont à rejeter pour toutes les raisons déjà mentionnées. Pieren ___ 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] Suppression des tirets cadratins
si je suis d'accord sur le principe, il reste possible aux tenants de la simplicité (et ça aussi c'est bien, mangez-en) d'utiliser des tirets simples partout, à condition de les encadrer d'espaces -- ou non -- selon le cas. On peut donc se contenter de : Champs-Élysées - Clemenceau Évidemment ! Il n’a jamais été question de contraindre ceux qui ne veulent ou ne peuvent pas à utiliser une typographie avancée. Mais, comme on est d’accord qu’une typographie avancée enrichi les données, il ne faut pas contraindre ceux qui le veulent et le peuvent à ne pas l’utiliser. Cordialement, -- Mikaël Cordon, mickey86 Le 29 novembre 2012 22:08, Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net a écrit : Bonjour, Le 28/11/2012 18:29, te...@free.fr a écrit : Champs-Élysées — Clemenceau (avenue des Champs-Élysées, place Clemenceau) si je suis d'accord sur le principe, il reste possible aux tenants de la simplicité (et ça aussi c'est bien, mangez-en) d'utiliser des tirets simples partout, à condition de les encadrer d'espaces -- ou non -- selon le cas. On peut donc se contenter de : Champs-Élysées - Clemenceau A+ -- 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des tirets cadratins
Je n’ai pas l’habitude de rentrer dans des sujets chauds aussi tôt dans la conversation… Mais comme je me sens un peu visé par le sujet — en effet, j’utilise la typographie française aussi précisément que je peux — je me permets d’intervenir en faveur du cadratin. Et je ne vois pas le problème à avoir une typo première version avec les caractères les plus accessibles à tous (-) et un maniaque derrière qui remettra une couche avec le beau tiret cadratin. +1, sachant que ce caractère n’est pas que « beau », mais surtout sémantique (terme souvent repris dans la base OSM). De plus, lors d’un traitement automatique de la typographie — qui est inévitable pour un rendu homogène —, j’imagine tout à fait que l’algorithme gère les espaces multiples, ou les manques d’espaces ; et dans le cas « Maisons-Alfort - Stade » il me semble bien plus compliqué de savoir si les espaces sont trop nombreux ou qu’ils manquent ; alors qu’avec « Maisons-Alfort — Stade » l’ambiguïté est levée et le traitement des espaces est trivial. D’autre part, on a souvent entendu à propos de la base OSM qu’elle doit être, d’une part uniforme, mais aussi préserver les spécificités ; et là, il s’agit clairement d’une spécificité de la langue française (je ne saurais dire si ce caractère a cours dans d’autres langues). Comme l’a justement fait remarqué Philippe, les balises name=* sont les noms locaux/officiels (rayez la mention que vous voulez) des objets auxquels ils sont attachés ; et en tant qu’objets français, ils se doivent être écrits en français. Et même si ce ne sont pas des « codes », avec la typographie qui va bien, leur décodage selon les règles de la langue locale (ici le français) peut tout à fait être systématisé et automatique. Enfin, je rajouterai que je suis également adepte de l’utilisation des différentes espaces (fines, insécables, etc…), l’apostrophe française et des guillemets français. Ceci dit, je n’imposerai jamais à notre communauté française de cartographieurs OSM ces subtilités ; mais de l’autre côté, je ne souhaite pas me voir imposer la non utilisation de ces subtilités, qui, je le rappelle, lèvent bon nombre d’ambiguïtés ! Cordialement, -- Mikaël Cordon, mickey86 Le 29 novembre 2012 09:56, JB jb...@mailoo.org a écrit : ** Bof, est-ce qu'un néophyte de la typo aura plus tendance à écrire « Maisons-Alfort - Stade » que « Maisons-Alfort—Stade » ou « Maisons-Alfort-Stade » ? Il ne comprendra pas plus la différence entre « Maisons-Alfort - Stade » et « Maisons-Alfort-Stade » qu'entre « Maisons-Alfort - Stade » et « Maisons-Alfort—Stade ». Et je ne vois pas le problème à avoir une typo première version avec les caractères les plus accessibles à tous (-) et un maniaque derrière qui remettra une couche avec le beau tiret cadratin. On répète à qui veut l'entendre d'utiliser les bons tags et que c'est aux moteurs de rendus de s'adapter, je ne vois pas pourquoi on changerait cette règle quand on passe à la typographie. JB Le 29.11.2012 09:19, Vladimir Vyskocil a écrit : On 28 nov. 2012, at 19:20, Pieren pier...@gmail.com wrote: Si on veut distinguer deux entités, on peut aussi bien mettre des espaces avant et après le tiret pour lever toute ambiguité (Maisons-Alfort - Stade est assez clair). Ce compromis me semble tout à fait acceptable car il résout à la fois le problème sémantique et l'utilisation de caractères typographique ésotériques pour 99.5% des contributeurs. Vlad. ___ Talk-fr mailing listTalk-fr@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-fr ___ 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] Suppression des tirets cadratins
Oui cela pourrait être une bonne façon d'entrer les données dans la base, le / serait alors un séparateur de liste et - représenterait l'union. Ensuite libre au moteur de rendu d'afficher ça de la bonne manière. Attention, le caractère « / » a sa propre signification. Et pour les cartographieurs qui reproduisent scrupuleusement les panneaux, « / » a pour signification dans des version abrégées de « sur ». Exemple : « Argenton / Creuse » ou « Argenton s/ Creuse », signifiant « Argenton sur Creuse » ; qui deviendrait alors « Argenton — Creuse » ayant une toute autre signification. Cordialement, -- Mikaël Cordon, mickey86 Le 29 novembre 2012 11:09, Mikaël Cordon mikael.cor...@gmail.com a écrit : Je n’ai pas l’habitude de rentrer dans des sujets chauds aussi tôt dans la conversation… Mais comme je me sens un peu visé par le sujet — en effet, j’utilise la typographie française aussi précisément que je peux — je me permets d’intervenir en faveur du cadratin. Et je ne vois pas le problème à avoir une typo première version avec les caractères les plus accessibles à tous (-) et un maniaque derrière qui remettra une couche avec le beau tiret cadratin. +1, sachant que ce caractère n’est pas que « beau », mais surtout sémantique (terme souvent repris dans la base OSM). De plus, lors d’un traitement automatique de la typographie — qui est inévitable pour un rendu homogène —, j’imagine tout à fait que l’algorithme gère les espaces multiples, ou les manques d’espaces ; et dans le cas « Maisons-Alfort - Stade » il me semble bien plus compliqué de savoir si les espaces sont trop nombreux ou qu’ils manquent ; alors qu’avec « Maisons-Alfort — Stade » l’ambiguïté est levée et le traitement des espaces est trivial. D’autre part, on a souvent entendu à propos de la base OSM qu’elle doit être, d’une part uniforme, mais aussi préserver les spécificités ; et là, il s’agit clairement d’une spécificité de la langue française (je ne saurais dire si ce caractère a cours dans d’autres langues). Comme l’a justement fait remarqué Philippe, les balises name=* sont les noms locaux/officiels (rayez la mention que vous voulez) des objets auxquels ils sont attachés ; et en tant qu’objets français, ils se doivent être écrits en français. Et même si ce ne sont pas des « codes », avec la typographie qui va bien, leur décodage selon les règles de la langue locale (ici le français) peut tout à fait être systématisé et automatique. Enfin, je rajouterai que je suis également adepte de l’utilisation des différentes espaces (fines, insécables, etc…), l’apostrophe française et des guillemets français. Ceci dit, je n’imposerai jamais à notre communauté française de cartographieurs OSM ces subtilités ; mais de l’autre côté, je ne souhaite pas me voir imposer la non utilisation de ces subtilités, qui, je le rappelle, lèvent bon nombre d’ambiguïtés ! Cordialement, -- Mikaël Cordon, mickey86 Le 29 novembre 2012 09:56, JB jb...@mailoo.org a écrit : ** Bof, est-ce qu'un néophyte de la typo aura plus tendance à écrire « Maisons-Alfort - Stade » que « Maisons-Alfort—Stade » ou « Maisons-Alfort-Stade » ? Il ne comprendra pas plus la différence entre « Maisons-Alfort - Stade » et « Maisons-Alfort-Stade » qu'entre « Maisons-Alfort - Stade » et « Maisons-Alfort—Stade ». Et je ne vois pas le problème à avoir une typo première version avec les caractères les plus accessibles à tous (-) et un maniaque derrière qui remettra une couche avec le beau tiret cadratin. On répète à qui veut l'entendre d'utiliser les bons tags et que c'est aux moteurs de rendus de s'adapter, je ne vois pas pourquoi on changerait cette règle quand on passe à la typographie. JB Le 29.11.2012 09:19, Vladimir Vyskocil a écrit : On 28 nov. 2012, at 19:20, Pieren pier...@gmail.com wrote: Si on veut distinguer deux entités, on peut aussi bien mettre des espaces avant et après le tiret pour lever toute ambiguité (Maisons-Alfort - Stade est assez clair). Ce compromis me semble tout à fait acceptable car il résout à la fois le problème sémantique et l'utilisation de caractères typographique ésotériques pour 99.5% des contributeurs. Vlad. ___ Talk-fr mailing listTalk-fr@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-fr ___ 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] Suppression des tirets cadratins
@Vladimir : je suis d’accord que mon exemple n’était pas le plus réfléchi, il est limite puisqu’effectivement les abréviations ne sont pas souhaitées. Ceci dit, il y a beaucoup de choses non souhaitées dans la base OSM :). Surtout ce que je voulais soulever, c’est que les caractères ont une signification bien établie ; et qu’il est dommage et risqué quant à en changer le sens localement. Pourquoi ne pas utiliser directement le bon caractère ? J’ai pour habitude, en cas de doute, d’appauvrir l’information plutôt que mettre une information ambiguë, ou pire, fausse. Cordialement, -- Mikaël Cordon, mickey86 Le 29 novembre 2012 11:24, Vladimir Vyskocil vladimir.vysko...@gmail.coma écrit : On 29 nov. 2012, at 11:15, Mikaël Cordon mikael.cor...@gmail.com wrote: Oui cela pourrait être une bonne façon d'entrer les données dans la base, le / serait alors un séparateur de liste et - représenterait l'union. Ensuite libre au moteur de rendu d'afficher ça de la bonne manière. Attention, le caractère « / » a sa propre signification. Et pour les cartographieurs qui reproduisent scrupuleusement les panneaux, « / » a pour signification dans des version abrégées de « sur ». Exemple : « Argenton / Creuse » ou « Argenton s/ Creuse », signifiant « Argenton sur Creuse » ; qui deviendrait alors « Argenton — Creuse » ayant une toute autre signification. Ok, une autre convention pourrait être trouvée mais l'exemple cité n'est pas bon car il ne faudrait pas entrer de versions abrégées des noms dans la base car la aussi c'est au moteur de rendu ou de recherche dans les données de faire les abréviations à la volée si besoin (autre débat, assez chaud chez les américains par exemple...) Cordialement, -- Mikaël Cordon, mickey86 cordialement, Vladimir. ___ 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] Suppression des tirets cadratins
Je suis entièrement d’accord du point de la séparation donnée/rendu. Le but du jeu c’est de pouvoir comprendre la donnée de façon univoque ! On sait que tant que ce seront des humains qui saisiront des données dans la base, il y aura des erreurs. Et les erreurs sont d’autant plus nombreuses qu’elles ne sont pas clairement visibles (je parle ici des espaces) ; ou que les règles sont méconnues. Beaucoup d’algorithmes automatiques sont justement là pour corriger ou pallier à ces erreurs. Ils font des merveilles pour rajouter ou supprimer des espaces ou de la ponctuation devant tel ou tel caractère, changer la casse (Rue saint-Antoine), même reconnaître des erreurs évidentes telles que « aveneu » à la place de « avenue ». Seulement voilà, ces algorithmes ont leurs limites devant une ambiguïté telle que « Maisons-Alfort - Stade » ; je trouve que tenter de lever une ambiguïté à l’aide de l’espace qui est un caractère particulièrement enclin à générer des erreurs n’est pas du tout judicieux. Les lettres, les articles de journaux, et autres éditions françaises ne sont pas traités automatiquement comme le sont les données d’OSM ; dans les journaux, c’est l’humain au final qui lève les ambiguïtés grâce à sa mémoire colossale et sa capacité de reconnaissance à la volée ; les algorithmes automatiques d’aujourd’hui ne sont pas capable d’un tel prodige à moins d’efforts démesurés pour les concevoir (parole de développeur). La base OSM est tellement grosse, que malgré la puissance du cerveau humain personne ne peut corriger la base. Et quand bien même il le pourrait, vu que c’est un humain, il fera des erreurs. Donc, c’est bien un algorithme qui traitera toutes ces données si on veut supprimer les erreurs. Je pense qu’on ne peut pas demander aux contributeurs bienveillant d’appauvrir leurs données sous prétexte que la majorité ne peuvent pas atteindre cette précision ; d’autant que cette précision est bénéfique et utilisable. Et là, je ne parle pas que de typographie ! Je pense qu’utiliser les bons caractères au bon endroit est un bonus ! Cordialement, -- Mikaël Cordon, mickey86 Le 29 novembre 2012 11:53, Pieren pier...@gmail.com a écrit : 2012/11/29 Mikaël Cordon mikael.cor...@gmail.com: Enfin, je rajouterai que je suis également adepte de l’utilisation des différentes espaces (fines, insécables, etc…), l’apostrophe française et des guillemets français. Ceci explique cela ;-) Je remarque qu'il y a parmi le public des contributeurs français une très petite minorité d'adeptes de la belle typographie française, qui en connaissent les règles et les moyens de saisie. D'ailleurs, ils viennent souvent de wikipedia. Mais le tag name n'est pas un article wikipedia, le tag name ne sert pas à imprimer les panneaux de signalisation, le tag name n'a pas à respecter les règles typographiques des imprimeurs. Parce que dans OSM, on sépare donnée factuelle et rendu. OSM, c'est de la donnée brute pour le monde entier. Et il n'y a qu'en France que je vois autant de tirets longs pour faire de la sémantique. Alors que oui, ce caractère existe dans tous les pays, même en chinois (—— 破折号) mais il risque de ne pas avoir le même emploi ! On a déjà discuté règles typographiques ici et on a constaté que 1. elles étaient en contradiction avec les règles de toponymie (Rue Saint-Antoine devrait s'écrire Rue saint-Antoine) 2. qu'il n'y avait pas de standard universel même en France puisque l'académie a ses règles, les grands journaux ont les leurs, les éditeurs/imprimeurs aussi, etc- Pieren ___ 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] Suppression des tirets cadratins
Se dépatouiller avec des bizarreries… On se demande ce qui est bizarre ou ce qui est normal. Il faut savoir que certaines (un certain nombre) implémentations de la reconnaissance de motifs par expressions régulières dans le monde UTF-8 (en perl, php, extension SQL et sûrement d’autres langages) permettent de reconnaître des classes de caractères : les espaces, les séparateurs, caractères de groupement (parenthèses, crochets, etc…), ponctuations, chiffres, caractères de citation, les caractères accentués, les caractères en haut de casse, etc… indépendamment de la langue ; ce sont des propriétés des caractères. Et j’insiste sur le fait qu’il serait une erreur d’imposer l’utilisation de ces fameux caractères, puisque tout le monde ne les connaissent pas, et ne peuvent les saisir ! Mais dès lors qu’ils enrichissent les données et qu’ils peuvent être exploités, ils ne doivent pas être bannis. Cordialement, -- Le 29 novembre 2012 15:13, Vladimir Vyskocil vladimir.vysko...@gmail.coma écrit : On 29 nov. 2012, at 12:45, Philippe Verdy verd...@wanadoo.fr wrote: Ce qui se complique encore quand les toponymes ***officiels*** espagnols utilisent le / pour séparer les noms ***co-officiels*** issus de plusieurs langues, ces deux langues ***devant*** toujours être citées ensembles et dans l'ordre indiqué sans qu'on puisse en supprimer un ! C'est alors le même toponyme dans les langues d'origine, les différences linguistiques étant alors abolies dans la dénomination officielle pour la même entité (regardez le Pays Basque espagnol par exemple). Dans ce cas le / ne signifie pas non plus sur, ***même*** en Français. Comment alors faire un traitement automatique de substitution pour faire joli ? Oui effectivement le / a sa propre sémantique dans ce cas, mais on ne doit PAS l'utiliser comme s'il s'agissait d'une abréviation, même en français. Bref en aucun cas Argenton / Creuse ne signifie la même chose que Argenton-sur-Creuse (ne pas oublier non plus les traits d'union ici !) Car en Espagne et même en français, ce / est un séparateur, distingué de l'autre séparateur trait d'union qui est aussi utilisé pour juxtaposer deux termes mais avec une autre signification. L'idée qu'un moteur de rendu peut librement remplacer la ponctuation est totalement erronée, chacune a sa signification propre mais on ne peut pas la déduire de la seule façon dont cette ponctuation est codée puisque pour cela il faudrait coder ***aussi*** la sémantique. Dans ce cas c'est le schema qui n'est pas bon et on aurait du partir par exemple sur un tag name multi-valué alors que l'on est clairement parti sur une solution simpliste qui revient a tagguer pour le rendu : on veut que les 2 noms s'affichent côte à côte séparés par un caractère lambda sans rien a avoir a changer aux moteurs de rendu actuels... Il faut également prendre en compte tous les outils de recherche qui vont faire comment pour se dépatouiller avec des données formatés avec des demi-espaces insécables ou je ne sais quelle curiosité de la langue française ? Vladimir ___ 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] Gérer l'empilement de bâtiments
Salut, Intuitivement, je dirais en utilisant la balise layer=*… ? Cordialement, -- Mikaël Cordon, mickey86 Le 16 novembre 2012 09:22, Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net a écrit : Bonjour, je suis en train de corriger les erreurs de bâtiments se recouvrant. J'ai bien avancé (le grand Sud-Ouest est presque complètement traité ;) Merci Osmose ! Il me reste un type de bâtiments que je ne sais pas intégrer : les bâtiments empilés. Par exemple, un grand bâtiment en RdC et une portion plus petite s'élevant à partir du 1er. Cas d'espèce : la cité administrative à Bordeaux http://www.openstreetmap.org/?**mlat=44.84117mlon=-0.60185** zoom=17layers=Mhttp://www.openstreetmap.org/?mlat=44.84117mlon=-0.60185zoom=17layers=M avec un bâtiment de 3-4 étages sur toute la surface, au-dessus duquel s'élèvent deux tours de 20 étages. Les tours de contrôle des aéroports peuvent aussi faire partie de ces cas. Ma première option serait de ne considérer que l'emprise au sol et donc d'ignorer la partie tour. Ceci aurait néanmoins un inconvénient en ce que la représentation 3D qui pourrait par la suite être ajoutée ne serait plus possible/fiable. Des idées ? -- 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Carte Nokia, le sandwich est offert…
Salut les OSMeurs, Je viens de le voir passer, alors j’en fais profiter la communauté : Nokia sort sa carte : here.net Du vu et revu, sauf peut-être le « sandwich terrien » (sic) :) Cordialement, -- Mikaël Cordon, mickey86 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Carte Nokia, le sandwich est offert…
@Nicolas : Je me doutais que comme l’information n’était pas apparue ce jour dans la liste de diffusion que ce n’était pas un scoop… Confirmé ;) (Je n’utilise pas Flickr, ou en tout cas je n’ai pas remarqué) @Eric : Oui, c’est clair, il me semble que c’est Navteq qu’il y a derrière ça… Lorsque j’ai vu la carte, je me suis empressé d’aller voir mon quartier qui n’apparaît que sur OSM ; et j’ai eu le malsain bonheur de voir que le quartier était vide ! Ouf :P Cordialement, -- Mikaël Cordon, mickey86 Le 14 novembre 2012 12:41, Eric eric...@sfr.fr a écrit : Y'a vachement de consanguinité dans tous ces fournisseurs quand même, je retrouve chez bcp les mêmes erreurs (des chemins difficilement faisables en VTT représentés comme des routes goudronnées). Ca m'amuserait bien de voir un google car, une mappy car ou une navteq car essayer d'y passer :) C'est pas bien de copier. Le 14 novembre 2012 12:34, Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net a écrit : Le mercredi 14 novembre 2012 12:23:04 Mikaël Cordon a écrit : Salut les OSMeurs, Salut :-) Je viens de le voir passer, alors j’en fais profiter la communauté : Nokia sort sa carte : here.net C'est pas si nouveau, puisque Flickr utilise la carte de Nokia justement. -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Carte Nokia, le sandwich est offert…
@Pierre : C’est d’ailleurs cet article qui a été à l’origine de ce sujet :) Comme bien souvent dans ce genre d’article c’est dans les commentaires qu’on voit apparaître OSM, dommage. Ceci dit, il me semble que de plus en plus d’articles font mention d’OSM (dans le coprs de l’article), même si ça reste rare. Cordialement, -- Mikaël Cordon, mickey86 Le 14 novembre 2012 15:22, Pierre Béland infosbelas-...@yahoo.fr a écrit : Mikaël Cordon mikael.cor...@gmail.com Mercredi 14 novembre 2012 6h23 ** Nokia sort sa carte : here.net Il y a aussi cet article du Figaro où on oublie OSM dans la liste des concurrents. http://www.lefigaro.fr/hightech/2012/11/13/01007-20121113ARTFIG00640-nokia-lance-un-rival-de-google-maps-sur-pc-et-smartphones.php Pierre -- *De :* Mikaël Cordon mikael.cor...@gmail.com *À :* Discussions sur OSM en français talk-fr@openstreetmap.org *Envoyé le :* Mercredi 14 novembre 2012 6h23 *Objet :* [OSM-talk-fr] Carte Nokia, le sandwich est offert… Salut les OSMeurs, Je viens de le voir passer, alors j’en fais profiter la communauté : Nokia sort sa carte : here.net Du vu et revu, sauf peut-être le « sandwich terrien » (sic) :) Cordialement, -- Mikaël Cordon, mickey86 ___ 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Membre du DWG
Salut, mode sarcastique=on Félicitations pour ton poste de stagiaire dans le mirador d’OSM… /mode Plus sérieusement, ça fait froid dans le dos… Pour un projet communautaire, où, à mon avis, devrait régner un sentiment d’équité entre tous les membres, une autorité pyramidale semble bien établie, et semble aussi être révélée une fois que tu es dedans : je ne m’imaginais pas que tu serais aussi contraint une fois admis au sein du delgroupe/del clan. Bon courage, :/ -- Mikaël Cordon, mickey86 Le 13 novembre 2012 16:32, sly (sylvain letuffe) li...@letuffe.org a écrit : Salut, En une phrase : ça y est, je suis membre. En plusieurs : - je ne peux pas intervenir pour bloquer pour l'instant (mais ça devrait venir quand j'aurais un peu mieux compris comment ils fonctionnent) - je suis membre de la liste privée et du système de suivi par ticket des différents cas de problèmes repérés sur les données - Je suis admis mais n'ai aucune obligation de bloquer des contributeurs en france sous le prétexte du 2ème compte pour les imports (eux continuerons à le faire bien sûr) - je ne suis pas considéré comme représentant de quoi que ce soit, mais j'ai bien indiqué que nous avons notre propre groupe de gestion des problèmes, que sur cette liste ici des cas sont souvent remontés qu'il nous faut gérer et ça ne semble pas leur poser de problème que je sois le rapporteur de la situation avec nos conclusions, mais en gros, c'est pas parceque je me pointe en disant : Lui on ne le bloque pas car 20 personnes dernière moi me soutiennent que ça fera 20 voix à opposer aux leurs (juste 1) - Mauvaise nouvelle (que je ne comprends pas et j'ai demandé pourquoi sans réponses) : Ils ne veulent pas de christian. C'est un peu con, car j'ai l'intention de prendre des vacances des fois et si un cas doit être réglé rapidement, ben ça obligera à les contacter eux alors que christian aurait pû gérer quand je ne suis pas dispo, et moi quand il ne l'est pas. -- sly (sylvain letuffe) ___ 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] [Cartopartie] orientée vélo le samedi 27 Octobre 2012 à 13h45 au 27 Route de Bignoux 86000 Poitiers
Salut les mappeurs, Je me rappelle qu’il y a quelques jours/semaines VéloCité 16 souhaitait s’investir dans le projet OSM… Dans le mail ci-dessous, une invitation est lancée par VéloCité 86 pour une cartopartie dédiée aux vélos ce samedi 27 octobre 2012, sur Poitiers. Nous (APP3L et Vélocité 86) vous (Vélocité 16 et autres) attendons… Pas trop nombreux, malheureusement, au risque de manquer de place chez l’adhérent qui reçoit. Cordialement, -- Mikaël Cordon (mickey86), Secrétaire de l’APP3L. -- Message transféré -- De : App3l Contact cont...@app3l.org Date : 24 octobre 2012 22:46 Objet : [app3l] Cartopartie orienté vélo le samedi 27 Octobre 2012 à 13h45 au 27 Route de Bignoux À : ap...@freelists.org Velocity 86 organise une catopartie à laquelle se joint l'APP3L. Venez tous avec vos vélo (ou vos jambes), des crayons/papiers et éventuellement des ordinateurs ou des smartphones. Le lieu de rencontre se fera à 13h45 samedi 27 Octobre Au LIDL 27, Route de Bignoux 86000 Poitiers Ensuite, nous irons à 14h chez un adhérent de Vélocité 86 où nous disposerons d'un accès à internet et commencerons à travailler. Le LIDL n'est pas encore sur OSM, voilà le lien direct vers la carte pour le retrouver: http://www.openstreetmap.org/?mlat=46.58482mlon=0.367607zoom=16layers=M Vous pouvez préciser votre présence dans les commentaires de cette page: http://www.app3l.org/comment.php?comment.news.123 -- Charles BRISSET Trésorier de l'APP3L ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [politique] Réflexion sur la manière de choisir des règles
Je suis d’accord avec Sylvain pour mettre sur le Wiki les idées ; ça évite de perdre les idées dans la conversation (devoir chercher tout au long de la discussion où est exprimée l’idée de base). Par contre, je ne fais pas (encore) partie de OSMFR, mais je suis l’affaire et compte participer au débat… :) Cordialement, -- Mikaël Cordon (mickey86) Le 23 octobre 2012 14:35, Sylvain Maillard sylvain.maill...@gmail.com a écrit : Je serais d'avis qu'on mette tout ça bien au clair sur une page de Wiki, avec un bon argumentaire et des propositions d'améliorations, puis que la question soit soumise sur al liste de discutions osmf-talk: à priori les participants à OSM qui ont décider d'adhérer à la fondation, c'est justement ceux qui se sentent impliqués par les problématiques de gouvernance et de la direction à donner au projet, et c'est le seul endroit où on peut initier un vote qui impacterait directement les missions du DWG ! Sylvain Le 23 octobre 2012 14:26, sly (sylvain letuffe) li...@letuffe.org a écrit : On mardi 23 octobre 2012, Christian Quest wrote: Si ça finit en bazar, c'est bien qu'il y a un problème... sinon on serait rapidement d'accord, non ? Tout à fait, je dis juste qu'on peut peut-être en limiter le bazar si on accepte de commencer par du concret avec des propositions, comme une page wiki par exemple. Et puis, comme de toute façon tes tentatives n'ont rien donné, c'est qu'il faut tenter de changer l'angle d'attaque. Beaucoup de personnes ne réagissent que lorsqu'elles sont impactées. C'est bien dommage car cela laisse à un trop petit nombre le champ libre. Ce n'est malheureusement pas spécifique à OSM. Oui, et comme on ne peut pas y faire grand chose, prenons ceux qui s'expriment, tant qu'on a une porte de sortie lorsqu'il y aura problème pour remettre en cause les lois établies, ce qui est le cas de facto. -- 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 ___ 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] Source des données dans OSM
Bonjour, Je suivais cette affaire sans vraiment m’y impliquer, mais comme des solutions commencent à faire leur chemin ça m’intéresse un peu plus :) Le fait de raffiner par des sous-tags les sources me paraît être une bonne idée ; j’y vais de ma vision des choses : — source:type = official (reconnue juridiquement par OSM), base (une base de données non officielle), survey (le reste, les informations apportées par le contributeur lui-même) — source:ref = un identifiant donné à la source officielle — source:import = yes|no — source:bot = yes|no — source = informations sur la source si pas de source:type=* ni de source:ref=*, ou en complément des tags précédents Quant au fait que ce soit attaché au changeset ou à l’objet… Je n’ai pas d’avis tranché : — il est vrai que la redondance est très gênante (pour toutes les mêmes raisons que la redondance de données (qui n’est pas une référence) est un problème dans les bases de données relationnelles), mais finalement nécessaire pour bien discriminer les données émanant de telle ou telle source. — je trouve que — par l’intermédiaire des tags source*=* — dire qu’une donnée vient de telle source alors que ce n’est pas le cas peut être très gênant pour OSM et la source : imaginez qu’une certaine quantité de bâtiments tracés à la main soient attribuée au cadastre, la qualité de la source pourrait être remise en cause. Le contraire (une donnée de meilleure qualité attribuée à une source qui n’est pas très fiable) peut avoir les mêmes conséquences : booster l’utilisation d’une source peu fiable. C’est pourquoi mettre la source sur le changeset est dangereux. — les données émanant de plusieurs sources (source + modifications) complexifient énormément les choses et je n’ai pas encore d’avis. — JOSM n’est pas le seul moyen d’ajouter des données. Faire un patch pour JOSM c’est bien, ceci dit ce n’est pas la panacée… Et surtout dangereux de faire un patch sans aller plus loin : les utilisateurs de JOSM se sentiront en confiance (ils auront assez raison) mais cette confiance déteindra sur les contributeurs avec un autre éditeur. Et un contributeur confiant contribue beaucoup… Autre remarque qui va encore compliquer l’affaire : — il existe des données émanant de sources officielles qui ne sont pas géographiques (ou en tout cas pas précisément), or les sources sont attachées à des objets géographiques… Du coup on se retrouve à avoir des données géographiques dont la source n’est pas géographique. Par exemple, l’INSEE est une source de données administratives et non géographiques. — l’idéal serait d’avoir un attribut de source pour un tag… — cette remarque ressemble évidemment plus à de la masturbation intellectuelle, mais si ça peut faire naître une idée sensée… ;) Cordialement, -- Mikaël Cordon (mickey86) Le 23 octobre 2012 11:44, sly (sylvain letuffe) li...@letuffe.org a écrit : On lundi 22 octobre 2012, Mickaël Guéret wrote: Salut, est-ce qu'on pourrait conseiller d'utiliser le tag source comme 'namespace' (espace de nom ??) ? ex: - source:geometry = Bing 2012 - source:ref = survey - source:name = cadastre-dgi-fr source : Direction Générale des Impôts - Cadastre. Mise à jour : 2010 Pourquoi pas, toutefois, si j'avais à le faire, je pense que je ferais plusieurs changeset, par soucis de clarté, de simplicité pour moi même et de meilleur compréhension pour les autres. En plus, si je suis en train de relever des noms sur le cadastre, en général je ne fais presque que ça puisqu'il faut basculer de fond de carte, et dans ce cas là, je préfère valider mes changements de géométries d'abord, puis mettre les noms et valider. Mais sinon, je n'y vois aucun inconvénient, comme on le fait d'ailleurs parfois pour les objets. Bien que l'utilisation du tag source=* étant le plus utilisé, je pense que je mettrais quand même ce tag avec la source majoritairement utilisée et j'affinerais avec des source:name=google maps (j'déconne ;-) ) source:amenity=survey source:place=survey source:sac_scale=survey source:building=bing source:geometry=gps;bing Mais bon, ça fait un peu bulldozer quand même. -- 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [politique] Conditions demandées pour être membre du DWG
Fiou… Peste, choléra… ? Pour résumer (qu’on me dise si je me trompe) : tu dois bloquer les comptes qui contreviennent les règles du DWG tout en pouvant dire que tu es contre ce blocage… En terme de communication, y’a pas un problème… ? Cordialement, -- Mikaël Cordon (mickey86) Le 23 octobre 2012 12:38, sly (sylvain letuffe) li...@letuffe.org a écrit : Bonjour, (Le mail d'origine étant en anglais, et en correspondance privée, j'en fais une traduction simplifiée et adaptée, le respect de la correspondance privée étant important pour moi) J'ai donc une bonne et une mauvaise nouvelle, je commence par la bonne ? J'ai été contacté par F. Ramm et ils m'acceptent comme membre du DWG, j'ai eu droit à une pommade de bienvenue : vous feriez un bon membre de notre équipe La mauvaise, c'est que les conditions sont en contradictions avec celles que j'avais exposées dans ma profession de foi pour représenter la communauté française (bien sûr, c'est toujours cette histoire de 2ème compte) En bref, ça donne : - Ils souhaitent que je m'investisse dans le traitements de tous les type de problèmes dont s'occupe le DWG, que ça soit en France ou non. Bien qu'ils acceptent qu'étant plus efficace en France, ce sont ces problèmes que je serais amenés à régler en particulier/priorité. - La règle du 2ème compte obligatoire pour les imports cadastre est à imposer actuellement, mais ils acceptent que je puisse indiquer, tout en bloquant les gens, que je leur disent que je suis contre cette règle, que la communauté française est contre cette règle et que nous comptons, dans l'avenir y remédier lorsque des problèmes auront été réglés concernant les imports faits avec le même compte (l'idée des tags sur les changesets étant accepté sur le principe) - Dans tous les cas ou je n'accepterais pas la règle, je suis invité à en discuter avec eux, expliquer en quoi elle est inadaptée (ou absurde), rapporter un résumé de l'avis de la communauté française, et soit accepter de ne finalement pas l'appliquer et/ou trouver des solutions à l'avenir pour s'en passer, (Le 2ème compte pour les imports cadastre n'étant pas dans ce cas actuellement : ça, ok, on a compris, c'est répété tout au long du mail) - Le refus de rejoindre notre équipe leur serait compréhensible, je continuerais à être contacté (ou un autre français, ou la liste [ga]) pour la communication en français, mais c'est eux qui continueraient à bloquer. Vos avis ? Si à la lecture de ce résumé vous êtes énervés et que votre réponse s'apprête à impliquer Hitler ou les nazis, je vous recommande d'attendre un peu (on réfléchi mieux à tête reposée ;-) ) -- 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] lieux-dits
Moi aussi, j’en ai placé un bon paquet dans la région poitevine, d’ailleurs. Ils viennent en grande majorité du cadastre. Cordialement, -- Mikaël Cordon (mickey86) Le 16 octobre 2012 22:02, Cyrille Giquello cyrill...@gmail.com a écrit : Le 16 octobre 2012 21:18, Eric SIBERT courr...@eric.sibert.fr a écrit : 4) Concernant le tag place=locality, je l'utilise pour mapper les lieux-dits par exemple Vallée de machin-chose, Plaine des bidules. Des lieux inhabités mais disposant tout de même de leur propre nom. Est-ce que ce tag convient ? Je fait de même. Moi, ça me convient. Éric -- Cyrille. ___ 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] lieux-dits
Il est vrai que je n’avais pas percuté sur « vallée » ou « plaine »… Il me semble qu’effectivement ça ne s’appliquerai pas, ou alors il faut une liaison hiérarchique pour les inclusions. Moi, je parlais des lieux-dits « La Pièce de Machin », « Le Clos de Bidule » et autres « Le Chatrain » ou « Le Chiron Poulet » (un des plus amusant). Je tiens à faire remarquer que certains de ces lieux-dits se nomment « Vallée… » ou « Plaine… » et sont bien des lieux-dits notés place=locality ; comme « La Vallée de la Digue » qui est bien une petite vallée mais trop petite pour contenir un autre lieu-dit. Ce dernier paragraphe étant, évidemment, pour souligner la non-systématisation de l’association « toponymie-tag ». Cordialement, -- Mikaël Cordon (mickey86) Le 17 octobre 2012 14:10, Pieren pier...@gmail.com a écrit : 2012/10/17 Mikaël Cordon mikael.cor...@gmail.com: Moi aussi, j’en ai placé un bon paquet dans la région poitevine, d’ailleurs. Ils viennent en grande majorité du cadastre. locality, c'est pour les lieux-dits inhabités mais tout ce qui inhabité n'est pas forcément un locality. Beaucoup d'îles sont inhabitées et ça n'en fait pas automatiquement des locality. Une vallée ou une plaine ou une forêt n'est pas un lieu-dit. C'est un espace trop vaste et qui peut contenir lui-même une multitudes de lieux-dits. Alors comment vous allez hiérarchiser le locality de la vallée et les locality / lieux-dits qui en font partie ? Un lieu-dit ne peut pas en contenir d'autres et se limite à un espace intra-communal, ce qui est rarement le cas pour une plaine ou une vallée. Pieren ___ 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] Création du Groupe d'accompagnement aka Cadastre task force - Liste privée ou liste publique ?
J’ai suivi un peu le sujet. Jusqu’ici, je n’avais pas tellement d’avis sur la publicité ou non de cette liste… Désormais, je me dis que si un groupe de gens veut discuter de façon privée sur comment prendre contact avec un nouveau contributeur, l’aider et éventuellement rétablir des erreurs qu’il a pû faire, on ne l’empêchera pas : il y a une multitude de façons de se contacter en dehors des listes de diffusion. D’autre part, ce groupe, qui tente de prendre en charge les contributeurs « saccageurs » (dans le sens défini plusieurs fois dans ce sujet : « qui, clairement, nuit aux contributions de la communauté et à la base OSM »), pourrait agir sans en référer à quiconque — ce qui est son droit en tant que groupe de contributeurs de la communauté — a décidé d’être clair sur ses intentions. Moi, je ne vois aucun problème à ce que la liste soit privée, d’autant qu’il a été plusieurs fois question que l’opacité pourra être changée si nécessaire. Et c’est moi qui dis ça, qui, habituellement prône l’ouverture totale :) De plus, si j’avais plus de temps, je m’engagerais dans ce groupe, mais pas pour l’instant. Cordialement, -- Mikaël Cordon (mickey86) Le 15 octobre 2012 16:51, Pieren pier...@gmail.com a écrit : 2012/10/15 Sylvain Maillard sylvain.maill...@gmail.com: je suis plutôt pour l'ouverture de la liste, avec éventuellement une ré-évaluation d'ici quelques temps si il y a vraiment beaucoup d'inscrtis: Ce que je voulais dire par ouverture, c'était dans le sens d'avoir au minimum accès aux archives sans avoir à s'inscrire comme c'est le cas, par exemple, pour la liste de l'asso. Je n'ai rien contre une modération dans les inscriptions pour éviter les hors-sujets (genre untel n'utilise pas le bon tag) ou les polémiques sur le rôle de ce groupe, discussions légitimes mais qui devraient se dérouler sur la liste talk-fr. Pieren ___ 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] Bâti et éoliennes
Une éolienne étant fixe, est donc immeuble… Sauf erreur de ma part, il me semble que le corps de l’éolienne est creux et que les gens de la maintenance grimpent à l’intérieur. Dès lors qu’on peut entrer dans un immeuble, je le considère comme un bâtiment ; « building » m’apparaît donc adapté. Se pose alors la question des éoliennes plus petites, dans lesquelles on ne peut pas entrer. D’autre part, question : modélise-t-on l’orientation des éoliennes ? Je ne sais pas si les éoliennes ont une orientation fixe ou non. Cordialement, -- Mikaël Cordon (mickey86) Le 16 octobre 2012 05:06, Philippe Verdy verd...@wanadoo.fr a écrit : Ce que je veux dire c'est que les bâtiments du cadastre tout petits de moins de 5 mètres de large dans leur plus grande dimension, pourraient être traités dans une liste à part, à valider de meilleure façon que de les importer par défaut en tant que building (de quoi mieux satisfaire le DWG qui nous reproche ces imports non qualifiés). Cela ne gènerait pas la travail sur les rues et routes, et cela permettrait un travail aussi en plusieurs phases, ces petites constructions nécessitant une visualisation (imagerie Bing) au minimum pour les identifier. Les bâtiments ronds de plus de 5 mètres ont de grrandes chances d'être des châteeaux d'eau ou des tours d'émetteurs, ils sont très repérables et essentiels au repérage sur le terrain, on doit les mettre dans OSM, mais eux aussi devraient être mieux qualifiés. Ils sont assez peu nombreux pour qu'on les mette clairement à part pour qu'ils soient identifiés en priorité même sur les autres constructions. Les petits bâtiments rectangulaires de moins de 5 mètres sont effectivemnt assez souvent des postes de transformation ou petits locaux techniques similaires. Dans certains cas (quand on les trouve dans un terrain résidentiel à côté d'un autre bâtiment) ce sont souvent des garages ou appentis. En milieu rural ce peuvent être des puits. En ville, ce peuvent être des kiosques, des toilettes publiques, des abris bus/taxi en dur. Dans les gares, difficile de savoir ce que c'est entre les bâtiments techniques, postes de transformation, abris, kiosques... Mais je crois que les gares sont déjà très bien cartographiées dans OSM et tout y est bien répertorié, simpelment car ce sont des lieux connus et très visités. Quand le milieu urbain est dense, avec des tas de bâtiments quasi jointifs, l'import en tant que building ne me choque pas, car les immeubles sont à usages multiples et changeants et ce n'est pas plus mal de devoir ensuite les qualifier en positionnant dessus les POIs pour les commerces, le reste étant par défaut résidentiel (les zones landuse peuvent aider à savoir qu'on est en zone résidentielle ou en zone industrielle et commerciale, souvent en périphérie des villes, avec des bâtiments souvent très différents en majorité en constructions métallique plus légère, plus espacés, rarement jointifs entre eux, et avec des tas de parkings autour). Mais comme on travaille normalement sur des imports localisés par quartiers à peu près homogènes, les classifications par défaut pour le gros des constructions peuvent être différentes. Maintenant je DWG ne devrait pas être réellement gêné si les données importées et intégrées n'ont qu'une partie des données qualifiantes. Si elles sont correctes géométriquement et donnent une info utile, le reste sera complété aussi au fur et à mesure par la méthode incrémentale inhérente au projet collaboratif. Il me semble en revanche que ce qu'on demande c'est déviter les doublons et s'assurer de la localisation (donc le bon calage initial des feuilles cadastrales, en vérifiant aussi le calage des l'imagerie, et vérifiant les points géodésiques). Et ne pas laisser des intersections des bâtiments intégrés avec les voies existantes pour que cela soit cohérent en terme de positions relatives des objets (souvent c'est une rue ou route qu'il faudra ajuster avec plus de précision en zone urbaine). Sinon le positionnement ultérieur des POIs sera pénible ou ambigu, ou générera ses propres erreurs (si on doit recaler les bâtiments et rues, que faire des POIs qui ont été mis dessus par collaboration incrémentale ?). Le 15 octobre 2012 22:31, Romain MEHUT romain.me...@gmail.com a écrit : Le 15 octobre 2012 22:29, Rainer Kluge rklug...@web.de a écrit : 15/10/2012 16:35 Philippe Verdy: Un truc rond qui fait 4 mètres de large n'a aucune chance d'être un bâtiment ou une tour, quel qu'il soit. Et quand c'est carrée, comme celui là: http://www.openstreetmap.org/browse/way/81551822 ? Ce serait pas un poste de transformation haute tension? Il m'arrive d'en trouver qu'y soit cadastré. Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr
Re: [OSM-talk-fr] 850000 membres... et autres stats...
Même si on suspecte un biais, les +1000 km / jour de route, par exemple, restent impressionnant, satisfaisant et motivant, je trouve. Cordialement, -- Mikaël Cordon (mickey86) Le 15 octobre 2012 11:09, Christophe Merlet red...@redfoxcenter.org a écrit : Le lundi 15 octobre 2012 à 10:38 +0200, Christian Quest a écrit : En préparation de notre réunion avec l'IGN, j'ai refait quelques statistiques... Il y a un an, on avait environ 48 membres, cela fait une croissance de 77%. Ce sont les compte ouverts, mais pas forcément actifs. Le rythme s'est clairement accéléré début juillet. Le nombre de contributeurs actifs a lui aussi augmenté pour passer d'environ 2000/jour à actuellement 3000/jour et la barre des 2/mois est désormais systématiquement franchie depuis début octobre. Pour la France, on est toujours entre 200 et 250 contributeurs actifs quotidiennement, ce qui nous place en second derrière l'Allemagne et devant la Russie. Cette forte augmentation de contributeurs n'a bien sûr rien à voir avec la nécessité de posséder plusieurs comptes pour faire des imports de données Librement, -- Christophe Merlet (RedFox) ___ 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] Profession de foi de sly à la candidature au poste de membre du DWG
+1 ! Le 26 septembre 2012 09:05, Vincent Pottier vpott...@gmail.com a écrit : +1 Le 26/09/2012 00:32, Vincent Privat a écrit : Le mien également :) Le 25 septembre 2012 23:35, Emilie Laffray emilie.laff...@gmail.com a écrit : Tu as mon soutien On Sep 25, 2012 6:52 PM, sly (sylvain letuffe) li...@letuffe.org wrote: Bonjour, Suite à ma proposition ici : http://lists.openstreetmap.org/pipermail/talk-fr/2012-September/048217.html Je confirme présenter ici même ma candidature au poste de membre du DWG http://wiki.openstreetmap.org/wiki/DWG à la communauté française. Tout en rappelant que même si l'on m'accepte ici à ce poste, le DWG peut toujours me refuser. Rappelons qu'occuper ce poste devrait comprendre : - La possibilité de discuter avec les autres membres du DWG avec plus de chance d'être écouté que le reste des contributeurs - La possibilité d'empécher un utilisateur OSM de continuer à éditer (blocage) exemple : http://www.openstreetmap.org/user_blocks/248 Voici un bref CV de qui je suis : http://wiki.openstreetmap.org/wiki/User:Sletuffe Merci de noter en outre que je ne suis pas membre de l'association osm-fr et que je ne compte pas le devenir. == Discuter == En me présentant à ce poste, j'entends surtout présenter auprès du DWG les attentes, inquiétudes et spécificité des autres membres de la communauté française au regard des imports du cadastre tout particulièrement, mais aussi d'autre imports ayants lieu sur le territoire français (Métropole + DOM/TOM) (imports étant défini par ce que le DWG appel import et sur lesquels ils entendent imposer des règles par des blocages) Ce que je souhaite mettre au service de la communauté, c'est mon franc parlé, ma capacité d'expression en anglais et ma capacité à relayer les demandes discutées sur la liste talk-fr, les forums français, ou tout moyen de communication utilisé par la communauté de contributeurs français. Je m'efforcerais de faire des comptes rendus de ce qui se dit en haut et ma position pourra évoluer au grè des discussions et conclusions de la communauté française. == bloquer == Bloquer des contributeurs, ce ne sera ni ma force ni mon plaisir. Je ne souhaite d'ailleurs jamais le décider moi même, mais uniquement être le doigt qui clic, suite à une décision majoritaire de la communauté fr elle même, ou du cadastre task force si celui-ci m'est désigné. (Sauf cas d'urgence avérée dont la définition sera laissée à la communauté sur acte de vandalisme évident) Il est donc hors de question que je sois celui qui fasse tout le (sale) boulot (surveillance IRC, outils,...) , ni et celui sur qui on tape parce que je n'ai pas bloqué à temps de mon propre chef ou par excès de blocage alors que le dit blocage fût demandé par l'instance ci-avant évoquée. En tout état de décision de la communauté française ou cadastre task force, je m'engage à ne jamais bloquer un utilisateur en dehors du territoire français, défini par la relation n°11980 (http://www.openstreetmap.org/browse/relation/11980) Je m'engage à ne jamais bloquer un utilisateur sans que quelqu'un lui ait déjà envoyé un message lui expliquant qu'il y a un problème (moi ou pas) == rupture de contrat ;-) == Je ne m'engage sur aucune durée, je suis libre de quitter ce poste à tout moment et sans préavis La communauté, sur consultation d'une majorité d'exprimés (à définir ?) peut me demander à tout moment de quitter ce poste fin ps: p'tain de prise de tête ! On dirait que j'ai fais ça toute ma vie ps2: si pas d'accord, modifications souhaités, me répondre, je ne suis pas borné, mais au service de la communauté ;-) -- 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing listTalk-fr@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nom commun à plusieurs polygones
Salut, Le 22 août 2012 10:05, Plop76 vaujani...@free.fr a écrit : Philippe Verdy a écrit : Le 21 août 2012 21:38, Plop76 vaujani...@free.fr a écrit : Bonjour, En essayant de nommer un bois qui est représenté par deux polygônes adjacents avec des tags incompatibles (http://www.openstreetmap.org/**browse/way/177031065http://www.openstreetmap.org/browse/way/177031065et http://www.openstreetmap.org/**browse/way/177031066http://www.openstreetmap.org/browse/way/177031066), je vois que Mapnik affiche deux fois le nom, ce qui me semble inutile. Est-ce la façon correcte de tagguer (en laissant se débrouiller les logiciels de rendu) ? J'ai pensé à faire un multipolygon avec le tag name dessus, mais cela ne respecterait pas le wiki qui dit que si la relation multipolygon a des tags, ceux des polygones extérieurs doivent être ignorés. C'est pour tant ce qu'il faut faire. Le nom commun pour l'ensemble des polygone va dans la relation multipolygone. Et tu fais une mauvaise interprétation de ce que dit le wiki : ce qu'il faut lire c'est que si les polygones adjascents peuvent avoir leur propre nom, cela ne veut pas dire qu'ils le perdent parce qu'un mutlipolygone qui les inclut en porte un autre. Ce que cela signifie c'est que le multipolygone, s'il definit un nom adopte ce nom pour l'ensemble qu'il représente, indépendamment des noms qui peuvent être définis pour ses composantes. En revanche si les composantes portent le même nom que l'ensemble, le nom donné aux composantes est inutile, souvent, mais pas toujours (par exemple une ville et un canton portent chacun un nom même s'il est identique dans le champ name (mais les autres tags indiquent que ce sont en fait des objets différents par nature, bien qu'homonymes : la ville ne perd pas son nom parce qu'un canton homonyme prend le même nom). Quand je lis : «There is more than one outer way: The relation has tags Use the relation tagging. Ignore anything on the ways.» Je comprends que si je mets le nom dans la relation, les tags wood des composantes vont être ignorés par exemple (Ça changerait rien avec Mapnik de toute façon...) En fait ignore anything on the ways voudrait dire d'ignorer tout ce qui est incohérent avec les tags sur la relation ? Je comprends le contraire… « The relation has tags » : la relation contient des attributs « Use the relation tagging » : utilise les attributs sur la relation. « Ignore anything on the ways » : ignore tout en ce qui concerne les chemins (les polygones). En tout cas, je ne sais pas quel logiciel te dis ça, mais ignorer des attributs, ça me paraît un peu culotté. __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr Cordialement, -- Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bilan opendata RATP... (Christian Quest)
Tant qu’à être précis… Devant les ponctuations hautes, on ajoute l’espace insécable ; entre les guillemets français et le texte qu’ils entourent il faut aussi cette espace insécable, les puristes préféreront l’espace fine insécable. Ceci dit, peut-être qu’on peut considérer que le type d’espace, voire même les espaces autour des ponctuations relèvent de la mise ne forme et pas de la donnée, ainsi pourrait-on laisser le soin de remplacer ces mises en forme aux moteurs de rendu ? Le 16 août 2012 08:07, Ista Pouss ista...@gmail.com a écrit : Peut être que l'on peut dire Une espèce d'espace ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Cordialement, -- Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Collecte terrain avec tablette Android sans 3G
OSMTracker est dispo pour une Galaxy Tab 7, c’est très intéressant comme appli, c’est ce que j’utilise :) Seulement dans le « cahier des charges » il y a besoin que la trace s’affiche sur une carte sans 3G… Or OSMTracker nécessite la 3G ou en tout cas Internet pour afficher la carte. Le 7 août 2012 09:47, Fabien marbolan...@gmail.com a écrit : Le 5 août 2012 17:46, Emmanuel Dewaele emmanuel.dewa...@geovelo.fr a écrit : Bonjour, Nouvellement possesseur d'une tablette sous Android, j'apprécie de pouvoir utiliser OsmAnd, avec la possibilité d'embarquer les données routières sur l'appareil pour consulter la carte sans connexion, puisque l'appareil ne peut se connecter qu'en Wifi. Je suis à la recherche d'un moyen de l'utiliser pour prendre des notes sur le terrain, sachant que dans OsmAnd on peut insérer des points d'intérêt OpenStreetBugs, système quelque peu rudimentaire mais plutôt pratique, mais l'enregistrement de signalements OpenStreetBugs nécessite d'avoir une connexion... Qui a une idée ? Existe t'il une autre application sur Android pour prendre des notes sur le terrain avec la carte stockée sur l'appareil (a priori, je n'en ai pas trouvé) ? Ou vaut t'il mieux tenter d'adapter OsmAnd ? Emmanuel OSMTracker n'est pas disponible dans le Google Play des tablettes ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Collecte terrain avec tablette Android sans 3G
+1 Moi aussi, la carte ne me sert pas, au pire j’ai OSMAnd qui reste en tâche de fond et je bascule dessus si j’ai besoin, et OSMTracker reste en tâche de fond une fois sur OSMAnd… Le 7 août 2012 10:38, Fabien marbolan...@gmail.com a écrit : Il est vrai que sans 3G le mode carte ne sert pas mais, personnellement, je ne me sers presque jamais du mode carte vu que je mets le tracé et j'ajoute les points que je vois. A voir avec l'OP, Fabien Le 7 août 2012 10:34, Mikaël Cordon mikael.cor...@gmail.com a écrit : OSMTracker est dispo pour une Galaxy Tab 7, c’est très intéressant comme appli, c’est ce que j’utilise :) Seulement dans le « cahier des charges » il y a besoin que la trace s’affiche sur une carte sans 3G… Or OSMTracker nécessite la 3G ou en tout cas Internet pour afficher la carte. Le 7 août 2012 09:47, Fabien marbolan...@gmail.com a écrit : Le 5 août 2012 17:46, Emmanuel Dewaele emmanuel.dewa...@geovelo.fr a écrit : Bonjour, Nouvellement possesseur d'une tablette sous Android, j'apprécie de pouvoir utiliser OsmAnd, avec la possibilité d'embarquer les données routières sur l'appareil pour consulter la carte sans connexion, puisque l'appareil ne peut se connecter qu'en Wifi. Je suis à la recherche d'un moyen de l'utiliser pour prendre des notes sur le terrain, sachant que dans OsmAnd on peut insérer des points d'intérêt OpenStreetBugs, système quelque peu rudimentaire mais plutôt pratique, mais l'enregistrement de signalements OpenStreetBugs nécessite d'avoir une connexion... Qui a une idée ? Existe t'il une autre application sur Android pour prendre des notes sur le terrain avec la carte stockée sur l'appareil (a priori, je n'en ai pas trouvé) ? Ou vaut t'il mieux tenter d'adapter OsmAnd ? Emmanuel OSMTracker n'est pas disponible dans le Google Play des tablettes ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Mikaël Cordon ___ 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 -- Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Réf.: Re: Suivi des opérations du Redaction bot
Pour le suivi des suppressions : http://harrywood.dev.openstreetmap.org/license-change/botprocessing.php?zoom=7lat=46.76126lon=2.66199layers=00BFTTFF C’est un autre calque du site de suivi. Le 18 juillet 2012 09:24, Etienne Trimaille etienne.trimai...@gmail.com a écrit : Est-ce que je suis le seul à penser que le bot a été plus ravageur que prévu ? La relation de ma commune a été supprimée, alors que j'étais le créateur initial. Idem pour les bornes incendies : j'avais rajouté un certain nombre de points sur ma commune. Un bot qui a refusé la licence avait modifié juste un tag. Et la je vois que mes points ont disparus ! C'était long à cartographier ces équipements. Les validateurs de JOSM/Geofabrik Tools étaient ok avec les versions (retour à une version antérieur). Mais la, c'est carrément une suppression. Existe-il un outil pour voir les objets supprimés ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Cordialement, -- Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOSM : pas de truc pour trackpad ?
Ton mouvement ne fonctionne pas chez moi (GNU/Linux + KDE, Synaptiks)… Le mouvement que j'ai trouvé n'est pas si compliqué, en revanche je l'ai peut- être mal expliqué. Je retente : Le mouvement pour déplacer la carte JOSM est sur la même base que le clicdrag pour déplacer des objets (une icône ou pour copier un fichier avec le pointeur…) à la différence que le clic se fait avec deux doigts. Cordialement, -- mickey86, Mikaël Cordon Le dimanche 13 mai 2012 22:28:04 Philippe Verdy a écrit : Pas très facile à faire comme mouvement... Personnellement je pense qu'il est plus facile de poser un doigt, le laisser posé pendant qu'on pose un second doigt, pour relever le premier sans lacher le second, qui sera utilisé pour glisser. Sur une échelle de temps, lue de haut en bas, tandis qu'horisontalement on visualise les doigts posés, ça donne dans un temps assez court mais avec une gestuelle très facile à faire avec deux doigts de la même main (par exemple index et majeur, ou pouce et index), et c'est compatible pour gauchers ou droitiers : : :O :O :O O :O O :O :O Rendu à ce point, ce n'est encore considéré que comme un clic droit non relaché (à la position du second doigt). - Si on relache tout de suite ce second doigt, c'est comme un simple clic droit de souris qui active le menu contextuel sur l'objet tapé). - On peut continuer à glisser le second doigt pour faire un glissement (dans JOSM ce serait faire glisser toute la carte et non pas déplacer un objet sur le fond de carte). Ça marche bien à condition que la tablette tactile détecte les entrées multitouche (ce que suppose aussi la gestuelle que tu proposes). Sinon, autant appuyer sur une touche du clavier en même temps qu'une tape simple sur la tablette. -- Philippe. Le 13 mai 2012 11:24, Mikaël Cordon mikael.cor...@gmail.com a écrit : Salut, Avec un autre contributeur (Amargein), on s'est posé la question pour naviguer dans la carte de JOSM avec un trackpad d'ordi portable… On a longtemps cherché, les meilleures solutions du moment fussent : — installer le plugin « touchscreenhelper » et activer le mode déplacement en cliquant dessus (pas de raccourcis clavier possible apparemment) — brancher une souris USB et utiliser classiquement le clic droit de la souris pour naviguer… Désormais, j'ai une autre solution, la solution qu'on attendait, une combinaison de taps permettant d'émuler le clic droit souris et déplacer la carte : — sur le trackpad, à la vitesse du double-clic : clic-droit, clic-gauche (sans relâcher) et glisser ; — soit donc sur mon trackpad en deux mouvements à la vitesse du double-tap : (1) tap-deux-doigts, (2) reposer un doigt et glisser. ___ 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] JOSM : pas de truc pour trackpad ?
Salut, Avec un autre contributeur (Amargein), on s'est posé la question pour naviguer dans la carte de JOSM avec un trackpad d'ordi portable… On a longtemps cherché, les meilleures solutions du moment fussent : — installer le plugin « touchscreenhelper » et activer le mode déplacement en cliquant dessus (pas de raccourcis clavier possible apparemment) — brancher une souris USB et utiliser classiquement le clic droit de la souris pour naviguer… Désormais, j'ai une autre solution, la solution qu'on attendait, une combinaison de taps permettant d'émuler le clic droit souris et déplacer la carte : — sur le trackpad, à la vitesse du double-clic : clic-droit, clic-gauche (sans relâcher) et glisser ; — soit donc sur mon trackpad en deux mouvements à la vitesse du double-tap : (1) tap-deux-doigts, (2) reposer un doigt et glisser. Cordialement, -- mickey86, Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Encore du SVG
Excellent… Ne serait-ce que la carte interactive et ses différentes projections : je me suis amusé avec pendant plusieurs minutes :) Le 6 mars 2012 20:30, yvecai yve...@gmail.com a écrit : ** Effectivement ! Le 06/03/2012 20:01, Ab_fab a écrit : Prometteur : http://kartograph.org/ -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing listTalk-fr@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Cordialement, -- Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Traduction des toponymes et lieux assistée par Wikipedia
salut, Juste une idée qui m’a traversé l’esprit quand j’ai vu passer les mots « traduction en plusieurs langues »… Il existe un projet/site de traduction communautaire basé sur une solution libre : Tatoeba (http://tatoeba.org/) Actuellement, les traductions ne concernent par les toponymies, mais peut-être qu’il y a un sujet à développer autour de ça ? Qu’en pensez-vous ? Le 9 février 2012 11:18, Vincent de Chateau-Thierry v...@laposte.net a écrit : De : Pieren 2012/2/9 Ab_fab (et qui plus est inutile puisque dans la même langue) Cet outil ne devrait pas ajouter de name:fr en France. C'est contre-productif et dangereux (doublon, risque de dichotomie, à l'encontre des pratiques actuelles et des éditeurs). Moi, je serais partisan de les supprimer systématiquement dans l'hexagone. Dans l'hexagone d'accord, mais peut-être pas au bord :-) Taginfo France compte un millier de name:fr : http://taginfo.openstreetmap.fr/keys/name:fr#values et les 3 valeurs les plus récurrentes sont sur des objets frontaliers : Frontière franco-suisse, Le Rhin et La Moselle. == début de HS == Cela dit, on peut de demander si sur une limite administrative, le tag name tout court est pertinent. Pour moi non, il devrait être déduit des noms des emprises administratives auxquelles il participe, et pas stocké en dur. Libre à chaque utilisateur de construire le nom qu'il veut, dans la langue qu'il veut, et avec le niveau administratif qu'il souhaite. == fin de HS == 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 Cordialement, -- Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Google maps condamné en France pour abus de position dominante
Je viens de voir également cet article sur FranceTV.fr et le terme « libre » dans cette situation m’a également choqué. Pieren m’a juste devancé de quelques minutes :) Le 1 février 2012 15:32, Pieren pier...@gmail.com a écrit : Le tribunal de commerce de Paris estimant que Google Maps fausse la concurrence en fournissant son service gratuitement, a condamné la société Google à 500.000€ de dommages et intérêts au bénéfice de la société plaignante Bottin Cartographes (et 15.000€ d'amende). Un porte-parole de Google s'exprime en réaction pour dire qu' un outil cartographique de haute qualité, libre, et gratuit est bénéfique tant pour les internautes que pour les propriétaires de site web. Le terme libre a été aussitôt corrigé par Camille Gévaudan dans son billet sur ecrans.fr ( http://www.ecrans.fr/Google-Maps-condamne-en-France,13992.html) et n'a pas raté - encore une fois - une occasion de citer OpenStreetMap. Bravo et merci Camille. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Cartographiquement, -- Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] fdg près de Poitiers ???
Salut, Je suis de Poitiers et j’ai des collègues qui habitent tout près de l’endroit où apparaissait ce fameux « fdg ». Je leur ai demandé si ça leur évoquait quelque chose, mais personne ne sait d’où ça vient ni à quoi ça pourrait correspondre. Donc, je pense que l’information était soit une erreur ou une annotation personnelle mal « taguée ». Le 28 novembre 2011 17:37, Maetma 91 maetm...@gmail.com a écrit : Le 28 novembre 2011 17:34, Vincent Pottier vpott...@gmail.com a écrit : Le 28/11/2011 16:57, Marc SIBERT a écrit : Testé rapidement sur la XAPI de Mapquest sans succès : http://open.mapquestapi.com/**xapi/api/0.6/node[name=fdg]http://open.mapquestapi.com/xapi/api/0.6/node%5Bname=fdg%5D http://open.mapquestapi.com/**xapi/api/0.6/way[name=fdg]http://open.mapquestapi.com/xapi/api/0.6/way%5Bname=fdg%5D http://open.mapquestapi.com/**xapi/api/0.6/relation[name=**fdg]http://open.mapquestapi.com/xapi/api/0.6/relation%5Bname=fdg%5D en plus cette xapi n'aime pas les *. A voir ce soir sur un planet en sqlite... A+ Pas trouvé sur ma base France en local (qui n'est pas toute fraîche : ~ 10 jours) avec SELECT osm_id, name FROM france_polygon WHERE ST_WITHIN(ST_SetSRID(ST_POINT(**0.39928795776361, 46.519490016171),4326), way) -7377;Vienne -8652;Poitou-Charentes -1662877;Poitiers -140475;Nouaillé-Maupertuis 41785320; Une nouvelle forme d'OVNI ? -- Les tuiles en question dataient du 5 novembre. Après avoir forcé un petit rafraichissement tout est rentré dans l'ordre. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Cordialement, -- Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Wacom Bamboo
Bonjour, Personnellement j’ai une tablette graphique Wacom Graphire4 que j’ai depuis des années, et je dois dire que placer des points avec la tablette sous JOSM c’est très confortable, précis et rapide, en revanche ça prend de la place sur le bureau et il faut tout de même avoir une main à proximité du clavier pour les touches de raccourcis. Le 4 octobre 2011 09:56, hams...@suna.fdn.fr a écrit : Le 04/10/2011 09:41, Fanny Schertzer a écrit : Bonjour, Je suis nouvelle sur cette liste, sur OSM un peu moins. Pour me présenter rapidement, je mappe surtout les routes de France et quelques POIs au gré de mes déplacements. J'ai une vieille tablette graphique Wacom qui ne convient pas vraiment pour éditer, je travaille surtout à la souris et au trackpad, sous JOSM et Potlatch. Il y a une Bamboo Fun Small en vente flash aujourd'hui sur http://qoqa.ch et je voudrais savoir si certains d'entre vous connaissent, et ce qu'ils en pensent pour la carto. pour moi la question n'est pas de savoir si c'est pour de la carto ou autre mais de savoir pour quel type de graphisme pour dessiner, c'est a dire faire des traits avec tout le travail des courbes et la souplesse du poignet qui correspond au dessin artistique, les tablettes graphiques sont un tres bon outil quand on edite OSM on ne fait que placer des points, le travail n'est pas la ligne et l'esthetique de la courbe mais bien de viser precisement des points, et pour ce travail la rien de tel que la souris je pense que les ecrans tactiles sur lesquels on pointe avec un stylet ont des chances d'etres efficaces, mais a condition que le stylet permette un pointage precis, au pixel pres, mais dans ce qui existe (genre ipad) on a pas cette precision __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr Cordialement, -- Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Reportage TV : demande de conseils
Salut voisin ! Je ne sais pas si ça peut t’aider, mais pour appuyer un argument ou un autre, sur Poitiers, suite à l’article de Centre-Presse « Des GPS toujours perdus dans la ville » [1], nous (APP3L[2]) avons contacté Centre-Presse pour donner écho à cet article qui nous a fait doucement rigoler : « L'association qui donne des ailes aux GPS » [3]… [1] L’article raconte que depuis que le centre ville de Poitiers a changé (sens de circulation et fermeture à la circulation) le 1er septembre 2010, aucune carte commerciale équipant les GPS-routiers n’était à jour encore le 30 juillet 2011 (et d’ailleurs toujours pas aujourd’hui)… L’article n’est plus disponible gratuitement, dommage. [2] Association Poitevine pour la Promotion de Linux et des Logiciels Libres [3] http://www.centre-presse.fr/article-166567-l-association-qui-donne-br-des- ailes-aux-gps.html … pour l’instant encore gratuit. Le lundi 26 septembre 2011 20:09:24, Pierre-Alain Dorange a écrit : Bonjour, Suite à un article de presse local (Charente Libre) sur mon cas et ma passion de la cartographie (et d'OSM bien sur) une journaliste de France 3 M'a contacter pour faire un petit documentaire de 3 minutes sur mon cas. Si j'ai bien compris, il s'agit de mettre en valeur des gens et leur passion et de montrer que c'est possible... Bon le sujet sera OSM à Cognac, la journaliste veut me voir travailler sur site (j'ai choisit un quartier populaire que je connais pas trop et ou il faut que je fasse des vérifications) et elle voudrait montrer le process : relevé sur le terrain (j'ai pas de GPS je fais tout avec WalkingPapers, photos, ipad, etc...) et puis la saisie ensuite dans OSM. Si vous avez des conseils, des pistes, des trucs a absolument pas oublier ou d'autres a cacher ;-) Merci. L'article : http://www.charentelibre.fr/2011/08/17/militant-a-la-rue-par-passion,10 50372.php Je suis d'avance désolé pour les termes que le journaliste m'attribu en disant que jai réalisé la carte de cognac libre... c'est bien sur un travail collectif, même si sur Cognac je suis quasiment le seul actif depuis 2 ans. Cordialement, -- Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] admin_level = 9
J’ajouterais une méfiance : il arrive que les codes postaux ne correspondent pas aux limites administratives… Il existe des communes dans la Vienne (86) ayant un code postal commençant par 37 (Indre et Loire) pour des raisons de proximité de centre de tri (ceci est sûrement valable ailleurs que dans la Vienne). Par exemple : la commune de Buxeuil [1] se trouvant géographiquement dans la Vienne (86) a pour code INSEE 86042, et pour code postal 37160 (37 — Indre et Loire). [1] http://www.openstreetmap.org/?lat=46.97105lon=0.69518zoom=16layers=M Il existe des bizarreries (probablement d’ordre historique et qui perdurent) qui pourraient mettre le « wise » dans nos théories bien carrées :) Le mardi 13 septembre 2011 17:36:09, Pieren a écrit : 2011/9/13 sly (sylvain letuffe) sylv...@letuffe.org: Le code postale d'un bâtiment à pour valeur celui de la commune dans laquelle il se trouve, sauf s'il existe un polygone administratif (boundary=administrative) entièrement contenu dans la commune et ayant un tag addr:postcode ou s'il porte directement un code postal. En gros : plus c'est petit, plus ça a raison Ca ne peut fonctionner que si les découpages administratifs supérieurs à 8 (arrondissements, quartiers) correspondent aussi aux découpages postaux. C'est le cas sur Paris, mais est-ce le cas dans les autres villes qui ont plusieurs codes postaux ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Cordialement, -- Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] admin_level = 9
En revanche, s’il s’avère qu’une zone administrative suffisamment petite n’a qu’un seul code postal, il suffit de ne pas interpréter le code postal, et le traiter comme un vulgaire numéro à l’instar de la population ou d’une coordonnée géographique. Et du coup ça a sa place dans la base OSM. Mais ce numéro ne sera pas déductible de l’appartenance à une zone administrative, et d’ailleurs les 3 derniers numéros ne l’ont jamais été (déductibles), et maintenant on sait que les 2 premiers ne le sont pas non plus. Aucun problème donc à le traiter comme un vulgaire numéro. Il n’y a que des exceptions, ou autrement dit, il n’y en a pas. :) Le mardi 13 septembre 2011 18:36:27, sly (sylvain letuffe) a écrit : On mardi 13 septembre 2011, Aurélien FILEZ wrote: Je pense qu'il ne faut pas faire de relation entre les codes postaux et les limites administratives, vu que comme dit plus haut, ça n'a rien à voire. Moi je pense que si, car ce qui a été dis plus haut est en partie faux. Ça n'est certes pas valable tout le temps (il existe des contre exemples) mais j'ai l'impression que c'est une grande majorité des cas. Le cadastre indique d'ailleurs le code postal en même temps que le code INSEE des communes, il y a donc un lien, mais il y'a des exceptions, à nous de les traiter (ou pas du tout). Après, franchement, si c'est pour importer des pack de polygones postaux que nous n'aurions aucun intérêt à toucher et se retrouver avec un super tag : hé-ho-pas-touche=yes, moi je dis que ça n'a rien à faire dans osm et autant laisser à à ceux qui le gère ou ailleurs. Aussi, dans le département 59, qu'une ville ait un code 59XXX ou 62XXX, ça change quoi concrètement ? ça pas là que ça poser problème en effet. -- Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Les bâtisseurs du désert - Carte des imports de bâtiments sans voies
Tout à fait d’accord également, Le 19 juillet 2011 09:47, Ophélie PETIT ophelie.petit.cheval...@gmail.coma écrit : Entièrement d'accord, De plus, la présence de bâtiments sans route indique qu'il en existe obligatoirement une et incite à la tracer ^^ Ces bâtiments permettent également de se situer dans l'espace. Enfin après c'est un point de vue personnel. Un point de vue partagé par moi également et — pour en avoir déjà discuté de vive voix avec eux — bien d’autres contributeurs. Et j’ajouterais qu’OSM n’a jamais trop de contributeurs, et que si on commence à contraindre leur façon de travailler, vu que la plupart font ça en tant que passe-temps, pour se relaxer ou s’amuser, on perdra des contributeurs ! Il ne faut pas oublier qu’un projet libre comme celui-là ne contrôle pas ses ressources humaines ainsi que peuvent le faire des entreprises ou d’autres projets moins ouverts. Malgré cela, je trouve qu’OSM est pourtant bien structuré et que la majorité des contributeurs suivent le même chemin alors qu’ils n’y sont pas obligés… N’en demandons pas trop ; laissons agir la magie du libre, ou en l’occurrence, la contribution collective/collaborative/participative (entourez les mentions applicables). Le 19 juillet 2011 09:26, ades_f...@orange.fr ades_f...@orange.fr a écrit : Effectivement intéressant, cependant j'ai un petit doute quant à l'opinion, souvent exprimée ici, de la nécessité d'avoir les routes avant le bâti. Ça a déjà été discuté, mais je pense que ce n'est pas très grave que le bâti soit importé avant les voies, d'abord parce que ça n'empêche pas de mettre les voies ultérieurement et, ensuite, pour les zones vierges, ça donne une base saine (enfin à peu près, compte tenu des imprécisions topographiques du cadastre) pour le tag des constructions, comme pour l'import de traces gps ou le décalque des voies à partir de Bing par exemple. Ça évite aussi, lorsque les contributeurs ne sont pas au courant de cette possibilité d'import, d'avoir du bâti dessiné (à partir de bing ou du cadastre) déjà taggé et qu'il faudra mettre en cohérence lors d'un apport ultérieur du cadastre. Le 17 juil. 2011 à 22:22, Vincent Pottier a écrit : Le 17/07/2011 19:18, Frédéric Rodrigo a écrit : Bonjour, J'ai réalisé une carte de l'import du bâti en fonction de la présence de highway dans la zone. Génial ! [...] La route est longue, oui très longue. Mais la voie est libre... (lu quelque part ;-) ) Fred -- FrViPofm qui pense que les routes sont faites pour relier les hommes ;-) ___ 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Mikaël mickey86 Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Les bâtisseurs du désert - Carte des imports de bâtiments sans voies
Le travail bâclé est regrettable, j’en conviens ; mais c’est un autre problème… [On ne supprime pas les voitures de la route parce qu’elles sont dangereuses entre les mains de certains conducteurs.] D’ailleurs, il existe aussi des contributeurs qui font des erreurs sur les voies et les POI… Seulement ici, ça effraie parce que les bâtiments sont entrés en masse ; mais je ne suis pas certains que les erreurs sur les bâtiments soient plus délétaires à la carte que les erreurs sur les voies de circulation ou les POI. (C’est un jugement personnel) Ce n’est évidemment pas une raison pour laisser faire les sagoins du bâtis, mais ce n’est pas l’import lui-même qu’il faut incriminer. Et puis je ne suis pas sûr que le terme « écrasante majorité » soit adapté, c’est trop précis comme terme ; en revanche, « beaucoup trop » c’est certainement ce que j’utiliserais en tant que OSMeur passionné. :) Le 19 juillet 2011 15:18, Philippe Pary phili...@cleo-carto.com a écrit : Le mardi 19 juillet 2011 à 09:47 +0200, Ophélie PETIT a écrit : Entièrement d'accord, De plus, la présence de bâtiments sans route indique qu'il en existe obligatoirement une et incite à la tracer ^^ Ces bâtiments permettent également de se situer dans l'espace. Enfin après c'est un point de vue personnel. Oui mais non. De manière empirique, on constate que dans la plupart des cas, l'import du bâti sans voies est le fait de contributeurs qui ne passent même pas un coup de validateur (des bourrins quoi) et que les voies n'apparaissent que tardivement de la part d'un autre contributeur. Le bâti seul n'indique pas grand chose ; l'import des zones urbaines de CLC indiquait déjà clairement les endroits où devraient se trouver des voies. Quand à la situation dans l'espace, elle n'a de sens, selon moi, que pour repérer les usages des bâtiments. Autrement dit quand on se casse la tête à indiquer les POI. C'est rarement le cas des gens qui importent le bâti sans voirie. L'opposition que j'ai à l'import du bâti sans voirie tient donc au constat que dans l'écrasante majorité des cas, il s'agit de bourrinage jamais suivi d'une phase d'affinage. Bref, du travail bâclé. Philippe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Mikaël mickey86 Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Retour arrière du rendu mapnik
Ok, merci pour les précisions. Cordialement, -- Mikaël Cordon. Le dimanche 17 juillet 2011 14:48:22, Vincent Privat a écrit : C'est bien ça, confirmé sur le bugtracker: http://trac.openstreetmap.org/ticket/3908 Les tuiles affichés sont des vieilles copiées avant le début de la maintenance. Vincent Le 16 juillet 2011 12:53, Vladimir Vyskocil vladimir.vysko...@gmail.com a écrit : Hello, J'ai remarqué la même chose. D'apres http://wiki.openstreetmap.org/wiki/Platform_Status le server de tuiles est en maintenance ainsi que d'autres services cela peut, peut etre expliquer ce phénomène... Waitsee... Vlad. On 16 juil. 2011, at 11:28, Mickey86 wrote: Salut ! Je surveille la zone [ http://www.openstreetmap.org/?lat=46.56041lon=0.32846zoom=17layers=M] que j’avais fort complété ces derniers temps qui était en ligne correctement jusqu’à hier ou avant hier. Voilà qu’aujourd’hui je constate que les tuiles du niveau 17 et 18 sont revenus à l’état d’il y a plus de 15 jours… Une explication ? PS : c’est en plus une zone que j’avais cartographié pour l’anniversaire de notre GULL (APP3L, Poitiers), demain ! Déjà que la météo n’est pas avec nous et qu’on a eu des problèmes de réservations d’activité, je vais finir par croire qu’il y a une conspiration… -- Mickey86 ___ 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 signature.asc Description: This is a digitally signed message part. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] L'import du bâti...
Le 11 juillet 2011 11:58, Eric Sibert courr...@eric.sibert.fr a écrit : Mais dès que le script d’import semi-auto était connu, j’ai quand même freiné… Fou, mais pas idiot ^^ Là, tu es en train de qualifier le contributeur en question de fou idiot? ;-) Je ne me permets pas de le traiter d’idiot… La remarque était par rapport à mon travail, je me serais trouvé idiot si j’avais continué à tracer les bâtiments à la main sachant que le script d’import semi-auto existait. Là, le contributeur ne sait probablement pas que les bâtiments peuvent être extraits automatiquement. ;) C'est vrai que voir des milliers de baraques avec source=cadastre et ne pas se demander comment elles sont arrivées là... Eric __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mapping d'intérieur
J’y vais de mon petit commentaire aussi… Le mapping intérieur est évidemment intéressant, mais rajoute énormément de complexité à la carte, et comme l’a dit Pieren OSM n’est pas adapté pour cette cartographie. D’un autre côté, je me suis adonné à l’exercice pour les gros bâtiments commerciaux : les couloirs dans les galeries marchandes pouvant être vus comme des « rues » couvertes, et balisés comme des tunnels dans le bâtiment http://www.openstreetmap.org/?lat=46.55133lon=0.300235zoom=18layers=M Autre remarque, le mapping intérieur étant intéressant pour les mal-voyants (messages précédents), ne pas cartographier les intérieurs reviendrait à une certaine discrimination, qui serait mal vue (sans mauvais jeu de mot)… Mais il y a probablement d’autres discriminations impliquées par notre façon de remplir la base dont on n’est pas conscient… Et je ne saurais dire lesquelles. Donc je ne suis pas pour interdire, évidemment, mais pas pour faire le travail aussi fourni dans les bâtiments qu’à l’extérieur. Il y a probablement un compromis entre le nécessaire et le superflus. Le 21 juin 2011 10:55, Pieren pier...@gmail.com a écrit : 2011/6/20 Marc Sibert m...@sibert.fr ** Il existe un tag level qui permet de qualifier le niveau... et en fait, ça renvoie sur une page http://wiki.openstreetmap.org/wiki/Indoor_Mapping; comme ça tombe bien. Il faut aussi savoir que le mapping d'intérieur est un sujet controversé depuis le début. Les données OSM ne supportent pas la 3D et le tag 'level' n'est qu'un pis-aller. Les sources sont rares et difficile à vérifier (surtout les parties non publiques). Sans plan, cela reste très imprécis. Et la juxtaposition des niveaux va rendre la zone rapidement ingérable dans les éditeurs classiques. Je vois bien les applications pour les aveugles ou pour les plans vous êtes ici mais OSM n'est pas forcément le meilleur modèle pour faire des plans d'architecte même si je comprends bien que certains trouvent bien pratique de pouvoir utiliser la suite d'outils logiciels libres développés pour OSM. Enfin, n'oubliez pas le disclaimer d'OSM (aucune garantie, blablabla). Je ne voudrais pas confier à un aveugle un plan que chacun peut modifier à sa guise... Dans le genre données 3D que certains voudraient mettre dans OSM et d'autres non, je pense aux infrastructures souterraines qui sont disponibles dans certains pays ou localement (réseaux d'eau potable, usée; réseau électrique enterré; téléphonique; gaz, etc) et qui n'est pas bien vu comme import dans OSM pour les même raisons citées plus haut. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Mes 2 cents. -- Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Présentation
Salut, Oui, c’est moi qui ai classé (puis reclassé) les rues de Poitiers, et je dois dire que j’ai pas mal de difficulté à classer… Les primaires ne me posent pas de problème… En ce qui concerne les autres classes, c’est plus compliqué je suis partagé entre suivre la classification en fonction des numéros des voies (D 147, C 6, etc.), et le traffic réel. Certaines voies non numérotées sont tellement passagères qu’il est plutôt mal venu de les classer mineures ou résidentielles. De plus visuellement (je sais qu’on ne tague pas pour le rendu), voir une voie qui se détache du reste laisse penser à une voie plutôt principale, c’est dans cette optique j’ai surclassé certaines rues alors qu’officiellement elles n’ont pas plus de classe que ces voisines :) De ce fait, les classes « officielles » peuvent être suivies par rapport au ref=* et l’importance réelle via les classes highway=*, non ? Quant aux rues classées qui débouchent sur des voies de classe inférieures, c’est dû au fait que le traffic est dévié progressivement dans les rues connexes et qu’au bout d’un moment il faut déclasser un bout de la rue pour coller au traffic effectif. Ceci dit, il ya peut-être des erreurs tout de même. Le dimanche 19 décembre 2010 16:57:05, Pieren a écrit : 2010/12/19 sechanb...@free.fr Bonjour à tous, Je m'interesse à OSM depuis un peu plus d'un 1 an, mais c'est seulement depuis 6 mois que je contribue. Je suis impressioné par l'ampleur du projet : la tâche est tout bonnement colossale mais les outils mis à disposition sont d'une qualité remarquable ce qui a permis au projet d'avancer à grand pas. Ce qui a déjà été fait est grandiose ! bravo et bon courage à tous !! Bienvenue sur la liste ! Je viens de voir la page d'acceuil de l'ap3l qui montre la carte OSM sur Poitiers. Il semble que sur cette ville comme dans d'autres en France, nous ayons un problème de classification des highway urbains. On voit souvent des classifications secondary/tertiary ou même parfois primary terminer en cul-de-sac (c.à.d vers des rues residential/unclassified) ou même être complétement isolés alors que ces axes routiers doivent en principe former un réseau. Imaginez que ces classifications supérieures peuvent être utilisées par des logiciels de navigation qui peuvent, par exemple, y envoyer le trafic routier de transit. Ce genre de voie ne devrait terminer qu'exceptionnellement en impasse. Bon mapping sur Poitiers et sa région, Pieren Cordialement, -- Mickey86 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Voies bus synthèse
Bonjour, Je sens mon mal de tête revenir… Il y a quelques temps sur cette liste, on a abordé un sujet épineux : la modélisation des voies pour cycles, mal comprise (c’est un fait), fouillie et comportant des soucis non négligeables ; la discussion s’est terminée sans statuer réellement. Mais je vois que la discussion revient d’elle-même, et c’était à prévoir ; sauf que là, ça s’empire (en un seul mot évidemment) : il y a les voies de bus, les voies piétonnes en plus. On entend ici et là qu’il faut simplifier la modélisation, que les « newbies » sont rebutés par certaines modélisations, et particulièrement des voies pour cycles, et je vois qu’on insiste à appliquer ce modèle pour les bus et les piétons ! Problèmes majeurs de la modélisation actuelle des voies pour cycles : — la direction des voies est dépendante du sens de circulation de la voie principale : lorsque la voie principale n’est plus affectée (plus de voiture, par exemple), il faut changer de modèle (donc en fait, ce n’est pas 1 modèle, mais 2) ; de la même manière il faut être particulièrement attentif à ce qu’il se passe lorsque le sens principal change et pas les autres voies — le modèle propose de séparer en plusieurs tracés parallèles les voies : on crée des données redondantes, donc espace perdu et maintenabilité difficile — les voitures, les vélos, les bus et par extrapolation, les piétons sont des véhicules qui peuvent avoir chacun sa voie (partagée ou non avec les autres) et pourtant on modélise toutes ces voies de manière différente ! Pourquoi ? Alors que le principe est le même, seul le nom du véhicule (et de sa voie) différent. Pourtant, il existe déjà un modèle qui est efficace, qui est largement utilisé, connu du tout le monde et qui ne pose pas vraiment de problème : les voies pour voitures (highway=*) attaché à un tracé (way). On pourrait étendre cette modélisation aux autres véhicules. Pour les cycles : cycleway=* ; pour les bus : busway=* ; pour les piétons : footway=*. Ces voies n’ont plus qu’a rester attaché au tracé et ne pas être interdépendants. Le seul point à éclaircir, reste la position des voies : :left/:right (sur le point d’être adopté) pour 2 voies supplémentaires, et éventuellement un indice (:2, :3) supplémentaire pour les voies supplémentaires. Il faut que le modèle reste simple pour les situations simples (il peut se compliquer pour les situations compliquées), facile à se rappeler et à retrouver (donc un modèle générique est bienvenu). J’avais déjà démontré (dans la ML) que le modèle que je propose modélise bien toutes les situations de façon systématique et laisse les voies indépendantes quant à leur sens de circulation. De plus, je dois dire que je me suis refusé jusque là à modéliser les voies cyclables sur Poitiers parce que le modèle actuel comporte des problèmes que j’aurai du mal à résoudre. Pareil pour les bus, je me suis contenté de faire des lignes (relation route) et pas les voies. Ceci dit, une association de cyclistes nous (des contributeurs OSM sur Poitiers) a contacté pour remplir la carte avec les pistes cyclables : vous imaginez le stress… Enseigner une modélisation à laquelle nous n’adhérons pas, et ainsi probablement ne pas faire de bons contributeurs, ou alors ne pas contribuer du tout. Il y a, à mon humble avis, à discuter encore sur ces points avant d’adopter un modèle qui montrera vite ses limites et mettra tout le monde dans l’embarras. Je ne dis pas que le modèle que je propose est le meilleur, mais il semble avoir plus d’avantages que d’inconvénients à être adopté. Cordialement, -- Mikaël Cordon, Mickey86 Le dimanche 14 novembre 2010 10:33:47, esperanza a écrit : Afin de proposer un Proposed feature sur le wiki concernant les voies de bus et avant d'envoyer cette synthèse sur la liste tagging, j'ai essayé de faire une synthèse des différentes discussions sur la liste et des pratiques dans certaines villes. Merci d'indiquer vos avis afin de compléter par la suite la page wiki : http://wiki.openstreetmap.org/wiki/Bus (qui n'indique pour l'instant que les rares bus_guideway et non les classiques voies bus) sur le modèle de ce qui se fait déjà ici : http://wiki.openstreetmap.org/wiki/Bicycle Il en ressort qu'il y a deux options pour tracer les voies bus séparées de la chaussée comme le montre les cas 1 et 7 et B4 (highway=service ou highway=busway) Par ailleurs, nous sommes au dernier jour pour la consultation (vote) sur les attributs :left/:right sur le wiki : http://wiki.openstreetmap.org/wiki/Proposed_features/right_left Les différents cas rencontrés : (1) Dans le cas d'une voie bus séparée par un potelet ou bien sur une voie bien à part : highway=service service=bus access=no psv=yes bicycle=yes/no ou bien highway=busway bicycle=yes/no (2) Dans le cas de voies bus peintes sur la chaussées sans séparation physique dans les deux sens de circulation ouverts aux vélos : highway=* busway
Re: [OSM-talk-fr] orthophoto Tours
\o/ -- Mikaël Cordon Le samedi 13 novembre 2010 11:15:49, simon a écrit : Bonjour, Je viens de recevoir un DVD de l'orthophoto de l'Agglomération de Tours http://reau.simon.perso.neuf.fr/Ortho_tours_plus.jpg Je dois faire préciser quelques détail au niveau du tag source et de l'utilisation que nous allons en faire et ensuite je vais avoir besoin d'aide technique pour la diffuser. Librement Monsieur a ___ 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] Rencontre mappers
Le dimanche 12 septembre 2010 20:01:41, julien balas a écrit : On 09/12/2010 05:33 PM, Stéphane Brunner wrote: Hello, salut Avec quelque mappeur on va ce retrouver le samedi 18 vers 13h, pour l'instant le lieux n'est pas encore défini, mais il va être quelque part entre Montreux et Villeneuve. ca se situe dans quel pays ? Entre la Belgique et l’Espagne :P Cordialement, -- Mikaël Cordon, Mickey86 06 74 92 69 43 — mikael.cor...@gmail.com Président de l'APP3L - Association Poitevine pour la Promotion de Linux et des Logiciels Libres 64 rue Gambetta 86000 Poitiers http://www.app3l.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : theme de couleurs dans JOSM
Pour les derniers écrans qui sont rétroéclairés avec des leds en matrice (full led et pas edge) lorsqu’une zone est sombre ou noire, la led de rétroéclairage s’éteint, donc des noirs plus profonds et moins de consommation. En ce qui concerne la couleur de fond, choisir blanc ou noir n’est pas vraiment la question, c’est surtout le rapport entre luminosité ambiante et luminosité de l’écran… Dans l’idéal ce rapport devrait être de 1. Plus la lumière ambiante est vive plus l’écran doit être lumineux, et plus on est dans un environnement sombre moins l’écran doit être lumineux. En revanche, plus l’écran est bigarré plus c’est fatiguant. En résumé, choisir une config d’écran plutôt contrastée, mais sans couleurs trop pures, et la luminosité doit suivre la lumière ambiante. De plus, il est recommandé de ne pas être trop près de son écran (ne pas tourner la tête pour suivre le pointeur de la souris), ni trop éloigné (pouvoir tout lire sans forcer), et idéalement lorsque les yeux regardent à l’horizontale, le centre de la vision vise le haut de l’écran. Et l’écran vertical, évidemment. Le vendredi 10 septembre 2010 16:59:46, Julien Balas a écrit : Le 10 septembre 2010 16:53, Vincent Pottier vpott...@gmail.com a écrit : On 10/09/2010 16:30, THEVENON Julien wrote: en plus de ca il y a aussi les considerations ecologiques qui font qu afficher du noir ca consomme moins Ça c'était vrai sur des tubes cathodiques, pas de lumière donc pas d'émission d'électrons donc pas de consommation de courant. Je suis nettement moins sûr pour les écrans LCD où la couche LCD varie en opacité, pas en émission. Mais je ne suis pas spécialiste... Peut-etre même que le fait d'activer les filtres pour que la lumière ne sorte pas fait consommer plus si on affiche du noir Cordialement, -- Mikaël Cordon mikael.cor...@gmail.com 06 74 92 69 43 — 09 52 89 02 08 30 rue Saint-Hilaire 86000 Poitiers ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] passage sous un porche
Le 24 août 2010 10:00, Pierre-Alain Dorange pdora...@mac.com a écrit : Mickey86 mikael.cor...@gmail.com wrote: [...] Après tout, le concept c'est de faire passer un chemin sous quelque chose, la balise tunnel=yes exprime très bien celà. C'est là que je suis pas tout à fait d'accord. Le chemin ne passe justement pas *sous* quelque chose (concept tunnel, underground), mais plutot à travers quelquec hose (concept covered, même si la mot peut sembler mal choisit) Si le passage se faisait sous le batiment alors tunnel serait approprié, AMHA. Si le passage se faisait « sous » le bâtiment alors j’utiliserais « layer=-1 » qui indique qu’on « change de plan ». -- Pierre-Alain Dorange ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Présentation
Salut charentais-maritime ! Et bienvenue ! Le mercredi 04 août 2010 10:42:25, Sébastien KALT a écrit : Bonjour, Cela fait quelques semaines que je suis cette liste, aussi avant de poser quelques questions, je vais me présenter. J'ai découvert OSM en 2008 il me semble, mais à l'époque je n'avais pas de GPS, et le greffon du cadastre n'existait pas. J'ai eu l'occasion de pouvoir emprunter un GPS à mon boulot (un simple enregistreur Garmin), et depuis fin 2009 j'ai fait quelques traces dans mon coin, avec le travail de cartographie kivabien avec josm. J'interviens autour de La Rochelle (Charente-Maritime), soit en voiture, soit à pied, et bientôt en vélo. J'ai eu besoin d'un fond de carte des communes, et du coup j'ai vu qu'il était possible de le récupérer à partir des données OSM. La Charente-Maritime n'étant pas complètement couverte, j'ai découvert les joies du cadastre non numérisé, et de ses feuilles non géoréférencées ... que du bonheur :-P . Sinon dans la vie je suis agronome, et curieux ;-) . A bientôt, pour quelques questions ! Sébastien De la part d’un charentais-maritime d’origine :), -- Mickey86 Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel
Le jeudi 29 juillet 2010 11:36:39, Lapinos03 a écrit :
Mikaël Cordon a écrit :
Le jeudi 29 juillet 2010 02:13:39, Pieren a écrit :
2010/7/28 Mikaël Cordon mikael.cor...@gmail.com
Avec le modèle des xxxway, on peut même modéliser des extras :
— C1 : (c : cycliste ; v : voiture ; b : bus)
|↓:↑| ↓ : ↑ | ↓ : ↑ |
|c:c| v : v | b : b |
highway=* ;
cycleway:left=lane ;
busway:right=lane
Mais avec ce système, comment tu taggues une route:
:c:v:v:c:
highway=* ; cycleway:left=opposite_lane ; cycleway:right=lane ;
oneway:bicycle=1
Entièrement d'accord avec cycleway:left=opposite_lane ;
cycleway:right=lane. Mais que vient faire oneway:bicycle=1 ?
Pour indiquer que le sens de circulation est unique sur chacune des cycleway,
et que le sens donné est dans le sens du tracé… Opposite venant opposer le
sens de la voie cyclable de gauche (puisque le tracé est dans le sens bas→haut
et oneway:bicycle=+1).
Si tu veux utiliser oneway:bicycle pour indiquer un sens de circulation
propre aux vélos, CYCLEWAY devrait se cantonner à une description
physique, et non pas combiner les deux (opposite_lane)... Cela devient
confus.
J’aimerais qu’on m’explique ce que vous appelez une représentation physique…
Puisque le modèle que le propose est justement une description bête et
méchante de la réalité : une voie à gauche, une voie à droite, en sens unique,
et celle de gauche à rebour (par rapport au tracé).
Le « truc » c’est que je considère cycleway=lane comme une voie cyclable à
double sens si on ne précise pas oneway:bicycle={-1,1} (quelque soit la voie
pour voitures adjacente). Mais ça, on n’en parle plus bas dans ce message.
Soit :
highway=* ; cycleway:left=opposite_lane ; cycleway:right=lane ;
(recommended)
soit :
highway=* ; cycleway:left=lane ; cycleway:right=lane ; oneway:bicycle=0
et
:c:v:v:
highway=* ; cycleway:left=opposite_lane ; oneway:bicycle=1
ou
highway=* ; cycleway:left=lane ; oneway:bicycle=-1 (pour s’économiser
quelques caractères)
?
Pieren
Là aussi, soit :
highway=* ; cycleway:left=opposite_lane ;
soit :
highway=* ; cycleway:left=lane ; oneway:bicycle=-1
Et pour revenir au cas C1 énoncé plus haut, l'attribut LANE me fait
penser qu'il n'y a qu'1 seule voie de circulation. Peut-être qu'une
nouvelle valeur LANES (avec un S) dissiperait tout ambiguïté.
+1 !
Je me suis fait la même réflexion, mais j’ai voulu réutiliser le vocabulaire
déjà en place vu que l’ambiance générale est à la frilosité quant à l’ajout de
vocabulaire :) Mais ce serait plus cohérent, d’autant que par défaut, je
considère les voies à double sens.
highway=*
cycleway:left=lanes
busway:right=lanes
Là, ça devient tout de suite plus évident, n'est-ce pas?
Tout à fait.
Et dans les cas suivants, pour reprendre ton modèle, ai-je tout bon?
|↑| ↑ |
|c | v |
highway=*
oneway=1
cycleway:left=lane
Avec la convention lanes == 2 × lanes (↓↑) j’aurais fait ça aussi.
|↓| ↑ |
|c | v |
highway=*
oneway=1
cycleway:left=lane
oneway:bicycle=-1
Itou.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
--
Mickey86
Mikaël Cordon
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel
Le jeudi 29 juillet 2010 11:42:44, Pieren a écrit : 2010/7/29 Mikaël Cordon mikael.cor...@gmail.com Mais avec ce système, comment tu taggues une route: :c:v:v:c: highway=* ; cycleway:left=opposite_lane ; cycleway:right=lane ; oneway:bicycle=1 et :c:v:v: highway=* ; cycleway:left=opposite_lane ; oneway:bicycle=1 ou highway=* ; cycleway:left=lane ; oneway:bicycle=-1 (pour s’économiser quelques caractères) Oui, je pensais bien qu'avec ces deux cas qui sont quand même les plus courants, ton système nécessitait plus de tags que celui actuellement en place. C’est sûr, c’est, à mon avis, le point qui fâche avec ce modèle ; mais d’un autre côté on gagne beaucoup en modélisation et en compréhension du modèle vu que c’est déjà ce qu’on utilise avec highway ; il permettrait d’unifier tous les types de voies. Ceci dit, autant ce modèle est bête (systématique) quand on utilise les tags oneway à chaque fois qu’il y a une voie indépendante à sens unique ; il pourrait peut-être être amélioré par des raccourcis syntaxiques, tant que ça ne rend pas le modèle confus ou ambigu. Si on reprend le message précédent de Lapinos03 auquel je réponds, l’utilisation de la valeur cycleway=lanes (avec le « s ») permettrait sans doute d’éviter la lourdeur des oneway:bicycle dans le cas le plus courant : |↓|↓:↑|↑| |c|v:v|c| Et aller un peu plus loin dans la précision avec :both : highway=* ; cycleway:both=lanes Et pour : | ↑ |↑| | v |c| highway=* ; cycleway:right=lane voire même (si la position droite de la bande cyclable est clairement majoritaire) highway=* ; cycleway=lane (ce qui commence à se rapprocher sérieusement du modèle actuel :)) Mais de manière générale, un modèle digne de ce nom, ne devrait être jamais ambigu, comporter le moins d’exceptions possible, et les exceptions devraient porter soit sur le cas vraiment majoritaire à des fins de raccourcis, ou les cas les plus rares. À mon sens, un modèle qui décrit unitairement quelques situations et change la signification de ses composants à chaque situation (autrement dit, un modèle qui n’est fait que d’exceptions) est à proscrire. Et on voit que quel que soit le système choisi, il arrive que des cas posent questions et auront différentes interprétations. Pieren Cordialement, -- Mickey86 Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel
Le jeudi 29 juillet 2010 18:50:41, Pieren a écrit : 2010/7/29 Mikaël Cordon mikael.cor...@gmail.com penser qu'il n'y a qu'1 seule voie de circulation. Peut-être qu'une nouvelle valeur LANES (avec un S) dissiperait tout ambiguïté. Et pour revenir au cas C1 énoncé plus haut, l'attribut LANE me fait +1 ! Je me suis fait la même réflexion, mais j’ai voulu réutiliser le vocabulaire déjà en place vu que l’ambiance générale est à la frilosité quant à l’ajout de vocabulaire :) Mais ce serait plus cohérent, d’autant que par défaut, je considère les voies à double sens. On a déjà un 'lanes' pour le nombre total de voies ( http://wiki.openstreetmap.org/wiki/Lanes). Pas sûr que rajouter un autre tag 'lanes' simpifie les choses... Je suis assez d’accord pour limiter le vocabulaire au strict nécessaire. Ceci dit, le lanes qu’on connaît déjà est une balise et non une valeur de balise. On rencontre ce schéma bien des fois, par exemple : type=junction ; junction=traffic_signals. Pieren Cordialement, -- Mickey86 Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel
Le jeudi 29 juillet 2010 19:41:53, simon a écrit : ok, refaisons entièrement le schéma du tag bicycle entre français, par contre ne conter pas sur moi pour argumenter auprès des autres pays pour imposer le nouveau schéma. Ni pour changer manuellement avec vérification sur le terrain les 78085 cycleway=track, 36778 cycleway=lane, 10558 cyclaway=opposite, 2988 cycleway=opposite_lane (chiffre au 27 juillet 2010). Comment vont faire les personnes utilisant les données OSM si les schémas de tag changes tous les ans ? il serait peut être judicieux de juste documenter les quelque cas qui nous manque avec le schéma actuelle et changer la photo sur la page http://wiki.openstreetmap.org/wiki/Proposed_features/right_left pour éviter toutes confusions. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Rien n’est décidé encore, ce n’est qu’une proposition. Ensuite, ce modèle est souvent compatible avec l’actuel et met à plat le problème des directions. Il est évident qu’il faudra un consensus avant toute adoption. Ceci dit il y a des problèmes avec le modèle actuel : imprecisions, incompréhensions, et des situations qu’on ne peut pas modéliser. C’est difficile pour les cartographieurs (interprétation des imprécisions), ainsi que pour les réutilisateurs des données (réinterprétation des imprécisions). Comme la tendance est à la précision de la carte (c’est un de ses fers de lance), et dans les villes à mettre des voies spécialisées dans tous les sens, il serait vraiment dommage de laisser pourrir une situation qui entache la réputation d’OSM. Si le modèle doit changer c’est le moment de le faire avant qu’il y ait encore plus de données à changer. D’autant que on se rend compte que certaines situations sont difficiles à cartographier ; on espère que les gens n’ont pas fait n’importe quoi. Ainsi sans les situations critiques, le modèle actuel est assez cohérent et alors le passage d’un modèle à l’autre pourrait être fait automatiquement. Mais je répète, rien n’est décidé. On discute parce qu’il y a des soucis. Cordialement, -- Mickey86 Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel
remarqué qu’il y a plus de tags, jusqu’à 3 par voies ! Ceci dit il n’est dit nulle part que le monde pouvait être modélisé avec 1 ou 2 tags :) Ensuite, si on s'intéresse au tag non recommandé, mais reconnu valide, on s'aperçoit que cette bande de contresens cyclable placée à droite, peut être décrite avec oneway=yes + cycleway:right=lane + oneway:bicycle=yes. Ce dont on peut déduire que, pour les sens uniques en tout cas, le sens de circulation des vélos n'est pas donné forcément par les suffixes :right/:left (puisque là on est en cycleway:right et que pourtant on ne roule pas dans le sens du way), ni non plus par les valeurs lane/opposite_lane (puisque là on est en lane et que pourtant on ne roule pas dans le sens du way), ni non plus par le sens de circulation des voitures (on a mis lane alors qu'on est en contresens). Dans les sens uniques, ce qui donne le sens de circulation des vélos en dernière instance, apparement, c'est le tag oneway:bicycle=no/yes. Ca c'est réglé. Reste un problème quand même : c'est que ce tag n'est pas utilisable dans les voies à double sens de circulation voiture. Du coup, encore cette question pénible : qu'est-ce qui définit le sens de circulation des vélos (ou des bus) dans les voies à double sens ? Il faut choisir : Est-ce que ce sont les suffixes :right/:left qui donnent le sens de circulation implicite (ce qui est la tendance de la page http://wiki.openstreetmap.org/wiki/Bicycle), mais alors on doit se contenter de décrire un schéma de circulation plutôt qu'une configuration précise de la voirie ? ou bien Est-ce que ce sont les valeurs lane/opposite_lane qui peuvent seules définir le sens de circulation des vélos en fonction du tracé du way (ce qui est en contradiction avec la tendance de la page http://wiki.openstreetmap.org/wiki/Bicycle, et particulièrement avec B3, mais en accord avec ce qui semble être indiqué dans l'exemple de la page http://wiki.openstreetmap.org/wiki/Proposed_features/right_left), mais alors on est bien embété pour taguer la configuration précise de B1 et B2 de la page http://wiki.openstreetmap.org/wiki/Bicycle ? Qu'est-ce qu'on choisit ? Cordialement, -- Mickey86 Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel
Le jeudi 29 juillet 2010 02:13:39, Pieren a écrit : 2010/7/28 Mikaël Cordon mikael.cor...@gmail.com Avec le modèle des xxxway, on peut même modéliser des extras : — C1 : (c : cycliste ; v : voiture ; b : bus) |↓:↑| ↓ : ↑ | ↓ : ↑ | |c:c| v : v | b : b | highway=* ; cycleway:left=lane ; busway:right=lane Mais avec ce système, comment tu taggues une route: :c:v:v:c: highway=* ; cycleway:left=opposite_lane ; cycleway:right=lane ; oneway:bicycle=1 et :c:v:v: highway=* ; cycleway:left=opposite_lane ; oneway:bicycle=1 ou highway=* ; cycleway:left=lane ; oneway:bicycle=-1 (pour s’économiser quelques caractères) ? Pieren Cordialement, -- Mickey86 Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel
: — nécessite probablement l’utilisation de plus (1 voire 2 de plus par situation) de balises que ce qui est décrit dans le wiki, (mais nécessaires pour lever les ambiguïtés) — vu que chacun y va de son interprétation du wiki, il y aura des remaniments à faire, mais ce n’est pas propre à ce modèle. À propos de dupliquer les tracés pour modéliser des voies supplémentaires : — mauvaise idée : — topologiquement c’est une erreur de séparer deux voies qui suivent le même tracé. — allourdissement du schéma, et de la base (mais c’est secondaire) — masque aux utilisateurs (calculateurs, GPS, etc.) qu’ils peuvent éventuellement passer d’une voie à l’autre (si nécessaire ; par ex. travaux sur une voie et passer sur celle d’à côté) — pas si mauvaise idée pour les cas vraiment complexes, ou les voies physiquement séparées (tracks). Voulons-nous une carte qui soit faite de brics et de brocs dont il faut deviner la signification ou une carte utilisable et non ambigüe ? Dites-moi si je suis complètement à côté de la plaque. :) Jocelyn (excusez pour l'erreur de manip'...) Cordialement, -- Mickey86 Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel
Le mardi 27 juillet 2010 23:26:01, Lapinos03 a écrit : Ouille ouille! Stop les oneway:=1/-1 à gogo! Le but du jeu, c'est de faire simple et dans la concision, mais sans rogner sur la qualité et la précision. Faire simple pour qui ? Pour nous ? Pour les futurs utilisateurs (lecteurs, développeurs, GPS) ? Mais alors comment indiquer les sens de circulation de chacune des voies alors ? En faisant tout hériter les sens de circulation des unes des autres ? En jouant avec les opposite_* ? Évidemment, si on veut préciser le sens des voies dans un système multiple, il faut un moyen d’identifier le sens de chacune des voies du groupe, sachant qu’on ne peut pas déduire le sens dans toutes les situations, ou alors il faut jouer avec les « opposite_* », mais alors ça revient à multiplier les valeurs plutôt que les tags ; c’est un choix, mais si on veut rester cohérent avec le modèle des highways… Je trouve que les oneway ont le mérite d’être simple et sans équivoque : oneway=1 ou yes ⇒ dans le sens du tracé, point. oneway=-1 ou no ⇒ dans le sens opposé du tracé, point. Si oneway n’est pas précisé, alors aucun sens privilégié ⇒ les deux sens, point. Je ne vois pas ce qu’il y a de compliqué là-dedans, il suffit de préciser. Il n’y a aucun calcul d’héritage de sens circulation ou de déduction, il suffit de lire. Ne me dites pas que vous êtes flemmard pour 1 tag par voie ? Vous qui avez déjà créé des milliers de tracés et de nœuds :) Mikaël Cordon a écrit : J’ai suivi un peu ce fil de discussion, et j’ai effectivement l’impression qu’une certaine obscurité reigne chez certains. Ceci dit, je n’ai pas encore pris la peine de cartographier les pistes et bandes cyclables. Aussi, c’est avec un œil assez neuf et intuitif (je n’ai pas lu précisément le wiki à ce sujet, mais en dehors des vélos, j’ai une certaine expérience). Alors j’ai répondu au QUIZZ avec la sensation d’avoir des réponses et une modélisation cohérentes. J’ai lu les questions, posé les balises modélisant chaque objet et condition, et je les ai combiné. 1. Une rue à double-sens (highway=*) dispose d'une bande cyclable (cycleway=lane) que d'un côté, highway=* ; cycleway=lane (on pourrait préciser :left ou :right) 2. Une rue à sens unique (highway=* ; oneway=1) dispose d'une bande cyclable (cycleway=lane) pour aller du Sud vers le Nord (oneway:bicycle=1) et d'une piste (cycleway=track) pour aller du Nord vers la Sud (oneway:bicycle=-1). Je mappe : highway=* ; oneway=1 ; cycleway=lane,opposite_track ; oneway:bicycle=1 3. Une rue, à double-sens (highway=*), dispose d'une piste cyclable de chaque côté (cycleway:left=track ; cycleway:right=track). si le sens des pistes n’est pas précisé : highway=* ; cycleway:left=track ; cycleway:right=track si il est implicite qu’il y a un seul sens par piste : highway=* ; cycleway:left=track ; cycleway:right=opposite_track ; oneway:bicycle=1 (ou -1 selon le sens à donner alors) 4. Une rue (highway=*), à sens unique (oneway=1), dispose d'une bande cyclable (cycleway=lane) pour aller du Sud vers le Nord (oneway:bicycle=1), placée côté gauche (cycleway:left=lane). Je mappe : highway=* ; oneway=1 ; cycleway:left=lane ; oneway:bicycle=1 5. Je suis en Angleterre (on s’en moque). Une rue (highway=*), à sens unique (oneway=1), dispose d'une bande cyclable (cycleway=lane) en contre-sens (oneway:bicycle=-1). Je mappe : highway=* ; oneway=1 ; cycleway=lane ; oneway:bicycle=-1 ou highway=* ; oneway=1 ; cycleway=opposite_lane ; oneway:bicycle=1 6. Une rue à sens unique (highway=* ; oneway=1) dispose de marquages répétés au sol, chevrons+sigle cycliste (bicycle=yes), dans le même sens de circulation (oneway:bicycle=1). Je mappe : highway=* ; oneway=1 ; bicycle=1 ; oneway:bicycle=1 Comme cycleway n’apparaît pas on pourrait le faire apparaître comme suit : highway=* ; oneway=1 ; cycleway=share_highway ; oneway:bicycle=1 7. Une rue à sens unique (highway=* ; oneway=1) dispose de marquages répétés au sol, chevrons+sigle cycliste (bicycle=yes), dans le sens contraire de circulation (oneway:bicycle=-1). Je mappe : Même chose que 6. mais le sens des cyclistes est opposé : highway=* ; oneway=1 ; bicycle=1 ; oneway:bicycle=-1 Comme cycleway n’apparaît pas on pourrait le faire apparaître comme suit : highway=* ; oneway=1 ; cycleway=share_highway ; oneway:bicycle=-1 8. Une rue à sens unique (highway=* ; oneway=1) dispose d'une bande cyclable (cycleway=lane) en sens contraire (oneway:bicycle=-1) à ses extrémités, sur 10m (je découpe le « way »), puis de marquages répétés au sol, chevrons+sigle cycliste, sur le reste de la rue (bicycle=yes). Je mappe : sur les extrémités coupées : highway=* ; oneway=1 ; cycleway=lane ; oneway:bicycle=-1 ou highway=* ; oneway=1
Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel
J’ai suivi un peu ce fil de discussion, et j’ai effectivement l’impression qu’une certaine obscurité reigne chez certains. Ceci dit, je n’ai pas encore pris la peine de cartographier les pistes et bandes cyclables. Aussi, c’est avec un œil assez neuf et intuitif (je n’ai pas lu précisément le wiki à ce sujet, mais en dehors des vélos, j’ai une certaine expérience). Alors j’ai répondu au QUIZZ avec la sensation d’avoir des réponses et une modélisation cohérentes. J’ai lu les questions, posé les balises modélisant chaque objet et condition, et je les ai combiné. 1. Une rue à double-sens (highway=*) dispose d'une bande cyclable (cycleway=lane) que d'un côté, highway=* ; cycleway=lane (on pourrait préciser :left ou :right) 2. Une rue à sens unique (highway=* ; oneway=1) dispose d'une bande cyclable (cycleway=lane) pour aller du Sud vers le Nord (oneway:bicycle=1) et d'une piste (cycleway=track) pour aller du Nord vers la Sud (oneway:bicycle=-1). Je mappe : highway=* ; oneway=1 ; cycleway=lane,opposite_track ; oneway:bicycle=1 3. Une rue, à double-sens (highway=*), dispose d'une piste cyclable de chaque côté (cycleway:left=track ; cycleway:right=track). si le sens des pistes n’est pas précisé : highway=* ; cycleway:left=track ; cycleway:right=track si il est implicite qu’il y a un seul sens par piste : highway=* ; cycleway:left=track ; cycleway:right=opposite_track ; oneway:bicycle=1 (ou -1 selon le sens à donner alors) 4. Une rue (highway=*), à sens unique (oneway=1), dispose d'une bande cyclable (cycleway=lane) pour aller du Sud vers le Nord (oneway:bicycle=1), placée côté gauche (cycleway:left=lane). Je mappe : highway=* ; oneway=1 ; cycleway:left=lane ; oneway:bicycle=1 5. Je suis en Angleterre (on s’en moque). Une rue (highway=*), à sens unique (oneway=1), dispose d'une bande cyclable (cycleway=lane) en contre-sens (oneway:bicycle=-1). Je mappe : highway=* ; oneway=1 ; cycleway=lane ; oneway:bicycle=-1 ou highway=* ; oneway=1 ; cycleway=opposite_lane ; oneway:bicycle=1 6. Une rue à sens unique (highway=* ; oneway=1) dispose de marquages répétés au sol, chevrons+sigle cycliste (bicycle=yes), dans le même sens de circulation (oneway:bicycle=1). Je mappe : highway=* ; oneway=1 ; bicycle=1 ; oneway:bicycle=1 Comme cycleway n’apparaît pas on pourrait le faire apparaître comme suit : highway=* ; oneway=1 ; cycleway=share_highway ; oneway:bicycle=1 7. Une rue à sens unique (highway=* ; oneway=1) dispose de marquages répétés au sol, chevrons+sigle cycliste (bicycle=yes), dans le sens contraire de circulation (oneway:bicycle=-1). Je mappe : Même chose que 6. mais le sens des cyclistes est opposé : highway=* ; oneway=1 ; bicycle=1 ; oneway:bicycle=-1 Comme cycleway n’apparaît pas on pourrait le faire apparaître comme suit : highway=* ; oneway=1 ; cycleway=share_highway ; oneway:bicycle=-1 8. Une rue à sens unique (highway=* ; oneway=1) dispose d'une bande cyclable (cycleway=lane) en sens contraire (oneway:bicycle=-1) à ses extrémités, sur 10m (je découpe le « way »), puis de marquages répétés au sol, chevrons+sigle cycliste, sur le reste de la rue (bicycle=yes). Je mappe : sur les extrémités coupées : highway=* ; oneway=1 ; cycleway=lane ; oneway:bicycle=-1 ou highway=* ; oneway=1 ; cycleway=opposite_lane ; oneway:bicycle=1 sur le reste : highway=* ; oneway=1 ; bicycle=1 ; oneway:bicycle=-1 ou highway=* ; oneway=1 ; cycleway=share_highway ; oneway:bicycle=-1 9. Une rue à sens unique (highway=* ; oneway=1) dispose d'un couloir de bus (busway=lane) en sens contraire (oneway:bus=-1) autorisé au vélo (bicycle=yes). Je mappe : highway=* ; oneway=1 ; busway=lane ; oneway:bus=-1 ; bicycle=1 ; oneway:bicycle=-1 (ici on ne voit pas que le vélo partage la voie des bus) ou highway=* ; oneway=1 ; busway=lane ; oneway:bus=-1 ; cycleway=share_busway ; oneway:bicycle=-1 10. Une rue (highway=*), à sens unique (oneway=1), dispose d'un couloir de bus (busway=lane) pour aller du Sud vers le Nord (oneway:bus=1), placée côté gauche (busway:left=lane). Laquelle bande de bus dispose d'une bande cyclable (cycleway=share_busway), placée côté gauche sur cette même bande (cycleway:left=lane). Je mappe : highway=* ; oneway=1 ; busway:left=lane ; oneway:bus=1 ; cycleway=share_busway ; cycleway:left=lane ; oneway:bicycle=1 (ici c’est la combinaison de cycleway=share_busway et cycleway:left=lane qui permet de déduire que la bande cyclable est sur la voie de bus) 11. Un couloir de bus à double-sens (busway=lane) n'autorise les vélos (bicycle=yes) dans le sens sud-nord (oneway:bicycle=1). Je mappe : busway=lane ; bicycle=1 ; oneway:bicycle=1 ou busway=lane ; cycleway=share_busway ; oneway:bicycle=1
Re: [OSM-talk-fr] [Tech] Extraction des adresses...
Le 19 juillet 2010 08:24, Benoît ROUSSEAU adressepossi...@free.fr a écrit : Mickey86 a écrit : Le lundi 19 juillet 2010 07:31:03, hamster a écrit : Benoît ROUSSEAU a écrit : Les adresses sont maintenant déplacées à x mètres du centre de la voie tracée dans OSM (plus propre) et notées sur les erreurs potentielles et mettre l'adresse en question sur le batiement le plus proche et non pas a x metre de la voie, ca serait faisable ? variante : mettre l'adresse sous forme d'un noeud sur le chemin du batiment le plus proche, en positionnant du cote ou le chemin du batiment est le plus proche de la rue C'est possible, mais le risque d'erreur me semble beaucoup trop élévé. Pour ce qui est d'un nœud ou le bâtiment c'est du pareil au même côté programmation. Ou à la limite de la parcelle si le bâtiment est trop loin. C'est possible aussi mais là encore, le risque d'erreur me semble trop élevé. Beaucoup de parcelles ou de bâtiments sont loin de leur n° de voie (allées privées, bât imbriqués, ...) ou proches d'une autre (toutes les intersections, ..). Les bâtiments sont parfois nombreux pour une adresse. Faut-il tous les n°ter, faut-il risquer de n°ter la grange ? A avoir bossé sur les adresses, j'ai changé d'avis sur les méthodes de numérotation. J'ai essayé les deux systèmes de n°tation bât et plaques. La signification première de ces numéros c'est un repérage lié à et dans la rue. Donner un n° à un bâtiment à moins de sens et quand on cherche un n° de rue on cherche à se positionner au sein de cette rue. Et penser aux bâtiments à plusieurs adresses (aux croisements, ceux qui donnent sur deux rues devant derrière, ...). Finalement les plaques de n° sont les plus utiles et ce qui fait le plus sens, le n° est bien lié à la rue. Je suis tout à fait d’accord ! :) En fait, ma proposition de mettre sur la limite de parcelle était dans un soucis de placement automatique sachant que la parcelle le plus souvent colle la rue, plutôt qu’une distance arbitraire par rapport au centre de la rue (ce qui dépend de la largeur de la rue). Et dans les faits, lorsque le bâtiment ne colle pas la limite de la parcelle et si le bâtiment est assez éloigné, à la main je positionne le numéro sur la limite de la parcelle. Mais c’est une méthode personnelle. Benoît R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] HELP les polygones CLC ont bougés au ssi
Hum, http://www.openstreetmap.org/?lat=46.595lon=0.194zoom=11layers=B000FTF [un polygone CLC (je suppose) « étiré » vers le sud.] Je pense que cet effet artistique (douteux certes :p) est lié… Peut-on confirmer ? Hier j’ai édité la carte juste à côté de cette zone, je n’ai touché qu’à la voirie, je doute y être pour quelque chose. Cordialement, -- Mikaël Cordon mikael.cor...@gmail.com 06 74 92 69 43 — 09 52 89 02 08 30 rue Saint-Hilaire 86000 Poitiers Le mercredi 30 juin 2010 03:51:59, Benoît ROUSSEAU a écrit : Bonjour, Alors là je ne sais pas quoi faire ! Malgré le filtrage, sous JOSM, des polygones CLC, ils étaient pris dans le déplacement... Je ne comprends pas. Mon revert n'a pas fonctionné, le décalage est beaucoup plus important, et les polygones CLC ont été pris dans le mouvement... J'en était à supprimer les bâtiments pour refaire un import quand j'ai vu ça. Si qqun à une solution simple pour remettre en ordre... Sinon je vais peaufiner mon revert en transférerant la zoneconcernée sur le serveur de dev. J'enrage ! D'autant plus que l'API sera indispo plusieurs jours. A demain... Benoît R. ___ 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] Présentation OpenStreetMap à l 'UNESCO
Plutôt encourageant, alors ! Impeccable :) Le 27 avril 2010 15:06, RatZilla$ ratzil...@gmail.com a écrit : Bonjour à tou[te]s J'ai rencontré des équipe de l'UNESCO vendredi matin, elle sont emballées par les possibilités d'OSM. En plus des questions classiques sur la qualité des données j'ai eu des questions que je détaillerai ci-dessous. Je vais discuter dans les semaines à venir dans quelles mesures les données géographiques propriétaires de l'UNESCO peuvent être données à OSM. -Il n'y a pas de réticences particulières pour le triplet (Nom du site / Latitude / Longitude) en revanche les commentaires associés sont propriétaires (ce n'est pas grave ;-) -Quid de la charge des serveurs si OSM est utilisé pour valoriser le patrimoine référencé à 'UNESCO je n'ai pas encore de chiffre mais il y a des données planète entière dans beaucoup de domaines. -Pour l'instant c'est Google qui a à sa charge la gestion de la bande passante, l'UNESCO n'a pas forcément les ressources (Bande passante, personnel, etc ... pour gérer ça ... un piti don ... à voir) -Certains états de veulent pas voir apparaitre leurs frontières (Openlayers pourrait régler ça ???) -Il y a des tonnes de cartes dans des tonnes projections à numériser (OSGéo / Qgis / Gdal / OpenStreetMap pour monter une méthode industrielle?) -Il y a des données qui leurs posent des problèmes de représentation là aussi j'attends nos futurs rencontres pour en avoir le détail. Dans l'ensemble IL Y A UN BOULOT ÉNORME et des volontés pour libérer et transmettre. Je reviendrai vers vous au fur et à mesure de la remontée des projets. Gaël ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import des bâtiments, Adresses des bâtiments, et plugin
+1 Le 2 avril 2010 14:51, Etienne Trimaille etienne.trimai...@gmail.com a écrit : C'est vrai que les relations, c'est plus propre au niveau de la modélisation. Cela évite la redondance du nom de la rue. Avec une relation, si le nom de la rue change(erreur de toponymie ou autre), il n'y a pas de problème de mise à jour pour chaque bâtiment. Le top serait un plugin : on sélectionne les bâtiments taggés avec le housenumber, on sélectionne en même temps les morceaux de rues concernées, et on clique sur un bouton (ou raccourcie clavier) création relation associatedStreet, et hop, tout automatique : type=associatedStreet, name=nom de la rue, avec les membres et les rôles respectifs aux highways et aux buildings. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Fwd: La communauté OpenStreetMap f rançais en quêtes d'informations
J'ai essayé d'en savoir un peu plus ce qu'il se passe au plus près de l'équipe en charge du SCPC (Service de Consultation des Plans Cadastraux) -- Message transféré -- De : G. Cyrille (75) Date : 26 février 2010 11:06 Objet : Re: La communauté OpenStreetMap français en quêtes d'informations À : Mikaël Cordon mikael.cor...@gmail.com Bonjour, Suite à votre message de ce jour, les précisions suivantes sont apportées : - en France métropolitaine, les projections dans lesquelles sont exprimés les plans cadastraux au format vecteur sont, depuis mars 2009, les coniques conformes 9 zones (auparavant, il s'agissait des projections Lambert zones). La migration des données cartographiques au format vecteur du Lambert zones vers les coniques conformes 9 zones s'explique par la nécessité de se conformer au décret n° 2006-272 du 3 mars 2006 (RGF93) ; - pour les plans cadastraux au format Image, selon les feuilles de plan et les communes concernées, l'on peut trouver diverses projections : lambert zones, lambert 93, coniques conformes 9 zones, ou aucun système légal de projection. Par ailleurs, les plans cadastraux de certaines communes qui étaient gérés au format Image peuvent passer au format Vecteur et, par conséquent, voir désormais leur projection exprimée en coniques conformes ; - s'agissant des temps d'accès, nous constatons depuis le début de l'année un nombre croissant d'utilisateurs du site cadastre.gouv.fr ce qui peut entraîner une dégradation des temps de réponses aux heures de pointe. Nous travaillons actuellement avec les services informatiques pour trouver le plus rapidement possible une solution ; - s'agissant du service WMS, nous souhaiterions l'ouvrir de manière visible à compter de la fin de cette année. Les études informatiques nécessaires à ce projet se poursuivent. Je devrais être en mesure de vous apporter des précisions qu'au cours du second semestre. En espérant avoir répondu à vos interrogations. Cordialement, -- [image: DGFIP] *Cyrille G.* *Inspecteur Principal* *Bureau GF3A* *86/92 allée de Bercy* *75572 PARIS 12ème* *Tél : 00 00 00 00 00* *_* Message original Sujet : La communauté OpenStreetMap français en quêtes d'informations De : Mikaël Cordon mikael.cor...@gmail.com mikael.cor...@gmail.com Pour : Date : 26/02/2010 09:52 Bonjour, Je fais partie de la communauté des contributeurs au projet OpenStreetMap (http://wiki.openstreetmap.org/wiki/FR:Main_Page), et depuis quelques mois je suis en mission à la DGFiP (CSI de Poitiers, projet OPERA-TOSCANE, service CCOT). Je vous contacte en tant contributeur OpenStreetMap. Depuis quelques temps, la communauté OSM française éprouve des difficultés quant à la récupération de certaines données cadastrales lui permettant de compléter sa chère carte libre ; frustration. Il semblerait qu'il y ait des changements de projection sur certaines communes. Nous observons également des temps accès plutôt long et irréguliers au serveur WMS. Nous ne sommes pas là pour nous plaindre, mais plutôt savoir (sans rentrer dans l'indiscrétion) ce qu'il se passe et ce qu'il est prévu à plus ou moins long terme à propos du service WMS. Cela nous permettrait de pouvoir éventuellement anticiper certains changements (types de projections, changement de format des tuiles cadastrales, etc.) et patienter en toute quiétude. En espérant que j'aie contacté un bon interlocuteur, et dans l'attente d'une réponse de votre part, nous vous prions d'accepter toute notre reconnaissance quant aux services forts intéressants que vous fournissez. PS : Pour éviter d'être assailli de questions, et dans le cas où d'autres échanges soient à venir, je me propose de faire l'intermédiaire entre la communauté OSM et vous. Image1___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] indication de zoom de rendu ?
http://www.openstreetbrowser.org et http://poitools.openstreetmap.de/ C’est effectivement ce à quoi je pensais :) Avec notre ami Simon (à Tours), nous avons fait quelques « grapho-parties » dans les centre-ville et à chaque fois les nouveaux « mappeurs » sont frustrés de ne voire qu’une petite partie de leur travail s’afficher sur la carte… Frustrant, et pas très encourageant. Maintenant, c’est une autre affaire ^^ Le mercredi 24 février 2010 00:29:27, eMerzh a écrit : dans le même genre je préfère http://poitools.openstreetmap.de/ bien que moins complet :) il serait effectivement intéressant d'élargir ces possibilitiés et de le coupler à nominatim 2010/2/24 Etienne Trimaille etienne.trimai...@gmail.com Le 22 février 2010 10:36, Mikaël Cordon mikael.cor...@gmail.com a écrit Je pose d'autres questions-propositions : --- ne serait-il pas le moment de développer une carte multi-plan : permettant d'afficher ou non des éléments qui se superposent ? --- j'imagine que ça remet en cause le fondement du moteur de rendu... --- quid alors de la licence ? Le fait de séparer les données par des plans... Et bien voila : http://www.openstreetbrowser.org C'est juste assez long à charger. ;-) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Librement, -- Mikaël Cordon, Mickey86 06 74 92 69 43 — mikael.cor...@gmail.com Président de l'APP3L - Association Poitevine pour la Promotion de Linux et des Logiciels Libres 64 rue Gambetta 86000 Poitiers http://www.app3l.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] indication de zoom de rendu ?
Sur Poitiers, j'ai le problème de priorité : des POI se masquent les uns les autres sans que l'un ait pourtant une priorité évidente sur l'autre ; en clair le système choisit d'afficher un POI au détriment de l'autre et pourtant l'un et l'autre sont de même importance. De même, à un niveau de zoom le nom d'un POI est affiché, au suivant, il ne l'est plus, c'est assez déroutant (ironique pour une carte). Je me pose plusieurs questions : --- qui va décider de l'importance de tel ou tel POI ? --- je crains que le fait de donner la possibilité de prioritariser les POI, certains se basent sur le rendu pour déterminer l'importance du POI... --- la prioritarisation ne ressemble-elle pas à au détournement du concept compléter la carte sans se préoccuper du rendu ? Je pose d'autres questions-propositions : --- ne serait-il pas le moment de développer une carte multi-plan : permettant d'afficher ou non des éléments qui se superposent ? --- j'imagine que ça remet en cause le fondement du moteur de rendu... --- quid alors de la licence ? Le fait de séparer les données par des plans... Librement, -- Mikaël, Mickey86 Le 22 février 2010 09:07, Guillaume Allegre allegre.guilla...@free.fr a écrit : Le Sun 21 Feb 2010 à 22:48 +0100, Pieren a ecrit : 2010/2/21 Guillaume Allegre allegre.guilla...@free.fr Elle n'apparait qu'aux zoom 17 et 18, ce qui parait normal pour un POI de ce type en milieu urbain. Mais au milieu du désert, il serait justifié de la voir jusqu'au zoom 9 ou 10, je pense. Techniquement, ça ne serait pas très compliqué. Il faudrait juste informer le moteur de rendu sur les critères qui feraient changer les niveaux de zoom minimum et maximum de certains POI. Ou plus simplement de faire un post-traitement des données OSM en y ajoutant un tag spécial qui serait fonction de la distance avec ses POI voisins de même type. Mais tout cela ne serait faisable que sur un rendu particulier qu'il faudrait mettre soi-même en place, le rendu standard d'OSM n'offrant pas, à ma connaissance, cette possibilité. Merci de ta réponse. Il me semble que c'est une question qui demanderait vraiment de l'attention. Je suis partagé entre la méthode calcul automatique que tu évoques, et qui demanderait sans doute des ressources de calcul assez importantes dans le moteur de rendu, et l'évaluation manuelle de l'importance d'un POI, qui justifierait de forcer les niveaux de zoom. Le risque serait évidemment une sorte de spam (je mets un zoom mini plus faible sur mon bar), mais si les contributeurs restent honnêtes, le degré d'importance d'un POI pourrait se justifier, indépendamment de la distance aux voisins. Par exemple, dans une grande ville, il y a généralement une poste centrale, et des bureaux de poste de quartier. Actuellement, je ne connais rien qui permette de les différencier pour le moteur de rendu (sauf la taille du bâtiment, certes). Pourtant, cela serait utile. Donc en y réfléchissant, il me semble qu'on peut distinguer deux critères : - POI important intrinsèquement - POI important car isolé Le premier se rapproche vraiment de la classification des routes (primary...). Serait-il envisageable d'avoir une notion d'importance générique pour tous les tags (ou au moins tous les tags de type POI) ? J'imagine que ça a déjà été évoqué quelque part ? Pour fixer un peu les idées, on pourrait partir de la proposition : importance = lowest, lower, normal (default), higher, highest (ou quelque chose dans ce genre) qui pourrait être prise en compte pour le calcul du zoom limite. -- ° /\Guillaume AllègreMembre de l'April /~~\/\ allegre.guilla...@free.fr Promouvoir et défendre le logiciel libre / /~~\tél. 04.76.63.26.99 http://www.april.org ___ 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] indication de zoom de rendu ?
Oui, pour le rendu de base, puisque c'est celui de la carte principale qui est sans doute utilisée par la majorité (moi en tout cas). Mais sûrement que le problème se retrouve sur toute autre carte mono-plan. Une solution alternative mais pas parfaite au problème de superposition serait d'avoir des zooms plus importants : cela permet de ne pas avoir plusieurs plans, et assez d'espace sur la carte pour tout afficher. Mais je crois que cette solution n'est que temporaire, plus on a d'espace sur un bureau, plus on met de papiers, jusqu'à ce que le bureau soit trop petit. Le 22 février 2010 12:28, jul...@krilin.org a écrit : Je me pose plusieurs questions : --- qui va décider de l'importance de tel ou tel POI ? --- je crains que le fait de donner la possibilité de prioritariser les POI, certains se basent sur le rendu pour déterminer l'importance du POI... Ca me fait penser à la personne qui avait mis un commerce en peak pour avoir une icône sur la carte ;) --- la prioritarisation ne ressemble-elle pas au détournement du concept compléter la carte sans se préoccuper du rendu ? Sans compter qu'un POI important car au milieu du desert devient moins important si plusieurs autres apparaissent dans la zone. Je pose d'autres questions-propositions : --- ne serait-il pas le moment de développer une carte multi-plan : permettant d'afficher ou non des éléments qui se superposent ? Tu veut dire pour le rendu de base d'OSM ? -- JB ___ 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] Re : Prestataires OpenStreetMap
+1 Le 29 janvier 2010 09:59, Robin PREST ro...@georezo.net a écrit : Hello, Désolé pour la réponse tardive. Encore une fois, je crois que nos communautés gagneraient à se rapprocher ! Jean, tu peux aller voir sur ce listing : http://georezo.net/geo-entreprise/ . C'est un annuaire des professionnels de l'information géographique que nous avons mis en place avec l'Afigéohttp://www.afigeo.asso.fr/pour pouvoir répondre à ce genre de question. Tu y trouveras notamment une carte pour trouver le professionnel le plus proche si tu choisis la voie d'un prestataire privé. J'en profite pour suggérer à Michael Douchin d'y enregistrer sa société 3liz si ce n'est pas déjà fait, c'est gratuit :o) *Pieren C'est ça ce que j'appelle l' esprit OSM : construire une* *communauté de contributeurs. Payer des gens pour le faire, c'est revenir à**l'ancien modèle. * Je rappelle que les données d'OSM dans les pays les plus fournis en data viennent de société privées (ou de gouvernement local) qui ont libérées leur données, de même que certaiens appli très utilisées dans le monde du logiciel libre viennent de sociétés privées à l'origine. Fustiger le commerce est une chose, ne pas reconnaître que la synergie peut être plus enrichissante en est une autre. Il existe aussi un modèle économique avec le libre (cf 3liz par exemple). Pour rappel (Sourcehttp://media.baliz-geospatial.com/fr/article/openstreetmap-l-information-geographique-issue-de-la-collaboration-de-masse) et exemple : *Les Pays-Bas ont aussi pu bénéficier d’un geste plutôt inattendu de la part de la compagnie AND http://www.and.com/, une société productrice de données cartographiques numériques, basée à Rotterdam (Pays-Bas), qui a décidé en 2007 de faire le don à OSM http://www.opengeodata.org/?p=223de toute la cartographie du réseau routier du pays. Faisant face à une concurrence féroce, et particulièrement aux Pays-Bas, aussi le pays hôte de Tele Atlas, la compagnie s’est offerte ce coup d’éclat qui a grandement servi la communauté OSM. Le communiqué émis par AND à l’époque mentionnait aussi le don à OSM des artères principales de la Chine et de l’Inde.* Je ne pense pas que ca ait freiné la communauté OSM dans ce pays, au contraire. Le fait d'avoir une base existante peut aussi donner envie de s'impliquer pour que la carte soit à jour (un peu comme quand le ménage est fait, c'est plus facile à entretenir :P) Je suis très intéressé par des retours d'expérience vis à vis des communes qui ont lancé ces démarches de diffusion(ou même de société dans le même esprit). Dans le cadre de mon boulot, je serais ravi de promouvoir OSM + accélérer le processus dans les zones rurales en proposant aux communes de diffuser sur OSM les données que nous avons créé pour elles. Celles ci ne se rendent souvent pas compte des possibilité d'OSM (voire ne connaissent pas) Ce ne serait pas forcément une prestation payante mais plutôt une sorte de bonus pour passer devant nos concurrents, par exemple. L'opposition société commerciale/communauté citée plus haut n'est pas si binaire que ça... My 2 cents, Robin. ___ 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] langues ?
Le 27 janvier 2010 02:43, hamster hams...@suna.fdn.fr a écrit : Mikaël Cordon a écrit : Bonjour, (Saluton) Je parle aussi un peu espéranto. J'avoue que l'adoption de l'espéranto par OSM me ravirait beaucoup ! Ceci dit je soulève quelques questions ou remarques quant à l'adoption de l'espéranto par OSM ; ce qui ne constitue pas une dissuasion ou une persuasion. --- Que fait-on des termes déjà en utilisation ? on les garde : il faut pas vouloir etre plus royaliste que le roi --- Si on bascule en espéranto, la masse de travail de traduction sur la base OSM c'est une chose, mais il y a aussi tous les interpréteurs de la carte (les convertisseurs, maposmatic) et les éditeurs (JOSM, Merkartor, etc.)... je n'ai jamais parle de traduire le contenu actuel de la base, mais de se demander quelle langue on utilise pour les nouveaux tags a l'origine j'ai reagi dans une discussion sur le choix du tag pour les defibrillateurs Personnellement, je doute que mélanger les langues soit une bonne chose ! Si on choisit une langue commune c'est bien pour qu'elle soit unique. Si on mélange, on perd l'avantage de déduire et de se rappeler logiquement le vocabulaire : à moins que l'on décide d'avoir une langue pour une catégorie d'objet, ce sera difficile de se rappeler la langue de chaque terme de vocabulaire. --- Alors que l'anglais permettait l'utilisation de tables de caractères anciennes, l'espéranto requerra l'adoption d'une table de caractère internationale -- UTF8, par exemple -- pour les consonnes accentuées (c, g, j, h, et s), à moins d'utiliser les méthodes cx et ch. l'esperanto est loin d'etre parfait, et les accents ne sont pas son seul defaut Mais aucune langue n'est parfaite, il s'agit là de savoir quelle langue offre plus d'avantages que d'inconvénients ! on trouve beaucoup d'esperantistes qui veulent conserver l'esperanto tel qu'il a ete invente par Zamenhof, je trouve que ca revient a en faire une langue morte et qu'il est nettement preferable de se l'approprier et donc pas hesiter a le modifier la ou on en ressent le besoin une langue vit en evoluant au gre des usages C'est pareil pour toute langue. En ce qui concerne l'espéranto, la philosophie de base étant la simplicité et la communauté, c'est une langue qui, si elle évolue, restera stable quant à sa philosophie, sinon, elle perdra ses avantages et mourra alors. Elle évoluera dans son vocabulaire, dans ses constructions de phrases peut-être, dans la culture qu'elle engendre ; ce qui n'est pas incompatible avec OSM, il me semble. --- La traduction dans les langues locales serait alors univoque à partir de l'espéranto (langue relativement neutre) pour les applications. Et c'est une langue très simple à apprendre et dépourvue de dialectes (uniforme sur la planète). si c'est largement adopte par la communaute internationale est-ce que ca va rester longtemps depourvu de dialectes ? la question que je pose c'est plutot est-ce que l'esperanto (ou une autre langue remplissant la meme fonction) va rester, de par sa structure, plus facile a apprendre malgre l'evolution de l'usage qu'une langue issue d'une culture et evoluant elle aussi avec l'usage ? --- L'espéranto dispose-t-il suffisamment de vocabulaire pour couvrir toutes les subtilités des objets sur les cartes ? rien ne nous interdit de contribuer a l'esperanto en rajoutant des mots Tout à fait ! ___ 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] langues ?
Le 27 janvier 2010 09:40, Dominique Rousseau d...@lee-loo.net a écrit : Le Mon, Jan 25, 2010 at 10:05:40AM +0100, Mikaël Cordon [mikael.cor...@gmail.com] a écrit: --- Alors que l'anglais permettait l'utilisation de tables de caractères anciennes, l'espéranto requerra l'adoption d'une table de caractère internationale -- UTF8, par exemple -- pour les consonnes accentuées (c, g, j, h, et s), à moins d'utiliser les méthodes cx et ch. Pour autant que je sache, la base d'OSM est entièrement en UTF8, puisque de toute façon, tu peux avoir des accents, du chinois, ... dans les valeurs de chacun des attributs. En fait, je ne parlais pas que de la base OSM, mais aussi de tous les outils afférents. Mais à vrai dire ce n'est pas un réel problème, la partie ASCII étant commune, l'espéranto loge tout à fait dans chaque table moyennant les méthodes cx et ch qui pourront être reconverties en caractères unicode accentués à la volée. -- Dominique Rousseau d...@lee-loo.net - 06 82 43 12 27 Si cinquante millions de gens disent une sottise, ça n'en reste pas moins une sottise. -- Anatole France ___ 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] langues ?
Bonjour, (Saluton) Je parle aussi un peu espéranto. J'avoue que l'adoption de l'espéranto par OSM me ravirait beaucoup ! Ceci dit je soulève quelques questions ou remarques quant à l'adoption de l'espéranto par OSM ; ce qui ne constitue pas une dissuasion ou une persuasion. --- Que fait-on des termes déjà en utilisation ? --- Si on bascule en espéranto, la masse de travail de traduction sur la base OSM c'est une chose, mais il y a aussi tous les interpréteurs de la carte (les convertisseurs, maposmatic) et les éditeurs (JOSM, Merkartor, etc.)... --- Alors que l'anglais permettait l'utilisation de tables de caractères anciennes, l'espéranto requerra l'adoption d'une table de caractère internationale -- UTF8, par exemple -- pour les consonnes accentuées (c, g, j, h, et s), à moins d'utiliser les méthodes cx et ch. --- La traduction dans les langues locales serait alors univoque à partir de l'espéranto (langue relativement neutre) pour les applications. Et c'est une langue très simple à apprendre et dépourvue de dialectes (uniforme sur la planète). --- L'espéranto dispose-t-il suffisamment de vocabulaire pour couvrir toutes les subtilités des objets sur les cartes ? --- De part le fait que les substantifs finissent par o et les adjectifs par a, il y aurait peut-être là un moyen efficace pour classer les tags de désignation et de qualification ? --- etc. Je trouve que cette langue serait bonne alternative à l'anglais pour l'OSM. Et ce serait un nouveau vecteur de promotion de cette langue encore minoritaire et pourtant pleine d'avantage ! -- Mickey86 Le 25 janvier 2010 09:11, Nicolas Dumoulin nicolas_openstreetmap.org@ dumoulin63.net a écrit : Le Monday 25 January 2010 01:20:27 hamster, vous avez écrit : Emilie Laffray a crit : Soit. Quelle langue proposes tu? l'esperanto n'est pas parfait mais ca corresponds deja beaucoup mieux a une langue internationale que l'anglais Je crois bien que ca soit un probleme insoluble dans ce cas la. On pourrait parler de la difficulte d'apprentissage des langues, mais je ne suis pas sure que le debat avancerait beaucoup. Quelqu'un a suggere l'esperanto mais j'ai bien peur que ca n'aide pas beaucoup vu le nombre de personnes parlant cette langue. si on compte au nombre de personne qui l'utilise on pouvait en dire autant de linux et freebsd en 1995, on pouvait en dire autant d'OSM en 2006, d'ailleurs je crois bien qu'on peut toujours en dire autant Je crois que par definition une langue est discriminante, car tu auras toujours ceux qui parlent la langue et ceux qui ne la parlent pas. L'anglais en comparaison de beaucoup de langues est facile a apprendre. alors la il faudra que tu m'explique comment tu fais tes comparaisons toujours en comparant on peut aussi trouver beaucoup de langues plus faciles a apprendre que l'anglais avec sa kirielle d'exceptions et irregularites, et meme des langues beaucoup plus faciles a apprendre par exemple L'esperanto s'apprend en moyenne cinq fois plus rapidement que n'importe quelle langue nationale ou ethnique (francais, anglais, chinois, etc.) [1] Bonjour, Le débat commence à faire du bruit et n'est pas facile à suivre. Je ne parle pas l'esperanto, et je ne sais pas si c'est la meilleur solution au problème, mais ce serait en tout cas moins pire. Je déteste devoir apprendre la langue de Shakespeare (langue littéraire avec effectivement beaucoup de subtilité) uniquement pour me faire comprendre d'autres personnes (souvent non anglophones). Voilà, +1 quoi -- Nicolas Dumoulin ___ 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] article dans la Nouvelle République
\o/ on ne l’arrête plus ce Simon ^^ Cordialement, -- Mikaël Cordon, Mickey86 06 74 92 69 43 — mikael.cor...@gmail.com Président de l'APP3L - Association Poitevine pour la Promotion de Linux et des Logiciels Libres 64 rue Gambetta 86000 Poitiers http://www.app3l.org Le mardi 12 janvier 2010 21:42:50, simon a écrit : Bonjour, Un peut de pub pour OpenStreetMap en Indre et Loire http://www.lanouvellerepublique.fr/dossiers/journal/index.php?dep=37num=15 08043PHPSESSID=c59ee73d4a485e49f5fd24f7b95b71ea ___ 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
