Re: [OSM-talk-fr] Frontière franco-italienne du Mont-Blanc
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
Re: [OSM-talk-fr] Frontière franco-italienne du Mont-Blanc
Il y a plus d'une station météo, de nationalités différentes en Antarctique, et on ne remet pas en cause le traité pour ça... Art. Le 25 juil. 2015 10:32 AM, Mathias jerome.math...@yahoo.fr a écrit : Si une station météo italienne a été installée sur la partie contestée, c'est quand même une sacré preuve de souveraineté et de gestion de fait de la zone, surtout si nos chasseurs alpins ne vont pas la démonter, ça passer la partie contesté bel et bien du côté italien et une zone disputée n'a même plus lieu d'être, la zone devrait être intégrée du côté italien. Moi je dis ça, mais je ne dis rien... Le 24 juil. 2015 à 18:55, Thierry Bézecourt thie...@thbz.org a écrit : Des Italiens viennent d'installer une station météo au sommet, sul versante italiano della montagna ( http://www.adnkronos.com/sostenibilita/world-in-progress/2015/07/21/clima-installata-sul-monte-bianco-stazione-meteo-piu-alta-europa_vLuRsXdg0AjMFy7TFfXLBM.html). Elle a été ajoutée sur OSM aujourd'hui même et, si la localisation est exacte (source:survey...), elle serait en pleine zone contestée : https://www.openstreetmap.org/node/3664571073 . S'agissant du champ name, je vois mal une organisation internationale se fâcher avec la France ou l'Italie en choisissant officiellement un nom plutôt que l'autre. Pour prendre des exemples non officiels, via-michelin.fr met le nom dans les deux langues. Google Maps met le nom en italien sur un sommet positionné au mauvais endroit et inscrit tout simplement « Alpes » sur le bon sommet, où il place également... une résidence Pierre et Vacances (pardon, mauvais exemple). La seule solution neutre est probablement de mettre les deux noms. Quant à l'idée de ne pas renseigner le champ name, cela conduirait sans doute à faire disparaître le nom d'un certain nombre de cartes faites à partir des données d'OSM. Même openstreetmap.org, sauf erreur de ma part, ne gère toujours pas les balises name:*. Je sais bien qu'on ne taggue pas pour le moteur de rendu, mais un purisme qui ferait disparaître en pratique le point culminant de l'Europe (enfin, presque) serait quelque peu excessif. Et il faut de toute manière un nom par défaut pour les langues dont la balise name:lang n'est pas renseignée. Thierry Le 24/07/2015 16:21, Jérôme Seigneuret a écrit : C'est déjà fait. Mais reste que name ne doit avoir qu'une seule valeur et là les deux sont regroupés et ça c'est pas une bonne chose. N'y a t'il pas un nom reconnu au niveau international? Je crois pas que l'on puisse ne mettre que name:*= sans name= Le 24 juillet 2015 16:12, Francescu GAROBY windu...@gmail.com mailto:windu...@gmail.com a écrit : pour le name, ne vaudrait-il mieux pas scinder la valeur que tu indiques via les tags name:fr et name:it ? Francescu Le 24 juillet 2015 15:08, Eric Sibert courr...@eric.sibert.fr mailto:courr...@eric.sibert.fr a écrit : J'ai un peu fait de nettoyage autour du Mont Blanc. J'ai découvert qu'il y avait 4 nœuds superposés pour le Mont Blanc lui-même, avec des tags pas tous identiques. J'ai mis name=Mont Blanc - Monte Bianco. Le Dôme du Gouter s'appelait Mont Blanc; Dôme du Gouter avec beaucoup d'infos (name:xx, wikipedia...) correspondant au Mont-Blanc et non au Gouter (d'ailleurs il semblerait aussi y avoir une légère contestation de frontière à ce niveau là). Et aussi Mont Blanc - Grand Pilier d'Angle qui est devenu Grand Pilier d'Angle tout court. Il y a encore des trucs comme ça vers les Jorasses. Je n'ai pas modifié la frontière qui fait un peu un zig-zag entre les prétentions françaises et italiennes. Le morceau de frontière est inclus dans 18 relations distinctes, surtout côté français. On discute sur [tagging]. L'idée de séparer la frontière en deux et de tagger la zone entre les deux comme disputée ne leur paraît pas extravagante. Après, le problème est de faire quelque chose de général pour les nombreuses zones disputées dans le monde. Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Francescu ___ 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
Re: [OSM-talk-fr] Frontière franco-italienne du Mont-Blanc
Il me semble qu'on est pas tout à fait dans le meme cas de figure en Antarctique celui-ci étant largement considéré comme une terra nullius, et un traité international est censé régir son statut international. Le 25 juil. 2015 à 10:40, Art Penteur art.pent...@gmail.com a écrit : Il y a plus d'une station météo, de nationalités différentes en Antarctique, et on ne remet pas en cause le traité pour ça... Art. Le 25 juil. 2015 10:32 AM, Mathias jerome.math...@yahoo.fr a écrit : Si une station météo italienne a été installée sur la partie contestée, c'est quand même une sacré preuve de souveraineté et de gestion de fait de la zone, surtout si nos chasseurs alpins ne vont pas la démonter, ça passer la partie contesté bel et bien du côté italien et une zone disputée n'a même plus lieu d'être, la zone devrait être intégrée du côté italien. Moi je dis ça, mais je ne dis rien... Le 24 juil. 2015 à 18:55, Thierry Bézecourt thie...@thbz.org a écrit : Des Italiens viennent d'installer une station météo au sommet, sul versante italiano della montagna (http://www.adnkronos.com/sostenibilita/world-in-progress/2015/07/21/clima-installata-sul-monte-bianco-stazione-meteo-piu-alta-europa_vLuRsXdg0AjMFy7TFfXLBM.html). Elle a été ajoutée sur OSM aujourd'hui même et, si la localisation est exacte (source:survey...), elle serait en pleine zone contestée : https://www.openstreetmap.org/node/3664571073 . S'agissant du champ name, je vois mal une organisation internationale se fâcher avec la France ou l'Italie en choisissant officiellement un nom plutôt que l'autre. Pour prendre des exemples non officiels, via-michelin.fr met le nom dans les deux langues. Google Maps met le nom en italien sur un sommet positionné au mauvais endroit et inscrit tout simplement « Alpes » sur le bon sommet, où il place également... une résidence Pierre et Vacances (pardon, mauvais exemple). La seule solution neutre est probablement de mettre les deux noms. Quant à l'idée de ne pas renseigner le champ name, cela conduirait sans doute à faire disparaître le nom d'un certain nombre de cartes faites à partir des données d'OSM. Même openstreetmap.org, sauf erreur de ma part, ne gère toujours pas les balises name:*. Je sais bien qu'on ne taggue pas pour le moteur de rendu, mais un purisme qui ferait disparaître en pratique le point culminant de l'Europe (enfin, presque) serait quelque peu excessif. Et il faut de toute manière un nom par défaut pour les langues dont la balise name:lang n'est pas renseignée. Thierry Le 24/07/2015 16:21, Jérôme Seigneuret a écrit : C'est déjà fait. Mais reste que name ne doit avoir qu'une seule valeur et là les deux sont regroupés et ça c'est pas une bonne chose. N'y a t'il pas un nom reconnu au niveau international? Je crois pas que l'on puisse ne mettre que name:*= sans name= Le 24 juillet 2015 16:12, Francescu GAROBY windu...@gmail.com mailto:windu...@gmail.com a écrit : pour le name, ne vaudrait-il mieux pas scinder la valeur que tu indiques via les tags name:fr et name:it ? Francescu Le 24 juillet 2015 15:08, Eric Sibert courr...@eric.sibert.fr mailto:courr...@eric.sibert.fr a écrit : J'ai un peu fait de nettoyage autour du Mont Blanc. J'ai découvert qu'il y avait 4 nœuds superposés pour le Mont Blanc lui-même, avec des tags pas tous identiques. J'ai mis name=Mont Blanc - Monte Bianco. Le Dôme du Gouter s'appelait Mont Blanc; Dôme du Gouter avec beaucoup d'infos (name:xx, wikipedia...) correspondant au Mont-Blanc et non au Gouter (d'ailleurs il semblerait aussi y avoir une légère contestation de frontière à ce niveau là). Et aussi Mont Blanc - Grand Pilier d'Angle qui est devenu Grand Pilier d'Angle tout court. Il y a encore des trucs comme ça vers les Jorasses. Je n'ai pas modifié la frontière qui fait un peu un zig-zag entre les prétentions françaises et italiennes. Le morceau de frontière est inclus dans 18 relations distinctes, surtout côté français. On discute sur [tagging]. L'idée de séparer la frontière en deux et de tagger la zone entre les deux comme disputée ne leur paraît pas extravagante. Après, le problème est de faire quelque chose de général pour les nombreuses zones disputées dans le monde. Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Francescu ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Frontière franco-italienne du Mont-Blanc
Le 25/07/2015 00:28, Thierry Bézecourt a écrit : En fait, c'est encore plus complexe. D'après l'IGN (http://geoportail.fr/url/7FcKIT), une partie de la zone contestée, au sud de la crête reliant le Mont Blanc et le Mont Blanc de Courmayeur, est une enclave de Saint-Gervais-les-Bains et non une partie de Chamonix... La représentation de l'IGN n'est pas conforme à arrêté préfectoral du 21 septembre 1946 qu'il paraît par ailleurs bien difficile de mettre en œuvre. St-Gervais devrait avoir un accès direct au sommet du Mt-Blanc avec une bande de terrain au niveau du Goûter entre la ligne de partage des eaux et la crête visible de Courmayeur. Non seulement cette bande est contestée entre France et Italie au niveau du Goûter mais en plus, elle n'existe physiquement plus entre les Bosses et la Tournette. Bien lire et ne pas héister à relire : https://fr.wikipedia.org/wiki/Histoire_de_la_fronti%C3%A8re_sur_le_mont_Blanc ___ 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
Si une station météo italienne a été installée sur la partie contestée, c'est quand même une sacré preuve de souveraineté et de gestion de fait de la zone, surtout si nos chasseurs alpins ne vont pas la démonter, ça passer la partie contesté bel et bien du côté italien et une zone disputée n'a même plus lieu d'être, la zone devrait être intégrée du côté italien. Moi je dis ça, mais je ne dis rien... Le 24 juil. 2015 à 18:55, Thierry Bézecourt thie...@thbz.org a écrit : Des Italiens viennent d'installer une station météo au sommet, sul versante italiano della montagna (http://www.adnkronos.com/sostenibilita/world-in-progress/2015/07/21/clima-installata-sul-monte-bianco-stazione-meteo-piu-alta-europa_vLuRsXdg0AjMFy7TFfXLBM.html). Elle a été ajoutée sur OSM aujourd'hui même et, si la localisation est exacte (source:survey...), elle serait en pleine zone contestée : https://www.openstreetmap.org/node/3664571073 . S'agissant du champ name, je vois mal une organisation internationale se fâcher avec la France ou l'Italie en choisissant officiellement un nom plutôt que l'autre. Pour prendre des exemples non officiels, via-michelin.fr met le nom dans les deux langues. Google Maps met le nom en italien sur un sommet positionné au mauvais endroit et inscrit tout simplement « Alpes » sur le bon sommet, où il place également... une résidence Pierre et Vacances (pardon, mauvais exemple). La seule solution neutre est probablement de mettre les deux noms. Quant à l'idée de ne pas renseigner le champ name, cela conduirait sans doute à faire disparaître le nom d'un certain nombre de cartes faites à partir des données d'OSM. Même openstreetmap.org, sauf erreur de ma part, ne gère toujours pas les balises name:*. Je sais bien qu'on ne taggue pas pour le moteur de rendu, mais un purisme qui ferait disparaître en pratique le point culminant de l'Europe (enfin, presque) serait quelque peu excessif. Et il faut de toute manière un nom par défaut pour les langues dont la balise name:lang n'est pas renseignée. Thierry Le 24/07/2015 16:21, Jérôme Seigneuret a écrit : C'est déjà fait. Mais reste que name ne doit avoir qu'une seule valeur et là les deux sont regroupés et ça c'est pas une bonne chose. N'y a t'il pas un nom reconnu au niveau international? Je crois pas que l'on puisse ne mettre que name:*= sans name= Le 24 juillet 2015 16:12, Francescu GAROBY windu...@gmail.com mailto:windu...@gmail.com a écrit : pour le name, ne vaudrait-il mieux pas scinder la valeur que tu indiques via les tags name:fr et name:it ? Francescu Le 24 juillet 2015 15:08, Eric Sibert courr...@eric.sibert.fr mailto:courr...@eric.sibert.fr a écrit : J'ai un peu fait de nettoyage autour du Mont Blanc. J'ai découvert qu'il y avait 4 nœuds superposés pour le Mont Blanc lui-même, avec des tags pas tous identiques. J'ai mis name=Mont Blanc - Monte Bianco. Le Dôme du Gouter s'appelait Mont Blanc; Dôme du Gouter avec beaucoup d'infos (name:xx, wikipedia...) correspondant au Mont-Blanc et non au Gouter (d'ailleurs il semblerait aussi y avoir une légère contestation de frontière à ce niveau là). Et aussi Mont Blanc - Grand Pilier d'Angle qui est devenu Grand Pilier d'Angle tout court. Il y a encore des trucs comme ça vers les Jorasses. Je n'ai pas modifié la frontière qui fait un peu un zig-zag entre les prétentions françaises et italiennes. Le morceau de frontière est inclus dans 18 relations distinctes, surtout côté français. On discute sur [tagging]. L'idée de séparer la frontière en deux et de tagger la zone entre les deux comme disputée ne leur paraît pas extravagante. Après, le problème est de faire quelque chose de général pour les nombreuses zones disputées dans le monde. Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Francescu ___ 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] Frontière franco-italienne du Mont-Blanc
Attention, l'article ne dit pas explicitement que la station est située en zone contestée. C'est un contributeur OSM (certes expérimenté) qui l'a placée à cet endroit. La station a été installée par une association, donc on peut penser qu'ils ont obtenu une autorisation. J'imagine mal que l'État accorde une autorisation d'occupation du domaine public (ou l'équivalent en italien) sur une zone dont la souveraineté est contestée. Enfin, qui sait... Thierry Le 25/07/2015 10:13, Mathias a écrit : Si une station météo italienne a été installée sur la partie contestée, c'est quand même une sacré preuve de souveraineté et de gestion de fait de la zone, surtout si nos chasseurs alpins ne vont pas la démonter, ça passer la partie contesté bel et bien du côté italien et une zone disputée n'a même plus lieu d'être, la zone devrait être intégrée du côté italien. Moi je dis ça, mais je ne dis rien... Le 24 juil. 2015 à 18:55, Thierry Bézecourt thie...@thbz.org a écrit : Des Italiens viennent d'installer une station météo au sommet, sul versante italiano della montagna (http://www.adnkronos.com/sostenibilita/world-in-progress/2015/07/21/clima-installata-sul-monte-bianco-stazione-meteo-piu-alta-europa_vLuRsXdg0AjMFy7TFfXLBM.html). Elle a été ajoutée sur OSM aujourd'hui même et, si la localisation est exacte (source:survey...), elle serait en pleine zone contestée : https://www.openstreetmap.org/node/3664571073 . S'agissant du champ name, je vois mal une organisation internationale se fâcher avec la France ou l'Italie en choisissant officiellement un nom plutôt que l'autre. Pour prendre des exemples non officiels, via-michelin.fr met le nom dans les deux langues. Google Maps met le nom en italien sur un sommet positionné au mauvais endroit et inscrit tout simplement « Alpes » sur le bon sommet, où il place également... une résidence Pierre et Vacances (pardon, mauvais exemple). La seule solution neutre est probablement de mettre les deux noms. Quant à l'idée de ne pas renseigner le champ name, cela conduirait sans doute à faire disparaître le nom d'un certain nombre de cartes faites à partir des données d'OSM. Même openstreetmap.org, sauf erreur de ma part, ne gère toujours pas les balises name:*. Je sais bien qu'on ne taggue pas pour le moteur de rendu, mais un purisme qui ferait disparaître en pratique le point culminant de l'Europe (enfin, presque) serait quelque peu excessif. Et il faut de toute manière un nom par défaut pour les langues dont la balise name:lang n'est pas renseignée. Thierry Le 24/07/2015 16:21, Jérôme Seigneuret a écrit : C'est déjà fait. Mais reste que name ne doit avoir qu'une seule valeur et là les deux sont regroupés et ça c'est pas une bonne chose. N'y a t'il pas un nom reconnu au niveau international? Je crois pas que l'on puisse ne mettre que name:*= sans name= Le 24 juillet 2015 16:12, Francescu GAROBY windu...@gmail.com mailto:windu...@gmail.com a écrit : pour le name, ne vaudrait-il mieux pas scinder la valeur que tu indiques via les tags name:fr et name:it ? Francescu Le 24 juillet 2015 15:08, Eric Sibert courr...@eric.sibert.fr mailto:courr...@eric.sibert.fr a écrit : J'ai un peu fait de nettoyage autour du Mont Blanc. J'ai découvert qu'il y avait 4 nœuds superposés pour le Mont Blanc lui-même, avec des tags pas tous identiques. J'ai mis name=Mont Blanc - Monte Bianco. Le Dôme du Gouter s'appelait Mont Blanc; Dôme du Gouter avec beaucoup d'infos (name:xx, wikipedia...) correspondant au Mont-Blanc et non au Gouter (d'ailleurs il semblerait aussi y avoir une légère contestation de frontière à ce niveau là). Et aussi Mont Blanc - Grand Pilier d'Angle qui est devenu Grand Pilier d'Angle tout court. Il y a encore des trucs comme ça vers les Jorasses. Je n'ai pas modifié la frontière qui fait un peu un zig-zag entre les prétentions françaises et italiennes. Le morceau de frontière est inclus dans 18 relations distinctes, surtout côté français. On discute sur [tagging]. L'idée de séparer la frontière en deux et de tagger la zone entre les deux comme disputée ne leur paraît pas extravagante. Après, le problème est de faire quelque chose de général pour les nombreuses zones disputées dans le monde. Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Francescu ___ 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
Re: [OSM-talk-fr] Intégration des données de PSS dans OSM
Effectivement ce tag pourrait leur faire plaisir mais je doute que ça soit suffisant pour leur faire abandonner leur clause NC. De toute les manière je vais un peu attendre un ou deux mois avant de revenir vers eux pour voir si leur position a changé.. Le 25 juillet 2015 16:59, osm.sanspourr...@spamgourmet.com a écrit : Je vois un tag qui pourrait leur faire plaisir : attribution http://wiki.openstreetmap.org/wiki/Key:attribution *User defined* [image: Nœud] http://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments#N.C5.93ud_.28node.29 [image: Chemin] http://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments#Chemin_.28way.29 [image: Zone] http://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments#Area_.28closed_way.29 [image: Relation] http://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments#Relation Attribution au créateur si requise. Mais le principe de l'ODbl est et reste : libre d'utilisation en citant. Jean-Yvon ___ 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
Le 25 juillet 2015 18:53, Vincent Pottier vpott...@gmail.com a écrit : Si le programme, qui détecte la présence d'un arbre à 2 m, pouvait modifier le point existant plutôt que de le remplacer, ce serait top. Merci pour ceux qui ont œuvré à OSM. Mais c'est le cas ! J'ai justement changé le programme pour qu'il mette à jour les arbres existants à moins de X mètres au lieu de les supprimer.. ___ 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
Moi, ce qui me gène dans le fait de remplacer ( effacer et créer un nouvel ) un arbre, c'est la perte de l'historique et le passage à la trappe des contributions antérieures. OpenStreetMap, c'est aussi la mémoire des contributions anciennes. Comme dans Wikipédia, la trace historique est une façon d'honorer ceux qui ont fait OSM. Certes, le point ancien reste quelque part au fond de la base de donnée. Mais, il n'apparait plus dans aucun historique d'objet présent, enterré, oublié, disparu. Dans le roman de science-fiction 1984, l'histoire est effacée et ré-écrite, sans mémoire, sans épaisseur du temps. Nous ne sommes pas Winston Smith, qui efface les archives pour les faire correspondre à l'actualité du Parti. Certes, dans le roman, l'effacement est idéologique, dans le cas présent, il ne serait que par négligence, insouciance, facilité. La richesse d'OSM, c'est bien sur ses données, techniquement excellentes (tout au moins on s'y essaie), mais c'est plus encore sa communauté. Que devient cette richesse technique, si par facilité, on efface l'épaisseur humaine de cette communauté ? Une donnée technique mouvante, errante à travers le temps ? Un peuple sans mémoire est un peuple sans avenir aurait dit un certain Foch. Si le programme, qui détecte la présence d'un arbre à 2 m, pouvait modifier le point existant plutôt que de le remplacer, ce serait top. Merci pour ceux qui ont œuvré à OSM. C'était mon quart-d'heure philo... -- FrViPofm Le 21 juillet 2015 14:05, Vincent Frison vincent.fri...@gmail.com a écrit : Hello Je compte importer dans OSM l'ensemble des arbres municipaux de Nice, merci au portail OpenData de l'agglomération de Côte d'Azur. Ici c'est du vrai open data, je ne devrais donc pas avoir la même frustration qu'avec l'import des immeubles de PSS ;) Ils viennent de mettre à jour leur fichier qui contient maintenant plus de 30 000 arbres : http://opendata.nicecotedazur.org/data/dataset?q=arbres En plus de créer les nouveaux arbres mon programme vérifie également la présence d'arbres existants afin de les effacer. Actuellement j'ai mis un rayon de 2 mètres donc pour chaque arbre importé, je regarde les arbres existants qui sont à moins de 2 mètres. Pour l'instant je n'efface que l'arbre plus proche de l'arbre importé (je pourrais également supprimer tous les arbres qui sont à moins de x mètres mais en fait ça ne change pas grand chose car s'il y a plusieurs arbres existants qui sont très proches à priori il y aura également plusieurs arbres importés qui seront très proches donc au final même en ne supprimant que l'arbre existant le plus proche tous les arbres existants seront bien effacés, ce que j'ai pu vérifier par mes tests). Concrètement sur les ~30 000 arbres importés il y a ~540 arbres existants à supprimer. Ce qui est dommage c'est que le fichier n'indique pas le type des arbres et c'est d'autant plus dommage que les arbres existants ont parfois un tag type=*. Par ex. les arbres existants le long de la Promenade des Anglais sont marqué comme palmier (type=palm). Malheureusement je serai obligé de remettre le type à la main une fois l'import exécuté. Mon programme pourrait éventuellement récupérer le type des arbres existants mais bon ça ne marcherait que sur une toute petite partie des arbres importés... D'ailleurs j'ai un peu de mal à comprendre la bonne manière d'indiquer le type car sur la page Wiki du tag natural=tree ( http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree) il est marqué que le tag type=* est obsolète et qu'il faut plutôt utilisé le tag leaf_type=*. Sauf que ce dernier n'est censé prendre que les valeurs suivantes : broadleaved / needleleaved / mixed / leafless. De plus sous JSOM si on met type=palm ça affiche bien l'arbre avec une image de palmier mais ça ne le fait pas si j'essaye avec genus|species=palm|palmtree. Bref c'est pas très clair... Voila si vous avez des conseils ou suggestions n'hésitez surtout pas.. ++ Vincent. ___ 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
Au fait le portail OpenData de Nice utilise la Licence Ouverte ( http://www.etalab.gouv.fr/licence-ouverte-open-licence), on est bien d'accord que c'est bien compatible avec l'ODbL ? A priori oui mais c'est juste pour être sûr ;) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Intégration des données de PSS dans OSM
Je vois un tag qui pourrait leur faire plaisir : attribution http://wiki.openstreetmap.org/wiki/Key:attribution /User defined/ Nœud http://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments#N.C5.93ud_.28node.29 Chemin http://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments#Chemin_.28way.29 Zone http://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments#Area_.28closed_way.29 Relation http://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments#Relation Attribution au créateur si requise. Mais le principe de l'ODbl est et reste : libre d'utilisation en citant. Jean-Yvon ___ 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, Le 25/07/2015 01:12, osm.sanspourr...@spamgourmet.com a écrit : Même openstreetmap.org, sauf erreur de ma part, ne gère toujours pas les balises name:*. OK, en clair : osm.org ne gère pas la langue (du user agent du navigateur ou sur demande) pour offrir la carte dans la langue préférée de l'utilisateur. Le contraire signifierait l'existence d'un jeu de tuiles par langue, ou un autre mécanisme pas déjà implémenté sur le site. On en a l'illustration avec http://mlm.jochentopf.com/ où l'éventail de tous les name:* est disponible. en principe il n'y a pas de double valeurs. S'il faut faire une exception c'est pas à nous de le décider il me semble mais à la fondation. Donc on peut décider dans notre coin de créer des no man land (à tous les sens du terme ici !) mais pas de mettre un nom neutre qui suis la pratique à 20 km au nord ? J'avoue que je suis perplexe. Non, la Fondation n'a (heureusement !) pas à mettre son nez dans un choix de schéma de tags, ou alors les contributeurs ne servent plus à rien dans le projet. Concrètement de la double toponymie directement dans le tag name on en trouve, par exemple à Bruxelles / Brussel, où tous les noms de rue respectent le même principe : http://www.openstreetmap.org/relation/2404021#map=19/50.84779/4.34652 vincent ___ 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
1) Oui, et les valeurs multiples pour le champ name sont recommandées par http://wiki.openstreetmap.org/wiki/Multilingual_names#Shared_boundary_features Always add name:code=* for each involved language, and for compatibility with older rendering engines, also set name=* to both names, separated by a forward slash with spaces in between, sorted in (a somewhat neutral) Unicode alphabetical order. Exemple : le Rhin (https://www.openstreetmap.org/way/61514585) Les valeurs multiples sont indispensables à une base qui cherche la neutralité. 2) J'ai lu sur une autre liste que Mapnik allait évoluer pour permettre à l'utilisateur de choisir une langue d'affichage. Avez-vous des informations à ce sujet ? Thierry Le 25/07/2015 08:12, Vincent de Château-Thierry a écrit : Bonjour, Le 25/07/2015 01:12, osm.sanspourr...@spamgourmet.com a écrit : Même openstreetmap.org, sauf erreur de ma part, ne gère toujours pas les balises name:*. OK, en clair : osm.org ne gère pas la langue (du user agent du navigateur ou sur demande) pour offrir la carte dans la langue préférée de l'utilisateur. Le contraire signifierait l'existence d'un jeu de tuiles par langue, ou un autre mécanisme pas déjà implémenté sur le site. On en a l'illustration avec http://mlm.jochentopf.com/ où l'éventail de tous les name:* est disponible. en principe il n'y a pas de double valeurs. S'il faut faire une exception c'est pas à nous de le décider il me semble mais à la fondation. Donc on peut décider dans notre coin de créer des no man land (à tous les sens du terme ici !) mais pas de mettre un nom neutre qui suis la pratique à 20 km au nord ? J'avoue que je suis perplexe. Non, la Fondation n'a (heureusement !) pas à mettre son nez dans un choix de schéma de tags, ou alors les contributeurs ne servent plus à rien dans le projet. Concrètement de la double toponymie directement dans le tag name on en trouve, par exemple à Bruxelles / Brussel, où tous les noms de rue respectent le même principe : http://www.openstreetmap.org/relation/2404021#map=19/50.84779/4.34652 vincent ___ 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
De plus si une administration a un SIG donnant ces informations et les proposant à l'import, on peut supposer que soit ils comptent sur les contributeurs pour leur signaler les problèmes soit ils vont vouloir que l'import soit fait régulièrement. Sinon ça ne fait pas très sérieux. Vincent, tu peux peut-être voir avec eux pour que leur base et OSM restent cohérents. Selon le wiki http://wiki.openstreetmap.org/wiki/FR:Tag:natural%3Dtree : natural=tree : Arbre important seul ou en groupes. 453 298 en France. Si tu ne sais pas, ne vaut-il pas mieux mettre pour les nouvelles entrées : natural http://wiki.openstreetmap.org/wiki/FR:Key:natural wood http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwood Nœud http://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments#N.C5.93ud_.28node.29 Zone http://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments#Area_.28closed_way.29 Bois. 360 en France Par contre quand je vois proposer de mettre une taille par défaut, ça me semble aller contre l'usage : quand on n'a pas d'info, on ne l'invente pas. Tu peux peut-être ajouter un fixme pour discriminer ceux qui n'ont pas été vérifiés sur le terrain, ou fixme et une hauteur arbitraire. Il me semble plus efficace d'essayer de récupérer plus d'information (j'imagine que la municipalité sait ce qui est planté). Ou une note (pour que les cartographes aillent compléter). Le rendu est donc conforme à la description (arbre important, pas arbre et encore moins arbuste). Donc soit il s'agit d'un arbre soit il s'agit d'un arbuste. Si tu veux ajouter une estimation de largeur : est_width http://wiki.openstreetmap.org/wiki/FR:Key:est_width=*. Alors est_height si tu y tiens ? Ou : height= source:height http://wiki.openstreetmap.org/wiki/FR:Key:source extrapolation Doit on mettre operator avec le service technique de Nice ? Jean-Yvon Le 24/07/2015 16:16, Jérôme Seigneuret - jseigneuret-...@yahoo.fr a écrit : Le problème des arbres est similaire à celui du bâti. On dézingue pas des arbres régulièrement (en tout cas en ville)... Il y a qu'a voir les platanes. Sauf maladie, tempête, risque pour la sécurité des usagers, il n'y a pas de raison. Si la croissance est importante et que les arbres sont plantés trop proche pour les premières années (histoire de faire joli), il y a un arbre sur deux qui saute (au bout de dix ans en principe). D'ici là on a le temps de voir les choses changer. Le 24 juillet 2015 14:53, Vincent Frison vincent.fri...@gmail.com mailto:vincent.fri...@gmail.com a écrit : Le 24 juillet 2015 14:44, JB jb...@mailoo.org mailto:jb...@mailoo.org a écrit : Sans vouloir trop m'avancer, je pense que Christian demandait : « Qui va s'occuper de l'entretien des données arbres à Nice ? ». C'est beau (ou pas) de les importer, mais quid de leur évolution dans 2, 5, 15 ans ? Est-ce que les mappeurs locaux sont ok pour s'en charger ? Est-ce que tu es prêt à t'en charger ? Oui je suis ok pour m'en occuper (j'habite la région pour info), y compris dans 15 ans si je suis toujours vivant... ___ 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 25 juillet 2015 16:45, osm.sanspourr...@spamgourmet.com a écrit : De plus si une administration a un SIG donnant ces informations et les proposant à l'import, on peut supposer que soit ils comptent sur les contributeurs pour leur signaler les problèmes soit ils vont vouloir que l'import soit fait régulièrement. Sinon ça ne fait pas très sérieux. Vincent, tu peux peut-être voir avec eux pour que leur base et OSM restent cohérents. A vrai dire je n'ai plus de nouvelles d'eux depuis quelque temps, la personne avec qui j'étais en contact est surement en vacance. Selon le wiki http://wiki.openstreetmap.org/wiki/FR:Tag:natural%3Dtree : natural=tree : Arbre important seul ou en groupes. 453 298 en France. Si tu ne sais pas, ne vaut-il pas mieux mettre pour les nouvelles entrées : natural http://wiki.openstreetmap.org/wiki/FR:Key:natural wood http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwood [image: Nœud] http://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments#N.C5.93ud_.28node.29 [image: Zone] http://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments#Area_.28closed_way.29 Bois. 360 en France J'avoue ne pas très bien comprendre, apparemment ce natural=wook est vraiment fait pour les forêts ou bois, mais dans le cadre d'import d'arbres municipaux ça n'a pas trop de sens.. enfin cela pourrait éventuellement en avoir pour deux ou trois gros parcs dans Nice mais perso je préfère les implémenter en rajoutant des éléments avec natural=tree. En plus de ça mon programme ne sait pas faire cela actuellement, il faudrait détecter des zones a forte concentration et c'est pas si simple. Ceci dit si c'est vraiment gênant rien n'empêchera de le faire manuellement après l'import (cad supprimer les arbres importés et rajouter une zone avec natural=wood). Par contre quand je vois proposer de mettre une taille par défaut, ça me semble aller contre l'usage : quand on n'a pas d'info, on ne l'invente pas. Tu peux peut-être ajouter un fixme pour discriminer ceux qui n'ont pas été vérifiés sur le terrain, ou fixme et une hauteur arbitraire. Il me semble plus efficace d'essayer de récupérer plus d'information (j'imagine que la municipalité sait ce qui est planté). Ou une note (pour que les cartographes aillent compléter). Oui j'avoue que cela me gênait aussi.. du coup j'essayerai de faire des mises à jour manuelles sur les arbres de la Prom' pour réduire la taille des petits arbres. Le rendu est donc conforme à la description (arbre important, pas arbre et encore moins arbuste). Donc soit il s'agit d'un arbre soit il s'agit d'un arbuste. J'ai pas trop compris.. il ne faudrait pas importer des arbres dans OSM si ceux ci sont petits ? Si tu veux ajouter une estimation de largeur : est_width http://wiki.openstreetmap.org/wiki/FR:Key:est_width=*. Alors est_height si tu y tiens ? Ah je ne savais pas que ce tag est_height existait.. mais est il vraiment pris en charge par les moteurs de rendu (F4map) ? Parce qu'il n'a pas l'air super officiel puisqu'il n'existe pas sur le wiki (contrairement au tag est_width) mais je vais essayer. Doit on mettre operator avec le service technique de Nice ? Ah je sais pas, mais ça me parait une bonne idée... en mettant Municipality of Nice comme valeur ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Recyclage du rendu QA dans osmose: bâti non importé
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 :) -- Christian Quest - OpenStreetMap France ___ 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
Les deux ne sont pas incompatible. L'import ne donne que la position. Rien n’empêche de faire une campagne de terrain pour définir qu'elle est le type d'arbre et les infos qui suivent. Je suis bien d'accord que faire du terrain en groupe c'est cool. Maintenant, il y a un intérêt certains d'avoir les arbres sur le plan et de pourvoir vérifier avec une version imprimé directement. Après il est sûr que suite à l'intégration laisser un message sur la liste PACA ou celle du 06 serait une bonne chose. Il y a aussi les Lycée d'aménagements Paysagers qui pourraient être sollicité ou intéressé ainsi que les filières SIG du coin... Peut-être qu'un serveur avec une carte bac à sable avec une possibilité d'imprimer offrirait le meilleur compromis pour éviter des coups d'intégration massif (de bonne volonté). Osmose me semble pas être le seul moyen de faire de l'intégration (en tous cas du point par point pour des arbres c'est trop long). Je rentre près de 200 arbres par jour pour des arbres d'alignements avec les taxons. D'ailleurs après avoir corrigé une erreur de tag obsolète name:botanical (proposition existant toujours dans le formulaire JOSM) et l'avoir remplacé massivement en taxon à partir de JOSM, j'ai les avertissements d'erreurs qui sont toujours présents. En évolution il serait intéressant d'ajouter un bouton pour forcer la vérification des erreurs pour savoir si elles existent encore ou de faire un check lors de la connexion. Le 25 juillet 2015 22:50, Vincent de Château-Thierry v...@laposte.net a écrit : Le 25/07/2015 19:27, Vincent Frison a écrit : Le 25 juillet 2015 18:53, Vincent Pottier vpott...@gmail.com mailto:vpott...@gmail.com a écrit : Si le programme, qui détecte la présence d'un arbre à 2 m, pouvait modifier le point existant plutôt que de le remplacer, ce serait top. Merci pour ceux qui ont œuvré à OSM. Mais c'est le cas ! J'ai justement changé le programme pour qu'il mette à jour les arbres existants à moins de X mètres au lieu de les supprimer.. Et si on s'y prenait autrement ? Et si les données des arbres de Nice étaient un prétexte à une autre démarche, où le programme, en cours de discussion, n'était pas une fin mais juste un moyen ? Les imports au sens strict sont rares en France. On a eu Corine fin 2009, les repères géodésiques début 2010, et depuis, pas grand chose. Car on a mis un point d'honneur, à maintes reprises, à _ne pas_ procéder à des imports, mais à des opérations d'intégration. En insistant bien sur la nuance : l'intégration laisse le dernier mot au contributeur, et non à un robot, aussi futé soit-il. L'intégration s'appuie sur Osmose ou des outils spécifiques (postes, écoles, adresses, bâtiments, etc.). Pourtant, ce ne sont pas les données qui manquent, qui seraient prétextes à import. On croule sous les jeux de données OpenData, on a depuis l'année dernière accès aux adresses du cadastre vectoriel, bref, si on voulait, on passerait notre temps à importer. Sauf qu'un import laisse de côté, par définition, une des forces principales d'OSM, à savoir l'implication de contributeurs sur le terrain, la connaissance qu'ils en tirent, et qui en retour profite à la base et au projet. Vincent, je salue ton initiative de vouloir ajouter les arbres sur Nice et alentours. Sans contester la finalité, si on prenait un autre chemin pour y arriver ? Par exemple, en prenant ce matériau comme prétexte pour réunir quelques contributeurs niçois, autour d'un ordi et d'un verre, afin de discuter d'une démarche concertée pour ajouter les arbres sur Nice ? Quid d'un relevé sur un quartier ? De prises de vue ? D'une intégration suite à constat terrain, qui au passage permet une vraie évaluation du jeu de données OD ? D'une division du territoire où chacun s'empare d'un quartier ? Si on parvient via ce prétexte à fédérer des énergies, le bénéfice, sur la durée, me semble évident. La contrepartie, toute aussi évidente, est que la présence des arbres de Nice dans la base prendra bien plus de temps et de délai que via un import. Mais est-ce un problème ? vincent ___ 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
Le 25/07/2015 23:42, Jérôme Seigneuret a écrit : Les deux ne sont pas incompatible. L'import ne donne que la position. Si au moins il la donnait... La précision géographique n'est clairement pas ce qu'il y a de meilleur quand on commence à challenger les jeux de données OpenData. Par principe il est impossible de généraliser sur la qualité, tant il y a de producteurs et de méthodes différents, mais s'il y a bien un point sur lequel il faut douter sur _tous_ les jeux de données, c'est le positionnement, la qualité de la géométrie. Rien n’empêche de faire une campagne de terrain pour définir qu'elle est le type d'arbre et les infos qui suivent. Je suis bien d'accord que faire du terrain en groupe c'est cool. Maintenant, il y a un intérêt certains d'avoir les arbres sur le plan et de pourvoir vérifier avec une version imprimé directement. L'intérêt d'avoir les arbres in fine, je ne le discute pas, c'est un niveau de détail vers lequel on va (tout comme distinguer les trottoirs du filaire de voie, etc.) même si la densité de points en certains endroits (c'est le cas dans Nice) va en intimider plus d'un au moment d'éditer la carte. Après il est sûr que suite à l'intégration laisser un message sur la liste PACA ou celle du 06 serait une bonne chose. Bingo : il n'y a ni liste PACA ni liste 06... Construire une dynamique locale passe je pense plus par la constitution de ce genre d'espace d'échange que par un import. Il y a aussi les Lycée d'aménagements Paysagers qui pourraient être sollicité ou intéressé ainsi que les filières SIG du coin... Par exemple oui. Peut-être qu'un serveur avec une carte bac à sable avec une possibilité d'imprimer offrirait le meilleur compromis pour éviter des coups d'intégration massif (de bonne volonté). Je lis coût ;) Imprimer le jeu de données dans son contexte, avec un fond carto dessous, ne nécessite absolument pas d'avoir procédé à un import. Avec un outil comme QGis (voire JOSM, mais je ne sais pas ce qu'il vaut pour imprimer) c'est très simple de combiner un jeu de données comme les arbres de Nice, et un fond OSM ou autre. Et c'est un bon document de travail pour aller sur place. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Recyclage du rendu QA dans osmose: bâti non importé
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 ! Par contre tu pourrais ajouter le nom de la commune dans le signalement ? ___ 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'intérêt d'avoir les arbres in fine, je ne le discute pas, c'est un niveau de détail vers lequel on va (tout comme distinguer les trottoirs du filaire de voie, etc.) Disons que ça fait une carte à plusieurs échelle de précision. C'est un peu le principe du schéma suisse INTERLIS 2 qui permet suivant l'échelle de spécifier des objets avec plus ou moins de détail. C'est pas forcément utile partout mais en ville c'est quand même sympa surtout quand derrière on parle de faire de la 3D. C'est sur que quand on parle de détail j'ai en mémoire la CLC et une échelle qui ne correspond pas à ce que l'on souhaite dans OSM. Si on parle de vandalisme en affichant des arbres qu'en est t'il de la CLC? J'ai déjà corrigé des zones mais en plus avec les multipolygones c'est vraiment pas simple à gérer. Perso je redécoupe Bingo : il n'y a ni liste PACA ni liste 06... Construire une dynamique locale passe je pense plus par la constitution de ce genre d'espace d'échange que par un import. Pas de liste de coordination ne veut pas forcément dire pas de contributeurs. Il n'y en a pas beaucoup de renseigné mais il y a ça juste pour Nice alors pour PACA je ne sais pas http://wiki.openstreetmap.org/wiki/Category:Users_in_Nice Je lis coût ;) Imprimer le jeu de données dans son contexte, avec un fond carto dessous, ne nécessite absolument pas d'avoir procédé à un import. Avec un outil comme QGis (voire JOSM, mais je ne sais pas ce qu'il vaut pour imprimer) c'est très simple de combiner un jeu de données comme les arbres de Nice, et un fond OSM ou autre. Et c'est un bon document de travail pour aller sur place. Je parle du bac à sable car ça permettrait aussi de faire des tests en effet ça a un coût mais c'est aussi le coût de l'entrainement ou le la formation pour éviter d'intégrer n'importe quoi n'importe comment. Oui c'est vrai que via QGIS c'est aussi possible.Où avais-je la tête... . Pour la question est-ce un bon document? Clairement oui. Je travaille ainsi sur le terrain pour faire mes relevés et je gagne pas mal de temps. Coté édition mobile c'est trop long pour moi et la qualité c'est trop pourri (de 3m à 15m) proche de batîments testé avec Mapillary qui refusait des fois de faire la prise de vu à cause d'une précision. Reste les bonnes vieilles méthodes. La trigonométrie sur le terrain avec un mètre de terrain de 20 à 50m et des points de référence. Au moins on voit ce qui est intégré. Le truc qui me manque coté QGIS c'est le mapcss qui existe sur JOSM pour faire de la carte orientée thématique. Peut-être en faisant des exports Overpass par thème et faire une symbologie spécifique sous QGIS. Jérôme ___ 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 25/07/2015 19:27, Vincent Frison a écrit : Le 25 juillet 2015 18:53, Vincent Pottier vpott...@gmail.com mailto:vpott...@gmail.com a écrit : Si le programme, qui détecte la présence d'un arbre à 2 m, pouvait modifier le point existant plutôt que de le remplacer, ce serait top. Merci pour ceux qui ont œuvré à OSM. Mais c'est le cas ! J'ai justement changé le programme pour qu'il mette à jour les arbres existants à moins de X mètres au lieu de les supprimer.. Et si on s'y prenait autrement ? Et si les données des arbres de Nice étaient un prétexte à une autre démarche, où le programme, en cours de discussion, n'était pas une fin mais juste un moyen ? Les imports au sens strict sont rares en France. On a eu Corine fin 2009, les repères géodésiques début 2010, et depuis, pas grand chose. Car on a mis un point d'honneur, à maintes reprises, à _ne pas_ procéder à des imports, mais à des opérations d'intégration. En insistant bien sur la nuance : l'intégration laisse le dernier mot au contributeur, et non à un robot, aussi futé soit-il. L'intégration s'appuie sur Osmose ou des outils spécifiques (postes, écoles, adresses, bâtiments, etc.). Pourtant, ce ne sont pas les données qui manquent, qui seraient prétextes à import. On croule sous les jeux de données OpenData, on a depuis l'année dernière accès aux adresses du cadastre vectoriel, bref, si on voulait, on passerait notre temps à importer. Sauf qu'un import laisse de côté, par définition, une des forces principales d'OSM, à savoir l'implication de contributeurs sur le terrain, la connaissance qu'ils en tirent, et qui en retour profite à la base et au projet. Vincent, je salue ton initiative de vouloir ajouter les arbres sur Nice et alentours. Sans contester la finalité, si on prenait un autre chemin pour y arriver ? Par exemple, en prenant ce matériau comme prétexte pour réunir quelques contributeurs niçois, autour d'un ordi et d'un verre, afin de discuter d'une démarche concertée pour ajouter les arbres sur Nice ? Quid d'un relevé sur un quartier ? De prises de vue ? D'une intégration suite à constat terrain, qui au passage permet une vraie évaluation du jeu de données OD ? D'une division du territoire où chacun s'empare d'un quartier ? Si on parvient via ce prétexte à fédérer des énergies, le bénéfice, sur la durée, me semble évident. La contrepartie, toute aussi évidente, est que la présence des arbres de Nice dans la base prendra bien plus de temps et de délai que via un import. Mais est-ce un problème ? vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] name:* C°
Le 25/07/2015 12:30, osm.sanspourr...@spamgourmet.com a écrit : *Nom :* Vincent, oui, une autre solution c'est un fond de carte sans nom et des noms géolocalisés (ou une tuile vectorielle rendue en local). Et là on a après I18N, L10N : outre la gestion internationale (langues) il y a la régionalisation (le logo d'un hôpital sur le rendu OSM-FR ressemble au panneau français désignant un hôpital). D'où une question : est-ce que le site openstreetmap.org ne devrait pas proposer par défaut le rendu du pays ? C'est à dire OSM-FR depuis la France ou si langue fr-FR. Techniquement c'est possible, mais il faut que les générateurs de tuiles locaux puissent encaisser le traffic. Quelques pays ont développé un rendu local, mais c'est encore bien rare. Le passage en vectoriel devrait permettre de plus facilement gérer cela (encore faut-il conserver plusieurs langues dans les tuiles de données). Après sur OSM on peut changer le fond en fonction de son centre d'intérêt (transports, cycle...) : je trouve dommage de devoir regarder OSM-FR (via une umap !) pour gagner en lisibilité par rapport au fond de carte OSM (non à cause des noms en étranger mais des règles de positionnement - ou non-positionnement des noms : la capitale des États-Unis n'était pas souvent visible sur la carte OSM : la position des textes peut dépendre du rendu). Le rendu FR est disponible autrement que via umap: http://tile.openstreetmap.fr/ 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. 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 ! Attention, loc_name=* correspond à une appelation locale, non officielle. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Intégration des données de PSS dans OSM
Le 25/07/2015 20:08, Mathias Jérôme a écrit : Les informations que contient cette source en terme de géocodage d'adresse sont une véritable mine. Un nombre appréciable (le champ n'étant pas exhaustif) de cités ou d'ensemble de bâtiments peuvent y trouver une description précise nulle part ailleurs existant ! Et ceci sans compter les plans de masse parfois disponible en doc. Sauf qu'on ne sait pas non plus comment cette information géographique a été obtenue... il y a a de fortes chances que ce soit via Google vu l'usage qui en est fait sur le site PSS... et donc inutilisable hors des API Google (si on respecte leurs conditions d'utilisation après les avoir lues). -- Christian Quest - OpenStreetMap France ___ 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
J'aime assez la proposition de Vincent (celui à qui un reflet d'un petit guide vert permet de faire un clin d’œil - vdct pour ceux qui n'auraient pas compris) : c'est de la Cartographie Assistée par Ordinateur. Il n'est pas le seul à se méfier des imports tueurs, le plus célèbre restant la base de donnée routière américaine Tiger. Excellent pour avoir 80 %... et geler les 20 % restants. Combien de routes en pleine campagne voir en forêt aux États-Unis sont encore taguées route résidentielle ? Un rapprochement comme ceux que proposent Osmose ou les outils typiquement proposés par Christian permet de faciliter la tâche sans la déshumaniser. Si après import, la référence devient OSM (mais je doute), on est sûr que ce ne sera pas une terre gelée. J'étais moins radical en proposant des fixme, j'avoue que maintenant je ne sais pas trop que penser (il faut aussi connaître le potentiel OSM du côté de Nice). Si tu ne sais pas, ne vaut-il pas mieux mettre pour les nouvelles entrées : natural http://wiki.openstreetmap.org/wiki/FR:Key:natural wood http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwood Nœud http://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments#N.C5.93ud_.28node.29 Zone http://wiki.openstreetmap.org/wiki/FR:%C3%89l%C3%A9ments#Area_.28closed_way.29 Bois. 360 en France J'avoue ne pas très bien comprendre, apparemment ce natural=wook est vraiment fait pour les forêts ou bois, mais dans le cadre d'import d'arbres municipaux ça n'a pas trop de sens.. C'est normal, j'ai oublié un mot : nœud : il y a 360 nœuds natural=wood en France, pour les zones ce sont des bois mais je n'y faisait pas référence. Je n'imagine pas qu'il s'agisse de parcs (un parc réduit à un nœud...) mais d'arbustes. du coup j'essayerai de faire des mises à jour manuelles sur les arbres de la Prom' pour réduire la taille des petits arbres. Si un de ces quatre vous entendez parler d'un maniaque du sécateur sur la Promenade qui s'attaque aux petits arbres :-D. J'ai pas trop compris.. il ne faudrait pas importer des arbres dans OSM si ceux ci sont petits ? je disais que s'ils sont petits on doit se poser la question : natural=wood ou natural=tree ? Non le tag est_height n'existe pas encore. Mais si on estime la taille il vaut mieux le dire proprement et voir avec F4map pour qu'il soit utilisé (et proposer le tag ça va de soit). Entrer massivement des données fausses ça s'appelle du vandalisme. Donc un height=une valeur arbitraire, tu oublies. Une carto-partie où tu te sers des données (en les imprimant) et en demandant aux mappeurs d'indiquer : - existe (ou pas) - position correcte (ou pas) - hauteur approximative (un étage = 3 m, on n'a pas besoin de la cinquième décimale) - taxon ou type de feuilles ? Ça devrait permettre d'améliorer les données open source puis de les importer. Comme ça le boulot de Vincent (toi) est utilisé et on suit Vincent (le guide de la Voie Verte ;-)). Maintenant, je dis ça, mais je suis loin (y'a qu'à, faut qu'on). Jean-Yvon ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] name:* C°
Lors du dernier hackhathon wikimedia on a commencé à travailler avec Yurik (un dev de wikimédia; https://github.com/nyurik), et Kolossos (osm allemagne; http://wiki.openstreetmap.org/wiki/User:Kolossos) sur un rendu vectoriel international interactif, mais il reste encore du travail du côté des outils ... l'objectif étant d'obtenir un rendu vierge (facile) et d'y ajouter les langues qu'on veut via des menus déroulants Sylvain Le 25 juillet 2015 23:11, Christian Quest cqu...@openstreetmap.fr a écrit : Le 25/07/2015 12:30, osm.sanspourr...@spamgourmet.com a écrit : *Nom :* Vincent, oui, une autre solution c'est un fond de carte sans nom et des noms géolocalisés (ou une tuile vectorielle rendue en local). Et là on a après I18N, L10N : outre la gestion internationale (langues) il y a la régionalisation (le logo d'un hôpital sur le rendu OSM-FR ressemble au panneau français désignant un hôpital). D'où une question : est-ce que le site openstreetmap.org ne devrait pas proposer par défaut le rendu du pays ? C'est à dire OSM-FR depuis la France ou si langue fr-FR. Techniquement c'est possible, mais il faut que les générateurs de tuiles locaux puissent encaisser le traffic. Quelques pays ont développé un rendu local, mais c'est encore bien rare. Le passage en vectoriel devrait permettre de plus facilement gérer cela (encore faut-il conserver plusieurs langues dans les tuiles de données). Après sur OSM on peut changer le fond en fonction de son centre d'intérêt (transports, cycle...) : je trouve dommage de devoir regarder OSM-FR (via une umap !) pour gagner en lisibilité par rapport au fond de carte OSM (non à cause des noms en étranger mais des règles de positionnement - ou non-positionnement des noms : la capitale des États-Unis n'était pas souvent visible sur la carte OSM : la position des textes peut dépendre du rendu). Le rendu FR est disponible autrement que via umap: http://tile.openstreetmap.fr/ 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. 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 ! Attention, loc_name=* correspond à une appelation locale, non officielle. -- Christian Quest - OpenStreetMap France ___ 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
Le 25/07/2015 23:45, osm.sanspourr...@spamgourmet.com a écrit : J'aime assez la proposition de Vincent (celui à qui un reflet d'un petit guide vert permet de faire un clin d’œil - vdct pour ceux qui n'auraient pas compris) ;) = bis ! Il n'est pas le seul à se méfier des imports tueurs, le plus célèbre restant la base de donnée routière américaine Tiger. Excellent pour avoir 80 %... et geler les 20 % restants. Combien de routes en pleine campagne voir en forêt aux États-Unis sont encore taguées route résidentielle ? Et même sans se perdre en forêt, j'ai pu faire le constat en plein New York lors du dernier SOTM US. On pourrait s'attendre là bas à un contenu ultra riche et à jour, et pas du tout. En rentrant, j'ai contribué sur un contenu aussi banal que les stations de velo en libre service : en en ajoutant 8, je me suis retrouvé 1er contributeur sur cette thématique, avec 18% des nodes. Car on en recense que 45 sur NYC dans OSM, contre +400 sur le terrain. Y'a comme un souci. Les 20% gelés sont un peu là. Instructif mais pas forcément pour suivre la même trajectoire par chez nous. J'étais moins radical en proposant des fixme, j'avoue que maintenant je ne sais pas trop que penser (il faut aussi connaître le potentiel OSM du côté de Nice). Devoir ajouter systématiquement un tag fixme est pour moi révélateur de la non adequation d'un contenu avec OSM. Car en pratique, le fixme va rester. Une carto-partie où tu te sers des données (en les imprimant) et en demandant aux mappeurs d'indiquer : - existe (ou pas) - position correcte (ou pas) - hauteur approximative (un étage = 3 m, on n'a pas besoin de la cinquième décimale) - taxon ou type de feuilles ? Ça devrait permettre d'améliorer les données open source puis de les importer. D'accord avec l'idée, y compris la chronologie. L'import serait alors la restitution du relevé terrain. 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
Bonjour, pour enfoncer encore un peu plus le clou que Vincent a enfonce. Je ne suis pas convaincue sur l'aspect de la precision des donnees present dans les jeux de donnees de type en general. Il me semble d'ailleurs que la plupart du temps ils sont plus fournis a titre indicatif et complemente par des puces implantes dans l'arbre. Grosso modo, ce n'est la que pour donner une indication generale. Pour avoir aider a l'import Corine et avoir vu un import similaire peu de temps a Girona avant le SOTM 10, on s'est retrouve avec une qualite un peu bizarre. Certains d'entre nous avions tente d'etablir la qualite de l'import (globalement bon) mais quand on comparait avec des donnees GPS (en incluant differentes puces), on se rendait compte que la precision etait mediocre (precision de 5 a 10m). N'oublions pas que la quasi totalite des puces GPS dont Smartphone ont au mieux une precision de 5 metres et qu'OpenStreetMap a une precision de 6 decimales (en gros 15cm si je me rappelle bien), on se retrouve avec quelque chose de douteux. Bref, lorsqu'on descendra au centrimetrique en GPS, j'aurais plus confiance. Anecdocte amusante, les feuilles des arbres absorbent la frequence utilisee par les GPS rendant la qualite du GPS bien pire. Je suis plus moderee sur l'aspect negatif d'un import sur la communaute surtout dans le cas d'un import de ce type. Toutefois, je suis convaincue tout comme Vincent de l'importance d'une communaute locale afin d'assurer une maintenance continue de la carte. Dans un de tes precedents emails, tu parlais de l'application potentielle de ce genre de donnees. C'est bien joli mais la premiere chose que je ferrai si j'avais a traiter ce genre de chose c'est surement de separer ces donnees dans une couche a part (voir aussi les arguments de Vincent). Bref, oui pour l'import, mais tes marges me font peur. De plus s'il y a overlap, soit on ne touche pas, soit on deplace le point existant. 2015-07-25 15:08 GMT-07:00 Vincent de Château-Thierry v...@laposte.net: Le 25/07/2015 23:42, Jérôme Seigneuret a écrit : Les deux ne sont pas incompatible. L'import ne donne que la position. Si au moins il la donnait... La précision géographique n'est clairement pas ce qu'il y a de meilleur quand on commence à challenger les jeux de données OpenData. Par principe il est impossible de généraliser sur la qualité, tant il y a de producteurs et de méthodes différents, mais s'il y a bien un point sur lequel il faut douter sur _tous_ les jeux de données, c'est le positionnement, la qualité de la géométrie. Rien n’empêche de faire une campagne de terrain pour définir qu'elle est le type d'arbre et les infos qui suivent. Je suis bien d'accord que faire du terrain en groupe c'est cool. Maintenant, il y a un intérêt certains d'avoir les arbres sur le plan et de pourvoir vérifier avec une version imprimé directement. L'intérêt d'avoir les arbres in fine, je ne le discute pas, c'est un niveau de détail vers lequel on va (tout comme distinguer les trottoirs du filaire de voie, etc.) même si la densité de points en certains endroits (c'est le cas dans Nice) va en intimider plus d'un au moment d'éditer la carte. Après il est sûr que suite à l'intégration laisser un message sur la liste PACA ou celle du 06 serait une bonne chose. Bingo : il n'y a ni liste PACA ni liste 06... Construire une dynamique locale passe je pense plus par la constitution de ce genre d'espace d'échange que par un import. Il y a aussi les Lycée d'aménagements Paysagers qui pourraient être sollicité ou intéressé ainsi que les filières SIG du coin... Par exemple oui. Peut-être qu'un serveur avec une carte bac à sable avec une possibilité d'imprimer offrirait le meilleur compromis pour éviter des coups d'intégration massif (de bonne volonté). Je lis coût ;) Imprimer le jeu de données dans son contexte, avec un fond carto dessous, ne nécessite absolument pas d'avoir procédé à un import. Avec un outil comme QGis (voire JOSM, mais je ne sais pas ce qu'il vaut pour imprimer) c'est très simple de combiner un jeu de données comme les arbres de Nice, et un fond OSM ou autre. Et c'est un bon document de travail pour aller sur place. vincent ___ 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] Frontière franco-italienne du Mont-Blanc
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: 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 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 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] Intégration des données de PSS dans OSM
Les informations que contient cette source en terme de géocodage d'adresse sont une véritable mine. Un nombre appréciable (le champ n'étant pas exhaustif) de cités ou d'ensemble de bâtiments peuvent y trouver une description précise nulle part ailleurs existant ! Et ceci sans compter les plans de masse parfois disponible en doc. Le Lundi 27 avril 2015 13h18, Vincent Frison vincent.fri...@gmail.com a écrit : Bonjour, J'en avais déjà parlé il y a quelques temps sur cette liste mais depuis ça a un peu avancé. Pour rappel le site PSS (http://www.pss-archi.eu) fournit une base de données avec plus de 47 000 immeubles répartis sur toute la France. Mon idée était de récupérer au minimum les infos de hauteur des immeubles (nombre d'étages ou hauteur réelle) afin de mettre à jour les bâtiments existants dans OSM, comme j'ai déjà pu le faire très récemment avec la base open data de Paris (49 000 immeubles mis à jour, soit plus de la moitié des immeubles parisiens). De ce que j'ai compris ce qui les gêne dans la licence OSM c'est que les données peuvent être réutilisées dans des projets commerciaux. Apparemment il vont bientôt rendre disponible leurs données sous la licence BY-NC-ND (https://creativecommons.org/licenses/by-nc-nd/2.0/fr/). Comme je ne suis pas du tout un expert sur ces questions juridiques je vous requiert de l'aide pour savoir que ce qu'on pourrait tirer de cette belle source de données. Mais peut-être rien du tout à cause des restrictions de cette licence... Merci d'avance pour votre aide, Vincent. ___ 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
Arfff, Je viens de voir qu'il n'y a pas d'information sur la taxonomie dans le fichier. Dommage. ___ 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
Juste une précision. Comment gères-tu les conflits quand les tags sont remplis ou quand tu détectes un arbre dans le rayon en question? Normalement on ne peut pas considérer une source de données plus fiable qu'une autre car les erreurs humaines existent. Pour la partie attributaire je viens de voir ce qui est fait coté Bordeaux et l'utilisation du tag *taxon *n'est pas bonne. Le 25 juillet 2015 19:27, Vincent Frison vincent.fri...@gmail.com a écrit : Le 25 juillet 2015 18:53, Vincent Pottier vpott...@gmail.com a écrit : Si le programme, qui détecte la présence d'un arbre à 2 m, pouvait modifier le point existant plutôt que de le remplacer, ce serait top. Merci pour ceux qui ont œuvré à OSM. Mais c'est le cas ! J'ai justement changé le programme pour qu'il mette à jour les arbres existants à moins de X mètres au lieu de les supprimer.. ___ 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, 2015-07-25 17:02 GMT-07:00 Jérôme Seigneuret jseigneuret-...@yahoo.fr: Le 26 juillet 2015 00:43, Emilie Laffray emilie.laff...@gmail.com a écrit : Bonjour, pour enfoncer encore un peu plus le clou que Vincent a enfonce. Je ne suis pas convaincue sur l'aspect de la precision des donnees present dans les jeux de donnees de type en general. Il me semble d'ailleurs que la plupart du temps ils sont plus fournis a titre indicatif et complemente par des puces implantes dans l'arbre. Grosso modo, ce n'est la que pour donner une indication generale. J'ai pas compris où tu veux en venir. En quoi le fait d'avoir une puce pose un problème d'intégration et cela entraînerait un jeu de données de mauvaise qualité ? Un jeu de données ça ce test avec un échantillon aléatoire. Question qualité, il n'existe pas de jeu de données avec une fiabilité à 100% à cause de plein de raison. J'ai jamais testé un jeu de données à 100% question coût ;-) Le point que je faisais passer etait que comme la précision des données concernant les arbres étaient tellement faible, on marque l'arbre avec une puce individuelle, ce qui permet de travailler avec l'arbre que l'on veut sans avoir une localisation precise. Pour avoir aider a l'import Corine et avoir vu un import similaire peu de temps a Girona avant le SOTM 10, on s'est retrouve avec une qualite un peu bizarre. Certains d'entre nous avions tente d'etablir la qualite de l'import (globalement bon) mais quand on comparait avec des donnees GPS (en incluant differentes puces), on se rendait compte que la precision etait mediocre (precision de 5 a 10m). N'oublions pas que la quasi totalite des puces GPS dont Smartphone ont au mieux une precision de 5 metres et qu'OpenStreetMap a une precision de 6 decimales (en gros 15cm si je me rappelle bien), on se retrouve avec quelque chose de douteux. Bref, lorsqu'on descendra au centrimetrique en GPS, j'aurais plus confiance. Anecdocte amusante, les feuilles des arbres absorbent la frequence utilisee par les GPS rendant la qualite du GPS bien pire. Comparer la CLC à des arbres positionnés le plus souvent sur des ortho du département ou de la ville dont la qualité est quand même pas celle de la CLC... le pixel d'une ortho a une résolution de 20cm maintenant 50cm pour la BD Ortho. Reste le calage... Sans compté qu'il est clair que connaitre le mode de saisie est important. Si c'est la ville je ne pense pas qu'il face ça avec un smartphone mais avec du Trimble et que c'est corrigé en bureau. Tu auras plus de décalage avec le changement de projection qu'avec la levé de terrain... Sinon les données correspondent (en tout cas pour celles des collectivités) à des données de CAO et à des plans de plantations. Moui, enfin, j'ai juste mentionné CLC afin de faire référence au fait que l'import je connais un peu, et le point principal était surtout sur l'import des arbres de la ville de Gerone en Espagne. De plus, si tu veux rentrer dans les détails des puces GPS soit mais je n'ai jamais parle de puce GPS pour Smartphone. Grosso modo, oui, il faut utiliser du GPS différentiel ou du RTK si tu veux de la précision centimétrique, mais je ne suis pas convaincue que la plupart des municipalités s'amusent avec ce genre de matériel en premier lieu. Au final, dans beaucoup de cas, je ne suis pas convaincue que les plans de plantations crées généralement a postériori ou des données de CAO soit vraiment si bon que ça. Bref, on en revient a la source des données au final. Dans un de tes precedents emails, tu parlais de l'application potentielle de ce genre de donnees. C'est bien joli mais la premiere chose que je ferrai si j'avais a traiter ce genre de chose c'est surement de separer ces donnees dans une couche a part (voir aussi les arguments de Vincent). Oui surement comme le bati, le réseau routier ou l'occupation du sol... reste qu'OSM et une base de données et pas un jeu de shapefile OSM est en effet une base de données. Je ne suis pas contre un import de ce type, je suis généralement contre un import dont la qualité peut être douteuse. Enfin dans le cas présent, la précision a quelques mètres d'un arbre n'est pas bien grave dans la plupart des cas (voir carte non voyant) par exemple. Historiquement, je fais partie des membres du bureau de la fondation qui se sont opposes a la création d'un map.openstreetmap.com parce que pour moi OSM est une base de donnée. Je suis parfaitement consciente qu'OSM n'est pas un jeu de shapefile mais si tu regardes bien l'usage qui en fait dans de nombreux milieux, tu vois une décomposition en couche ce qui est relativement naturel dans la manière de travailler des gens. La question se pose alors sur la pertinence d'avoir ce jeu de données dans OSM au lieu d'un shapefile différent, en tenant compte de la qualité des données en premier lieu et de ces implications. Un des gros problèmes actuellement est a mes yeux les éditeurs OSM qui gère mal la densité des
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Le 26 juillet 2015 00:43, Emilie Laffray emilie.laff...@gmail.com a écrit : Bonjour, pour enfoncer encore un peu plus le clou que Vincent a enfonce. Je ne suis pas convaincue sur l'aspect de la precision des donnees present dans les jeux de donnees de type en general. Il me semble d'ailleurs que la plupart du temps ils sont plus fournis a titre indicatif et complemente par des puces implantes dans l'arbre. Grosso modo, ce n'est la que pour donner une indication generale. J'ai pas compris où tu veux en venir. En quoi le fait d'avoir une puce pose un problème d'intégration et cela entraînerait un jeu de données de mauvaise qualité ? Un jeu de données ça ce test avec un échantillon aléatoire. Question qualité, il n'existe pas de jeu de données avec une fiabilité à 100% à cause de plein de raison. J'ai jamais testé un jeu de données à 100% question coût ;-) Pour avoir aider a l'import Corine et avoir vu un import similaire peu de temps a Girona avant le SOTM 10, on s'est retrouve avec une qualite un peu bizarre. Certains d'entre nous avions tente d'etablir la qualite de l'import (globalement bon) mais quand on comparait avec des donnees GPS (en incluant differentes puces), on se rendait compte que la precision etait mediocre (precision de 5 a 10m). N'oublions pas que la quasi totalite des puces GPS dont Smartphone ont au mieux une precision de 5 metres et qu'OpenStreetMap a une precision de 6 decimales (en gros 15cm si je me rappelle bien), on se retrouve avec quelque chose de douteux. Bref, lorsqu'on descendra au centrimetrique en GPS, j'aurais plus confiance. Anecdocte amusante, les feuilles des arbres absorbent la frequence utilisee par les GPS rendant la qualite du GPS bien pire. Comparer la CLC à des arbres positionnés le plus souvent sur des ortho du département ou de la ville dont la qualité est quand même pas celle de la CLC... le pixel d'une ortho a une résolution de 20cm maintenant 50cm pour la BD Ortho. Reste le calage... Sans compté qu'il est clair que connaitre le mode de saisie est important. Si c'est la ville je ne pense pas qu'il face ça avec un smartphone mais avec du Trimble et que c'est corrigé en bureau. Tu auras plus de décalage avec le changement de projection qu'avec la levé de terrain... Sinon les données correspondent (en tout cas pour celles des collectivités) à des données de CAO et à des plans de plantations. Je suis plus moderee sur l'aspect negatif d'un import sur la communaute surtout dans le cas d'un import de ce type. Toutefois, je suis convaincue tout comme Vincent de l'importance d'une communaute locale afin d'assurer une maintenance continue de la carte. Je suis aussi de cet avis. En même temps, il y a des gens qui font ça en vacance (cas vu chez nous d'un jeune qui préfère ça à sa playstation) Dans un de tes precedents emails, tu parlais de l'application potentielle de ce genre de donnees. C'est bien joli mais la premiere chose que je ferrai si j'avais a traiter ce genre de chose c'est surement de separer ces donnees dans une couche a part (voir aussi les arguments de Vincent). Oui surement comme le bati, le réseau routier ou l'occupation du sol... reste qu'OSM et une base de données et pas un jeu de shapefile Bref, oui pour l'import, mais tes marges me font peur. De plus s'il y a overlap, soit on ne touche pas, soit on deplace le point existant. En effet. C'est pour cela que je lui ai posé la question de savoir ce qu'il ferait en cas de conflit. Là c'est le terrain qui doit permettre de faire un choix en cas de conflit ou un fond de plan bien calé pour le positionnement ou des données GPS de qualité pro. C'est le même principe pour le reste des éléments comme le nom des voies en cas de conflits entre différentes sources ___ 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
Je rejoins Thierry et Art Penteur (j'avais commencé à écrire ce message avant de lire leurs messages). *Lieu et revendication :* J'allais dire qu'on balançait des centaines de ballons sonde sans revendiquer les lieux où ils retombaient. Surtout qu'il s'agit selon l'article Il progetto nasce dalla collaborazione tra Associazione Ev-K2-Cnr e Arpa Valle d’Aosta. (traduction Bing + Bibi : Le projet est une collaboration entre l'Association Ev-K2-Cnr et l'Agence Régionale pour la Protection de la Vallée d'Aoste.) Utilisateur expérimenté ne veut pas dire non provocateur ou ne pouvant faire d'erreur. A priori ni l'un ni l'autre. Sur la localisation : https://www.openstreetmap.org/node/3664571073#map=18/45.82910/6.86731 correspond assez bien à la description du Dauphiné-Libéré et donc à la zone contestée : http://www.ledauphine.com/haute-savoie/2014/10/24/une-petite-station-meteo-bientot-implantee-au-col-major La plus haute station météorologique d’Europe naîtra à 4 750 mètres, au col Major, situé entre le mont Blanc de Courmayeur et le mont Blanc. « L’éperon est le lieu le plus sûr et apte, affirme l’un des techniciens. Pas exactement une troupe napoléonienne : une association qui comporte K2 dans le nom et une agence environnementale régionale et un lieu choisi pour sa solidité (après il peut y avoir de mauvaises raisons non données mais a priori on peut leur faire confiance). Selon taginfo, operator=EvK2Cnr n'a qu'une occurrence. *Nom :* Vincent, oui, une autre solution c'est un fond de carte sans nom et des noms géolocalisés (ou une tuile vectorielle rendue en local). Et là on a après I18N, L10N : outre la gestion internationale (langues) il y a la régionalisation (le logo d'un hôpital sur le rendu OSM-FR ressemble au panneau français désignant un hôpital). D'où une question : est-ce que le site openstreetmap.org ne devrait pas proposer par défaut le rendu du pays ? C'est à dire OSM-FR depuis la France ou si langue fr-FR. Après sur OSM on peut changer le fond en fonction de son centre d'intérêt (transports, cycle...) : je trouve dommage de devoir regarder OSM-FR (via une umap !) pour gagner en lisibilité par rapport au fond de carte OSM (non à cause des noms en étranger mais des règles de positionnement - ou non-positionnement des noms : la capitale des États-Unis n'était pas souvent visible sur la carte OSM : la position des textes peut dépendre du rendu). 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. Jean-Yvon Le 25/07/2015 10:40, Art Penteur - art.pent...@gmail.com a écrit : Il y a plus d'une station météo, de nationalités différentes en Antarctique, et on ne remet pas en cause le traité pour ça... Art. Le 25 juil. 2015 10:32 AM, Mathias jerome.math...@yahoo.fr a écrit : ___ 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
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 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 https://lists.openstreetmap.org/listinfo/talk-fr
