Re: [OSM-talk-fr] Démo OSM for Hiking - HRP
Je ne connaissais pas ce rendu OpenTopoMap. Pas mal du tout Côté site, on peut ajouter les itinéraires Lonvia en surimpression. Le 30 mars 2015 23:55, Greg ewala...@gmail.com a écrit : Pour ce qui est du rendu, je me pencherai plutôt du côté d'OpenTopoMap que je trouve très réussi : http://opentopomap.org/#map=14/42.75300/0.06437 Ça ne comble pas le manque de données d'à côté, mais l'aspect est plus conforme à une carte de rando. 2015-03-30 23:22 GMT+02:00 Léo Serre l...@lstronic.com: Salut à tous, Vu que l'idée est intéresse beaucoup de monde et que manifestement la FFRP n'est pas sujette à discussion. Voilà ce que je propose : J'avais ajouté la HRP à OpenStreetMap (http://wiki.openstreetmap.org/HRP) et contacté Jérôme Bonneau (l'actuel repreneur des topos de la HRP) pour lui proposer de la carto OSM pour ses bouquins. Ça n'a jamais abouti car les fait que j'utilise SRTM pour l'élévation le gêne (les valeurs sont différentes de l'IGN), car OSM est assez pauvre pour les à-côtés de la trace et car je suis une merde pour le rendu. Mais je suis toujours motivé pour démontrer le potentiel d'OSM via cet itinéraire qui a été soutenu par une personne pendant 60 ans (et qui tombe à l'abandon aujourd'hui). Je vous invite à contribuer sur la page du wiki si vous le souhaitez afin d'étoffer les alentours, ajouter les variantes, et mettre au point un rendu. Pour ce qui est du rendu, n'étant pas satisfait de Maperitive (trop peu utilisé à mon goût), j'ai débuté et perdu un projet TileMill. Léo Le 30/03/2015 16:48, JB a écrit : Le 25/03/2015 17:36, Bruno Cortial a écrit : Je vois un projet du style OSM hacke le GR20 ! On enrichi OSM de la relation GR20 On en démontre tous les usages libres comme : * Un rendu TOPO20 Maperitive * un calcul de distance * un calcul de dénivellé+ dynamique * une video historique à la ITO * Les usages dans OSMand et autres app ... que sais-je ?! J'aime beaucoup beaucoup l'idée, et des idées de ce genre me titillent régulièrement. Malheureusement, les données pour la randonnées sont encore bien rares dans certains secteurs. Par exemple, si la voie du HRP était parfaitement cartographiée, il n'y avait rien autour il y a quelques mois. Dans les Vosges, si entre le lac Blanc et le Grand Ballon, il n'y a pas à rougir, il ne faut pas descendre beaucoup plus au sud. Un tronçon du Tour des Volcans d'Auvergne n'était pas cartographié il y a 1 an. Il y a une vraie valeur ajoutée dans un topoguide® par rapport à juste une carte (listes d'hébergement, ravitaillement, eau). Je pense que ça demande un vrai travail de terrain, notamment de cartographie pour avoir une qualité raisonnable. Bon, comme j'étais de retour dans le Puy de Dôme pour deux mois, je me dis qu'il faudrait trouver à récupérer leur réseau de chemins inscrits au PDIPR qui a l'air bien fichu, et proposer une Grande Traversée de la Chaine des Puys, parce que le circuit de la FFRP est vraiment pourri… JB. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- [image: LSTRONIC logo] Léo SERRE *LSTRONIC Founder* [image: mail] l...@lstronic.com [image: website] lstronic.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 -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] FFRandonnée ? de quoi rire encore un moment (jaune ?)
Le 30/03/2015 21:01, Christian Rogel a écrit : J'emploie le terme propriété intellectuelle en visant le droit moral de l'auteur qui, en droit français, est inaliénable, mais, maintenant, est limité à 70 ans. La FFR s'est vu reconnaître ce droit moral par le tribunal, ce qui lui permet d'en contrôler l'exploitation commerciale par elle-même ou par ceux quelle désigne. Il me semble que le transfert du droit moral prévu par les CT d'OSM aurait été illégal en France. Christian R. Dans UN cas la FFRP s'est vue reconnaître ce droit par un tribunal, et dans un autre elle a été déboutée. C'est trop mince pour généraliser... Pour les CT d'OSM, peut-on vraiment parler de propriété intellectuelle vis à vis de nos contributions ? En principe non, car il elle n'ont rien d'originales vu qu'elles se basent en principe sur des faits vérifiables, constatables par tous. C'est justement ça le noeud du problème, qu'y a-t-il de vraiment original dans la majorité des itinéraires de la FFRP ? Quand on creuse un peu on constate que soit ces itinéraires existent depuis bien plus longtemps que la FFRP, soit qu'il n'y a pas d'originalité car la rando optimale entre A et B c'est cet itinéraire à cause de la géographie, soit l'itinéraire a été créé par une collectivité, etc... -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Panneau de signalisation A13a
Le 30/03/2015 22:06, herve lefebvre a écrit : Le lundi 30 mars 2015, 16:05:18 Jérôme Seigneuret a écrit : @aegir : Ok en effet le panneau est moins précis en générale et mentionne une zone fréquenté par des enfants http://www.signastore.fr/panneau-routiers-endroit-frequente-par-les-enfants .html M9z1 http://www.signastore.fr/panonceau-ecole-approche-securite.htmlprécise que c'est fréquenté dû à la proximité d'une école. Sauf que mon cas fusionne les deux dans un panneau carré Oui, mais c'est pas du tout pareil. Par exemple, sur un calcul d'itinéraire, s'il est 16h30 en période scolaire, sur un point school on va mettre un malus dû au trafic, ce qu'on ne fera pas sur un point children. Pour ce genre d'usage, il me semblerait plus efficace de se baser sur la proximité géographique d'une école que sur la présence de ce panneau qui... signale la proximité d'une école ;) Plus généralement, doit-on mapper les panneaux ou ce qu'ils décrivent ? En général dans OSM on décrit plutôt la finalité (le nom d'une rue sur le tronçon de la rue ou le fait qu'elle soit en sens unique) que le panneau lui même (qui mappe les plaques de rue ou les panneaux de sens unique ?). -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] FFRandonnée ? de quoi rire encore un moment (jaune ?)
Le 31/03/2015 09:32, Christian Quest a écrit : et dans un autre elle a été déboutée. Tu as des détails ? On parle toujours de l'autre cas… JB. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Panneau de signalisation A13a
2015-03-31 9:38 GMT+02:00 Christian Quest cqu...@openstreetmap.fr: En général dans OSM on décrit plutôt la finalité (le nom d'une rue sur le tronçon de la rue ou le fait qu'elle soit en sens unique) que le panneau lui même (qui mappe les plaques de rue ou les panneaux de sens unique ?). Pourtant, un traffic_sign=FR:B1 est beaucoup plus clair qu'un oneway=yes... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Hauteur et nombre d'étages des bâtiments
Le 30 mars 2015 21:24, Vincent Frison vincent.fri...@gmail.com a écrit : Le 30 mars 2015 20:59, erwan salomon r...@gmx.fr a écrit : je dit peut-être une connerie : les 83 éléments non valides sont peut-être des éléments pour les-quels le score dépasse 100 % ? (bâtiment OSM plus petit que le bâtiment de l'import) Normalement le score est forcément compris entre 0 et 1 (si le bâtiment d'OSM est plus petit que l'import j'inverse le ratio) mais il faut que je debug.. Erf j'avais tout simplement oublié un petit '=' et ces 83 mauvais éléments correspondaient en fait à des éléments parfait puisqu'avec un score de 1.0 :) Dans ma zone de test il y a donc un peu plus de 34% de bâtiment ayant un import dont le score est d'au moins 90%. Je vais essayer d'implémenter l'astuce décrite dans mon précédent mail : pour chacun des bâtiments OSM regrouper les imports par nombre d'étages pour voir si je peux les cumuler afin d'atteindre le bon score minimal. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Panneau de signalisation A13a
Bonjour - Mail original - De: Christian Quest cqu...@openstreetmap.fr Plus généralement, doit-on mapper les panneaux ou ce qu'ils décrivent ? - Mail original - Pour ma part, je m'y amuse parfois : http://www.openstreetmap.org/node/2989723377 http://www.openstreetmap.org/node/2989723379 http://www.openstreetmap.org/node/2989723384 http://www.openstreetmap.org/node/2989723385 ou plus généralement [out:json] [timeout:25] ; area(3601110899)-.searchArea; ( node [traffic_sign] (area.searchArea); way [traffic_sign] (area.searchArea); relation [traffic_sign] (area.searchArea); ); out body; ; out skel qt; C'est fastidieux. Et c'est pour cela qu'un plug-in Mapillary - JOSM serait très interessant Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Panneau de signalisation A13a
Le plugin Mapillary fait partie d'une proposition du projet GSoC 2015 maintenant. Espérons qu'il sera accepté. J'ai bon espoir. Néanmoins, moi j'ajouterai les panneaux comme noeud isolé, exactement où se trouve le panneau. Les inclure comme noeud dans le chemin me semble moins efficace et en outre le tag 'direction' est très fragile. Il perd son sens, (litt. et fig.) quand le chemin est découpé sur ce noeud-là. Polyglot 2015-03-31 10:15 GMT+02:00 david.croc...@online.fr: Bonjour - Mail original - De: Christian Quest cqu...@openstreetmap.fr Plus généralement, doit-on mapper les panneaux ou ce qu'ils décrivent ? - Mail original - Pour ma part, je m'y amuse parfois : http://www.openstreetmap.org/node/2989723377 http://www.openstreetmap.org/node/2989723379 http://www.openstreetmap.org/node/2989723384 http://www.openstreetmap.org/node/2989723385 ou plus généralement [out:json] [timeout:25] ; area(3601110899)-.searchArea; ( node [traffic_sign] (area.searchArea); way [traffic_sign] (area.searchArea); relation [traffic_sign] (area.searchArea); ); out body; ; out skel qt; C'est fastidieux. Et c'est pour cela qu'un plug-in Mapillary - JOSM serait très interessant Cordialement -- David Crochet ___ 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] Démo OSM for Hiking - HRP
Le 31 mars 2015 à 09:13, Ab_fab gamma@gmail.com a écrit : Je ne désespère pas de me lancer un jour sur la thématique eau vive (au moins une couche en surimpression, comme pour les itinéraires Lonvia sur le site OpenTopoMap. Tu peux proposer à Sarah de rajouter une couche sur le site waymarktrail. Je l’ai fait pour l’équitation. Ça a pris un peu de temps, mais maintenant c’est fait (il manque juste des volontaires pour saisir les tracés officiels). — Yves___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démo OSM for Hiking - HRP
Le 30/03/2015 23:22, Léo Serre a écrit : Pour ce qui est du rendu, n'étant pas satisfait de Maperitive (trop peu utilisé à mon goût)… C'est la seule raison, qu'il est trop peu utilisé ? J'en connaitrais d'autres, mais celle-là n'en faisait pas partie… (et d'ailleurs, Tilemill est-il vraiment très utilisé ? Mapbox Studio ? QGis ? Quelques stats représentatives ?). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démo OSM for Hiking - HRP
Pour info, hormis Tilemill et Maperitive, il y a aussi kosmtik, développé par Yohann Boniface. C'est très fortement inspiré de (basé sur ?) Tilemill, mais totalement libre indépendant de l'écosystème Mapbox. Je ne désespère pas de me lancer un jour sur la thématique eau vive (au moins une couche en surimpression, comme pour les itinéraires Lonvia sur le site OpenTopoMap. Le 30 mars 2015 23:22, Léo Serre l...@lstronic.com a écrit : Salut à tous, Vu que l'idée est intéresse beaucoup de monde et que manifestement la FFRP n'est pas sujette à discussion. Voilà ce que je propose : J'avais ajouté la HRP à OpenStreetMap (http://wiki.openstreetmap.org/HRP) et contacté Jérôme Bonneau (l'actuel repreneur des topos de la HRP) pour lui proposer de la carto OSM pour ses bouquins. Ça n'a jamais abouti car les fait que j'utilise SRTM pour l'élévation le gêne (les valeurs sont différentes de l'IGN), car OSM est assez pauvre pour les à-côtés de la trace et car je suis une merde pour le rendu. Mais je suis toujours motivé pour démontrer le potentiel d'OSM via cet itinéraire qui a été soutenu par une personne pendant 60 ans (et qui tombe à l'abandon aujourd'hui). Je vous invite à contribuer sur la page du wiki si vous le souhaitez afin d'étoffer les alentours, ajouter les variantes, et mettre au point un rendu. Pour ce qui est du rendu, n'étant pas satisfait de Maperitive (trop peu utilisé à mon goût), j'ai débuté et perdu un projet TileMill. Léo Le 30/03/2015 16:48, JB a écrit : Le 25/03/2015 17:36, Bruno Cortial a écrit : Je vois un projet du style OSM hacke le GR20 ! On enrichi OSM de la relation GR20 On en démontre tous les usages libres comme : * Un rendu TOPO20 Maperitive * un calcul de distance * un calcul de dénivellé+ dynamique * une video historique à la ITO * Les usages dans OSMand et autres app ... que sais-je ?! J'aime beaucoup beaucoup l'idée, et des idées de ce genre me titillent régulièrement. Malheureusement, les données pour la randonnées sont encore bien rares dans certains secteurs. Par exemple, si la voie du HRP était parfaitement cartographiée, il n'y avait rien autour il y a quelques mois. Dans les Vosges, si entre le lac Blanc et le Grand Ballon, il n'y a pas à rougir, il ne faut pas descendre beaucoup plus au sud. Un tronçon du Tour des Volcans d'Auvergne n'était pas cartographié il y a 1 an. Il y a une vraie valeur ajoutée dans un topoguide® par rapport à juste une carte (listes d'hébergement, ravitaillement, eau). Je pense que ça demande un vrai travail de terrain, notamment de cartographie pour avoir une qualité raisonnable. Bon, comme j'étais de retour dans le Puy de Dôme pour deux mois, je me dis qu'il faudrait trouver à récupérer leur réseau de chemins inscrits au PDIPR qui a l'air bien fichu, et proposer une Grande Traversée de la Chaine des Puys, parce que le circuit de la FFRP est vraiment pourri… JB. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- [image: LSTRONIC logo] Léo SERRE *LSTRONIC Founder* [image: mail] l...@lstronic.com [image: website] lstronic.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pause des mises à jour BANO
Le 30/03/2015 22:53, Vincent de Château-Thierry a écrit : Bonjour, Le 30/03/2015 21:14, Jérôme Amagat a écrit : C'est reparti? Oui, les mises à jour OSM sontà jour : http://munin.openstreetmap.fr/osm12.free.org/osm105.openstreetmap.fr/osm_replication_lag_osm2pgsql.html et BANO a été mis à jour dans la journée. Et les tuiles BANO tirent profit du nouveau SSD... c'est donc un peu plus rapide au rendu. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démo OSM for Hiking - HRP
Il y a eu les tracés eaux vives sur francetopo.fr pendant une période Le 31/03/2015 09:34, Yves Pratter a écrit : Le 31 mars 2015 à 09:13, Ab_fab gamma@gmail.com mailto:gamma@gmail.com a écrit : Je ne désespère pas de me lancer un jour sur la thématique eau vive (au moins une couche en surimpression, comme pour les itinéraires Lonvia sur le site OpenTopoMap. Tu peux proposer à Sarah de rajouter une couche sur le site waymarktrail. Je l’ai fait pour l’équitation. Ça a pris un peu de temps, mais maintenant c’est fait (il manque juste des volontaires pour saisir les tracés officiels). — Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- LSTRONIC logo Léo SERRE /LSTRONIC Founder/ mail l...@lstronic.com mailto:l...@lstronic.com website lstronic.com http://lstronic.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Panneau de signalisation A13a
Plus généralement, doit-on mapper les panneaux ou ce qu'ils décrivent ? En général dans OSM on décrit plutôt la finalité (le nom d'une rue sur le tronçon de la rue ou le fait qu'elle soit en sens unique) que le panneau lui même (qui mappe les plaques de rue ou les panneaux de sens unique ?). Les micromappeurs? L'effet d'un panneau est le plus important, ça c'est certain. Mais pouvoir déterminer d'où vient cet effet est intéressant aussi. Je ne dis pas que nous devons mapper tous les panneaux, mais c'est ce qu'ils font au Finlande. Les panneaux de parking me semblent plus facile à mapper que leur effet, pour lequel il faudrait découper le chemin en beaucoup de petits bouts. J'ai adapté les données du RoadSigns plugin. Ils contient tous les panneaux pour la Belgique maintenant. J'aimerais également adapter le code, façon de faire que l'effet est ajouté sur les chemins/relations (turn_restrictions) et que le code national de panneau aboutit sur un noeud isolé. Jo ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nice, rajouter une place
Le 30 mars 2015 14:22, Brice MALLET brice...@free.fr mailto:brice...@free.fr a écrit : Bonjour, A mon avis la polyligne pour ta place devrait englober les voies extérieures (les numéros de maisons sont rattachés, à priori, à la place de Gaulle donc celle-ci va jusqu'aux façades) mais dans la liste de tes tags, il est certain que place = locality n'est pas bon (place est un lieu et non une place - http://wiki.openstreetmap.org/wiki/FR:Key:place) donc à supprimer et à remplacer par soit la place est accessible en voiture, et alors highway = residential soit piétonne, et alors highway = pedestrian soit un parking, et alors amenity = parking soit composite et là devient compliqué, il fut proposé (cf. échanges ci-dessous) landuse (or area !) = plaza NB : la qualification des places composites (i.e. partie circulation, partie piétonne, partie espace vert, ...) ne fait pas consensus, cf. échange récent : https://lists.openstreetmap.org/pipermail/talk-fr/2015-February/075236.html https://lists.openstreetmap.org/pipermail/talk-fr/2015-March/07.html Je n'ai pas retouché ;-) à toi de voir Ok j'ai agrandi la polyligne pour qu'elle englobe tout, et je viens de la rendre circulaire tant qu'à faire. J'ai : - mis area=yes - retiré place=locality (j'avais vu ça sur la Place Massena, plus au sud si vous suivez l'avenue Jean Médecin) - mis puis retiré highway=pedestrian (la place est principalement piétonne, mais elle est coupé par le tram dans le sens nord/sud et par une rue dans le sens est/ouest, et je n'ai aucune idée des relations à mettre entre tout ça pour ne pas casser ces axes de communications et/ou les espaces verts) Le 30/03/2015 17:28, Philippe Verdy a écrit : Il avait été proposé il me semble place=plazza (ailleurs j'ai vu des place=square... bien que toutes les places ne soient pas carrées ou même rectangulaires, bon nombre sont rondes ou triangulaires). Parfois on trouve aussi place=neighborhood, bien que cela désigne plutôt des sous-quartiers beaucoup plus grands que la seule place, et souvent au contour mal défini et qu'on tague donc juste avec un nœud central indicatif, mais parfois matérialisé par un panneau d'information sur le terrain ou un arrêt de bus, mais dans certaines villes les sous-quartiers neighborhood ont des contours bien définis administrativement). [notes] Ces sous-quartiers quand ils sont administratifs (admin_level=11) s'assemblent ensuite en quartiers administratifs (admin_level=10) - soit au sein des municipalités (admin_level=8), - soit au sein des arrondissements municipaux à Paris/Lyon/Marseille (admin_level=9), - soit encore au sein (dans le cas des communes en fusion-association ou des communes nouvelles) des communes déléguées (ce devrait être aussi admin_level=9 et non admin_level=10 car ces communes déléguées ont toujours leurs quartiers en admin_level=10 et éventuels sous-quartiers, mais visiblement certains ici veulent les mettre aussi en niveau 10 ce qui bloque le découpage de leurs quartiers respectifs ! Alors qu'il n'y a strictement aucune confusion entre arrondissements municipaux et communes délégués, les deux ne pouvant pas coexister en France au sein des mêmes communes. Et là je ne parle pas des réelles anciennes communes en fusion simple et qui ont totalement disparu et dont l'ancien découpage en quartiers n'est plus pertinent du tout puisque réarrangé dans un découpage unique de la nouvelle commune qui a un unique maire, un unique état-civil, et un unique cadastre). Les sous-quartiers non administratifs existent de façon informelle ailleurs (certains ont utilisé ici les noms sur les tableaux d'assemblage du cadastre, et les zones cadastrales individuelles sont devenues selon les endroits des hameaux place=hamlet). Mais certains ici les ont tagués en admin_level=10 (uniquement pour les voir sur layers.openstreetmap.fr http://layers.openstreetmap.fr, lequel en revanche n'affiche rien pour admin_level=11... n'utilisez pas Layers pour ça: utilisez plutôt Overpass Turbo, en plus le résultats est quasiment instantané, le rendu vectoriel est fait sur votre navigateur; Layers a trop de travail et manque de ressources pour mettre à jour ses bitmaps en un temps raisonnable) [/notes] Il est grands temps de standardiser un place=* convenable pour ces places (oui ce sont bien des lieux qu'on ne peut pas confondre avec des lieux-dits place=locality utilisés aussi par endroits, toujours à cause du manque de consensus, afin qu'ils puissent être indexés et trouvés indépendamment des rues qui les traversent. place=plazza me semble tres approprié ! Ok je rajouterai peut-être place=plazza alors aussi. Merci pour vos réponses. Xavier. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Panneau de signalisation A13a
Bonjour - Mail original - De: Jo winfi...@gmail.com À: Discussions sur OSM en français talk-fr@openstreetmap.org Dessiner la piste cyclable comme chemin séparé? S'ils ont réussi d'intercaler un panneau, il doît y avoir une séparation entre les deux? - Mail original - Oui oui, c'est bien une piste cyclable (highway=cycleway), et non une bande cyclable( highway=* + cycleway=lane), donc il y a séparation physique. Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Panneau de signalisation A13a
Le 31 mars 2015 à 11:59, Jo winfi...@gmail.com a écrit : Chez Mapillary le jeu de panneaux est encore assez incomplet. Ne pas hésiter à leur en proposer d’autres sur https://github.com/mapillary/traffico/issues https://github.com/mapillary/traffico/issues et sur https://github.com/mapillary/mapillary_issues/issues https://github.com/mapillary/mapillary_issues/issues (pour les panneaux existant dans trafic mais pas encore implémentés dans Mapillary). Ils ont un panneau avec deux enfants qui courent. Aucune idée dans quel pays celui-là est utilisé. Apparemment, tous les pays d’Europe : http://fr.wikipedia.org/wiki/Comparaison_des_panneaux_de_signalisation_routière_en_Europe http://fr.wikipedia.org/wiki/Comparaison_des_panneaux_de_signalisation_routi%C3%A8re_en_Europe — Yves___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Panneau de signalisation A13a
Les deux son complémentaire à mon sens. C'est le panneau qui implique la caractéristique de la voie soit en son implantation soit avec une distance prédéfini. C'est le code de la route et la signalisation qui donne les caractéristiques. On ne peut pas se baser juste sur la proximité d'une école car dans ce cas il faudrait générer des isochrone autour de toute les écoles (v'est pas toutes les routes qui sont à proximité de l'école qui sont touchés mais celles donnent accès aux entrée et aux zones de stationnement à proximité ou/et zones de tranport en commun. Vu le nombre de traffic_sign et autre saisie on ne peut pas considérer que c'est une question dénuer de sens même si c'est long et fastidieux à saisir tout comme les informations d'éclairage public(autre sujet) ... qui permettrait de faire des analyses de pollution lumineuse pour les différentes villes et ainsi d'améliorer les réseaux publics (consommation en outre) Bref je vais pas rentrer dans un débat sur ce qui est considéré utile ou pas. C'est un panneau comme un autre. Les panneaux publicitaires sont aussi saisie... L'intérêt peut être faible mais ce genre de panneau peut aussi être (et à déjà été) mis en cause dans le cadre d'analyse accidentogène (Genre les pub Aubade). Il faut pas oublier que c'est une base de données et que les utilisations sont pas forcément les même sur toutes les communes (même si elle a vocation à répondre à un contexte générale) le contenu dépend quand même fortement de l'effort de contribution et du nombre de contributeurs. Donc en effet c'est pas la priorité pour certains... Mais je m'occupe déjà de ce qu'il se passe autour de chez moi car j'ai la connaissance pour le faire. Quand j'aurai fini mon quartier, je m'occuperai de ceux d'à coté et ainsi de suite (ou des lieux dans lesquels je suis en visite) Chacun sa méthode et il me semble qu'il y en a dont c'est le taf donc c'est encore un autre contexte. ERDF saisie les pylônes et les lignes. Perso j'ai pas la connaissance pour m'en occupé et j'ai pas spécialement envie de saisir cela... Plus généralement, doit-on mapper les panneaux ou ce qu'ils décrivent ? Je pense que les gens qui exploite et développe des soft d'itinéraire en serai ravi car dans les carrefours complexe je préférerai entendre prendre la direction de Paris plutôt que Tourner à gauche puis tourner franchement à droite dans 10m On a des panneaux devant les yeux et c'est ça qui devrait prédominer dans l'affichage Les infos sur le réseau genre dans les ways sont purement utilisé à titre de calcul de temps de déplacement et de plus court chemin (à l'affichage c'est que du sens unique qui et visible et l'importance que l'on veut bien donner à une voirie). Donc les vitesses sur la carte c'est les panneaux qui les donnent (sauf carto spécifique sur les vitesses) Il perd son sens, (litt. et fig.) quand le chemin est découpé sur ce nœud-là En effet dans ce cas c'est compliqué et doit ton faire un panneau hors du réseau dans ce cas à son implantation réel et définir une relation (via, from, to) ...? @Jo: RoadSigns ou Mapillary ont-ils une réponse pour le cas du panneau dont je parlais et des autres panneau moins conformes qui exister (non remplacer et pas au standard CE ou NF) ? Question implantation c'est toujours un dilemme entre implanter le panneau sur le réseau comme pour les vitesses de circulation ou les entrées de ville ou le mettre à son emplacement réel avec une éventuelle relation sur le réseau dans le cas ou le panneau aurait une implication réel dans la qualification de celui-ci. Le 31 mars 2015 10:42, Pieren pier...@gmail.com a écrit : 2015-03-31 9:38 GMT+02:00 Christian Quest cqu...@openstreetmap.fr: En général dans OSM on décrit plutôt la finalité (le nom d'une rue sur le tronçon de la rue ou le fait qu'elle soit en sens unique) que le panneau lui même (qui mappe les plaques de rue ou les panneaux de sens unique ?). Pourtant, un traffic_sign=FR:B1 est beaucoup plus clair qu'un oneway=yes... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Panneau de signalisation A13a
Il perd son sens, (litt. et fig.) quand le chemin est découpé sur ce nœud-là En effet dans ce cas c'est compliqué et doit ton faire un panneau hors du réseau dans ce cas à son implantation réel et définir une relation (via, from, to) ...? Moi, je n'ai pas peur des relations, mais pour la plupart des contributeurs ils ne les aiment pas... @Jo: RoadSigns ou Mapillary ont-ils une réponse pour le cas du panneau dont je parlais et des autres panneau moins conformes qui exister (non remplacer et pas au standard CE ou NF) ? Chez Mapillary le jeu de panneaux est encore assez incomplet. Ils ont un panneau avec deux enfants qui courent. Aucune idée dans quel pays celui-là est utilisé. En RoadSigns on peut définir ce que l'on veut. Mais il n'y a pas encore bcp de pays pour lesquels c'est déjà fait. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] FFRandonnée ? de quoi rire encore un moment (jaune ?)
Le 31 mars 2015 à 09:32, Christian Quest cqu...@openstreetmap.fr a écrit : Le 30/03/2015 21:01, Christian Rogel a écrit : J'emploie le terme propriété intellectuelle en visant le droit moral de l'auteur qui, en droit français, est inaliénable, mais, maintenant, est limité à 70 ans. La FFR s'est vu reconnaître ce droit moral par le tribunal, ce qui lui permet d'en contrôler l'exploitation commerciale par elle-même ou par ceux quelle désigne. Il me semble que le transfert du droit moral prévu par les CT d'OSM aurait été illégal en France. Christian R. Dans UN cas la FFRP s'est vue reconnaître ce droit par un tribunal, et dans un autre elle a été déboutée. C'est trop mince pour généraliser... Pour les CT d'OSM, peut-on vraiment parler de propriété intellectuelle vis à vis de nos contributions ? En principe non, car il elle n'ont rien d'originales vu qu'elles se basent en principe sur des faits vérifiables, constatables par tous. Ce qui complique la comparaison entre le droit moral à la française et ses équivalents étrangers, c'est que la source du droit est la même (convention de Berne) et l'interprétation différente. Dans la pratique, en droit anglo-saxon, le droit moral est effacé au profit du droit commercial. OSM visait donc l'obtention des droits commerciaux pour sécuriser leur cession par licence libre et s'est assise, au passage, sur les droits moraux éventuels qui, en droit français, auraient été incessibles. Christian R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Panneau de signalisation A13a
Bonjour - Mail original - De: Jo winfi...@gmail.com Néanmoins, moi j'ajouterai les panneaux comme noeud isolé, exactement où se trouve le panneau. - Mail original - Le wiki l'autorise (comme un point du chemin ou comme un point isolé à proximité du chemin) . C'est parce que j'ai pris l'habitude de déjà placé les highway=stop highway=give_way sur les chemins que je continue. Maintenant si c'est la position physique, que faire lorsqu'il y a une voie de circulation automobile et en parallèle une piste cyclable et que le panneau est entre les 2 (car physiquement il n'y a pas de place à droite de la piste cyclable pour placer les panneaux). Le positionnement sur le chemin permet dans cette situation de connaitre l'effet impliqué sur ledit chemin. Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nice, rajouter une place
@Brice: Par contre je viens de voir que tu parlais de highway=residential pour une place. Il me semble que sur la page du tag *highway* http://wiki.openstreetmap.org/wiki/Key:highway ce couple de clé valeur n'est a exploiter qu'en linéaire. Il n'y a que *highway=service* et *highway=pedestrian* qui accepte des tracés fermés et dans le cas de la valeur pedestrian il faut bien mettre *area=yes *en plus car par défaut c'est un tracé ouvert Pour service on ne peut pas avoir plus de détails car *service=** n'accepte que du tracé ouvert à moins de compléter les règles. Le 31 mars 2015 11:22, Xavier Cremaschi omega.xav...@gmail.com a écrit : Le 31/03/2015 10:43, Xavier Cremaschi a écrit : J'ai : - mis area=yes - retiré place=locality (j'avais vu ça sur la Place Massena, plus au sud si vous suivez l'avenue Jean Médecin) - mis puis retiré highway=pedestrian (la place est principalement piétonne, mais elle est coupé par le tram dans le sens nord/sud et par une rue dans le sens est/ouest, et je n'ai aucune idée des relations à mettre entre tout ça pour ne pas casser ces axes de communications et/ou les espaces verts) Par contre ça serait bien que ça apparaisse sur le rendu et dans la recherche de nom, vu que je l'ai rajoutée pour ça à l'origine (pas de résultat en cherchant 'place de gaulle'), donc il manque encore sans doute un tag ou deux :/ ___ 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] Nice, rajouter une place
Le 31/03/2015 10:43, Xavier Cremaschi a écrit : J'ai : - mis area=yes - retiré place=locality (j'avais vu ça sur la Place Massena, plus au sud si vous suivez l'avenue Jean Médecin) - mis puis retiré highway=pedestrian (la place est principalement piétonne, mais elle est coupé par le tram dans le sens nord/sud et par une rue dans le sens est/ouest, et je n'ai aucune idée des relations à mettre entre tout ça pour ne pas casser ces axes de communications et/ou les espaces verts) Par contre ça serait bien que ça apparaisse sur le rendu et dans la recherche de nom, vu que je l'ai rajoutée pour ça à l'origine (pas de résultat en cherchant 'place de gaulle'), donc il manque encore sans doute un tag ou deux :/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Panneau de signalisation A13a
Maintenant si c'est la position physique, que faire lorsqu'il y a une voie de circulation automobile et en parallèle une piste cyclable et que le panneau est entre les 2 (car physiquement il n'y a pas de place à droite de la piste cyclable pour placer les panneaux). Le positionnement sur le chemin permet dans cette situation de connaitre l'effet impliqué sur ledit chemin. Dessiner la piste cyclable comme chemin séparé? S'ils ont réussi d'intercaler un panneau, il doît y avoir une séparation entre les deux? Jo ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Tag pour les bornes de stionnement payant
Comment peut-on taguer cela ? https://cecilegladel.files.wordpress.com/2007/08/dscn4845.jpg Merci ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag pour les bornes de stionnement payant
Bonjour - Mail original - De: Jérôme Seigneuret jseigneuret-...@yahoo.fr Comment peut-on taguer cela ? - Mail original - amenity=vending_machine vending=parking_tickets payment:coins=yes -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] FFRandonnée ? de quoi rire encore un moment (jaune ?)
Salut, Le lundi 30 mars 2015 16:48:41 JB a écrit : Bon, comme j'étais de retour dans le Puy de Dôme pour deux mois, je me dis qu'il faudrait trouver à récupérer leur réseau de chemins inscrits au PDIPR qui a l'air bien fichu, et proposer une Grande Traversée de la Chaine des Puys, parce que le circuit de la FFRP est vraiment pourri… JB. Oui, il y a matière à faire. J'avais contacté le CG au sujet du PDIPR sans succès. C'était il y a 2 ans, je viens de le relancer le contact PDIPR du CD :-) -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Éclairage public
J'ai vu le couple *highway=street_lamp http://taginfo.openstreetmap.fr/tags/highway=street_lamp#map . *Celui-ci indique l'implantation des éclairages (lampadaire) Il y a aussi *lit=yes*, ou* lit=no* et autres combinaisons basés sur la fréquence d'éclairage. Utilisez-vous ces tags? Pour lit en zone urbaine j'ai pas vu de concensus entre dire que par défaut c'est éclairé ou l'inverse... Malheureusement *street_lamp* n'est pas très utilisé encore (environ 12500 entrées). J'ai vu cela http://lightmap.uni-hd.de/ mais c'est restreint. Est il possible de créer une couches de la même manière pour le territoire français avec les voies éclairés et les implantations des lampadaires? Cela permettrait de monter des études sur la pollution lumineuse ;-). Il me semble que Toulouse utilise des lampadaires automatique (d'autres villes aussi mais j'ai vu ça que là-bas ;) ) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Imagerie Yamoussoukro
Comment peut-on avoir un imagerie de Yamoussoukro plus claire ? si c'est possible bien evidement ? Dans le cadre de projets humanitaires, des images aériennes plus récentes ou plus précises sont rendues accessibles. Il y a en a peut-être dans cette zone. Tu trouveras éventuellement ça sur http://tasks.hotosm.org Tu peux aussi t’adresser à la liste hot-francoph...@openstreetmap.org — Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Mapillary gère dorénavant les vidéos
Bonjour, Une nouvelle vue sur leur newsletter : Introducing Video Upload a Manual Upload Update http://blog.mapillary.com/update/2015/03/31/video-upload.html Je me souviens d’un cycliste d’Île de France qui documente les itinéraires cyclables à partir de vidéos… — Yves___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Publications libres
Bonjour, Le lundi 30 mars 2015 11:25:26 Pierre Knobel a écrit : En farfouillant sur un site de publications scientifiques libres, j'ai découvert qu'on y trouvait un certain nombre d'articles qui nous concernent. Je n'ai pas encore trouvé comment faire une recherche incluant le corps de l'article, mais rien qu'en cherchant dans les titres on trouve déjà de belles choses : http://www.mdpi.com/search?q=openstreetmapsearch=Search http://www.mdpi.com/search?q=volunteeredsearch=Search http://www.mdpi.com/search?q=mapsubjects=computer-math%2Cengineering%2Cenvi ronment%2Carts-humanity Si tu l'as ratée, voici une thèse soutenue en 2014 qui parle d'OSM. Donc potentiellement des refs intéressantes dedans … http://www.geog.uni-heidelberg.de/md/chemgeo/geog/gis/dissertation_pascal_neis_reduced.pdf[1] -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin [1] http://www.geog.uni-heidelberg.de/md/chemgeo/geog/gis/dissertation_pascal_neis_reduced.pdf ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Éclairage public
ITO fait ce genre de carte : http://www.itoworld.com/map/69?lon=5.00559lat=45.86048zoom=8 Par contre, j'ai l'impression que les tuiles sont générées à la demande, ce qui fait que c'est parfois (souvent?) lent a arriver. 2015-03-31 16:26 GMT+02:00 Jérôme Seigneuret jseigneuret-...@yahoo.fr: J'ai vu le couple *highway=street_lamp http://taginfo.openstreetmap.fr/tags/highway=street_lamp#map . *Celui-ci indique l'implantation des éclairages (lampadaire) Il y a aussi *lit=yes*, ou* lit=no* et autres combinaisons basés sur la fréquence d'éclairage. Utilisez-vous ces tags? Pour lit en zone urbaine j'ai pas vu de concensus entre dire que par défaut c'est éclairé ou l'inverse... Malheureusement *street_lamp* n'est pas très utilisé encore (environ 12500 entrées). J'ai vu cela http://lightmap.uni-hd.de/ mais c'est restreint. Est il possible de créer une couches de la même manière pour le territoire français avec les voies éclairés et les implantations des lampadaires? Cela permettrait de monter des études sur la pollution lumineuse ;-). Il me semble que Toulouse utilise des lampadaires automatique (d'autres villes aussi mais j'ai vu ça que là-bas ;) ) ___ 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] Publications libres
Bonjour, J'avais commis cet article pour la revue Espaces tourisme loisirs et mis comme condition qu'il soit sous licence libre : Openstreetmap crée des données libres pour le territoire - le projet dessine ta ville http://apitux.com/medias/apitux-revue-espaces-article-becquet-jean-christophe-openstreetmap-cree-des-donnees-libres-pour-le-territoire-le-projet-dessine-ta-ville.pdf Licence Creative Commons BY-SA Bonne journée Librement JCB -- Libérez vos créations http://www.apitux.org/index.php?2008/05/03/232-liberez-vos-creations ==APITUX : le choix du logiciel libre== APITUX - Jean-Christophe Becquet BP 32 - 04001 Digne-les-Bains Cedex 06 25 86 07 92 - j...@apitux.com - http://www.apitux.com/ SIRET : 452 887 441 00031 - APE : 6202A === ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tours penchées
voila ce que ca donne : http://gis.19327.n5.nabble.com/file/n5839259/angle-tilt.jpg http://gis.19327.n5.nabble.com/file/n5839259/width-tilt.jpg http://gis.19327.n5.nabble.com/file/n5839259/shearing_angle-tilt.jpg je vais faire la même chose pour les parts par contre coté type de leaning, j'ai pas trouvé de bon termes, on a le batiment qui est penché completement, genre tour de pise, on a celui qui est incliné, mais ou chaque étage est a plat, genre porte de l'europe (madrid) - pour le moment j'ai mis shearing pour ceux la. et on peux aussi imaginer mettre un type pour les encorbellements (par exemple half-shearing). -- View this message in context: http://gis.19327.n5.nabble.com/tours-penchees-tp5836844p5839259.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
Re: [OSM-talk-fr] Tag pour les bornes de stionnement payant
amenity=vending_machine vending=parking=_tickets http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dvending_machine Le 31/03/2015 15:00, Jérôme Seigneuret a écrit : Comment peut-on taguer cela ? https://cecilegladel.files.wordpress.com/2007/08/dscn4845.jpg Merci ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Manque d'attribution sur le logiciel Artelys Crystal Super Grid
Bonsoir, J'ai remarqué un manque d'attribution sur les vues du logiciel Artelys Crystal Super Grid utilisé pour représenter des échanges d'énergie sur les réseaux de transport électrique. Les captures d'écran sont visibles ici http://www.artelys.com/fr/applications/artelys-super-grid Et la source de mon info https://twitter.com/pleiades2015/status/582859340375302144 C'est très positif de retrouver ce genre d'utilisation, surtout sur un logiciel de ce type et connaissant mes centres d’intérêt. Néanmoins, rien ne les empêche de faire les choses normalement. Dois-je transmettre l'info à d'autres ? Bonne soirée *François Lacombe* fl dot infosreseaux At gmail dot com www.infos-reseaux.com @InfosReseaux http://www.twitter.com/InfosReseaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Imagerie Yamoussoukro
Bonjour à tous, J'ai un ami qui vient de s'installer à Yamoussoukro, la capital de la Côte d'Ivoire. Autant l'imagerie sur Abidjan est génial, autant celle de Yamoussoukro est illisible. J'aimerais l'aider et avancer sur cette ville. Comment peut-on avoir un imagerie de Yamoussoukro plus claire ? si c'est possible bien evidement ? Merci de l'info @+ Piwi ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag pour les bornes de stionnement payant
Le 31 mars 2015 15:00, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : Comment peut-on taguer cela ? https://cecilegladel.files.wordpress.com/2007/08/dscn4845.jpg Merci amenity=vending_machine vending=parking_tickets http://wiki.openstreetmap.org/wiki/Tag:vending%3Dparking_tickets ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de schéma de tags pour améliorer la cartographie des arbres
On peut typer les branches et aller jusqu'aux les bourgeons, nervures et découpes externes des feuilles, ou des pétales des fleurs ou leurs étamines et pistils, les épines des branches, feuilles ou fruits, ou les radicules, rhizomes ? et la position des greffons d'une autre espèce que le porteur? et typer les branches mortes/brisées/sciées, les feuilles seches qui vont tomber, leur poids, leur hygrométrie, les maladies, les traitements appliqués ? et la stabilité et l'emplacement des points d'accroche (câbles ou poteaux de soutien, tiges naturelles enroulées sur un grillage ou un tuteur, et les types de tuteurs? et les trous et nids d'oiseaux et insectes ou nichages de petits rongeurs au pied de l'arbre entre les racines, ou les meilleures branches où viennent se prélasser les mammiferes (fauves, singes et même humains) ? et encore les meilleurs endroits pour appuyer une échelle pour y aller ou pour la cueillette ou construire une cabane? et la production fruitiere, de seve, et leur poids et qualité gustative ou esthétique? et celle de bois et écorces de coupe, ou petits bois, pour le chauffage et le prix moyen à la stere (en plusieurs devises tant qu'à faire et sur plusieurs marchés, avec les frais de transaction, de change, les taxes et le transport par kilo ou par tonne) et la consommation de CO2 diurne et sa production nocturne (avec relevés calendaires réguliers sur plusieurs années) et des autres gaz produits (aromatiques ou de dégradation) ainsi que les éléments puisées ou injectés dans le sol et l'eau, la composition de la sève? - allons plus loin, comptons et cartographions les cellules des différents organes, et les éléments internes (filaments, chloroplastes, ribosomes, ... avec leur génome respectif si nécessaire) et pourquoi pas le génôme nucléaire complet, les mutations gène par gène, et la conformation spatiale des gènes et protéines, et la position des ponts sulfurés, inter-amines ou acido-basiques, et les pôles électromagnétiques du génome et de ses copies extranucléaires, le tout selon la température, l'hygrométrie, les saturations en minéraux? ;-) Le 1 avril 2015 00:29, Vincent de Château-Thierry v...@laposte.net a écrit : Chalut, Le 01/04/2015 00:02, Frédéric Rodrigo a écrit : On commence donc par décrire le tronc, longueur, direction et l'inclinaison : - tree:trunk:length=* (en m par défaut, mais d'autres unités restent bien sûr possible, c'est important) Puis les branches ou la suite du tronc : - tree:trunk:trunk:length=* Et pour chaque branche : - tree:trunk:branch[X]:length=* On va enfin pouvoir décrire les soles pleureu(ses|rs) :D Mais il manque les racines, dans ton schéma. Je propose des indices négatifs, à l'image des layers : root[-2]:root[-1]:tree:trunk:... ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Proposition de schéma de tags pour améliorer la cartographie des arbres
Bonjour, Suite aux discussions très intéressantes sur le la façon de tagger les bâtiments qui penchent (à l'extérieur, comme à l'intérieur) et également aux éclairages pertinents de Mr. Verdy sur la question, il m'a paru clair qu'il était possible de se baser sur ce même principe pour l'appliquer à la micro-cartographie des arbres. Jusqu'à présent pour cartographie un arbre on utilise : natural=tree adjoint éventuellement de tags pour en décrire la nature, le genre ou l'espèce (genus=*, species=*, taxon=*). Une autre partie des tag permettent de d'écrire l'instance de l'arbre : circumference=*, height=* et même l'age. Cependant cela ne permet toujours d'avoir une idée plus précise de ce à quoi ressemble l'arbre. Une tentative de cartographie des arbres en 3D est disponible sur le wiki, où l'on peut décrire la forme générale de l'arbre et l'inclinaison du tronc, mais ce n'est pas suffisant : http://wiki.openstreetmap.org/wiki/Tree_table Ce que je propose, donc en partant de l'idée des bâtiments inclinés, c'est de décrire les arbres de façon arborescente (je sais elle est facile ;) ). On commence donc par décrire le tronc, longueur, direction et l'inclinaison : - tree:trunk:length=* (en m par défaut, mais d'autres unités restent bien sûr possible, c'est important) - tree:trunk:direction=* (en degré par rapport au nord, dans le sens anti-horaire, c'est plus naturel par rapport à l'orientation de la végétation vis-à-vis de la course du soleil, mais c'est du détail), si le tronc est parfaitement droit, et donc que la direction est de 0° on peut l'omettre. - tree:trunk:inclination=* (en degré, idem omettable si pas d'inclinaison, l’inclinaison doit être absolue par rapport à l'horizontale, et pas rapport à l'inclinaison du sol bien sûr !) À noter pour Omsose, s'il y a une inclinaison il y a forcément une direction (et réciproquement). Puis les branches ou la suite du tronc : - tree:trunk:trunk:length=* - tree:trunk:trunk:direction=* (en degré par rapport au nord, c'est-à-dire de façon absolue, ou alors de façon relative à la direction du segment précédent en préfixant le nombre par « + » ou « - »). - tree:trunk:trunk:inclination=*, idem, simple combinaison de tree:trunk:trunk:direction=* et tree:trunk:inclination=*. Et pour chaque branche : - tree:trunk:branch[X]:length=* - tree:trunk:branch[X]:direction=* - tree:trunk:branch[X]:inclination=* Il faut remplacer X par un numéro d'ordre sur le nœud, pas besoin d'ordre particulier, juste besoin de les numéroter pour pouvoir suivre la branche. Cela dépend des espèces, certaines espèces n'ont pas plus d'une seule branche par nœud, on peut dans ce cas également ne pas mentionner le numéro d'ordre. L'avantage c'est que l'on peut ainsi continuer ou s'arrêter quand on veut, on est en plein dans l'idée simple d'OSM, contribution itérative. Un premier contributeur ne cartographie que les grosses branches, puis un autre peut aller plus loin ou mettre à jour parce que de nouvelles branches ont poussées. Pour l'exemple : tree:trunk:length=4.32 tree:trunk:direction=7.7 tree:trunk:inclination=2.4 tree:trunk:trunk:length=1.28 tree:trunk:trunk:direction=-1.8 tree:trunk:trunk:inclination=+2.6 tree:trunk:branch[1]:length=0.8 tree:trunk:branch[1]:direction=+5.7 tree:trunk:branch[1]:inclination=-9.8 tree:trunk:branch[1]:branch[1]:length=0.5 tree:trunk:branch[1]:branch[1]:direction=+6.8 tree:trunk:branch[1]:branch[1]:inclination=+3.2 tree:trunk:branch[1]:branch[2]:length=0.5 tree:trunk:branch[1]:branch[2]:direction=+6.8 tree:trunk:branch[1]:branch[2]:inclination=+3.2 tree:trunk:branch[2]:length=0.6 tree:trunk:branch[2]:direction=-9.4 tree:trunk:branch[2]:inclination=+4.6 tree:trunk:branch[2]:branch:length=0.2 tree:trunk:branch[2]:branch:direction=+4.9 tree:trunk:branch[2]:branch:inclination=+4.8 tree:trunk:trunk:trunk:length=0.8 tree:trunk:trunk:trunk:direction=+8.6 tree:trunk:trunk:trunk:inclination=-7.8 L'avantage de cette façon de faire est de pouvoir rester concis, un seul nœud suffit, pas besoin de cartographier les branches avec des ways. Certains vont penser que ce n'est que pour le rendu, mais on peut faire bien plus de choses avec, par exemple du calcul d'itinéraires ou d’ensoleillement par ombre porté sur le feuillage en fonction de l'espèce de l'arbre. J'espère que des moteurs 3D comme F4 pourront rapidement prendre en compte cette approche, le résultat sera quand même beaucoup plus réaliste. Je suis ouvert à vos remarques avant de faire une proposition en bon et due forme sur le wiki puis sur la liste tagging. Note, il faudra maintenant aller mapper avec des boussoles, des niveaux et des compas ; mais nos chers smartphones font déjà tout ça ! Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de schéma de tags pour améliorer la cartographie des arbres
Chalut, Le 01/04/2015 00:02, Frédéric Rodrigo a écrit : On commence donc par décrire le tronc, longueur, direction et l'inclinaison : - tree:trunk:length=* (en m par défaut, mais d'autres unités restent bien sûr possible, c'est important) Puis les branches ou la suite du tronc : - tree:trunk:trunk:length=* Et pour chaque branche : - tree:trunk:branch[X]:length=* On va enfin pouvoir décrire les soles pleureu(ses|rs) :D Mais il manque les racines, dans ton schéma. Je propose des indices négatifs, à l'image des layers : root[-2]:root[-1]:tree:trunk:... Comme ça on peut creuser. Voire trouver de l'eau. L'avantage de cette façon de faire est de pouvoir rester concis, un seul nœud suffit, pas besoin de cartographier les branches avec des ways. Certains vont penser que ce n'est que pour le rendu, mais on peut faire bien plus de choses avec, par exemple du calcul d'itinéraires ou d’ensoleillement par ombre porté sur le feuillage en fonction de l'espèce de l'arbre. Pour le calcul d'itinéraire, cette approche permet enfin de parcourir les arêtes. Il était temps, je vote pour. J'espère que des moteurs 3D comme F4 pourront rapidement prendre en compte cette approche, le résultat sera quand même beaucoup plus réaliste. Je suis ouvert à vos remarques avant de faire une proposition en bon et due forme sur le wiki puis sur la liste tagging. Sur le wiki ? Aqua bon. Note, il faudra maintenant aller mapper avec des boussoles, des niveaux et des compas ; mais nos chers smartphones font déjà tout ça ! Frédéric. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de schéma de tags pour améliorer la cartographie des arbres
Le 01/04/2015 00:02, Frédéric Rodrigo a écrit : Bonjour, Suite aux discussions très intéressantes sur le la façon de tagger les bâtiments qui penchent (à l'extérieur, comme à l'intérieur) et également aux éclairages pertinents de Mr. Verdy sur la question, il m'a paru clair qu'il était possible de se baser sur ce même principe pour l'appliquer à la micro-cartographie des arbres. Jusqu'à présent pour cartographie un arbre on utilise : natural=tree adjoint éventuellement de tags pour en décrire la nature, le genre ou l'espèce (genus=*, species=*, taxon=*). Une autre partie des tag permettent de d'écrire l'instance de l'arbre : circumference=*, height=* et même l'age. Cependant cela ne permet toujours d'avoir une idée plus précise de ce à quoi ressemble l'arbre. Une tentative de cartographie des arbres en 3D est disponible sur le wiki, où l'on peut décrire la forme générale de l'arbre et l'inclinaison du tronc, mais ce n'est pas suffisant : http://wiki.openstreetmap.org/wiki/Tree_table Ce que je propose, donc en partant de l'idée des bâtiments inclinés, c'est de décrire les arbres de façon arborescente (je sais elle est facile ;) ). On commence donc par décrire le tronc, longueur, direction et l'inclinaison : - tree:trunk:length=* (en m par défaut, mais d'autres unités restent bien sûr possible, c'est important) - tree:trunk:direction=* (en degré par rapport au nord, dans le sens anti-horaire, c'est plus naturel par rapport à l'orientation de la végétation vis-à-vis de la course du soleil, mais c'est du détail), si le tronc est parfaitement droit, et donc que la direction est de 0° on peut l'omettre. - tree:trunk:inclination=* (en degré, idem omettable si pas d'inclinaison, l’inclinaison doit être absolue par rapport à l'horizontale, et pas rapport à l'inclinaison du sol bien sûr !) À noter pour Omsose, s'il y a une inclinaison il y a forcément une direction (et réciproquement). Puis les branches ou la suite du tronc : - tree:trunk:trunk:length=* - tree:trunk:trunk:direction=* (en degré par rapport au nord, c'est-à-dire de façon absolue, ou alors de façon relative à la direction du segment précédent en préfixant le nombre par « + » ou « - »). - tree:trunk:trunk:inclination=*, idem, simple combinaison de tree:trunk:trunk:direction=* et tree:trunk:inclination=*. Et pour chaque branche : - tree:trunk:branch[X]:length=* - tree:trunk:branch[X]:direction=* En fonction du nord géographique ou magnétique ? - tree:trunk:branch[X]:inclination=* Il faut remplacer X par un numéro d'ordre sur le nœud, pas besoin d'ordre particulier, juste besoin de les numéroter pour pouvoir suivre la branche. Cela dépend des espèces, certaines espèces n'ont pas plus d'une seule branche par nœud, on peut dans ce cas également ne pas mentionner le numéro d'ordre. L'avantage c'est que l'on peut ainsi continuer ou s'arrêter quand on veut, on est en plein dans l'idée simple d'OSM, contribution itérative. Un premier contributeur ne cartographie que les grosses branches, puis un autre peut aller plus loin ou mettre à jour parce que de nouvelles branches ont poussées. Et chaque année on ajoute les nouvelles branches... Simple comme schéma. À moins qu'un bon bot qui enregistre la météo au jour le jour pour l'emplacement fasse le calcul de croissance lui-même et produise un fichier de mise à jour. Parce qu'on fait de l'intégration, hein ! pas de l'import de données. Pour l'exemple : tree:trunk:length=4.32 tree:trunk:direction=7.7 tree:trunk:inclination=2.4 tree:trunk:trunk:length=1.28 tree:trunk:trunk:direction=-1.8 tree:trunk:trunk:inclination=+2.6 tree:trunk:branch[1]:length=0.8 tree:trunk:branch[1]:direction=+5.7 tree:trunk:branch[1]:inclination=-9.8 tree:trunk:branch[1]:branch[1]:length=0.5 tree:trunk:branch[1]:branch[1]:direction=+6.8 tree:trunk:branch[1]:branch[1]:inclination=+3.2 tree:trunk:branch[1]:branch[2]:length=0.5 tree:trunk:branch[1]:branch[2]:direction=+6.8 tree:trunk:branch[1]:branch[2]:inclination=+3.2 tree:trunk:branch[2]:length=0.6 tree:trunk:branch[2]:direction=-9.4 tree:trunk:branch[2]:inclination=+4.6 tree:trunk:branch[2]:branch:length=0.2 tree:trunk:branch[2]:branch:direction=+4.9 tree:trunk:branch[2]:branch:inclination=+4.8 tree:trunk:trunk:trunk:length=0.8 tree:trunk:trunk:trunk:direction=+8.6 tree:trunk:trunk:trunk:inclination=-7.8 L'avantage de cette façon de faire est de pouvoir rester concis, un seul nœud suffit, pas besoin de cartographier les branches avec des ways. Certains vont penser que ce n'est que pour le rendu, mais on peut faire bien plus de choses avec, par exemple du calcul d'itinéraires ou d’ensoleillement par ombre porté sur le feuillage en fonction de l'espèce de l'arbre. J'espère que des moteurs 3D comme F4 pourront rapidement prendre en compte cette approche, le résultat sera quand même beaucoup plus réaliste. Je suis ouvert à vos remarques avant de faire une proposition en bon et due forme sur le wiki puis sur la liste tagging.
