Re: [OSM-talk-fr] Recyclage du rendu QA dans osmose: bâti non importé
Le Sat, 25 Jul 2015 23:30:25 +0200, Christian Quest cqu...@openstreetmap.fr a écrit : Encore du recyclage du rendu QA pour osmose... la localisation des communes au bâti non importé. On en compte un peu plus de 4000. Pour cela, la requête compare le nombre de carreaux INSEE sans bâti au nombre total de carreaux dans la commune. Si il y a plus de la moitié et que le cadastre est vectoriel sur la commune, ça remonte dans Osmose... Visible en test ici (serveur de dev d'osmose): http://dev.osmose.openstreetmap.fr/fr/map/#source=10786item=7170class=2 Du coup j'ai terminé l'Yonne ce soir :) Il me semble qu'il y a des faux positifs pour le bati sur le site de rendu QA : exemple ce carreau bleu à cet endroit : http://www.openstreetmap.org/#map=17/48.60845/-4.15860 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Alors pour répondre à la question de Jérôme sur la gestion des conflits: Avant je ne considérais que l'arbre existant le plus proche de l'arbre importé. Mais comme je disais dans un post précédent: la gestion des multi matching trees (ie. les arbres existants qui sont dans le rayon de plusieurs arbres importés) est très basique puisque je met à jour l'élément avec les valeurs du 1er arbre importé tout simplement (pour les autres éléments importés je créé donc un nouvel élément). Comme tu l'as remarqué Jérôme il y a aucun tag taxon ou genus sur l'ensemble des arbres existants de Nice, ce qui est une mauvaise chose dans l'absolu... mais plutôt une bonne chose pour mon import ! :p Ceci dit on était pas à l'abri de cas problématiques, imaginons 2 arbres importés I1, I2 et 3 arbres existants E1, E2, E3 (et que le rayon est de 5m). I12mE1 I13mE2 I21mE1 I24mE3 Avant si je tombais d'abord sur I1 j'utilisais E1 pour le mettre à jour et laissait E2 tel quel. Sauf que I2 est encore plus proche de E1, il devrait être donc être mis à jour pour I2 et c'est E2 qui devrait être mis à jour pour I1. C'est maintenant le cas car je conserve pour chaque arbre existant l'arbre importé le plus proche. - si l'arbre importé n'est pas le meilleur candidat (ie. il y a un autre arbre importé qui est plus proche de l'arbre existant), j'essaye avec les autres arbres existants qui étaient dans son rayon (et s'il n'y a plus d'autres arbres existants alors il faudra créer un nouvel élément) - si l'arbre importé est le meilleur candidat, je peux alors utiliser l'arbre existant pour le mettre à jour. Mais je dois alors relancer tout le processus pour l'ancien meilleur arbre importé qui à son tour pourrait éventuellement faire des changements (fonction récursive). Bon c'est pas évident d'expliquer tout ça par mail mais vous pouvez voir les sources ici: https://github.com/vince-from-nice/osmaxil/blob/master/src/main/java/org/openstreetmap/osmaxil/plugin/maker/NiceTreeMaker.java Il faut que je fasse plus de vérifications mais ça a l'air de bien fonctionner. De plus, comme je suis sûr d'associer l'arbre existant avec l'arbre importé le plus proche, je peux me permettre d'augmenter le rayon (là j'ai mis 5 mètres). D'ailleurs je peux attacher le résultat sur la mailing list (environ 500KB) ? PS: outch j'avais pas vu tous les mails qui s'était accumulés depuis que j'ai commencé mon mail hier soir ! Je vais essayer d'y répondre un peu plus tard... ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tuiles vectorielles et internationales
à rapprocher de :
http://wiki.openstreetmap.org/wiki/Proposed_features/Language_of_this_element
sauf que je pense utiliser l'inclusion pour avoir des valeurs par défaut.
Jean-Yvon
Le 26/07/2015 15:44, osm.sanspourr...@spamgourmet.com a écrit :
/- impossible de savoir dans quelle lanque est le name par défaut
(ou alors il faudrait ajouter un tag pour l'indiquer)//
/ Est-ce que la langue de name ne devrait pas être déterminée par la
relation / les polygones (de type boundary ?) englobants ?
La langue principale de la France est le français, donc les name en
France sont en français. Un peu comme on a timezone.
Actuellement je ne trouve l'info que sur le wiki, alors que si on
avait un default_language=fr (par exemple) voir un
default_language={{fr}} - {{de}} (lire : le name c'est name:fr suivi
de name:de séparés par - ).
Mais mettre l'info sur les objets englobants suffit.
Bon, pour des règles comme langue X et Y par ordre alphabétique
international ça ne marche pas.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] tuiles vectorielles et internationales
L'autre solution est un rendu purement vectoriel comme le projet de
Google en WebGL ce qui est généralement horriblement lent.
Purement vectoriel ne veut pas dire laisser le client tout gérer, il
peut y avoir du pré-calcul.
Mais oui, il y a du boulot (comme pour l'internationalisation).
Si on regarde
http://demo.f4map.com/#lat=38.8883621lon=-77.0171328zoom=19camera.phi=-119.519
(je n'ai pas regardé la techno, WebGL je suppose), on voit qu'ils
passent la 2D, 2,5D puis la 3D (arbres, grues pour le tag construction,
vrais modèles 3D hors OSM) pour obtenir de la 3D et c'est encore lent.
Avec des gags dus à l'inhomogénéité des données, ainsi il y a des
bosquets qui y sont et d'autres qui n'y sont pas : n'auraient-ils
importé que les arbres municipaux ? ;-).
Par contre, pas de soucis pour le WebGL en soit.
Le rendu FR est disponible autrement que via umap:
http://tile.openstreetmap.fr/
Merci, je m'en suis rappelé après avoir posté le message.
Nous n'avons cependant jamais fait le pas pour finaliser un site avec
tout les services utiles...
(recherche d'adresse ou POI, calcul d'itinéraire, différents rendus,
etc).
Ce n'est pas par choix, mais plus par manque de disponibilité et
d'huile de coude.
Tu es dans l'optique OpenStreetMap.org redirige vers OpenStreetMap.fr,
j'avais en tête osm.org va chercher les tuiles chez osm.fr.
Les deux possibilités sont intéressantes.
La seconde solution nécessite essentiellement une machine qui accepte le
trafic, on utilise toujours OSM.org pour les outils.
L'un n'empêche pas l'autre : renforcer la structure puis la suite
logicielle.
Dans le second cas il faudrait que les serveurs de tuiles (osm.fr)
puissent s'enregistrer auprès d'osm.org pour apparaître dans les couches
disponibles (en fonction du user agent plus exactement du
Accept-Language ? Si je dis que j'accepte fr/de/en, des couches
produites par osm.fr, osm.de et celles produites en utilisant l'anglais
m'intéressent potentiellement).
/Sinon une question marginale : je vois que pas mal de villes/pays ont
un attribut name:lg qui est identique à l'attribut name.//
//Certes ça permet de savoir que Paris s'écrit Paris en allemand, mais
est-ce bien utile ?//
//name=Paris ne veut-il pas dire que le nom est Paris dans toutes les
langues sauf celles précisées (name:br=Pariz par exemple).//
//Pour le Mont Blanc, on peut imaginer qu'un jour name= change et que
l'on veuille avoir dans tous les cas name:it et name:fr.//
///
///
//On gagnerait très peu (un seul tag de moins) et on perdrait beaucoup://
//- impossible de savoir dans quelle lanque est le name par défaut (ou
alors il faudrait ajouter un tag pour l'indiquer)//
//- complication pour le rendu... sur FR, un simple coalesce permet de
prendre le name:fr si présent, puis name:en, puis intl_name puis name...
sans name:fr sur Londres ça compliquerai énormément !
/Soit tu n'as pas compris ma proposition soit je n'ai pas compris ta
réponse.
Car sur l'exemple ça voudrait dire que le name de Paris est en allemand,
pas en français ;-(.
Le name c'est le nom dans la langue locale, c'est à dire pour Londres
l'anglais (name=London), figure aussi name:fr=Londres et name:en=London.
Tu me dis (je pense) que name:en=London est utile. Soit.
Je disais que name:de=Paris est inutile puisque name=Paris et que si on
ajoute le nom dans toutes les langues du monde alors que c'est le nom
dans la langue locale, ça va alourdir inutilement.
/- impossible de savoir dans quelle lanque est le name par défaut (ou
alors il faudrait ajouter un tag pour l'indiquer)//
/ Est-ce que la langue de name ne devrait pas être déterminée par la
relation / les polygones (de type boundary ?) englobants ?
La langue principale de la France est le français, donc les name en
France sont en français. Un peu comme on a timezone.
Actuellement je ne trouve l'info que sur le wiki, alors que si on avait
un default_language=fr (par exemple) voir un default_language={{fr}} -
{{de}} (lire : le name c'est name:fr suivi de name:de séparés par - ).
Mais mettre l'info sur les objets englobants suffit.
Bon, pour des règles comme langue X et Y par ordre alphabétique
international ça ne marche pas.
L'ordre fr, à défaut en, à défaut international, à défaut name c'est
pour les pays à alphabet non latin ?
Je pensais que l'ordre était /name:fr/, i/ntl_name/, /name/.
Si je prends Nuremberg:
name http://wiki.openstreetmap.org/wiki/FR:Key:name?uselang=fr Nürnberg
name:de http://wiki.openstreetmap.org/wiki/Key:name:de?uselang=fr
Nürnberg
name:en http://wiki.openstreetmap.org/wiki/Key:name:en?uselang=fr
Nuremberg
name:fr http://wiki.openstreetmap.org/wiki/Key:name:fr?uselang=fr
Nuremberg
Ça me semble correct : le nom en français n'est pas le nom en langue
officielle locale (l'allemand), donc on le met.
C'est ce que je disais.
D'après ce que tu dis, s'il n'y avait pas de nom en français il
prendrait le nom en anglais. Ça tomberait juste, mais ça me dérange.
Car si les 6 000
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Je comprends aisément votre méfiance sur les imports automatiques, surtout si ceux ci sont mal faits, ou faits à partir de mauvaises données. Sauf que là je ne pense pas que ça soit le cas car les données importées correspondant bien à la réalité. La précision n'est évidemment pas parfaite, tout comme celles des arbres existants d'ailleurs, mais je pense qu'elle est largement suffisante pour des arbres. Et je pense pas faire ça mal, en tout cas je ne fais pas ça comme un sagouin tout seul dans mon cave: j'essaye de communiquer autant que possible et j'essaye de prendre en compte vos remarques bien souvent constructives. Par contre j'ai plus de mal à adhérer à l'idée que les imports automatiques déshumaniseraient OSM. Bon déjà je serais le premier partant pour aller boire un verre avec des contributeurs locaux pour parler architecture et botanique :) Mais surtout, à partir du moment où évidemment les données sont correctes, je ne vois pas en quoi ça gêne: un import a le mérite de rajouter avec peu d'effort (enfin quoique) beaucoup de données qui seraient généralement beaucoup trop fastidieuses à rentrer manuellement. Alors qu'il y a tellement de chose à rajouter dans OSM... c'est pas comme si je volais du travail à des contributeurs humains ! De plus je rappelle que je conserve les contributions existantes au lieu de les supprimer comme initialement. Pour revenir à l'exemple US que je ne connais pas du tout, j'avoue avoir du mal à croire que ça soit simplement à cause de l'import auto de TIGER qu'il y ait aussi peu de contributeurs. Sauf si l'import a été mal fait mais à ce moment là c'est un autre problème. En fait j'aurais même tendance à penser l'inverse: il est plus facile de motiver des contributeurs à travailler sur une carte déjà bien remplie plutôt que sur une carte quasiment vide, où à peu près tout reste à faire.. mais bon là on rentre dans la psychologie. Donc voilà, à mon sens je ne vois que des côtés positifs à partir du moment où l'import automatique est bien fait. Et encore une fois rien n'empêche de pas retravailler manuellement des données importées automatiquement. Rajouter les tags height / taxon / etc. sur les 30 000 les arbres municipaux de Nice représenterait un sacré travail manuel. Je serais tout à fait partant pour le faire avec du monde mais il faut aussi être réaliste, les forces vives sur la région niçoise ont l'air assez minces. J'ai en tout cas contacté les 2 personnes qui ont déjà rajouté des arbres sur Nice, s'ils me répondent j'essayerai de voir s'elles sont motivées mais si au final on est que 3 ou 4 ça serait titanesque de faire l'ensemble des arbres. Disons qu'on pourrait au moins faire la Prom' (pour ceux qui ne connaissent pas c'est la route en bord de mer de Nice). Par contre je verrais plutôt ça en rajoutant les tags directement dans OSM depuis son téléphone plutôt que de les noter sur une carte imprimée pour après les faire intégrer dans l'OD de Nice (s'ils le veulent bien !) pour après les réimporter dans OSM... à ce moment autant considérer que LA référence c'est OSM ! ;p Le 26 juillet 2015 14:44, Vincent Frison vincent.fri...@gmail.com a écrit : Alors pour répondre à la question de Jérôme sur la gestion des conflits: Avant je ne considérais que l'arbre existant le plus proche de l'arbre importé. Mais comme je disais dans un post précédent: la gestion des multi matching trees (ie. les arbres existants qui sont dans le rayon de plusieurs arbres importés) est très basique puisque je met à jour l'élément avec les valeurs du 1er arbre importé tout simplement (pour les autres éléments importés je créé donc un nouvel élément). Comme tu l'as remarqué Jérôme il y a aucun tag taxon ou genus sur l'ensemble des arbres existants de Nice, ce qui est une mauvaise chose dans l'absolu... mais plutôt une bonne chose pour mon import ! :p Ceci dit on était pas à l'abri de cas problématiques, imaginons 2 arbres importés I1, I2 et 3 arbres existants E1, E2, E3 (et que le rayon est de 5m). I12mE1 I13mE2 I21mE1 I24mE3 Avant si je tombais d'abord sur I1 j'utilisais E1 pour le mettre à jour et laissait E2 tel quel. Sauf que I2 est encore plus proche de E1, il devrait être donc être mis à jour pour I2 et c'est E2 qui devrait être mis à jour pour I1. C'est maintenant le cas car je conserve pour chaque arbre existant l'arbre importé le plus proche. - si l'arbre importé n'est pas le meilleur candidat (ie. il y a un autre arbre importé qui est plus proche de l'arbre existant), j'essaye avec les autres arbres existants qui étaient dans son rayon (et s'il n'y a plus d'autres arbres existants alors il faudra créer un nouvel élément) - si l'arbre importé est le meilleur candidat, je peux alors utiliser l'arbre existant pour le mettre à jour. Mais je dois alors relancer tout le processus pour l'ancien meilleur arbre importé qui à son tour pourrait éventuellement faire des changements (fonction récursive). Bon c'est pas évident d'expliquer tout ça par
Re: [OSM-talk-fr] Recyclage du rendu QA dans osmose: bâti non importé
Le 26/07/2015 00:53, Frédéric Rodrigo a écrit : Le 25/07/2015 23:30, Christian Quest a écrit : Encore du recyclage du rendu QA pour osmose... la localisation des communes au bâti non importé. On en compte un peu plus de 4000. Pour cela, la requête compare le nombre de carreaux INSEE sans bâti au nombre total de carreaux dans la commune. Si il y a plus de la moitié et que le cadastre est vectoriel sur la commune, ça remonte dans Osmose... Visible en test ici (serveur de dev d'osmose): http://dev.osmose.openstreetmap.fr/fr/map/#source=10786item=7170class=2 Ça à l'air d'être les mêmes coins ou il manques des voies ! C'est assez proche en effet. Ces analyses montrent finalement les endroits où avant de s'occuper des arbres, on peut déjà y mettre les routes, des bâtiments... quelques noms (à l'aide de BANO couplé au cadastre tuilé). Par contre tu pourrais ajouter le nom de la commune dans le signalement ? Je l'ai ajouté ce matin. Il y a d'ailleurs sûrement un bug dans le gestion des corrigé / faux-positifs lorsque l'erreur n'est pas liée à un élément OSM (l'unicité n'est que sur lat/lon, ou alors il faudrait aouter un error_id unique). -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Frontière franco-italienne du Mont-Blanc
Bonjour Thierry, je suis contente de voir que la communauté Japonaise a enfin décidé de laisser tomber la translittération dans le name. C'est quelque chose dans laquelle je crois assez fortement: on met la langue et l’écriture du pays dans la zone concernée. Toutefois, il faut noter que les japonais mettent quasiment a chaque fois la translittération (romaji) dans un tag name donc ce n'est qu'une question de rendu. 2015-07-25 22:46 GMT-07:00 Thierry Bézecourt thie...@thbz.org: Merci pour ces précisions. La conséquence est que la carte Openstreetmap qui est sans doute la plus visible (openstreetmap.org) est difficile à utiliser pour les non-locaux dans des pays n'utilisant pas l'alphabet latin, c'est un peu dommage. En fait, il suffirait de supporter une seule langue occidentale (l'anglais) pour faciliter la vie des voyageurs ou expats qui n'ont pas encore appris la langue. Pour info, les Japonais ont décidé de ne plus mettre les translittérations dans le champ name. Il en est de même en principe des Coréens (en pratique, la plupart des noms de rue à Séoul ont à la fois le nom coréen et le nom anglais dans le champ name). Thierry Le 26/07/2015 01:35, Emilie Laffray a écrit : Bonjour, La règle globalement est d'afficher seulement le name qui se doit d'etre dans la langue locale de l'endroit. Certaines communautés préfèrent aussi rajouter des translittérations dans name (voir les Japonais). Après, le problème d'affichage des noms en plusieurs langues est un problème compliqué a résoudre d'un point de vue technologique. * Les cartes sont des tuiles Raster (pour supporter plusieurs langues, il faut donc régénérer la carte autant de fois qu'il y a de langues) * Mapnik toutefois est en train de travailler sur un support de rendu vectoriel (ce qui permet de ne recalculer que certaines couches, réduisant le temps de rendu) * Les cartes Raster prennent de la place * Créer des cartes sans nom et rajouter les noms dessus n'est pas évident. C'est même quelque chose de très compliqué. Ça implique utilisation des fonctions Javascript et de CSS avance. Mapquest avait fait des essais il y a quelques annees et avait abandonne le projet lie a la complexité du système. C'est plus complique que de rajouter des points d’intérêts. * L'autre solution est un rendu purement vectoriel comme le projet de Google en WebGL ce qui est généralement horriblement lent. Bref, il ne faut pas s'attendre a ce que cela soit résolu du jour au lendemain. 2015-07-25 4:25 GMT-07:00 Thierry Bézecourt thie...@thbz.org mailto:thie...@thbz.org: Bien trouvé pour cet article du Dauphiné, qui confirme le placement de la station météo dans la zone contestée. Peut-être y a-t-il eu des discussions informelles avec la France, mais l'article de l'ARPA Valle d'Aosta ( http://www.arpa.vda.it/index.php?option=com_flexicontentview=itemsid=2320:2015-07-21-15-14-35Itemid=541 ) ne mentionne que les autorisations obtenues des communes italiennes voisines. Le 25/07/2015 12:30, osm.sanspourr...@spamgourmet.com mailto:osm.sanspourr...@spamgourmet.com a écrit : Sinon une question marginale : je vois que pas mal de villes/pays ont un attribut name:lg qui est identique à l'attribut name. Certes ça permet de savoir que Paris s'écrit Paris en allemand, mais est-ce bien utile ? name=Paris ne veut-il pas dire que le nom est Paris dans toutes les langues sauf celles précisées (name:br=Pariz par exemple). Oui, c'est utile pour faire la différence entre les langues dans lesquelles on connaît le nom et les autres. Si mes langues préférées sont, dans l'ordre, l'akkadien et l'italien, je veux que le nom affiché soit : - le nom akkadien s'il existe dans la base ; - sinon, le nom italien (Parigi). Le nom par défaut (Paris) ne serait affiché que si le nom italien n'existait pas dans la base. Thierry ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Bonsoir, Le 26/07/2015 21:30, Vincent Frison a écrit : Bon d'accord l'import TIGER a visiblement été très négatif pour la naissance de la communauté US.. mais pour revenir concrètement (et plus modestement) à mon import d'arbres sur Nice, vous pensez sincèrement que ça aurait un impact négatif sur la communauté niçoise d'OSM ? Oui, tant que cette communauté n'aura pas dit le contraire. Ce qui est pointé depuis hier, c'est notamment le caractère intimidant de données importées, et le fait que la maintenance est une tâche beaucoup plus ingrate que la création de données. D'où l'importance de pouvoir s'approprier ce qui est fait, et le meilleur moyen reste encore d'avoir eu l'opportunité de le faire soi-même. Avec un import, difficile de se sentir concerné, affecté, par les données. C'est plutôt le découragement qui prévaut. J'aurais un discours plus modulé si on avait dans le cadre de ce fil un echo de contributeurs locaux, qui diraient en substance : c'est bon, que l'import soit fait, on s'occupe de la suite. Mais pour l'instant je n'entends rien. Le constat sur la couverture BANO va dans le même sens. En s'appuyant sur les stats par département (pour Nice : http://cadastre.openstreetmap.fr/fantoir-dev/stats_dept.html#dept=06 ) sur les 10 plus grosses communes de France Nice est celle avec le moins bon ratio a/c. Ça n'est qu'un constat (surtout pas un reproche) mais ce thermomètre (parmi d'autres) de l'activité locale montre qu'on a moins de dynamisme que sur les autres villes de même importance. Et dans ce contexte, je ne vois pas comment un ajout massif et mécanique va motiver du monde pour s'approprier la ville et alentours et _maintenir_ les données (des arbres mais pas que). Le 26/07/2015 21:34, Jérôme Seigneuret a écrit : Autre problématique d'intégration et dont il n'y a même pas un consensus (même sur une commune) c'est adresse postal Certains parle de le mettre à l'entrée du bâtiment, d'autres sur le bâtiment, d'autre devant la rue à l'entrée. On fait quoi pour qui en fait? La poste prendra la boite et la sonnette, d'autre service pour les clients ce sera la porte d'entrée, Certains ce sera le boitier électrique, le compteur de gaz ou d'eau. Et c'est la même pour les commerces. Pour les adresses, la démarche a consisté à ne pas décider qu'un modèle était meilleur qu'un autre : on a pas moins de 8 schémas de tags disponibles par commune. Et surtout, ce qui est généré à http://cadastre.openstreetmap.fr/ sont des fichiers à intégrer, manuellement, par les contributeurs. C'est un choix délibéré. Techniquement il était tout à fait possible, une fois les adresses extraites du cadastre, de tout importer, sur les 30.000 communes vectorielles. Mais ça n'est pas parce que c'est techniquement possible que c'est forcément souhaitable (pour les raisons évoquées plus haut notamment). vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tuiles vectorielles et internationales
OK pour que osm.org ne soit pas LE point d'entrée. Mais on pourrait aussi faciliter le passage d'un site à l'autre. Même le codage de la position et du niveau de zoom diffèrent maintenant entre les différents sites (zoom=zoomlat=latlon=lon ou #map=zoom/lat/lon). J'aimerais passer facilement d'un site à l'autre pour prendre le meilleur de chaque. Operator (sur FireFox), c'est bien, mais il faut un microformat et je suis sans doute le seul sur la liste à l'utiliser (et pourtant c'est un public globalement avisé). Le web sémantique a encore du pain sur la planche ! Là dès que tu passes sur openseamap par exemple, tu dois te recoltiner les transformations en lat=... (bon, je devrais proposer la modif à openseamap pour favoriser le passage de l'un à l'autre). Il y a eu de longues discussions avant d'ajouter le calcul d'itinéraires. Ce site sert surtout à montrer ce qu'on peut faire avec OSM, mais sans vouloir faire trop d'ombre à toutes les initiatives autour. C'est le fait d'avoir ajouté le calcul d'itinéraire qui a éclairé les initiatives autour plus qu'il ne les a entravées. Maintenant je n'hésite pas à donner une url pointant sur la page directions. On peut penser à suggérer des sites en fonction du niveau de zoom. Les gens regardent du côté de Lorient ? Allez, on propose le site du calcul d'itinéraire avec handicap qui marche bien sur Lorient. Près de la côte ? Allez, www.openseamap.org. Ta liste de courses pour osm.fr me plait. Le 26/07/2015 18:47, Christian Quest - cqu...@openstreetmap.fr a écrit : Si il n'y a qu'une langue locale ça marche... mais c'est pas le cas partout ! Belgique, Suisse, etc... sans oublier aussi les langues régionales. Je n'ai jamais dit de ne pas garder les tags qui sont différents. name:br=Pariz, on garde ! Je dis juste que name:de=Paris (qui existe actuellement dans la base) n'a pas grand intérêt. S'il y a plusieurs langues locales, soit il y en a une prédominante (par zone), soit il n'y en a pas. Le name reflète la situation de terrain. Donc éventuellement plusieurs langues. name=Rennes mais name:br=Roazhon Tu me dis (je pense) que name:en=London est utile. Soit. Je disais que name:de=Paris est inutile puisque name=Paris et que si on ajoute le nom dans toutes les langues du monde alors que c'est le nom dans la langue locale, ça va alourdir inutilement. name=Paris ne me dit pas que Paris en allemand s'écrit aussi Paris... name=Paris me dit que Paris sera toujours Paris sauf si explicitement dit autrement. Il faut penser au fait que de nombreux name ne sont disponibles que dans la langue locale par défaut et que toutes les traductions n'ont peut être pas été ajoutées. Si name:de n'est pas là c'est peut être qu'il n'a pas encore été renseigné plutôt que dire que c'est la même graphie que le name. Là le problème c'est plus que c'est effectivement le même. /- impossible de savoir dans quelle lanque est le name par défaut (ou alors il faudrait ajouter un tag pour l'indiquer)// / Est-ce que la langue de name ne devrait pas être déterminée par la relation / les polygones (de type boundary ?) englobants ? Ouille... bonjour le préprocessing, et ce n'est pas toujours le cas. oui et non : les contours ne changent pas beaucoup. Allez, faisons des geohash des zones, déjà dans la plupart des zones tu auras une seule langue (ou une liste pour les zones comme la Suisse). Il y a beaucoup de name qu'on peut trouver qui n'ont pas été renseignés dans la langue locale (par manque de contributeurs locaux). Déterminer la langue de name est donc peu fiable alors que si on renseigne les name:* là l'info est claire et sans ambiguïté. Mettre un name= dans la langue qui n'est pas la langue locale c'est une faute de goût. name:en= si la personne récupère le nom en anglais est ce qu'il faut faire. Je n'ai rien contre les name:*, je parlais juste des name:*= qui sont identiques au name= J'aurais plus tendance à écrire une méta donnée disant que le nom de Paris c'est Paris en allemand, papou, etc... En général ce sont les noms différents qui nous intéressent, seul le contributeur en papou veut savoir que le nom de Paris est bien renseigné en papou. Je dis papou, histoire de rappeler qu'il n'y a pas que le français, l'anglais et l'allemand et que si chacun fait ça, ça va faire beaucoup. Bien-sûr un champ de bits suffit pour dire indiquer dans une tuile vectorielle les noms identiques au nom local : ça se comprime bien. Mais si on veut aller dans cette direction (qui n'est pas ce qui est indiqué dans le wiki), il faut que l'affichage des tags soit plus fin (on met par exemple les noms différents et un plus pour afficher les noms identiques au name). L'ordre fr, à défaut en, à défaut international, à défaut name c'est pour les pays à alphabet non latin ? Je pensais que l'ordre était /name:fr/, i/ntl_name/, /name/. Je ne sais pas dans quel alphabet est intl_name et il est parfois multilingue... j'ai eu quelques surprises d'où le name:en
Re: [OSM-talk-fr] tuiles vectorielles et internationales
Le 26/07/2015 15:44, osm.sanspourr...@spamgourmet.com a écrit :
Nous n'avons cependant jamais fait le pas pour finaliser un site
avec tout les services utiles...
(recherche d'adresse ou POI, calcul d'itinéraire, différents rendus,
etc).
Ce n'est pas par choix, mais plus par manque de disponibilité et
d'huile de coude.
Tu es dans l'optique OpenStreetMap.org redirige vers OpenStreetMap.fr,
j'avais en tête osm.org va chercher les tuiles chez osm.fr.
Les deux possibilités sont intéressantes.
La seconde solution nécessite essentiellement une machine qui accepte
le trafic, on utilise toujours OSM.org pour les outils.
L'un n'empêche pas l'autre : renforcer la structure puis la suite
logicielle.
Dans le second cas il faudrait que les serveurs de tuiles (osm.fr)
puissent s'enregistrer auprès d'osm.org pour apparaître dans les
couches disponibles (en fonction du user agent plus exactement du
Accept-Language ? Si je dis que j'accepte fr/de/en, des couches
produites par osm.fr, osm.de et celles produites en utilisant
l'anglais m'intéressent potentiellement).
J'avais bien compris, mais c'est un choix qui se fait au niveau de la
fondation et l'objectif du site openstreetmap.org n'est pas de devenir
LE point d'entrée pour fournir des services à partir des données OSM (ce
qu'Emilie décrivait en parlant d'un map.openstreetmap.com).
Il y a eu de longues discussions avant d'ajouter le calcul
d'itinéraires. Ce site sert surtout à montrer ce qu'on peut faire avec
OSM, mais sans vouloir faire trop d'ombre à toutes les initiatives autour.
Dans les services que je verrai bien sur un map.openstreetmap.fr il y a:
- des tuiles FR
- un géocodage qui s'appuie sur BANO/BAN+POI OSM et avec
l'autocomplétion que permet addok
- d'autres couches de tuiles
- un calcul d'itinéraire (comme osm.org)
- un accès facilité à uMap avec un bouton Personnaliser cette carte
etc...
Certains de ces ajouts trop spécifiques n'iront pas sur osm.org.
/Sinon une question marginale : je vois que pas mal de villes/pays
ont un attribut name:lg qui est identique à l'attribut name.//
//Certes ça permet de savoir que Paris s'écrit Paris en allemand,
mais est-ce bien utile ?//
//name=Paris ne veut-il pas dire que le nom est Paris dans toutes les
langues sauf celles précisées (name:br=Pariz par exemple).//
//Pour le Mont Blanc, on peut imaginer qu'un jour name= change et que
l'on veuille avoir dans tous les cas name:it et name:fr.//
///
///
//On gagnerait très peu (un seul tag de moins) et on perdrait beaucoup://
//- impossible de savoir dans quelle lanque est le name par défaut (ou
alors il faudrait ajouter un tag pour l'indiquer)//
//- complication pour le rendu... sur FR, un simple coalesce permet de
prendre le name:fr si présent, puis name:en, puis intl_name puis
name... sans name:fr sur Londres ça compliquerai énormément !
/Soit tu n'as pas compris ma proposition soit je n'ai pas compris ta
réponse.
Car sur l'exemple ça voudrait dire que le name de Paris est en
allemand, pas en français ;-(.
Le name c'est le nom dans la langue locale, c'est à dire pour Londres
l'anglais (name=London), figure aussi name:fr=Londres et name:en=London.
Si il n'y a qu'une langue locale ça marche... mais c'est pas le cas
partout !
Belgique, Suisse, etc... sans oublier aussi les langues régionales.
Tu me dis (je pense) que name:en=London est utile. Soit.
Je disais que name:de=Paris est inutile puisque name=Paris et que si
on ajoute le nom dans toutes les langues du monde alors que c'est le
nom dans la langue locale, ça va alourdir inutilement.
name=Paris ne me dit pas que Paris en allemand s'écrit aussi Paris...
Il faut penser au fait que de nombreux name ne sont disponibles que dans
la langue locale par défaut et que toutes les traductions n'ont peut
être pas été ajoutées. Si name:de n'est pas là c'est peut être qu'il n'a
pas encore été renseigné plutôt que dire que c'est la même graphie que
le name.
/- impossible de savoir dans quelle lanque est le name par défaut
(ou alors il faudrait ajouter un tag pour l'indiquer)//
/ Est-ce que la langue de name ne devrait pas être déterminée par la
relation / les polygones (de type boundary ?) englobants ?
Ouille... bonjour le préprocessing, et ce n'est pas toujours le cas.
Il y a beaucoup de name qu'on peut trouver qui n'ont pas été renseignés
dans la langue locale (par manque de contributeurs locaux).
Déterminer la langue de name est donc peu fiable alors que si on
renseigne les name:* là l'info est claire et sans ambiguïté.
La langue principale de la France est le français, donc les name en
France sont en français. Un peu comme on a timezone.
Actuellement je ne trouve l'info que sur le wiki, alors que si on
avait un default_language=fr (par exemple) voir un
default_language={{fr}} - {{de}} (lire : le name c'est name:fr suivi
de name:de séparés par - ).
Mais mettre l'info sur les objets englobants suffit.
Bon, pour des règles comme langue X et Y par ordre
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Le 26 juillet 2015 19:51, JB jb...@mailoo.org a écrit : Quelques réponses décousues : Le 26/07/2015 15:47, Vincent Frison a écrit : Par contre j'ai plus de mal à adhérer à l'idée que les imports automatiques déshumaniseraient OSM. Bon déjà je serais le premier partant pour aller boire un verre avec des contributeurs locaux pour parler architecture et botanique :) Vas-y, lance une invitation. Je pense qu'on ne le fait pas assez. En rase campagne, c'est pas forcément évident, mais en ville… On va y aller tranquille, j'ai déjà envoyé des mails à 2 personnes.. et je pars bientôt en vacances ! :) Mais surtout, à partir du moment où évidemment les données sont correctes, je ne vois pas en quoi ça gêne: un import a le mérite de rajouter avec peu d'effort (enfin quoique) beaucoup de données qui seraient généralement beaucoup trop fastidieuses à rentrer manuellement. … d'où la demande de leur entretien. Si ça n'intéresse pas grand monde de les mapper, qui va en plus les entretenir ? Dans 10, 20 ans, à quoi ressemblera la base de données ? Oui mais bon à ce moment là on ne peut plus rien rajouter ! Si je rajoute (manuellement) un arbre dans mon quartier et que dans 20 ans je ne suis plus dans la région qui va mettre à jour mon arbre ? Pour revenir à l'exemple US que je ne connais pas du tout, j'avoue avoir du mal à croire que ça soit simplement à cause de l'import auto de TIGER qu'il y ait aussi peu de contributeurs. Sauf si l'import a été mal fait mais à ce moment là c'est un autre problème. En fait j'aurais même tendance à penser l'inverse: il est plus facile de motiver des contributeurs à travailler sur une carte déjà bien remplie plutôt que sur une carte quasiment vide, où à peu près tout reste à faire.. mais bon là on rentre dans la psychologie. Quelle était ta première contribution ? Dans les ateliers de découverte, l'accroche des participants est classiquement : il manque ma rue, le nom de ma rue, la boite aux lettres à coté de chez moi, mon boulanger. Une fois ça ajouté, ils sont pris dans le jeu et continuent. Tu leurs donnes une carte visuellement « complète », ils ne voient pas quoi faire. Alors, si l'import Tiger a été fait avant d'avoir une base de contributeurs locaux, celle-ci est beaucoup plus difficile à construire à postériori. Et puis, je ne veux pas tourner en rond, mais tu préfères contribuer sur de la nouvelle donnée, ou corriger l'existant, voire reprendre l'existant quand celui-ci est foireux ? Donc voilà, à mon sens je ne vois que des côtés positifs à partir du moment où l'import automatique est bien fait. Et encore une fois rien n'empêche de pas retravailler manuellement des données importées automatiquement. Même question. Qui préfère retravailler de la mauvaise donnée que d'en entrer de la nouvelle ? Oui mais bon là t'es en train de partir sur le postulat que j'insère des mauvaises données... Je ne connais pas le langage Java, mais processMultiMatchingTree n'est-il pas une emplâtre sur une jambe de bois ? Un petit tri par distance à l'existant, pour intégrer d'abord les plus proches ? Ah ba te remercie pour la jambe de bois ! ;p Le souci c'est que le tri doit se faire à plusieurs niveaux.. mais il y a sans doute y avoir plus simple ou plus efficace, même si la performance n'est pas du tout un problème puisque l'import prend déjà très peu de temps (environ 3 minutes). Ceci toute pull request est évidemment la bienvenue.. Mais surtout, aussi beau que tu fasses l'algorithme, s'il y a plusieurs MatchingTree avec des distances à moins de 5m avec des distances à peu près équivalentes (un arbre à 2.5m, un autre à 3m), pour moi, c'est plutôt un signe que ces cas devraient être gérés à la main… C'est un cas extrêmement rare qui pourrait éventuellement poser problème mais à condition que les 2 arbres soient différents. Mais il faut rappeler qu'aucun arbre existant sur Nice n'a de tag taxon / height / etc. Il y a juste ceux de la Prom' ont le type=palm (qui sera gardé). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Quelques réponses décousues : Le 26/07/2015 15:47, Vincent Frison a écrit : Par contre j'ai plus de mal à adhérer à l'idée que les imports automatiques déshumaniseraient OSM. Bon déjà je serais le premier partant pour aller boire un verre avec des contributeurs locaux pour parler architecture et botanique :) Vas-y, lance une invitation. Je pense qu'on ne le fait pas assez. En rase campagne, c'est pas forcément évident, mais en ville… Mais surtout, à partir du moment où évidemment les données sont correctes, je ne vois pas en quoi ça gêne: un import a le mérite de rajouter avec peu d'effort (enfin quoique) beaucoup de données qui seraient généralement beaucoup trop fastidieuses à rentrer manuellement. … d'où la demande de leur entretien. Si ça n'intéresse pas grand monde de les mapper, qui va en plus les entretenir ? Dans 10, 20 ans, à quoi ressemblera la base de données ? Pour revenir à l'exemple US que je ne connais pas du tout, j'avoue avoir du mal à croire que ça soit simplement à cause de l'import auto de TIGER qu'il y ait aussi peu de contributeurs. Sauf si l'import a été mal fait mais à ce moment là c'est un autre problème. En fait j'aurais même tendance à penser l'inverse: il est plus facile de motiver des contributeurs à travailler sur une carte déjà bien remplie plutôt que sur une carte quasiment vide, où à peu près tout reste à faire.. mais bon là on rentre dans la psychologie. Quelle était ta première contribution ? Dans les ateliers de découverte, l'accroche des participants est classiquement : il manque ma rue, le nom de ma rue, la boite aux lettres à coté de chez moi, mon boulanger. Une fois ça ajouté, ils sont pris dans le jeu et continuent. Tu leurs donnes une carte visuellement « complète », ils ne voient pas quoi faire. Alors, si l'import Tiger a été fait avant d'avoir une base de contributeurs locaux, celle-ci est beaucoup plus difficile à construire à postériori. Et puis, je ne veux pas tourner en rond, mais tu préfères contribuer sur de la nouvelle donnée, ou corriger l'existant, voire reprendre l'existant quand celui-ci est foireux ? Donc voilà, à mon sens je ne vois que des côtés positifs à partir du moment où l'import automatique est bien fait. Et encore une fois rien n'empêche de pas retravailler manuellement des données importées automatiquement. Même question. Qui préfère retravailler de la mauvaise donnée que d'en entrer de la nouvelle ? Pourquoi la BD Carthage n'a pas été importée ? …Par contre je verrais plutôt ça en rajoutant les tags directement dans OSM depuis son téléphone plutôt que de les noter sur une carte imprimée… La reconnaissance terrain, ce n'est pas forcément avec les Fieldpapers… La charte du contributeur ne le mentionne pas… Ceci dit on était pas à l'abri de cas problématiques, imaginons 2 arbres importés I1, I2 et 3 arbres existants E1, E2, E3 (et que le rayon est de 5m). I12mE1 I13mE2 I21mE1 I24mE3 Avant si je tombais d'abord sur I1 j'utilisais E1 pour le mettre à jour et laissait E2 tel quel. Sauf que I2 est encore plus proche de E1, il devrait être donc être mis à jour pour I2 et c'est E2 qui devrait être mis à jour pour I1. C'est maintenant le cas car je conserve pour chaque arbre existant l'arbre importé le plus proche. - si l'arbre importé n'est pas le meilleur candidat (ie. il y a un autre arbre importé qui est plus proche de l'arbre existant), j'essaye avec les autres arbres existants qui étaient dans son rayon (et s'il n'y a plus d'autres arbres existants alors il faudra créer un nouvel élément) - si l'arbre importé est le meilleur candidat, je peux alors utiliser l'arbre existant pour le mettre à jour. Mais je dois alors relancer tout le processus pour l'ancien meilleur arbre importé qui à son tour pourrait éventuellement faire des changements (fonction récursive). Je ne connais pas le langage Java, mais processMultiMatchingTree n'est-il pas une emplâtre sur une jambe de bois ? Un petit tri par distance à l'existant, pour intégrer d'abord les plus proches ? Mais surtout, aussi beau que tu fasses l'algorithme, s'il y a plusieurs MatchingTree avec des distances à moins de 5m avec des distances à peu près équivalentes (un arbre à 2.5m, un autre à 3m), pour moi, c'est plutôt un signe que ces cas devraient être gérés à la main… Bon c'est pas évident d'expliquer tout ça par mail mais vous pouvez voir les sources ici: https://github.com/vince-from-nice/osmaxil/blob/master/src/main/java/org/openstreetmap/osmaxil/plugin/maker/NiceTreeMaker.java ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rapprochement BANO - Carhaix-Plouguer (29)
Le 26/07/2015 22:59, . ZZ29 a écrit : Certainement un coup de fatigue du dimanche soir, mais quelqu'un peut-il m'expliquer pourquoi aucune voie de la commune de Carhaix n'est rapprochée sur Bano? http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#15/48.2771/-3.5678 Le festival des vieilles charrues s'est terminé, les adresses sont pourtant censées persister. ;-) Le rapprochement Fantoir est de même type, mais les voies dans la catégorie sans adresses sont bien rapprochées. http://cadastre.openstreetmap.fr/fantoir/#insee=29024 La raison habituelle est que la limite de commune était cassée au moment du dernier passage de script BANO (donc la nuit dernière). C'est confirmé par l'historique de la relation, qui a été corrigée aujourd'hui : http://www.openstreetmap.org/changeset/32882406 Tu peux tester que tout est rentré dans l'ordre, en demandant une mise à jour du rapprochement sur la commune avec le bouton noir en haut à droite de : http://cadastre.openstreetmap.fr/fantoir/#insee=29024 vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] comment ajouter un point wifi gratuit sur openstreetmap
bonsoir, comment ajoute t on un point wifi gratuit sur openstreetmap, s’il vous plait? merci___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Les cartes soviétiques hyper détaillées durant la guerre froide
Le 20/07/2015 22:31, Xavier Cremaschi a écrit : Un article très intéressant à lire pour les passionnés de cartographie : http://www.wired.com/2015/07/secret-cold-war-maps/ Xavier. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr Ça pourrait peut être servir de base pour des zones blanches, mais je n'ai pas trouvé de scan de ces fameuses cartes, sans dire que je n'ai aucun idée de la licence qui pourrait s'appliquer. Si quelqu'un sait où trouver des scans... A+ -- Marc Sibert mailto:m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Le 26 juillet 2015 19:59, Emilie Laffray emilie.laff...@gmail.com a écrit : Petite anecdote. Il fut même considéré a un moment d'effacer les données TIGER existantes afin de recréer une toile blanche. Chose qui au final ne s'est pas fait du faire de la difficulté de séparer ce qui avait été retouché (mais base sur TIGER) et ce qui ne l'avait pas été. Bon d'accord l'import TIGER a visiblement été très négatif pour la naissance de la communauté US.. mais pour revenir concrètement (et plus modestement) à mon import d'arbres sur Nice, vous pensez sincèrement que ça aurait un impact négatif sur la communauté niçoise d'OSM ? Personnellement je ne le pense pas.. je dirais même que la communauté niçoise s'intéressant aux arbres, passerait de 2 à 3 personnes, ce qui ferait tout de même un gain de 50% ! ;p ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Les cartes soviétiques hyper détaillées durant la guerre froide
Bonjour Marc, il y a eus une discussion sur cela sur une des mailing lists il y a quelques années de cela et plus récemment encore suite a l'article de Wired. Ces cartes sont toujours sous copyright. Les russes se refusent d'y toucher car les droits ont tout simplement migrés vers la société de cartographie qui a remplacé ce qui existait. La disparition de l'union soviétique n'a donc pas laisse un grand vide béant concernant ce genre de chose. Je ne suis donc pas sure que l'on veuille toucher a ces données en premier lieu du fait de ces informations. Emilie 2015-07-26 9:36 GMT-07:00 Marc Sibert m...@sibert.fr: Le 20/07/2015 22:31, Xavier Cremaschi a écrit : Un article très intéressant à lire pour les passionnés de cartographie : http://www.wired.com/2015/07/secret-cold-war-maps/ Xavier. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr Ça pourrait peut être servir de base pour des zones blanches, mais je n'ai pas trouvé de scan de ces fameuses cartes, sans dire que je n'ai aucun idée de la licence qui pourrait s'appliquer. Si quelqu'un sait où trouver des scans... A+ -- Marc Sibert mailto:m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tuiles vectorielles et internationales
Attention, loc_name=* correspond à une appelation locale, non officielle. J'entends bien. name c'est le nom dans la langue officielle locale, ce qui est différent. Question post SOTM 2015 : Brest-même c'est loc_name ou alt_name ? ;-) On pourrait dire que le alt_name remplace officiellement le name d'où le fait que Nominatim renvoi des résultats. On a l'exemple de la métropole de Montpellier qui est :Montpellier Méditerranée Métropole et en nom alternatif Montpellier 3M en nom local l'agglo de Montpel Le cas que tu cites est un loc_name. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Rapprochement BANO - Carhaix-Plouguer (29)
Bonsoir à tous, Certainement un coup de fatigue du dimanche soir, mais quelqu'un peut-il m'expliquer pourquoi aucune voie de la commune de Carhaix n'est rapprochée sur Bano? http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#15/48.2771/-3.5678 Le festival des vieilles charrues s'est terminé, les adresses sont pourtant censées persister. ;-) Le rapprochement Fantoir est de même type, mais les voies dans la catégorie sans adresses sont bien rapprochées. http://cadastre.openstreetmap.fr/fantoir/#insee=29024 Merci d'avance pour vos réponses, A+ ZZ29 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Le 27/07/2015 00:08, Vincent Frison a écrit : Je commence juste à me rendre compte (je suis un nouveau de 6 mois hein) à quel point les imports auto sont mal vues par ici. Je savais bien que ça pouvait être sensible (ils en parlent même sur la page import du wiki) mais pour être franc je ne m'attendais pas du tout à une telle levée de boucliers pour cet import d'arbres.. si peu risqué à mon sens ! Ça n'est pas pour rien qu'on met un point d'honneur en France à parler d'intégration et non d'import. Intégration signifie que le contributeur (humain) a toujours le dernier mot avant d'envoyer les données au serveur, et que le travail de combinaison avec l'existant lui incombe, bien plus qu'à un robot-algo. J'ai bien conscience que la problématique de la maintenance est évidemment primordiale mais personnellement je ne suis vraiment pas sûr qu'une donnée rentrée manuellement soit forcément plus viable, sur le long terme, qu'une entrée rentrée automatiquement, surtout pour ce type de donnée.Pour revenir par exemple au cas où je rentre manuellement un arbre de mon quartier puis je déménage, je risque fortement de ne plus jamais le mettre à jour. Alors que je pourrais continuer à rejouer tous les 6 mois et sans effort via mon script pour utiliser la dernière mise à jour de l'opendata de Nice indiquant le très peu probable abattage de l'arbre. Ce qui veut dire une confiance totale en la source Open Data. Ça a déjà été rappelé dans ce fil (et dans bien d'autres avant) : une source Open Data doit être croisée à autre chose et pas prise comme telle, seule. D'où souvent le verdict du terrain pour valider la qualité. Je me permet quand même de rappeler que mon import insère des arbres qui sont actuellement bien réels, tout.en respectant les données déjà insérés par environ.. 3 contributeurs différents depuis le tout début d'OSM ! Il faut peut-être admettre le fait que c'est pas un sujet qui passionne les foules et le fait que l'on puisse se l'approprier ou pas un arbre en le créant ne va pas changer grand chose. Avec un peu de pragmatisme on imagine sans peine que sans import automatique il n'y aura jamais de bonne couvertures du parc niçois avant un bon petit siècle.. Le sujet, depuis le début du fil, ce ne sont pas les arbres. C'est comment ce contenu _et le reste_ forme un tout cohérent et maintenu. Quant au temps, ça n'est vraiment pas un souci. Si un besoin d'utiliser les arbres de Nice se présente demain, le fichier OD en tant que tel peut servir, sans passer par la case OSM. Bref j'aurais vraiment du mal admettre que l'on m'interdisse cet import (après la déception de celui pour PSS ça serait dur) même si je ne fera évidemment rien si c'était le cas.. par contre ça serait bien de me le dire clairement et si possible rapidement parce que mine de rien le dev est bientôt fini. Personne ne t'interdira quoi que ce soit, mais entends les messages que tu as ici depuis quelques jours. Tu le dis toi même, ton implication dans le projet est récente, et, de ce que j'en vois, surtout liée à des activités d'import. Ça vaudrait vraiment le coup que tu explores d'autres facettes du projet que les tentatives d'import. Et si c'est vraiment l'aspect technique (dev Java ou autre) qui te botte au final, ce ne sont pas les projets qui manquent dans l'ecosystème OSM pour y trouver ton compte. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Le 26 juillet 2015 22:26, Vincent de Château-Thierry v...@laposte.net a écrit : Le 26/07/2015 21:30, Vincent Frison a écrit : Bon d'accord l'import TIGER a visiblement été très négatif pour la naissance de la communauté US.. mais pour revenir concrètement (et plus modestement) à mon import d'arbres sur Nice, vous pensez sincèrement que ça aurait un impact négatif sur la communauté niçoise d'OSM ? Oui, tant que cette communauté n'aura pas dit le contraire. Ce qui est pointé depuis hier, c'est notamment le caractère intimidant de données importées, et le fait que la maintenance est une tâche beaucoup plus ingrate que la création de données. D'où l'importance de pouvoir s'approprier ce qui est fait, et le meilleur moyen reste encore d'avoir eu l'opportunité de le faire soi-même. Avec un import, difficile de se sentir concerné, affecté, par les données. C'est plutôt le découragement qui prévaut. J'aurais un discours plus modulé si on avait dans le cadre de ce fil un echo de contributeurs locaux, qui diraient en substance : c'est bon, que l'import soit fait, on s'occupe de la suite. Mais pour l'instant je n'entends rien. Il est effectivement assez peu probable qu'une task force niçoise envahissent le forum pour me venir en secours, à priori elle aurait déjà fait vu le titre du sujet ! Je commence juste à me rendre compte (je suis un nouveau de 6 mois hein) à quel point les imports auto sont mal vues par ici. Je savais bien que ça pouvait être sensible (ils en parlent même sur la page import du wiki) mais pour être franc je ne m'attendais pas du tout à une telle levée de boucliers pour cet import d'arbres.. si peu risqué à mon sens ! J'ai bien conscience que la problématique de la maintenance est évidemment primordiale mais personnellement je ne suis vraiment pas sûr qu'une donnée rentrée manuellement soit forcément plus viable, sur le long terme, qu'une entrée rentrée automatiquement, surtout pour ce type de donnée. Pour revenir par exemple au cas où je rentre manuellement un arbre de mon quartier puis je déménage, je risque fortement de ne plus jamais le mettre à jour. Alors que je pourrais continuer à rejouer tous les 6 mois et sans effort via mon script pour utiliser la dernière mise à jour de l'opendata de Nice indiquant le très peu probable abattage de l'arbre. Je me permet quand même de rappeler que mon import insère des arbres qui sont actuellement bien réels, tout.en respectant les données déjà insérés par environ.. 3 contributeurs différents depuis le tout début d'OSM ! Il faut peut-être admettre le fait que c'est pas un sujet qui passionne les foules et le fait que l'on puisse se l'approprier ou pas un arbre en le créant ne va pas changer grand chose. Avec un peu de pragmatisme on imagine sans peine que sans import automatique il n'y aura jamais de bonne couvertures du parc niçois avant un bon petit siècle.. Bref j'aurais vraiment du mal admettre que l'on m'interdisse cet import (après la déception de celui pour PSS ça serait dur) même si je ne fera évidemment rien si c'était le cas.. par contre ça serait bien de me le dire clairement et si possible rapidement parce que mine de rien le dev est bientôt fini. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] comment ajouter un point wifi gratuit sur openstreetmap
bonjour Le 26/07/2015 23:22, lucja...@virginbox.fr a écrit : comment ajoute t on un point wifi gratuit sur openstreetmap, s’il vous plait? En utilisant les tags suivants sur le nœud ou le polygone : internet_access:fee=no internet_access=wlan http://wiki.openstreetmap.org/wiki/Key:internet_access Gwen ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
L'import se résume à peu de valeur ajoutée, ce n'est pas comparable à PSS. Ici tu veux ajouter un nœud par arbre (nouveau). Pas de taille, pas d'âge, pas d'espèce, etc... Donc suffisant pour la municipalité pour savoir quoi arroser. C'est le problème de l'usage. Ajouter une info globalement pauvre même si pertinente sur un point, c'est bien *s**'il* est probable que les gens la complètent. Si c'est une graine que tu peux faire germer c'est bien, si c'est un sapin de Noël synthétique, ça nuit aux données alentour ! Mais d'un point de vue cartographique c'est pauvre. MarcelHerault http://www.openstreetmap.org/user/MarcelHerault a ajouté le type (bon, il a dû se taper Bing pour repérer les palmiers). Tu ne peux pas contacter ceux qui ont contribué localement à OSM pour voir s'ils sont disposés à compléter les données que tu veux importer ? Ce qu'on essaye de dire, ce n'est pas que tu as bossé pour rien, c'est qu'il faut ce servir de ce travail pour apporter une vraie valeur ajoutée (mon discours) ou de pas casser la communauté ou inciter à la créer. Peut-être que les deux autres mappeurs d'arbres sur OSM seront contents et s'ils disent qu'ils veulent partir de cet import pour le compléter, banco. Et je suis le premier à reconnaître que la discussion aura permis d'éviter des problèmes d'import (import avec destruction, hauteur arbitraire). Ce qui es la preuve que tu n'as pas bossé pour rien puisque tu as appris (pas de raison d'être frustré). Ce qu'on te suggère c'est d'importer sous QGIS, umap, etc... et de faire des carto-parties (en vriae, en orhto-pohto, en Mapillary...) pour ajouter de vraies informations. Désolé, savoir qu'il y a un arbre m'importe peu. Un parc, oui c'est une info intéressante, un chêne centenaire aussi. Mais un arbre quelconque ? Et si c'est une rangée de platanes, si tu as le type d'un, la suite est facile. Mais c'est l'arbre qui cache la forêt : je vois que des rues de Nice n'ont pas de nom (http://www.openstreetmap.org/way/156776064). Il semble pourtant y avoir des habitants, il y a même des numéros sur les bâtiments (http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#19/43.71235/7.27541 http://tile.openstreetmap.fr/%7Ecquest/leaflet/bano.html#19/43.71235/7.27541). Alors un nom de rue, de résidence ? Si je veux aller à Nice, la carte me sert avant tout à trouver les rues. Les arbres, ça vient après, seulement après. PSS donne des infos pertinentes sur des lieux remarquables, comme http://structurae.net/. Relier ces données à OSM me semble bien plus intéressant, pertinent. Jean-Yvon Le 27/07/2015 00:08, Vincent Frison - vincent.fri...@gmail.com a écrit : Le 26 juillet 2015 22:26, Vincent de Château-Thierry v...@laposte.net mailto:v...@laposte.net a écrit : Le 26/07/2015 21:30, Vincent Frison a écrit : Bon d'accord l'import TIGER a visiblement été très négatif pour la naissance de la communauté US.. mais pour revenir concrètement (et plus modestement) à mon import d'arbres sur Nice, vous pensez sincèrement que ça aurait un impact négatif sur la communauté niçoise d'OSM ? Oui, tant que cette communauté n'aura pas dit le contraire. Ce qui est pointé depuis hier, c'est notamment le caractère intimidant de données importées, et le fait que la maintenance est une tâche beaucoup plus ingrate que la création de données. D'où l'importance de pouvoir s'approprier ce qui est fait, et le meilleur moyen reste encore d'avoir eu l'opportunité de le faire soi-même. Avec un import, difficile de se sentir concerné, affecté, par les données. C'est plutôt le découragement qui prévaut. J'aurais un discours plus modulé si on avait dans le cadre de ce fil un echo de contributeurs locaux, qui diraient en substance : c'est bon, que l'import soit fait, on s'occupe de la suite. Mais pour l'instant je n'entends rien. Il est effectivement assez peu probable qu'une task force niçoise envahissent le forum pour me venir en secours, à priori elle aurait déjà fait vu le titre du sujet ! Je commence juste à me rendre compte (je suis un nouveau de 6 mois hein) à quel point les imports auto sont mal vues par ici. Je savais bien que ça pouvait être sensible (ils en parlent même sur la page import du wiki) mais pour être franc je ne m'attendais pas du tout à une telle levée de boucliers pour cet import d'arbres.. si peu risqué à mon sens ! J'ai bien conscience que la problématique de la maintenance est évidemment primordiale mais personnellement je ne suis vraiment pas sûr qu'une donnée rentrée manuellement soit forcément plus viable, sur le long terme, qu'une entrée rentrée automatiquement, surtout pour ce type de donnée. Pour revenir par exemple au cas où je rentre manuellement un arbre de mon quartier puis je déménage, je risque fortement de ne plus jamais le mettre à jour. Alors que je pourrais continuer à rejouer tous les 6 mois et sans effort via mon script pour
Re: [OSM-talk-fr] tuiles vectorielles et internationales
Tu l'as effectivement dit mais ce n'est simplement pas vrai. Si le nom en anglais existe, name:en sera renseigné. Ton logiciel pourra en tirer partie o(u pas). Tu connais beaucoup de villes en Chine dont la version en anglais est la même qu'en Chinois ? Si tel est le cas alors ton rendu fr sinon en sinon zh rendra en qui sera égal à zh, le mien rendra zh c'est à dire... la même chose. J'ai aussi précisé que si ça peut être utile on peut ajouter mais à part (dans le sens moins visible car moins pertinent) les données. Ton name:equals_default=, c'est ce que je dis dans Bien-sûr un champ de bits suffit pour dire indiquer dans une tuile vectorielle les noms identiques au nom local : ça se comprime bien. Jean-Yvon Le 26/07/2015 23:28, Thierry Bézecourt - thie...@thbz.org a écrit : Le 26/07/2015 22:33, osm.sanspourr...@spamgourmet.com a écrit : Je n'ai jamais dit de ne pas garder les tags qui sont différents. name:br=Pariz, on garde ! Je dis juste que name:de=Paris (qui existe actuellement dans la base) n'a pas grand intérêt. Comme je crois l'avoir déjà dit, ton système me paraît incompatible avec une fonctionnalité utile des logiciels, à savoir la possibilité pour l'utilisateur de choisir deux ou trois langues et non pas une seule. (Cette fonctionnalité n'est peut-être guère implémentée, mais c'est une autre question.) Supposons que mes langues favorites soient, dans l'ordre, le français et l'anglais. Avec ton système, je ne verrai jamais le nom anglais (name:en) pour les villes ou rues chinoises ou japonaises, car le système, ne trouvant pas un nom français (name:fr), affichera le nom par défaut en chinois (name). Qui ne m'est guère utile... Une solution serait de créer un champ spécial contenant la liste des langues pour lesquelles le nom est identique au nom par défaut : name=Paris name:it=Parigi name:ko=파리 name:equals_default=fr;en;de... Mais le jeu en vaut-il la chandelle ? La situation actuelle ne pose pas vraiment de difficulté. Thierry ___ 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] Importation des arbres municipaux sur Nice
2015-07-26 10:51 GMT-07:00 JB jb...@mailoo.org: Pour revenir à l'exemple US que je ne connais pas du tout, j'avoue avoir du mal à croire que ça soit simplement à cause de l'import auto de TIGER qu'il y ait aussi peu de contributeurs. Sauf si l'import a été mal fait mais à ce moment là c'est un autre problème. En fait j'aurais même tendance à penser l'inverse: il est plus facile de motiver des contributeurs à travailler sur une carte déjà bien remplie plutôt que sur une carte quasiment vide, où à peu près tout reste à faire.. mais bon là on rentre dans la psychologie. Quelle était ta première contribution ? Dans les ateliers de découverte, l'accroche des participants est classiquement : il manque ma rue, le nom de ma rue, la boite aux lettres à coté de chez moi, mon boulanger. Une fois ça ajouté, ils sont pris dans le jeu et continuent. Tu leurs donnes une carte visuellement « complète », ils ne voient pas quoi faire. Alors, si l'import Tiger a été fait avant d'avoir une base de contributeurs locaux, celle-ci est beaucoup plus difficile à construire à postériori. Et puis, je ne veux pas tourner en rond, mais tu préfères contribuer sur de la nouvelle donnée, ou corriger l'existant, voire reprendre l'existant quand celui-ci est foireux ? Petite anecdote. Il fut même considéré a un moment d'effacer les données TIGER existantes afin de recréer une toile blanche. Chose qui au final ne s'est pas fait du faire de la difficulté de séparer ce qui avait été retouché (mais base sur TIGER) et ce qui ne l'avait pas été. Parmi les exemples similaires, on peut parler des Pays-Bas qui après un import de très grande qualité a perdue une grosse partie de ses contributeurs. Le fait est travailler avec des données vectorielles n'est pas facile et il y a au moins une étude qui montre que pour beaucoup de contributeurs (je ne retrouve plus le lien) s'approprie ce qu'ils ont ajouté (cad C'est moi qui l'ai fait!). C'est aussi un peu la difficulté de la maintenance d'OSM (la encore plusieurs articles scientifiques sur le sujet) une fois que la carte est bien remplie. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Mais surtout, aussi beau que tu fasses l'algorithme, s'il y a plusieurs MatchingTree avec des distances à moins de 5m avec des distances à peu près équivalentes (un arbre à 2.5m, un autre à 3m), pour moi, c'est plutôt un signe que ces cas devraient être gérés à la main… Ce que je voulais entendre de la part de Vincent quand je parlais de ne pas privilégier une source plus qu'une autre. Surtout si l'on part du principe que les données ne sont pas de bonne qualité (ce qui n'est pas forcément le cas) Et pas besoin de FieldPapers pour aller faire du terrain avec un fond de plan. QGIS le fait très bien! Et pour travailler sur une thématique c'est assez simple de pointer avec un stylo et de vérifier avec une ortho. Comme dit précédemment, un Smartphone pour prendre des points sur le terrain c'est vraiment médiocre surtout quand ces points sont pris par des personnes qui considèrent que le GPS c'est toujours le meilleurs moyen d'avoir de la qualité et que les données sont poussés dans OSM sans retouche... On a des données à OSM qui sont affichés au même niveau avec une différence de qualité de rendu. Chaque référentiel importé ou non dans OSM est prévu avec une précision correspondant à son utilisation métier. Le problème c'est de pouvoir regrouper des usages. Autre problématique d'intégration et dont il n'y a même pas un consensus (même sur une commune) c'est adresse postal Certains parle de le mettre à l'entrée du bâtiment, d'autres sur le bâtiment, d'autre devant la rue à l'entrée. On fait quoi pour qui en fait? La poste prendra la boite et la sonnette, d'autre service pour les clients ce sera la porte d'entrée, Certains ce sera le boitier électrique, le compteur de gaz ou d'eau. Et c'est la même pour les commerces. Pas facile de faire la part des choses quand on parle de précision avec une base qui en contient différents niveaux de précision (contribution ou données importées) ___ 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] Importation des arbres municipaux sur Nice
Je comprends les raisons et je vais pas insister dessus. D'ailleurs en passant par QGIS, je peux valider mes données, en vérifier la complétude, invalider ou valider mes données avant de faire une intégration ou un complément sous JOSM. J'aurais un discours plus modulé si on avait dans le cadre de ce fil un echo de contributeurs locaux, qui diraient en substance : c'est bon, que l'import soit fait, on s'occupe de la suite. Mais pour l'instant je n'entends rien. Le constat sur la couverture BANO va dans le même sens. En s'appuyant sur les stats par département (pour Nice : http://cadastre.openstreetmap.fr/fantoir-dev/stats_dept.html#dept=06 ) sur les 10 plus grosses communes de France Nice est celle avec le moins bon ratio a/c. Ça n'est qu'un constat (surtout pas un reproche) mais ce thermomètre (parmi d'autres) de l'activité locale montre qu'on a moins de dynamisme que sur les autres villes de même importance. Et dans ce contexte, je ne vois pas comment un ajout massif et mécanique va motiver du monde pour s'approprier la ville et alentours et _maintenir_ les données (des arbres mais pas que). Ça justifie la problématique de suivi. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tuiles vectorielles et internationales
Le 26/07/2015 22:33, osm.sanspourr...@spamgourmet.com a écrit : Je n'ai jamais dit de ne pas garder les tags qui sont différents. name:br=Pariz, on garde ! Je dis juste que name:de=Paris (qui existe actuellement dans la base) n'a pas grand intérêt. Comme je crois l'avoir déjà dit, ton système me paraît incompatible avec une fonctionnalité utile des logiciels, à savoir la possibilité pour l'utilisateur de choisir deux ou trois langues et non pas une seule. (Cette fonctionnalité n'est peut-être guère implémentée, mais c'est une autre question.) Supposons que mes langues favorites soient, dans l'ordre, le français et l'anglais. Avec ton système, je ne verrai jamais le nom anglais (name:en) pour les villes ou rues chinoises ou japonaises, car le système, ne trouvant pas un nom français (name:fr), affichera le nom par défaut en chinois (name). Qui ne m'est guère utile... Une solution serait de créer un champ spécial contenant la liste des langues pour lesquelles le nom est identique au nom par défaut : name=Paris name:it=Parigi name:ko=파리 name:equals_default=fr;en;de... Mais le jeu en vaut-il la chandelle ? La situation actuelle ne pose pas vraiment de difficulté. Thierry ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
