Re: [OSM-talk-fr] Prémisses d'un groupe de travail sur les nouveaux inscrits
Le 14/10/2012 23:54, Nicolas Dumoulin a écrit : Il y a cette page (en anglais) qui en rapporte pas mal (même si ça ne concerne pas uniquement les débutants) : https://help.openstreetmap.org/questions/1022/what-are-the-most-common- mapping-mistakes-that-other-users-make Merci ! En fait, peu de questions se rapportent directement au bâti. Mais cette page reste très utile. -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Prémisses d'un groupe de travail sur les nouveaux inscrits
Bonjour, 15/10/2012 08:03 Jean-Francois Nifenecker: Merci ! En fait, peu de questions se rapportent directement au bâti. Mais cette page reste très utile. J'ai eu récemment un cas d'un nouveau contributeur qui a dessiné des bâtiments à partir de Bing qui auraient pu être importés, et un autre cas où quelqu'un a supprimé des bâtiments importés pour les redessiner à partir des images satellite. Il a sûrement pas compris que ce qu'on voit du bâtiment sur les images ne correspond pas à l'emprise au sol. Il est donc important de parler du cadastre, sans les inviter à se lancer à l'import eux-mêmes. Les connexions manquantes font effectivement une grande partie des erreurs, suivie des fausses manipulations Potlatch, tel que les points sans attributs qu'on crée quand on veut déplacer la carter et n'appuie pas bien sur le bouton de la souris. Puis les faux attributs qui sont souvent dus à l'absence de traduction française dans Potlatch. Une page avec quelques mots sur les principes de la communauté, sur les éditeurs Potlatch et Josm, sur les erreurs ci-dessus et quelques liens vers openstreetmap.fr, des pages wiki tel que http://wiki.openstreetmap.org/wiki/FR:Map_Features et http://wiki.openstreetmap.org/wiki/FR:France_roads_tagging, le forum et talk-fr, pas plus qu'une ou deux pages sur un ecran standard, sinon personne ne la lira, cela serait parfait pour moi. Ça éviterait de répéter chaque fois les mêmes chose dans le message de bienvenue. Rainer ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger du nucléaire [long]
Le 13 octobre 2012 20:44, Pierre-Alain Dorange pdora...@mac.com a écrit : PS : Sur un sujet proche je fais aussi des recherches pour cartographier les sites types seveso en France (classement Seveso 1 et 2, c'est à dire dnagereux et surveillé par l'administration), à priori j'ai rien trouvé d'existant sur ce sujet. Je réponds sur le PS. Est-ce que le site de l'IREP http://www.irep.ecologie.gouv.fr/IREP/index.php peut être utile? Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Boites aux lettres concentrées au même endroit
Le 14 octobre 2012 14:09, Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net a écrit : Oui, c'est maintenant de plus en plus fréquent en zone d'habitat diffus. La Poste donne des adresses Cidex : http://fr.wikipedia.org/wiki/** Adresse_postale#CIDEX http://fr.wikipedia.org/wiki/Adresse_postale#CIDEX Oui c'est bien ça mais le tag amenity=post_box complété avec type=cmb est absent de taginfo en France. Alors vous êtes d'avis de mettre ou de ne pas mettre? Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pnorman = Spam
Sauf que j'ai cru comprendre que le DWG n'était pas dans une logique de concessions. Pourtant, il me semble que pour trouver des compromis, les deux parties doivent faire des efforts. Mais bon, apparemment, j'ai du oublier mon Tranxen et je semble nuire au bon déroulement de la chose. N'hésitez pas à venir mapper la Franche-Comté car je n'y ajouterai plus une node. -- View this message in context: http://gis.19327.n5.nabble.com/Pnorman-Spam-tp5730049p5730627.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Prémisses d'un groupe de travail sur les nouveaux inscrits
Bonjour, Je suis bien d'accord avec tout ça. Concernant Potlatch, je dois être mal-comprenant, mais je n'ai pas encore trouvé la méthode adaptée pour aller traduire proprement l'interface en Français. C'est vraiment quelque chose à affûter. Le manuel de découverte d'OSM (http://fr.flossmanuals.net/openstreetmap/) est là, mais dans une révision #1 qui a des lacunes connues (en particulier pour le contexte français), qui sont développées dans ce pad : http://piratepad.net/OSM-frEvolutions On y retrouve la référence de pages du wiki existantesqui sont destinées aux nouveaux arrivants de France, comme celle-ci : http://wiki.openstreetmap.org/wiki/FR:Guide_des_bonnes_pratiques_pour_cartographier_une_commune http://wiki.openstreetmap.org/wiki/FR:Howto_Map_A La page du wiki dédiée au plugin cadastre-fr est touffue, et je pense qu'elle intimide au premier abord. On n'y retrouve pas directement l'essentiel : comment afficher le cadastre en fond de plan (chargement du plugin, calage de la projection, recherche de la commune, cas particulier des communes images) Elle gagnerait à être scindée en plusieurs parties, et peut être remise à jour. (et sinon, oui, je sais, c'est un wiki, vous fatiguez pas !) Le 15 octobre 2012 08:41, Rainer Kluge rklug...@web.de a écrit : Bonjour, 15/10/2012 08:03 Jean-Francois Nifenecker: Merci ! En fait, peu de questions se rapportent directement au bâti. Mais cette page reste très utile. J'ai eu récemment un cas d'un nouveau contributeur qui a dessiné des bâtiments à partir de Bing qui auraient pu être importés, et un autre cas où quelqu'un a supprimé des bâtiments importés pour les redessiner à partir des images satellite. Il a sûrement pas compris que ce qu'on voit du bâtiment sur les images ne correspond pas à l'emprise au sol. Il est donc important de parler du cadastre, sans les inviter à se lancer à l'import eux-mêmes. Les connexions manquantes font effectivement une grande partie des erreurs, suivie des fausses manipulations Potlatch, tel que les points sans attributs qu'on crée quand on veut déplacer la carter et n'appuie pas bien sur le bouton de la souris. Puis les faux attributs qui sont souvent dus à l'absence de traduction française dans Potlatch. Une page avec quelques mots sur les principes de la communauté, sur les éditeurs Potlatch et Josm, sur les erreurs ci-dessus et quelques liens vers openstreetmap.fr, des pages wiki tel que http://wiki.openstreetmap.org/** wiki/FR:Map_Features http://wiki.openstreetmap.org/wiki/FR:Map_Featureset http://wiki.openstreetmap.org/**wiki/FR:France_roads_tagginghttp://wiki.openstreetmap.org/wiki/FR:France_roads_tagging, le forum et talk-fr, pas plus qu'une ou deux pages sur un ecran standard, sinon personne ne la lira, cela serait parfait pour moi. Ça éviterait de répéter chaque fois les mêmes chose dans le message de bienvenue. Rainer __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Bâti et éoliennes
Bonjour, et concernant les éoliennes et le bâti du cadastre ; quelqu'un sait quoi faire ?? garder le bâti sans tag spécifique? supprimer le bâti? mettre les infos de l'éolienne sur le bâti? et créer une nouvelle catégorie de bâti? voir un exemple : http://www.openstreetmap.org/browse/way/172254820 http://www.openstreetmap.org/browse/node/1759545595 Simon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] 850000 membres... et autres stats...
En préparation de notre réunion avec l'IGN, j'ai refait quelques statistiques... Il y a un an, on avait environ 48 membres, cela fait une croissance de 77%. Ce sont les compte ouverts, mais pas forcément actifs. Le rythme s'est clairement accéléré début juillet. Le nombre de contributeurs actifs a lui aussi augmenté pour passer d'environ 2000/jour à actuellement 3000/jour et la barre des 2/mois est désormais systématiquement franchie depuis début octobre. Pour la France, on est toujours entre 200 et 250 contributeurs actifs quotidiennement, ce qui nous place en second derrière l'Allemagne et devant la Russie. Côté données, un petit point sur les statistiques du réseau routier: - 1,3 million de km de routes et chemins, soit 340.000 de plus qu'il y a un an, une progression globale de 35% (malgré le passage à l'ODbL) - les réseaux autoroutiers, primaires et secondaires plafonnent avec une progression respective de 2%, 4% et 5% - le réseau tertiaire continue à avancer (+23%), ainsi que les unclassified (+50%) et +29% de residential - les routes de type inconnu (road) sont en baisse de 26% - les voies non carrossables progressent aussi: +53% de path, +76% de track, +20% de cycleway, +39% de footway, +26% de pedestrian Sur l'année qui vient de s'écouler, c'est en moyenne 1000km de routes et chemins qui ont été ajoutés chaque jour. Le prochain qui me dit que l'import du bâti est nuisible je lui enverrai ces stats en réponse ;) -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâti et éoliennes
Bonjour, Les pages du wiki http://wiki.openstreetmap.org/wiki/FR:Tag:generator:source%3Dwind en anglais et français indiquent que les éoliennes peut êtres définies par des nœuds des polygones mais la page en allemand n'indique que les les nœuds. Donc à toi de choisir... Aussi tu me compléter cette page: http://wiki.openstreetmap.org/wiki/WikiProject_France/Parcs_%C3%A9oliens Romain Le 15 octobre 2012 10:30, Simon Miniou simon.min...@gmail.com a écrit : Bonjour, et concernant les éoliennes et le bâti du cadastre ; quelqu'un sait quoi faire ?? garder le bâti sans tag spécifique? supprimer le bâti? mettre les infos de l'éolienne sur le bâti? et créer une nouvelle catégorie de bâti? voir un exemple : http://www.openstreetmap.org/browse/way/172254820 http://www.openstreetmap.org/browse/node/1759545595 Simon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Boites aux lettres concentrées au même endroit
Je pense qu'on va confondre entre une boite aux lettre pour envoyer du courrier et une boite aux lettre pour en recevoir... Certains CIDEX possèdent aussi une boite au lettres jaune (pour envoyer), mais ce n'est pas systématique. Un tag différent me semblerait plus adapté. Le 15 octobre 2012 09:35, Romain MEHUT romain.me...@gmail.com a écrit : Le 14 octobre 2012 14:09, Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net a écrit : Oui, c'est maintenant de plus en plus fréquent en zone d'habitat diffus. La Poste donne des adresses Cidex : http://fr.wikipedia.org/wiki/Adresse_postale#CIDEX Oui c'est bien ça mais le tag amenity=post_box complété avec type=cmb est absent de taginfo en France. Alors vous êtes d'avis de mettre ou de ne pas mettre? Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâti et éoliennes
Mettre les infos de l'éolienne sur le bâti... c'est le plus logique, non ? Le 15 octobre 2012 10:30, Simon Miniou simon.min...@gmail.com a écrit : Bonjour, et concernant les éoliennes et le bâti du cadastre ; quelqu'un sait quoi faire ?? garder le bâti sans tag spécifique? supprimer le bâti? mettre les infos de l'éolienne sur le bâti? et créer une nouvelle catégorie de bâti? voir un exemple : http://www.openstreetmap.org/browse/way/172254820 http://www.openstreetmap.org/browse/node/1759545595 Simon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Boites aux lettres concentrées au même endroit
Le 15 octobre 2012 10:39, Christian Quest cqu...@openstreetmap.fr a écrit : Je pense qu'on va confondre entre une boite aux lettre pour envoyer du courrier et une boite aux lettre pour en recevoir... Oui c'est ce que je craignais. Certains CIDEX possèdent aussi une boite au lettres jaune (pour envoyer), mais ce n'est pas systématique. Dans mon cas, c'était comme ça là plupart du temps Un tag différent me semblerait plus adapté. Je le pense aussi mais il reste à inventer. Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Boites aux lettres concentrées au même endroit
Le 15 octobre 2012 10:43, Romain MEHUT romain.me...@gmail.com a écrit : Le 15 octobre 2012 10:39, Christian Quest cqu...@openstreetmap.fr a écrit : Je pense qu'on va confondre entre une boite aux lettre pour envoyer du courrier et une boite aux lettre pour en recevoir... Oui c'est ce que je craignais. Certains CIDEX possèdent aussi une boite au lettres jaune (pour envoyer), mais ce n'est pas systématique. Dans mon cas, c'était comme ça là plupart du temps Mais c'est pas systématique. Dans le coin de Bourgogne que je fréquente régulièrement, les CIDEX n'ont pas tous une boite jaune... quand il y en a une, j'ai mis un post_box, mais quand il n'y en a pas je n'ai rien cartographié (pour l'instant). Ces CIDEX ont un numéro, numéro qu'on indique comme adresse postale. Depuis quelques années les maisons ont aussi une adresse avec n°+rue, mais c'est plus récent. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Boites aux lettres concentrées au même endroit
Le 15 octobre 2012 10:48, Christian Quest cqu...@openstreetmap.fr a écrit : Mais c'est pas systématique. Dans le coin de Bourgogne que je fréquente régulièrement, les CIDEX n'ont pas tous une boite jaune... quand il y en a une, j'ai mis un post_box, mais quand il n'y en a pas je n'ai rien cartographié (pour l'instant). Ces CIDEX ont un numéro, numéro qu'on indique comme adresse postale. Depuis quelques années les maisons ont aussi une adresse avec n°+rue, mais c'est plus récent. C'était aussi mon cas, des maisons avec un numéro mais pas de boites aux lettres individuelles. Je ne mettrai donc que les post_box pour envoyer du courrier. Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] HS _ panne chez free
Je figure dans les 0,15% de clients free qui voient leurs mails en mode essui-glace (un coup ça marche, un coup ça marche pas) depuis le 12/10. Pipermail et abonnement depuis un autre fournisseur, ok, mais ça ne suffit pas pour suivre les débats un peu hot du moment. Vous ne me voyez pas, n'en déduisez pas que je m'abstiens ;) enfin, si ce mail ne reste pas coincé dans le tuyau ... ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Changement de fournisseur était Re: HS _ panne chez free
Changement de fournisseur Le 15/10/2012 10:59, Hélène PETIT a écrit : Je figure dans les 0,15% de clients free qui voient leurs mails en mode essui-glace (un coup ça marche, un coup ça marche pas) depuis le 12/10. Pipermail et abonnement depuis un autre fournisseur, ok, mais ça ne suffit pas pour suivre les débats un peu hot du moment. Vous ne me voyez pas, n'en déduisez pas que je m'abstiens ;) enfin, si ce mail ne reste pas coincé dans le tuyau ... ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Bâti et éoliennes
je veux bien mettre les infos de l'éolienne sur le bâti mais du coup on considère que l'éolienne fait partie de la catégorie buildinghttp://wiki.openstreetmap.org/wiki/FR:Key:building?uselang=fr *(avec une valeur yes ou une nouvelle?)* ou que l'éolienne est dessiné par un chemin et n'est pas un bâti? Simon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 850000 membres... et autres stats...
Le lundi 15 octobre 2012 à 10:38 +0200, Christian Quest a écrit : En préparation de notre réunion avec l'IGN, j'ai refait quelques statistiques... Il y a un an, on avait environ 48 membres, cela fait une croissance de 77%. Ce sont les compte ouverts, mais pas forcément actifs. Le rythme s'est clairement accéléré début juillet. Le nombre de contributeurs actifs a lui aussi augmenté pour passer d'environ 2000/jour à actuellement 3000/jour et la barre des 2/mois est désormais systématiquement franchie depuis début octobre. Pour la France, on est toujours entre 200 et 250 contributeurs actifs quotidiennement, ce qui nous place en second derrière l'Allemagne et devant la Russie. Cette forte augmentation de contributeurs n'a bien sûr rien à voir avec la nécessité de posséder plusieurs comptes pour faire des imports de données Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 850000 membres... et autres stats...
Même si on suspecte un biais, les +1000 km / jour de route, par exemple, restent impressionnant, satisfaisant et motivant, je trouve. Cordialement, -- Mikaël Cordon (mickey86) Le 15 octobre 2012 11:09, Christophe Merlet red...@redfoxcenter.org a écrit : Le lundi 15 octobre 2012 à 10:38 +0200, Christian Quest a écrit : En préparation de notre réunion avec l'IGN, j'ai refait quelques statistiques... Il y a un an, on avait environ 48 membres, cela fait une croissance de 77%. Ce sont les compte ouverts, mais pas forcément actifs. Le rythme s'est clairement accéléré début juillet. Le nombre de contributeurs actifs a lui aussi augmenté pour passer d'environ 2000/jour à actuellement 3000/jour et la barre des 2/mois est désormais systématiquement franchie depuis début octobre. Pour la France, on est toujours entre 200 et 250 contributeurs actifs quotidiennement, ce qui nous place en second derrière l'Allemagne et devant la Russie. Cette forte augmentation de contributeurs n'a bien sûr rien à voir avec la nécessité de posséder plusieurs comptes pour faire des imports de données Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâti et éoliennes
On Mon, Oct 15, 2012 at 10:40 AM, Christian Quest cqu...@openstreetmap.fr wrote: Mettre les infos de l'éolienne sur le bâti... c'est le plus logique, non ? Le terme de bâti prête à confusion ici. C'est effectivement une construction mais je vois mal l'utilisation du tag building automatiquement ajouté dans les imports du cadastre s'appliquer à une éolienne qui n'est finalement qu'un gros tuyau vertical dans sa partie statique. A ce compte là, tous les pylônes électriques sont aussi des buildings. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâti et éoliennes
Garder ou pas le tag building... on le garde bien sur les châteaux d'eau, je le garderai aussi. Le 15 octobre 2012 11:08, Simon Miniou simon.min...@gmail.com a écrit : je veux bien mettre les infos de l'éolienne sur le bâti mais du coup on considère que l'éolienne fait partie de la catégorie building (avec une valeur yes ou une nouvelle?) ou que l'éolienne est dessiné par un chemin et n'est pas un bâti? Simon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâti et éoliennes
De base, je trouve qu'utiliser une way pour marquer une éolienne, c'est un poil too much (ou alors, utilisons aussi des ways pour marquer le contour du moindre conteneur de tri sélectif...), mais soit. Mais là... Il y a 458 nodes ! O_O Francescu Le 15 octobre 2012 10:30, Simon Miniou simon.min...@gmail.com a écrit : Bonjour, et concernant les éoliennes et le bâti du cadastre ; quelqu'un sait quoi faire ?? garder le bâti sans tag spécifique? supprimer le bâti? mettre les infos de l'éolienne sur le bâti? et créer une nouvelle catégorie de bâti? voir un exemple : http://www.openstreetmap.org/browse/way/172254820 http://www.openstreetmap.org/browse/node/1759545595 Simon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Création du Groupe d'accompagnement aka Cadastre task force
Sauf celui de la confidentialité en cas de dénonciation erronée ou calomnieuse ! Mon avis est que la non-publicité n'est pas un problème*. *Sauf celui de la démocratie. Créer un réseau fermé, c'est forcément exclure certaines personnes à plus ou moins court terme. Personnellement, je pense qu'une fois cette liste/cette zone de décision opaque sera créée, on en endentera plus parler et les nouveaux n'auront quasi aucune chance d'y rentrer. De plus, on entre dans la même dérive que celle du DWG à savoir : un petit nombre décide pour beaucoup. -- View this message in context: http://gis.19327.n5.nabble.com/Creation-du-Groupe-d-accompagnement-aka-Cadastre-task-force-tp5730121p5730663.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâti et éoliennes
Oui, il y a une analyse Osmose sur les bâtiments circulaires. On pourrait la compléter avec une analyse du nombre de points qui constituent le cercle, car c'est un défaut récurrent du cadastre (dont on a déjà parlé, concernant les éoliennes) Alors, un bon cercle, combien de points ? :-) Le way pour décrire l'éolienne, on le justifiera le jour où on indiquera où se trouve la porte d'entrée :-) Le 15 octobre 2012 11:30, Francescu GAROBY windu...@gmail.com a écrit : De base, je trouve qu'utiliser une way pour marquer une éolienne, c'est un poil too much (ou alors, utilisons aussi des ways pour marquer le contour du moindre conteneur de tri sélectif...), mais soit. Mais là... Il y a 458 nodes ! O_O Francescu Le 15 octobre 2012 10:30, Simon Miniou simon.min...@gmail.com a écrit : Bonjour, et concernant les éoliennes et le bâti du cadastre ; quelqu'un sait quoi faire ?? garder le bâti sans tag spécifique? supprimer le bâti? mettre les infos de l'éolienne sur le bâti? et créer une nouvelle catégorie de bâti? voir un exemple : http://www.openstreetmap.org/browse/way/172254820 http://www.openstreetmap.org/browse/node/1759545595 Simon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 850000 membres... et autres stats...
2012/10/15 Mikaël Cordon mikael.cor...@gmail.com: Même si on suspecte un biais, les +1000 km / jour de route, par exemple, restent impressionnant, satisfaisant et motivant, je trouve. Oui, je trouve que ça fait beaucoup. Comment est-ce calculé ? Est-ce que ça ne cumule pas créations et modifications ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 850000 membres... et autres stats...
Toi qui les aimes tant, tu pourrais compléter avec un inventaire (non exhaustif) à la Prévert des TOC qui peuvent être attrapés sur le projet. C'est un élément important concernant la fidélisation des participants. Une page wiki mi-humour (pour la description des symptômes) / mi-sérieuse (pour la manière de s'y prendre correctement) concernant la question des TOC pourrait être sympa à faire) Le 15 octobre 2012 10:38, Christian Quest cqu...@openstreetmap.fr a écrit : En préparation de notre réunion avec l'IGN, j'ai refait quelques statistiques... Il y a un an, on avait environ 48 membres, cela fait une croissance de 77%. Ce sont les compte ouverts, mais pas forcément actifs. Le rythme s'est clairement accéléré début juillet. Le nombre de contributeurs actifs a lui aussi augmenté pour passer d'environ 2000/jour à actuellement 3000/jour et la barre des 2/mois est désormais systématiquement franchie depuis début octobre. Pour la France, on est toujours entre 200 et 250 contributeurs actifs quotidiennement, ce qui nous place en second derrière l'Allemagne et devant la Russie. Côté données, un petit point sur les statistiques du réseau routier: - 1,3 million de km de routes et chemins, soit 340.000 de plus qu'il y a un an, une progression globale de 35% (malgré le passage à l'ODbL) - les réseaux autoroutiers, primaires et secondaires plafonnent avec une progression respective de 2%, 4% et 5% - le réseau tertiaire continue à avancer (+23%), ainsi que les unclassified (+50%) et +29% de residential - les routes de type inconnu (road) sont en baisse de 26% - les voies non carrossables progressent aussi: +53% de path, +76% de track, +20% de cycleway, +39% de footway, +26% de pedestrian Sur l'année qui vient de s'écouler, c'est en moyenne 1000km de routes et chemins qui ont été ajoutés chaque jour. Le prochain qui me dit que l'import du bâti est nuisible je lui enverrai ces stats en réponse ;) -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâti et éoliennes
A ce compte là, tous les pylônes électriques sont aussi des buildings. J'ai déjà rencontré le cas, je ne sais plus sur quelle commune (bon, c'était quand même des pylônes haute-tension). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 850000 membres... et autres stats...
si on regarde ici : http://length.osm4people.org/france.html Entre le 09/11/2011 et le 23/03/2012 (133 jours) on a 117 069 km de highways en plus - Soit 880 km créés par jour. On parle de tous les types de highways mélangés, pas seulement des routes. Comme je pense que les données de base sont des extraits pris à un instant t, cela ne doit pas tenir compte des modifications. Le 15 octobre 2012 11:36, Pieren pier...@gmail.com a écrit : 2012/10/15 Mikaël Cordon mikael.cor...@gmail.com: Même si on suspecte un biais, les +1000 km / jour de route, par exemple, restent impressionnant, satisfaisant et motivant, je trouve. Oui, je trouve que ça fait beaucoup. Comment est-ce calculé ? Est-ce que ça ne cumule pas créations et modifications ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 850000 membres... et autres stats...
Le 15 octobre 2012 11:36, Pieren pier...@gmail.com a écrit : Oui, je trouve que ça fait beaucoup. Comment est-ce calculé ? Est-ce que ça ne cumule pas créations et modifications ? Comment c'est calculé ? Très simplement... Il y avait 959365 km de routes et chemin le 9/11/2011, il y en a 1299338 km aujourd'hui 15/10/2012. 1299338 - 959365 = 339973 km en 341 jours, ça fait... 339973/341 = 996,98km/jour Oui, j'ai arrondi ;) -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâti et éoliennes
D'après ce site, la base fait quand même 17,5 m : http://pascal.baudouin.pagesperso-orange.fr/salles_eolien.htm Building est justifié, amha. Le 15/10/2012 11:30, Francescu GAROBY a écrit : De base, je trouve qu'utiliser une way pour marquer une éolienne, c'est un poil too much (ou alors, utilisons aussi des ways pour marquer le contour du moindre conteneur de tri sélectif...), mais soit. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 850000 membres... et autres stats...
1032 km / jour entre le 21/03 et le 15/10 alors Je mettrais ça sur le compte de l'imagerie qui s'est beaucoup amélioré à la campagne ces derniers mois. Le 15 octobre 2012 11:46, Christian Quest cqu...@openstreetmap.fr a écrit : Le 15 octobre 2012 11:36, Pieren pier...@gmail.com a écrit : Oui, je trouve que ça fait beaucoup. Comment est-ce calculé ? Est-ce que ça ne cumule pas créations et modifications ? Comment c'est calculé ? Très simplement... Il y avait 959365 km de routes et chemin le 9/11/2011, il y en a 1299338 km aujourd'hui 15/10/2012. 1299338 - 959365 = 339973 km en 341 jours, ça fait... 339973/341 = 996,98km/jour Oui, j'ai arrondi ;) -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâti et éoliennes
Moui, 17 m, c'est en sous-sol, pour la fondation. Il est question d'un cylindre de 4 m de diamètre et 30 m de haut. *Au dessus une collerette d'acier pour boulonner le mât (diamètre 4 m, haut 30 m)* (pas dur de vérifier dans JOSM) Le 15 octobre 2012 11:51, helene_gmx.fr helene.pe...@gmx.fr a écrit : D'après ce site, la base fait quand même 17,5 m : http://pascal.baudouin.**pagesperso-orange.fr/salles_**eolien.htmhttp://pascal.baudouin.pagesperso-orange.fr/salles_eolien.htm Building est justifié, amha. Le 15/10/2012 11:30, Francescu GAROBY a écrit : De base, je trouve qu'utiliser une way pour marquer une éolienne, c'est un poil too much (ou alors, utilisons aussi des ways pour marquer le contour du moindre conteneur de tri sélectif...), mais soit. __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 850000 membres... et autres stats...
Et du nombre de contributeurs actifs qui ne fait que progresser lui aussi. Les deux se combinent... Le 15 octobre 2012 11:53, Ab_fab gamma@gmail.com a écrit : 1032 km / jour entre le 21/03 et le 15/10 alors Je mettrais ça sur le compte de l'imagerie qui s'est beaucoup amélioré à la campagne ces derniers mois. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâti et éoliennes
Je serais aussi d'avis de garder le tag building, quitte à créer une nouvelle variante du contenu. Il ne faut pas oublier que le building=yes ajouté automatiquement lors de l'ajout de données du cadastre est normalement à remanier avec les données de terrain pour obtenir quelque chose de plus précis ! Sylvain Le 15 octobre 2012 11:56, Ab_fab gamma@gmail.com a écrit : Moui, 17 m, c'est en sous-sol, pour la fondation. Il est question d'un cylindre de 4 m de diamètre et 30 m de haut. *Au dessus une collerette d'acier pour boulonner le mât (diamètre 4 m, haut 30 m)* (pas dur de vérifier dans JOSM) Le 15 octobre 2012 11:51, helene_gmx.fr helene.pe...@gmx.fr a écrit : D'après ce site, la base fait quand même 17,5 m : http://pascal.baudouin.**pagesperso-orange.fr/salles_**eolien.htmhttp://pascal.baudouin.pagesperso-orange.fr/salles_eolien.htm Building est justifié, amha. Le 15/10/2012 11:30, Francescu GAROBY a écrit : De base, je trouve qu'utiliser une way pour marquer une éolienne, c'est un poil too much (ou alors, utilisons aussi des ways pour marquer le contour du moindre conteneur de tri sélectif...), mais soit. __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger du nucléaire [long]
Le 15 octobre 2012 09:25, Romain MEHUT romain.me...@gmail.com a écrit : Le 13 octobre 2012 20:44, Pierre-Alain Dorange pdora...@mac.com a écrit : PS : Sur un sujet proche je fais aussi des recherches pour cartographier les sites types seveso en France (classement Seveso 1 et 2, c'est à dire dnagereux et surveillé par l'administration), à priori j'ai rien trouvé d'existant sur ce sujet. Je réponds sur le PS. Est-ce que le site de l'IREP http://www.irep.ecologie.gouv.fr/IREP/index.php peut être utile? Même si les données sont relatives, ça fait quelque chose d'arriver sur une carte toute pleine de points : http://www.irep.ecologie.gouv.fr/IREP/map/cartoFrame.php -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Création du Groupe d'accompagnement aka Cadastre task force
Bonjour, Je fais acte de candidature par la présente, en reprenant des points de Marc ;-) - que je ne traine pas (ou rarement) sur IRC - je ne suis pas tout le temps diplomate modéré, mais je me soigne - j'ai une bonne expérience dans l'import bâti cadastre (mdr) Donc, Christian et Sly, si vous pouvez étudier ma candidature ;-) -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger du nucléaire [long]
Romain MEHUT romain.me...@gmail.com wrote: PS : Sur un sujet proche je fais aussi des recherches pour cartographier les sites types seveso en France (classement Seveso 1 et 2, c'est à dire dnagereux et surveillé par l'administration), à priori j'ai rien trouvé d'existant sur ce sujet. Je réponds sur le PS. Est-ce que le site de l'IREP http://www.irep.ecologie.gouv.fr/IREP/index.php peut être utile? IREP oui mais surtout aussi nouveau site Installations Classées. Mon questionnement sur ce point n'est pas tant les sources de données (il y en a pleins et publiques) mais plutot comment tagger dans la pratique. Comment identifié un site : - installation classée - installation Seveso Seuil Bas - installation Seveso Seuil Haut et éventuellement intégrer la nomenclature du ministère pour décrire le ou les produits dangereux. Installations classées (définition) http://www.installationsclassees.developpement-durable.gouv.fr/-Installa tion-classee-.html Nomenclature : http://www.installationsclassees.developpement-durable.gouv.fr/La-nomenc lature-des-installations.html Par exemple à coté de chez moi (Cognac) y'a plusieurs usines de cette boisson alcoolisée qui sont en Seveso Bas voir Haut pour certaines, la fiche du ministère ressemble par exemple à ça : http://www.installationsclassees.developpement-durable.gouv.fr/recherch eICForm.php Hennessy Bagnolet Régime Seveso : Seuil AS Priorité nationale : Oui IPPC : Non Nomenclature : 1434.1b, 2250.1, 2250.2, 2251.2, 2255.1, 2920.2b, 2921.2, 2925 Je pense qu'il serait a minima important de pouvoir tagger les site Seveso (Bas et haut) qui sont les plus dangereux. -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Création du Groupe d'accompagnement aka Cadastre task force
2012/10/15 partir-en-vtt ad...@partir-en-vtt.com: De plus, on entre dans la même dérive que celle du DWG à savoir : un petit nombre décide pour beaucoup. Je vais être d'accord avec partir-en-vtt sur un point mais pas celui-ci. Le DWG se targue de n'appliquer qu'une politique définie par la ... communauté. Même si on voit bien que ce qui est désigné par communauté, c'est toujours à peu près le même groupe de personnes. Mais bon, d'un autre côté, les membres de la communauté se foutent des imports massifs tant que ça n'arrive pas chez-eux. L'histoire du compte séparé, ça leur passe à 20.000 au dessus de la tête. Donc, il reste un petit groupe de gens qui sont soucieux de l'impact de ces imports sur le projet, en particulier dans des zones à faibles niveaux de participants (et donc d'auto-contrôle). Pendant longtemps, ils se sont cru seuls et ont dû être surpris par notre mobilisation sur la liste principale parce que jusque là, leurs interventions n'intéressaient qu'un nombre limité de personnes. Par contre, sur le point de la confidentialité, j'aurais tendance maintenant à être d'accord avec partir-en-vtt. Ce qui mine le plus l'action du DWG ou de l' OSMF en général, c'est leur manque de communication et de transparence. Dans un projet comme OSM, il ne faut rien cacher et il faudrait ouvrir cette liste, sans inscription préalable. Le risque de voir des contributeurs injustement accusés est inférieur à celui de créer une suspicion de prise de contrôle par un petit groupe sur le reste de la communauté. Si le but de ce groupe est d'imposer certaines règles, il faut d'abord montrer que ces règles sont connues et admises par l'immense majorité et que l'avis de tous, même du plus petit contributeur, est pris en compte. Ne répétons pas les mêmes erreurs que le DWG. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger du nucléaire [long]
Marc Sibert m...@sibert.fr wrote: Mes 0.02 € : c'est tellement spécifique (et invisible donc difficilement cartographiable vérifiable surtout) que ça devrait rester dans une couche locale à ton application. Salut, Je veux bien admettre que sur le point de cartographier tout les utilisateurs de produits nécléaire c'est un peu spécifique (c'est par contre, en France du moins faisable et vérifiable même si long). Par contre sur la cartographie des sites de production d'uranium, des centrales et des déchets ça me semble indispensable. L'information est de plus totalement publique. -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 850000 membres... et autres stats...
2012/10/15 Christian Quest cqu...@openstreetmap.fr: Et du nombre de contributeurs actifs qui ne fait que progresser lui aussi. Les deux se combinent... Est-ce que quelqu'un serait capable de montrer les 1000 kms de highway ajoutés hier ? Sachant que l'essentiel des routes principales est déjà présent, ça ferait 4 à 5 kms en moyenne de unclassified ou residential ou track par personne et par jour ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâti et éoliennes
Le lundi 15 octobre 2012 à 11:35 +0200, Ab_fab a écrit : Oui, il y a une analyse Osmose sur les bâtiments circulaires. On pourrait la compléter avec une analyse du nombre de points qui constituent le cercle, car c'est un défaut récurrent du cadastre (dont on a déjà parlé, concernant les éoliennes) Alors, un bon cercle, combien de points ? :-) Je propose de créer un groupe de travail. Les débats se dérouleront dans une liste privée pour éviter que les fourmis ne puissent être tentés de donner leur avis forcément inintéressant. Dans 6 mois, peut-être 12, on saura si importer un bâtiment de 450 nœuds pour décrire un cercle de 5m de diamètre est une bonne pratique ou non... Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendez vous avec la Direction de l'IGN
Salut à tous, Un petit message pour vous souhaiter une bonne réunion. Si possible essayez de glisser la possibilité d'accéder en WMS aux orthos sur la Réunion. La qualité de celles de Bing est vraiment mauvaise ! @++ Arnaud 2012/10/3 Vincent Privat vincent.pri...@gmail.com Un peu de lecture pour situer ces propos dans le contexte financier de l'IGN: - 2011: http://www.senat.fr/commission/fin/pjlf2011/np/np10/np107.html - 2012: http://www.senat.fr/rap/l11-107-310/l11-107-31054.html - 2013: http://www.developpement-durable.gouv.fr/IMG/pdf/PLF-2013_28p_V5_28-09-12.pdf(page 23) Où l'on voit qu'effectivement que les recettes commerciales de l'IGN sont une part importante de son financement. Pour plus de détails, le rapport annuel de l'IGN: - http://www.ign.fr/publications-de-l-ign/Institut/Publications/RA/RA_2011/Rapport-annuel-2011.pdf(pages 43 à 45) Vincent Le 3 octobre 2012 17:59, Romain MEHUT romain.me...@gmail.com a écrit : Bonjour, Un articlehttp://blog.grandesvilles.org/3233/administration-electronique/interoperabilite/lign-mise-sur-son-api-pour-booster-les-usages-du-geoportail/concernant la mise en ligne de la nouvelle version du Géoportail où on peut lire: *L’institut reste en revanche très en retrait sur l’Open Data et le mot n’a pas été prononcé par le directeur général lors de la présentation de la V3. L’IGN estime en effet que seule la gratuité de visualisation des données entre dans sa mission de service public, le paiement des redevances liées à la réutilisation des données IGN étant en outre indispensable à l’équilibre budgétaire de l’établissement public.* Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Arnaud Vandecasteele Mines Paris Tech - CRC Sophia-Antipolis 0698 24 25 29 SIG - WebMapping - Spatial Ontology - GeoCollaboration Web Site http://perso.crc.mines-paristech.fr/~arnaud.van_de_casteele/ http://geotribu.net/ http://www.i2c.eu/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâti et éoliennes
2012/10/15 Sylvain Maillard sylvain.maill...@gmail.com: Je serais aussi d'avis de garder le tag building, quitte à créer une nouvelle variante du contenu. Il ne faut pas oublier que le building=yes ajouté automatiquement lors de l'ajout de données du cadastre est normalement à remanier avec les données de terrain pour obtenir quelque chose de plus précis ! à remanier ne veux pas dire conserver la clé building à tout prix. Si je passe à côté d'une éolienne, je ne vais pas m'exclamer oh, tiens, quel beau bâtiment !. J'ai peur qu'on ne tombe dans le tagguer de façon incorrecte pour le rendu. J'aurais la même réflexion pour les pylônes électriques. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Prémisses d'un groupe de travail sur les nouveaux inscrits
Le 15 octobre 2012 10:04, Ab_fab gamma@gmail.com a écrit : Bonjour, Je suis bien d'accord avec tout ça. Concernant Potlatch, je dois être mal-comprenant, mais je n'ai pas encore trouvé la méthode adaptée pour aller traduire proprement l'interface en Français. C'est vraiment quelque chose à affûter. Bonjour, Pour le passage en français, il me semble qu'il faut mettre en ligne sa propre instance et en modifier les paramètres : args[locale] = fr_FR; http://wiki.openstreetmap.org/wiki/Potlatch_2/Deploying_Potlatch_2 Cela pourrait faire l'objet d'un projet à mettre en place sur les serveurs de l'asso. On pourrait également mettre en place notre propre preset (et virer le tag designation). Bruno ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pnorman = Spam
Moi, toutes ces histoires, ça ne me donne qu'une envie : me mettre à intégrer du bati, juste histoire de voir :) Erik Le 15 octobre 2012 09:59, partir-en-vtt ad...@partir-en-vtt.com a écrit : Sauf que j'ai cru comprendre que le DWG n'était pas dans une logique de concessions. Pourtant, il me semble que pour trouver des compromis, les deux parties doivent faire des efforts. Mais bon, apparemment, j'ai du oublier mon Tranxen et je semble nuire au bon déroulement de la chose. N'hésitez pas à venir mapper la Franche-Comté car je n'y ajouterai plus une node. -- View this message in context: http://gis.19327.n5.nabble.com/Pnorman-Spam-tp5730049p5730627.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendez vous avec la Direction de l'IGN
Tu as raison Jean-Claude mais ne connaissant pas la qualité de Bing sur la métropole je n'ai pas préféré généralisé. Néanmoins, un accès généralisé serait vraiment top. Mais bon je ne suis pas certain que cette demande soit possible... Gaël, amène un peu de rhum ça aidera peut être à signer des engagements :D Arnaud 2012/10/15 Jean-Claude Repetto jrepe...@free.fr Le 15/10/2012 13:29, Arnaud Vandecasteele a écrit : Salut à tous, Un petit message pour vous souhaiter une bonne réunion. Si possible essayez de glisser la possibilité d'accéder en WMS aux orthos sur la Réunion. La qualité de celles de Bing est vraiment mauvaise ! Pourquoi seulement à la Réunion ? L'idéal serait que l'IGN autorise l'utilisation de toutes leurs orthophotos, comme l'a fait Bing. Jean-Claude __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- Arnaud Vandecasteele Mines Paris Tech - CRC Sophia-Antipolis 0698 24 25 29 SIG - WebMapping - Spatial Ontology - GeoCollaboration Web Site http://perso.crc.mines-paristech.fr/~arnaud.van_de_casteele/ http://geotribu.net/ http://www.i2c.eu/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Prémisses d'un groupe de travail sur les nouveaux inscrits
Quand j'ouvre Potlatch 2 chez moi (depuis openstreetmap.org), les boutons en haut sont bien en français. Ce sont les descriptions des éléments qui restent en anglais. Il y a des captures d'écran ici qui montrent bien ce qui est en Français et ce qui n'a pas été traduit. http://fr.flossmanuals.net/openstreetmap/ch010_modifier-avec-lediteur-en-ligne-potlatch-2 C'est effectivement possible de monter une instance propre, mais il faudrait s'assurer que les nouveaux tombent dessus en priorité. C'est pas gagné :-) S'il est possible d'améliorer l'instance hébergée sur openstreetmap.org, autant le faire là bas. Le 15 octobre 2012 13:42, Bruno Cortial bruno.cort...@laposte.net a écrit : Le 15 octobre 2012 10:04, Ab_fab gamma@gmail.com a écrit : Bonjour, Je suis bien d'accord avec tout ça. Concernant Potlatch, je dois être mal-comprenant, mais je n'ai pas encore trouvé la méthode adaptée pour aller traduire proprement l'interface en Français. C'est vraiment quelque chose à affûter. Bonjour, Pour le passage en français, il me semble qu'il faut mettre en ligne sa propre instance et en modifier les paramètres : args[locale] = fr_FR; http://wiki.openstreetmap.org/wiki/Potlatch_2/Deploying_Potlatch_2 Cela pourrait faire l'objet d'un projet à mettre en place sur les serveurs de l'asso. On pourrait également mettre en place notre propre preset (et virer le tag designation). Bruno ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Création du Groupe d'accompagnement aka Cadastre task force
Le 15 octobre 2012 13:00, Pieren pier...@gmail.com a écrit : Par contre, sur le point de la confidentialité, j'aurais tendance maintenant à être d'accord avec partir-en-vtt. Ce qui mine le plus l'action du DWG ou de l' OSMF en général, c'est leur manque de communication et de transparence. Dans un projet comme OSM, il ne faut rien cacher et il faudrait ouvrir cette liste, sans inscription préalable. Le risque de voir des contributeurs injustement accusés est inférieur à celui de créer une suspicion de prise de contrôle par un petit groupe sur le reste de la communauté. Si le but de ce groupe est d'imposer certaines règles, il faut d'abord montrer que ces règles sont connues et admises par l'immense majorité et que l'avis de tous, même du plus petit contributeur, est pris en compte. Ne répétons pas les mêmes erreurs que le DWG. Non, je ne crois pas. D'abord, il n'est pas établi que le DWG manque de communication ou de transparence. Il est établi qu'ils font une erreur (c'est Phillipe Verdy qui en parle le mieux, je crois). On pourrait très bien raconter que c'est la communauté française qui manque de communication ou de transparence avec ses imports/intégration/machin de cadastre... accuse quelqu'un de manquer de communication ou de transparence... tu gagnes à tous les coups. Si ce groupe d'accompagnement a quelque chance de succès, c'est comme interface avec le DWG. S'il se construit dès le départ contre le DWG, il est mal barré comme interface. La transparence ne garanti nullement le bon fonctionnement, mais elle peut apporter la confiance. C'est déjà pas mal. Mais le groupe ne peut pas se mettre à vérifier que le plus petit contributeur, comme tu dis, a compris avant de faire quelque chose. Pour réussir quand même à gagner la confiance, on peut aussi travailler sur la traçabilité et sur la réactivité. Par exemple, que ce groupe réponde même au plus petit contributeur, là, oui, mais j'imagine que c'est de toutes façons compris comme ça ? Et il faut aussi donner la limite de ces notions. Par exemple, on peut dire que le groupe ne réagit pas le dimanche. Ou dire que les échanges concernant une personne particulière restent privés. Sinon, plus rien ne fonctionnera de toutes manières. Donc moa je pense : 1) Se calmer au niveau du DWG 2) Travailler non seulement sur la transparence, mais en plus sur la réactivité du groupe. Et sachant qu'il faut expliciter les limites pratiques de ces notions. Hugh. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâti et éoliennes
Le 15 octobre 2012 13:34, Pieren pier...@gmail.com a écrit : à remanier ne veux pas dire conserver la clé building à tout prix. Si je passe à côté d'une éolienne, je ne vais pas m'exclamer oh, tiens, quel beau bâtiment !. J'ai peur qu'on ne tombe dans le tagguer de façon incorrecte pour le rendu. J'aurais la même réflexion pour les pylônes électriques. totalement d'accord pour ne pas tagguer pour le rendu, pour ma part qu'une éolienne soit représentée par un point ou par un polygone m'importe peu en réalité ... Je pense que c'est surtout une histoire de définition de qu'est-ce qui est considéré comme du bâti : j'aurais tendance à considérer qu'une tour de 4m de diamètre par 30m de haut, avec un escalier/échelle à l'intérieur peut être considéré comme du bâti ... mais pas un pylône ouvert constitué uniquement de poutrelles métalliques (alors qu'une tour parisienne avec en plus des restos dedans, oui) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Création du Groupe d'accompagnement aka Cadastre task force
D'abord, il n'est pas établi que le DWG manque de communication ou de transparence. Il est établi qu'ils font une erreur (c'est Phillipe Verdy qui en parle le mieux, je crois). L'erreur commise est intimement liée au fait qu'il n'y a pas eu de communication et de prise en compte des avis de la communauté Française. - Manque de communication - Manque de transparence et d'échanges *Résultante :* erreur et incompréhensions On pourrait très bien raconter que c'est la communauté française qui manque de communication ou de transparence avec ses imports/intégration/machin de cadastre... accuse quelqu'un de manquer de communication ou de transparence... tu gagnes à tous les coups. Du côté de la communauté FR, il me semble que l'ajout du bâti est expliqué sur le wiki d'une façon claire et cohérente. De plus, il est bien noté que cet ajout de données est à prendre avec des pincettes. La transparence ne garanti nullement le bon fonctionnement, mais elle peut apporter la confiance. C'est déjà pas mal. Mais le groupe ne peut pas se mettre à vérifier que le plus petit contributeur, comme tu dis, a compris avant de faire quelque chose. Pour réussir quand même à gagner la confiance, on peut aussi travailler sur la traçabilité et sur la réactivité. Par exemple, que ce groupe réponde même au plus petit contributeur, là, oui, mais j'imagine que c'est de toutes façons compris comme ça ? Chaque contributeur à pour moi une valeur identique et tous ont le droit de connaître les prises de décisions et peuvent participer à ces dernières. De ce fait, il faut communiquer et laisser ouvert les discussions relatives aux prises de décisions et procéder à des votes si nécessaire. Le site OSM.fr doit être une passerelle pour alerter les contributeurs en leur disant eh les contributeurs, ils y a des décisions importantes qui se jouent en ce moment sur ce lien, venez participer si vous souhaitez prendre à bras le corps les évolutions du projet. Si l'utilisateur ne vient pas, tant pis pour lui mais l'organe officiel aura communiquer sur le sujet. -- View this message in context: http://gis.19327.n5.nabble.com/Creation-du-Groupe-d-accompagnement-aka-Cadastre-task-force-tp5730121p5730717.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pnorman = Spam
C'est ce que je me suis dit aussi sauf que le tout puissant DWG va te menacer et bloquer ton compte si tu n'écoutes pas leurs lois. -- View this message in context: http://gis.19327.n5.nabble.com/Pnorman-Spam-tp5730049p5730718.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Import des cantons
Bonjour, En juin dernier, juste avant les dernières élections on avait travaillé sur l'import des circonscriptions avec Regard Citoyen. Aujourd'hui j'ai reproduit le même procédé avec les cantons. J'ai préparé des .osm contenant les relations de plus de 2000 cantons, un peu moins de la moitié de la France. Ils ne regroupent que les cantons dont toutes le communes sont déjà dans OpenStreetMap et uniquement des agrégats des communes entières. Les cantons déjà présents dans OSM n'ont également pas été générées. Les fichiers groupés par département sont disponible là : http://osm7.openstreetmap.fr/~fred/canton/ Pour la coordination de l'import c'est là : http://lite.framapad.org/p/FMjG1rV0KN Pour la visualisation c'est là (en orange): http://layers.openstreetmap.fr/?layers=B00TFF Pour plus d'info : http://wiki.openstreetmap.org/wiki/FR:Circonscription_l%C3%A9gislative Ensuite les cantons comprenant des communes partielles doivent être fait à la main. Ce genre de découpage à en partie déjà été réalisé pour les circonscriptions. Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] parking entouré d'une barrière
Salut à tous, Je comprends qu'il est plus simple et moins encombrant pour la base de données de mêler le tag barrier=* avec la surface utilisée comme parking, mais ça reste quelque peu incohérent pour moi, car on mélange les sémantiques pour un même objet qui, une fois est interprété comme un way, une autre fois est interprété comme une area (quelle est la valeur implicite de la clé non fournie area ?). C'est comme mélanger un disque et un cercle : l'un est plein, l'autre n'est que périphérique. Comment voulez-vous par la suite attribuer des propriétés à l'un sans que l'autre ne soit concerné ? Par exemple electrified=yes : est-ce que la surface du parking est électrifiée ? Si on doit placer un tag généraliste comme, disons un hypothétique color=*, à qui celui-ci s'appliquerait-il ? Sans aller jusqu'aux surfaces, il a déjà été conclu que les railway=* et les highway=* devaient être sur des ways différents, justement parce que les confusions peuvent survenir dans les tags. Dans un autre ordre d'idées, certains tags ont besoin d'un area=yes pour exprimer une surface plutôt qu'un way : citons railway=platform, mais aussi tous les highway=*. Alors, tous les tags qui y sont accolés devront aussi être interprétés avec area=yes. De mon point de vue, dans notre base de données géographique (nous ne nous limitons pas aux cartes il me semble, même s'il s'agit du principal objectif), on devrait décrire des objets avec leurs propriétés : - quelle est la nature de cet objet (route, building, barrière, étendue d'eau, etc.) avec l'aide éventuelle de plusieurs tags ; - quelles sont les propriétés de cet objet (en termes d'accès, de propriété, de forme, d'altitude, etc.) avec autant de tags qu'on veut. C'est simple et logique. Une barrière n'est pas un parking, une barrière n'est pas une sorte de parking, et un parking n'est pas une sorte de barrière. Un parking peut être entouré d'une barrière, mais dans ce cas on utilise un tag approprié. Si on mélange les objets et leurs propriétés, on perd une importante logique descriptive pour en faire un inventaire à la Prévert, où seule une interprétation méticuleuse des éléments (triés à la main) permet de comprendre ce qu'il en est. Teuxe PS. Je n'ai rien compris quant à l'utilisation de relations pour taguer un parking entouré d'une barrière. - Mail original - De: Philippe Verdy verd...@wanadoo.fr À: Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé: Vendredi 12 Octobre 2012 10:59:29 Objet: Re: [OSM-talk-fr]parking entouré d'une barrière Le 11 octobre 2012 14:17, te...@free.fr a écrit : On peut se dire que le way fermé (area) représente une surface qui sert de parking ; à l'opposé, la barrière, même si elle couvre tout le périmètre du parking, n'en reste pas moins un linéaire et n'est pas une surface : n'étant pas de même nature, on ne peut pas associer les deux au même objet. Pas dans un même way, mais la surface fermer peut devenir une relation avec se attributs propres, mais dont les membres sont les ways linéaires ayant leurs propres tags. Ce qui évite de superposer les ways ouverts des clôtures et barrières et un way fermé dessus, voire aussi de dupliquer les noeuds ou de les intercaler le long du même tracé quasi superposé sur une grande longueur (où les traits ne cessent de se recouper aléatoirement alors que les tracés n'ont pas de raison partioculière de s'écarter l'un de l'autre). Donc on transforme dans ce cas un way fermé en multipolygone (c'est le multipolygone qui portera les attributs de la surface, plus le way fermé inclus comme membre du multipolygone) avant de le découper, et on fusionne les chemins linéaires communs : il ne reste alors que le chemin linéaire et non fermé de la cloture, et celui de la barrière, les deux utilisés en membres du multipolygone pour la surface fermée du parking. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Création du Groupe d'accompagnement aka Cadastre task force - Liste privée ou liste publique ?
On lundi 15 octobre 2012, Pieren wrote: Dans un projet comme OSM, il ne faut rien cacher et il faudrait ouvrir cette liste, sans inscription préalable. Disons que je ne suis pas certain de ta conclusion, mais je suis en tout cas d'avis d'essayer. Rien n'empêche, ultérieurement, de revenir en arrière si on découvre de gros défauts. Donc, +1 à la ré-ouverture de la liste. Je note 4 avis pour l'ouverture, un avis contre l'ouverture. D'autres avis ? -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [forum-osm-fr] Utilisation de la key:area
Le message suivant de : ## Bonjour, j'avais souvent taguer area=yes pour: amenity=parking highway=pedestrian public_transport = platform etc... Etant donné les erreurs reportées par OsmOse, il semblerait que area=yes soit maintenant restreint à certaines utilisations. J'ai regardé sur ces liens pour trouver les usages [url]http://wiki.openstreetmap.org/wiki/Key:area[/url] [url]http://wiki.openstreetmap.org/wiki/Area[/url] Je peux comprendre que certains tracés sont area par défaut, comme certainement les parkings. Mais malheureusement, je ne comprends plus trop dans le détail lorsqu'il faut mettre ou pas area=yes. Merci de votre aide a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=5 Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une concertation sur la liste avant de recopier la/les meilleurs réponses sur le forum. Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre. -- Les questions sur ce robot de transfert forum-liste peuvent être posées à sylvainaletuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Création du Groupe d'accompagnement aka Cadastre task force - Liste privée ou liste publique ?
Le lundi 15 octobre 2012 à 15:20 +0200, sly (sylvain letuffe) a écrit : On lundi 15 octobre 2012, Pieren wrote: Dans un projet comme OSM, il ne faut rien cacher et il faudrait ouvrir cette liste, sans inscription préalable. Disons que je ne suis pas certain de ta conclusion, mais je suis en tout cas d'avis d'essayer. Rien n'empêche, ultérieurement, de revenir en arrière si on découvre de gros défauts. Donc, +1 à la ré-ouverture de la liste. je suis d'avis que toutes les personnes qui utilisent le cadastre devraient avoir un avis. le mien est confu: la liste et le groupe sont pour moi des (re)actions, mais je ne sais toujours pas en francais basique: - ce qui a changé en 6 mois pour que le dwg donne des avertissements ou pire - ce que désire le dwg Je note 4 avis pour l'ouverture, un avis contre l'ouverture. D'autres avis ? avis a l'ouverture publique dans un premier temps au moins pour ne pas etre afublé de dwgisme didier ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] parking entouré d'une barrière
Une relation sert à regrouper un ensemble de ways connectés ensembles : - Les ways isolément ne représentent alors que des lignes et pas une surface, ils peuvent donc avoir les attributs/tags d'une barrière. - En revanche la relation ignore les attribits des ways membres, et possède ses propres tags pour mentionner ce que désigne la surface. - Toute surface fermée représentable par un way fermé peut être transformée en relation, afin de découper ses ways (et dans ce cas ils ne se ferment plus isolément et ne peuvent pas représenter une surface. Tout dans ton message indique ton incompréhension. Regarde le wiki documentaire au sujet des relations de type=multipolygones (les type=boundary utilisés pour définir la surface d'une région par ses frontières)sont un cas particulier de multipolygone. = NOTES ANNEXES Les relations OSM peuvent avoir d'autres usages, quand elles servent à regrouper des ways qui ne se ferment volontairement pas dans la relation : - les rivières par exemple (type=waterway), ou les routages de lignes de transport (type=route) - les type=multilinestring aussi (pour représenter un morceau de frontière commune entre deux régions), expérimental. Elles ne représentent aucune surface puisqu'elles ne sont normalement pas fermées, et n'ont donc pas de côté interne ni externe (inner/outer) comme les relations de type=boundary. Par défaut toutes les relations qui ont des ways qui se ferment représentent une surface, sauf justement les rivières (avec leurs ways membres de rôle main_stream par défaut, ou side_stream, au contraire des ways membres de rôle riverbank qu'on peut y mettre aussi), et les rues/routes/chemins/pistes (highway=*) pour lesquels on doit encore utiliser area=yes dans la relation si on veut représenter leur surface et non le contour (exemple : les places piétonnes), et les voies ferrées (railway=*) pour lesquelles il n'y a aucun usage d'area=yes actuellement défini.. Par défaut aussi, toutes les mêmes relations qui ont des ways qui ne se ferment pas ne représentent que des lignes (continues ou pas). Toutes les relations de type=boundary (également celles de type=land_area qui ne réprésentent que la partie émergée d'une région, peu utilisée actuellement en France mais très utilisées dans les pays pour lesquelles les frontières administratives incluent le domaine maritime) devraient se fermer, de même que toutes les relations de type=multipolygone (par exemple les landuse=* ou natural=*). Le 15 octobre 2012 14:54, te...@free.fr a écrit : Salut à tous, Je comprends qu'il est plus simple et moins encombrant pour la base de données de mêler le tag barrier=* avec la surface utilisée comme parking, mais ça reste quelque peu incohérent pour moi, car on mélange les sémantiques pour un même objet qui, une fois est interprété comme un way, une autre fois est interprété comme une area (quelle est la valeur implicite de la clé non fournie area ?). C'est comme mélanger un disque et un cercle : l'un est plein, l'autre n'est que périphérique. Comment voulez-vous par la suite attribuer des propriétés à l'un sans que l'autre ne soit concerné ? Par exemple electrified=yes : est-ce que la surface du parking est électrifiée ? Si on doit placer un tag généraliste comme, disons un hypothétique color=*, à qui celui-ci s'appliquerait-il ? Sans aller jusqu'aux surfaces, il a déjà été conclu que les railway=* et les highway=* devaient être sur des ways différents, justement parce que les confusions peuvent survenir dans les tags. Dans un autre ordre d'idées, certains tags ont besoin d'un area=yes pour exprimer une surface plutôt qu'un way : citons railway=platform, mais aussi tous les highway=*. Alors, tous les tags qui y sont accolés devront aussi être interprétés avec area=yes. De mon point de vue, dans notre base de données géographique (nous ne nous limitons pas aux cartes il me semble, même s'il s'agit du principal objectif), on devrait décrire des objets avec leurs propriétés : - quelle est la nature de cet objet (route, building, barrière, étendue d'eau, etc.) avec l'aide éventuelle de plusieurs tags ; - quelles sont les propriétés de cet objet (en termes d'accès, de propriété, de forme, d'altitude, etc.) avec autant de tags qu'on veut. C'est simple et logique. Une barrière n'est pas un parking, une barrière n'est pas une sorte de parking, et un parking n'est pas une sorte de barrière. Un parking peut être entouré d'une barrière, mais dans ce cas on utilise un tag approprié. Si on mélange les objets et leurs propriétés, on perd une importante logique descriptive pour en faire un inventaire à la Prévert, où seule une interprétation méticuleuse des éléments (triés à la main) permet de comprendre ce qu'il en est. Teuxe PS. Je n'ai rien compris quant à l'utilisation de relations pour taguer un parking entouré d'une barrière. ___ Talk-fr mailing list
Re: [OSM-talk-fr] Import des cantons
Ja suis toujours gˆné par le fait qu'on a défini les cantons avec le même tag boundary=political que les circonscriptions législatives. Ce n'est pas une erreur en soi, mais Layers (et Osmose) ne les différencient toujours pas sur la valeur donnée à political_division=*. Alors soit : - on utilise boundary=election pour les cantons - soir on modifie Osmose / Layers pour qu'il permettre de séparer les cantons dans une couche à part. Sinon le suivi n'est pas très pratique (on n'a pas non plus sur le site OpenStreetMap France de recensement des cantons et circonscriptions dans les pages de suivi du découpage de la France métropolitaine, pas plus que pour l'outremer d'ailleurs, meˆme si leur découpage est bien plus simple). Le 15 octobre 2012 14:49, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Bonjour, En juin dernier, juste avant les dernières élections on avait travaillé sur l'import des circonscriptions avec Regard Citoyen. Aujourd'hui j'ai reproduit le même procédé avec les cantons. J'ai préparé des .osm contenant les relations de plus de 2000 cantons, un peu moins de la moitié de la France. Ils ne regroupent que les cantons dont toutes le communes sont déjà dans OpenStreetMap et uniquement des agrégats des communes entières. Les cantons déjà présents dans OSM n'ont également pas été générées. Les fichiers groupés par département sont disponible là : http://osm7.openstreetmap.fr/~fred/canton/ Pour la coordination de l'import c'est là : http://lite.framapad.org/p/FMjG1rV0KN Pour la visualisation c'est là (en orange): http://layers.openstreetmap.fr/?layers=B00TFF Pour plus d'info : http://wiki.openstreetmap.org/wiki/FR:Circonscription_l%C3%A9gislative Ensuite les cantons comprenant des communes partielles doivent être fait à la main. Ce genre de découpage à en partie déjà été réalisé pour les circonscriptions. Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâti et éoliennes
Un truc rond qui fait 4 mètres de large n'a aucune chance d'être un bâtiment ou une tour, quel qu'il soit. Si c'est le cas ce n'est qu'une hutte. Et peut-être alors on peut éviter de l'importer, ou de le mettre dans une liste à part. Car effectivement au zoom maximum des rendus actuels, le mat est aussi gros que l'icône représentant le noeud d'une éolienne, et ce polygone n'apporte pas plus de détail (et on tombe aussi dans les limites de précision de nos géolocalisations et du cadastre, de sorte que les traits du polygone importé risquent très fort de ne même pas inclure la position centrale réelle de l'éolienne. Bref les éoliennes, comme les autres pylones et mats devraient rester des nœuds simples et non des polygones. Comme ce sera aussi le cas des arbres si on les positionne précisément dans un parc paysagé. Le 15 octobre 2012 11:56, Ab_fab gamma@gmail.com a écrit : Moui, 17 m, c'est en sous-sol, pour la fondation. Il est question d'un cylindre de 4 m de diamètre et 30 m de haut. Au dessus une collerette d'acier pour boulonner le mât (diamètre 4 m, haut 30 m) (pas dur de vérifier dans JOSM) Le 15 octobre 2012 11:51, helene_gmx.fr helene.pe...@gmx.fr a écrit : D'après ce site, la base fait quand même 17,5 m : http://pascal.baudouin.pagesperso-orange.fr/salles_eolien.htm Building est justifié, amha. Le 15/10/2012 11:30, Francescu GAROBY a écrit : De base, je trouve qu'utiliser une way pour marquer une éolienne, c'est un poil too much (ou alors, utilisons aussi des ways pour marquer le contour du moindre conteneur de tri sélectif...), mais soit. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import des cantons
Le 15/10/2012 16:25, Philippe Verdy a écrit : Ja suis toujours gˆné par le fait qu'on a défini les cantons avec le même tag boundary=political que les circonscriptions législatives. Ce n'est pas une erreur en soi, mais Layers (et Osmose) ne les différencient toujours pas sur la valeur donnée à political_division=*. Alors soit : - on utilise boundary=election pour les cantons Effectivement, je pense que c'est la bonne et la plus simple solution. Il suffit de changer ce qui est déjà fait et d'adapter les donnés aux outils, c'est toujours plus simple, et de toutes façon on fini toujours par faire comme ça. Parce que finalement c'est plus simple, ou pas. - soir on modifie Osmose / Layers pour qu'il permettre de séparer les cantons dans une couche à part. Sinon le suivi n'est pas très pratique (on n'a pas non plus sur le site OpenStreetMap France de recensement des cantons et circonscriptions dans les pages de suivi du découpage de la France métropolitaine, pas plus que pour l'outremer d'ailleurs, meˆme si leur découpage est bien plus simple). Ha, d'ailleurs, si tu avais regardé les liens fournit tu aurais pu y voir une carte sur layer représentant les cantons et les circonscriptions différemment. Mais je veux bien concevoir qu'il était plus judicieux de commencer par râler, par précaution. Le 15 octobre 2012 14:49, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Bonjour, En juin dernier, juste avant les dernières élections on avait travaillé sur l'import des circonscriptions avec Regard Citoyen. Aujourd'hui j'ai reproduit le même procédé avec les cantons. J'ai préparé des .osm contenant les relations de plus de 2000 cantons, un peu moins de la moitié de la France. Ils ne regroupent que les cantons dont toutes le communes sont déjà dans OpenStreetMap et uniquement des agrégats des communes entières. Les cantons déjà présents dans OSM n'ont également pas été générées. Les fichiers groupés par département sont disponible là : http://osm7.openstreetmap.fr/~fred/canton/ Pour la coordination de l'import c'est là : http://lite.framapad.org/p/FMjG1rV0KN Pour la visualisation c'est là (en orange): http://layers.openstreetmap.fr/?layers=B00TFF Pour plus d'info : http://wiki.openstreetmap.org/wiki/FR:Circonscription_l%C3%A9gislative Ensuite les cantons comprenant des communes partielles doivent être fait à la main. Ce genre de découpage à en partie déjà été réalisé pour les circonscriptions. Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import des cantons
Le 15 octobre 2012 16:38, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Le 15/10/2012 16:25, Philippe Verdy a écrit : Ja suis toujours gˆné par le fait qu'on a défini les cantons avec le même tag boundary=political que les circonscriptions législatives. Ce n'est pas une erreur en soi, mais Layers (et Osmose) ne les différencient toujours pas sur la valeur donnée à political_division=*. Alors soit : - on utilise boundary=election pour les cantons Effectivement, je pense que c'est la bonne et la plus simple solution. Il suffit de changer ce qui est déjà fait et d'adapter les donnés aux outils, c'est toujours plus simple, et de toutes façon on fini toujours par faire comme ça. Parce que finalement c'est plus simple, ou pas. - soir on modifie Osmose / Layers pour qu'il permettre de séparer les cantons dans une couche à part. Sinon le suivi n'est pas très pratique (on n'a pas non plus sur le site OpenStreetMap France de recensement des cantons et circonscriptions dans les pages de suivi du découpage de la France métropolitaine, pas plus que pour l'outremer d'ailleurs, meˆme si leur découpage est bien plus simple). Ha, d'ailleurs, si tu avais regardé les liens fournit tu aurais pu y voir une carte sur layer représentant les cantons et les circonscriptions différemment. Mais je veux bien concevoir qu'il était plus judicieux de commencer par râler, par précaution. Ca vient de changer alors. Parce que jusqu'à présent (et même encore maintenant) je ne vois pas de sélection possible pour ne voir que les uns ou les autres. Si seule la couleur fait la différence, alors je ne vois pas ces différences de couleur. (Je suis partiellement deutérotope, comme environ 15% des hommes en France, soit 1 sur 6 ; ce qui ne veut pas dire que je ne différencie pas 3 couleurs de base, mais qu'une des 3 composantes chromatique que je vois est légèrement décalé vers le vert avec une moins grande sensibilité, et que les rapports de proportion entre les 3 types de batonnets chromatiques sont différentes ; et cela affecte ma différenciation des beiges et des oranges, que j'ai du mal à voir sur des petites surfaces surtout quand elles sont contiguës). La vision des couleurs varie en fait avec chaque individu (surtout dans les proportions relatives entre les composantes). Alors je râle si je veux, pour les trucs que je ne vois pas, quand l'affichage mélange tout systématiquement et pourrait utilement les séparer (ou alors au moins les différencier avec des couleurs réellement très différentes parmi celles que tu as définies pour les boundary=political). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 850000 membres... et autres stats...
En cherchant avec l'overpass les way en version 1 dont la date de modif est de moins de 24h ? Le 15 octobre 2012 13:23, Pieren pier...@gmail.com a écrit : 2012/10/15 Christian Quest cqu...@openstreetmap.fr: Et du nombre de contributeurs actifs qui ne fait que progresser lui aussi. Les deux se combinent... Est-ce que quelqu'un serait capable de montrer les 1000 kms de highway ajoutés hier ? Sachant que l'essentiel des routes principales est déjà présent, ça ferait 4 à 5 kms en moyenne de unclassified ou residential ou track par personne et par jour ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâti et éoliennes
2012/10/15 Philippe Verdy verd...@wanadoo.fr: Un truc rond qui fait 4 mètres de large n'a aucune chance d'être un bâtiment ou une tour, quel qu'il soit. Si c'est le cas ce n'est qu'une hutte. Je connais une hutte qui fait 20 mètres de haut: http://fr.wikipedia.org/wiki/Fichier:Champ_du_feu.jpg Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Création du Groupe d'accompagnement aka Cadastre task force
bonjour à tous +1 avis de Pieren Peu importe les inconvénients de gestion, à terme il y a plus de risque à être non-visible qu'a être ouvert, même si c'est souvent dur d’être ouvert et si ça ralenti fortement les actions. L'ouverture de toutes les paroles garanti l'existence même de tout projet commun. Bien souvent le caché engendre à lui tout seul masse de problèmes. Vérifiable dans la vie de tout les jours djo_man Le 15/10/2012 13:00, Pieren a écrit : 2012/10/15 partir-en-vtt ad...@partir-en-vtt.com: De plus, on entre dans la même dérive que celle du DWG à savoir : un petit nombre décide pour beaucoup. Je vais être d'accord avec partir-en-vtt sur un point mais pas celui-ci. Le DWG se targue de n'appliquer qu'une politique définie par la ... communauté. Même si on voit bien que ce qui est désigné par communauté, c'est toujours à peu près le même groupe de personnes. Mais bon, d'un autre côté, les membres de la communauté se foutent des imports massifs tant que ça n'arrive pas chez-eux. L'histoire du compte séparé, ça leur passe à 20.000 au dessus de la tête. Donc, il reste un petit groupe de gens qui sont soucieux de l'impact de ces imports sur le projet, en particulier dans des zones à faibles niveaux de participants (et donc d'auto-contrôle). Pendant longtemps, ils se sont cru seuls et ont dû être surpris par notre mobilisation sur la liste principale parce que jusque là, leurs interventions n'intéressaient qu'un nombre limité de personnes. Par contre, sur le point de la confidentialité, j'aurais tendance maintenant à être d'accord avec partir-en-vtt. Ce qui mine le plus l'action du DWG ou de l' OSMF en général, c'est leur manque de communication et de transparence. Dans un projet comme OSM, il ne faut rien cacher et il faudrait ouvrir cette liste, sans inscription préalable. Le risque de voir des contributeurs injustement accusés est inférieur à celui de créer une suspicion de prise de contrôle par un petit groupe sur le reste de la communauté. Si le but de ce groupe est d'imposer certaines règles, il faut d'abord montrer que ces règles sont connues et admises par l'immense majorité et que l'avis de tous, même du plus petit contributeur, est pris en compte. Ne répétons pas les mêmes erreurs que le DWG. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Suivi des modifications : Comment visualiser simplement les objets modifiés ou détruits
Chai-pâ ce que vous penseriez d'un Sujet du lundi matin pour réchauffer les méninges. Les contributeurs du nord de L'Ontario, au Canada, on repéré une zone où quelqu'un s'est amusé à créer une ville imaginaire. Facile à repérer et effacer. Mais lorsque ce loustic ou un contributeur inexpérimenté ou distrait efface plutôt une zone? whodidit[1] ou des outils similaires nous permettent de repérer rapidement les zones où des modifications ont été effectuées. Par contre, de là, il est difficile de visualiser ce qui a été fait. À partir des changesets, il reste difficile de repérer si des dommages ont été effectués à une zone. Avec whodidit, par exemple, je peux toujours télécharger la zone dans JOSM et faire une recherche sur le code usager. Pour les objets effacés, par contre, c'est le néant. Il serait utile de pouvoir visualiser rapidement un objet effacé pour voir s'il était pertinent ou non de l'effacer. Je suis tombé sur un changeset où un nouveau contributeur a effacé plusieurs objets. Il a effacé une limite administrative, un club nautique etc. Mais lorsque nous faisons le suivi d'une zone, il n'est pas évident de repérer rapidement ces infos. Une solution intéressante serait d'ajouter la possibilité de visualiser les objets effacés dans un changeset particulier. À ma connaissance ceci n'existe pas. À partir de la liste des objets ajoutés, modifiés, effacés, un lien pourrait rediriger vers une carte OSM où cet objet est superposé. Qu'en pensez-vous? Pierre [1] http://zverik.osm.rambler.ru/whodidit/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] parking entouré d'une barrière
Salut Philippe, Une relation sert à regrouper un ensemble de ways connectés ensembles : - Les ways isolément ne représentent alors que des lignes et pas une surface, ils peuvent donc avoir les attributs/tags d'une barrière. - En revanche la relation ignore les attribits des ways membres, et possède ses propres tags pour mentionner ce que désigne la surface. - Toute surface fermée représentable par un way fermé peut être transformée en relation, afin de découper ses ways (et dans ce cas ils ne se ferment plus isolément et ne peuvent pas représenter une surface. C'est plus clair, merci. Dans ce cas, on n'a pas de way fermé (aucun doute way/area) mais des ways unis par une relation, relation qui porte la propriété formée par l'ensemble. Le type multipolygon sert à ça, j'étais au courant. Par défaut toutes les relations qui ont des ways qui se ferment représentent une surface, sauf justement les rivières (avec leurs ways membres de rôle main_stream par défaut, ou side_stream, au contraire des ways membres de rôle riverbank qu'on peut y mettre aussi), et les rues/routes/chemins/pistes (highway=*) pour lesquels on doit encore utiliser area=yes dans la relation si on veut représenter leur surface et non le contour (exemple : les places piétonnes), et les voies ferrées (railway=*) pour lesquelles il n'y a aucun usage d'area=yes actuellement défini.. Alors il y a contradiction avec http://wiki.openstreetmap.org/wiki/Way : par défaut, un way fermé n'est pas une area, sauf si area=yes est fourni. Certaines clés impliquent area=yes, cette page cite leisure=* et amenity=*, on peut aussi citer landuse=*, building=*, etc. (waterway=* ?) ; par contre il est dommage de trouver autant d'exceptions, surtout qu'elles sont listées nulle part. Et ça fait autant d'exceptions à intégrer dans les programmes qui utilisent ces données. Toutes les relations de type=boundary (également celles de type=land_area qui ne réprésentent que la partie émergée d'une région, peu utilisée actuellement en France mais très utilisées dans les pays pour lesquelles les frontières administratives incluent le domaine maritime) devraient se fermer, de même que toutes les relations de type=multipolygone (par exemple les landuse=* ou natural=*). Note : devraient : on peut avoir de telles relations non fermées dans la base de données, tant que personne n'aura corrigé l'erreur reportée par OsmOse. On pourra constater sur la France de nombreux landuse blanchis au rendu par des multipolygones cassés. Pour ces larges surfaces, le multipolygon est nécessaire ; pour un petit parking, je ne suis pas convaincu. Bref tout cela ne répond pas à la question du cumul des objets : peut-on logiquement représenter deux objets réels _différents_ dans un même objet OSM (node/way/relation, qui peuvent être considérés comme des groupes de tags) ? Pour ma part, non, car : - on casse une logique sémantique, - et le risque de rencontrer des incompatibilités grandit avec le nombre de combinaisons possibles. (Les bons concepteurs vous parleront de l'adage KISS : http://fr.wikipedia.org/wiki/Principe_KISS) Teuxe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 850000 membres... et autres stats...
Salut Christian, Merci beaucoup pour ces stats ! Je vais poser une question très bête, mais c'est pour être sûr : les stats que tu as donné sur le réseau routier c'est bien seulement pour la France ? a+ Nicolas ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâti et éoliennes
Techniquement c'est une construction, avec une emprise non négligeable au sol. Non seulement le fut mais aussi souvent le gros massif béton qui est au raz du sol ... difficile de ne pas garder le tag building vu la quantité de béton et de ferraille qu'il y a! Du moins pour les grosses éoliennes. Pour les petit modèle en treillis métallique ou avec un fut pas plus gros qu'un lampadaire il me semble pas indispensable de tagger le bati. Pour les pylone électrique je ne sais pas trop, meme les gros on des emprise au sol assez faible vu leur structure a quatre petit pieds et le treilli métallique tres aéré ne fait pas tres batiment. Difficile de tagger les quatre petites fondations béton apparentes puis de retagger un noeuds pylone au milieu! 2012/10/15 Christian Quest cqu...@openstreetmap.fr: Garder ou pas le tag building... on le garde bien sur les châteaux d'eau, je le garderai aussi. Le 15 octobre 2012 11:08, Simon Miniou simon.min...@gmail.com a écrit : je veux bien mettre les infos de l'éolienne sur le bâti mais du coup on considère que l'éolienne fait partie de la catégorie building (avec une valeur yes ou une nouvelle?) ou que l'éolienne est dessiné par un chemin et n'est pas un bâti? Simon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâti et éoliennes
Tetsuo Shima tets...@gmail.com wrote: Techniquement c'est une construction, avec une emprise non négligeable au sol. Non seulement le fut mais aussi souvent le gros massif béton qui est au raz du sol ... difficile de ne pas garder le tag building vu la quantité de béton et de ferraille qu'il y a! Du moins pour les grosses éoliennes. Pour les petit modèle en treillis métallique ou avec un fut pas plus gros qu'un lampadaire il me semble pas indispensable de tagger le bati. Je suis pas du tout d'accord ;-) Building n'a pas le sens bâti mais batiment... La nuance est importante. http://wiki.openstreetmap.org/wiki/Buildings Les balises annexes conseillés sont : height, levels et name... Le wiki conseille d'y indiquer l'entrée (entrance) et l'adresse (addr:street...) Je veux bien qu'une éolienne soit un truc construit, mais l'usage d'un simple point me parait largement suffisant et surtout je vois pas ce qui permettrait de lui appliquer le tag building... Ce n'est pas un batiment, c'est tout au plus un pylone, voir une espèce de tour... [...] Pour les pylone électrique je ne sais pas trop, meme les gros on des emprise au sol assez faible vu leur structure a quatre petit pieds et le treilli métallique tres aéré ne fait pas tres batiment. Difficile de tagger les quatre petites fondations béton apparentes puis de retagger un noeuds pylone au milieu! Pour les pylones électriques là ça me semble encore plus tordu, il existe déjà des tags pour ça et ça fonctionne très bien... L'emprise au sol reste faible et building n'a rien a voir avec l'emprise au sol... http://wiki.openstreetmap.org/wiki/Tag:power%3Dtower Les stats sont élocantes, il y a 3,3 millions de power=tower en simple point et 199 qui ont été représentés par un polygone... C'est plus que marginal comme pratique. -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suivi des modifications : Comment visualiser simplement les objets modifiés ou détruits
Je peste régulièrement contre l'impossibilité de voir vraiment ce qu'a apporté un changeset, donc oui, je pense qu'il y a beaucoup à faire de ce côté là. Il manque : - sur openstreetmap.org, un résumé du changeset comme on l'a sur whodidit avec les nodes/ways/relation créés/modifiés/supprimés. - Des infos plus pertinentes sur l'historique des id, un peu à la manière de Potlatch (création, déplacement de node, ajout de node, way coupé, way étendu, way joint, etc.) - Sur osm ou dans josm, une visualisation graphique de avant/après sur une période, un changeset ou, à défaut, sur un id en particulier. a suivre ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] parking entouré d'une barrière
Le 15 octobre 2012 17:29, te...@free.fr a écrit : Salut Philippe, Une relation sert à regrouper un ensemble de ways connectés ensembles : - Les ways isolément ne représentent alors que des lignes et pas une surface, ils peuvent donc avoir les attributs/tags d'une barrière. - En revanche la relation ignore les attribits des ways membres, et possède ses propres tags pour mentionner ce que désigne la surface. - Toute surface fermée représentable par un way fermé peut être transformée en relation, afin de découper ses ways (et dans ce cas ils ne se ferment plus isolément et ne peuvent pas représenter une surface. C'est plus clair, merci. Dans ce cas, on n'a pas de way fermé (aucun doute way/area) mais des ways unis par une relation, relation qui porte la propriété formée par l'ensemble. Le type multipolygon sert à ça, j'étais au courant. Par défaut toutes les relations qui ont des ways qui se ferment représentent une surface, sauf justement les rivières (avec leurs ways membres de rôle main_stream par défaut, ou side_stream, au contraire des ways membres de rôle riverbank qu'on peut y mettre aussi), et les rues/routes/chemins/pistes (highway=*) pour lesquels on doit encore utiliser area=yes dans la relation si on veut représenter leur surface et non le contour (exemple : les places piétonnes), et les voies ferrées (railway=*) pour lesquelles il n'y a aucun usage d'area=yes actuellement défini.. Alors il y a contradiction avec http://wiki.openstreetmap.org/wiki/Way : par défaut, un way fermé n'est pas une area, sauf si area=yes est fourni. Non, par défaut un way fermé est une surface, sauf pour les highway=*; waterway=* (sauf riverbank), et railway=* qui par défaut sont filaires (et qui justifient alors qu'on mette area=yes dans les très cas rares où il faut changer l'interprétation par défaut de ces éléments comme du filaire) Par exemple tous les way fermés de landuse=*, de riverbank, de natural=* (y compris les coastlines), de boundary, land_area, buildings... sont des surfaces (même si une bordure peut leur être dessinée aussi) et il n'y a même pas besoin de préciser area=yes (et encore moins area=no que je n'ai encore jamais vu justifié dans aucun élément). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâti et éoliennes
Le 15 octobre 2012 17:00, Pieren pier...@gmail.com a écrit : 2012/10/15 Philippe Verdy verd...@wanadoo.fr: Un truc rond qui fait 4 mètres de large n'a aucune chance d'être un bâtiment ou une tour, quel qu'il soit. Si c'est le cas ce n'est qu'une hutte. Je connais une hutte qui fait 20 mètres de haut: http://fr.wikipedia.org/wiki/Fichier:Champ_du_feu.jpg J'ai dit 4 m de === LARGE === (diamètre au sol), peu importe la hauteur d'ailleurs. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suivi des modifications : Comment visualiser simplement les objets modifiés ou détruits
Cf. cette discussion de juillet: http://lists.openstreetmap.org/pipermail/talk-fr/2012-July/045141.html Romain Le 15 octobre 2012 21:25, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : Je peste régulièrement contre l'impossibilité de voir vraiment ce qu'a apporté un changeset, donc oui, je pense qu'il y a beaucoup à faire de ce côté là. Il manque : - sur openstreetmap.org, un résumé du changeset comme on l'a sur whodidit avec les nodes/ways/relation créés/modifiés/supprimés. - Des infos plus pertinentes sur l'historique des id, un peu à la manière de Potlatch (création, déplacement de node, ajout de node, way coupé, way étendu, way joint, etc.) - Sur osm ou dans josm, une visualisation graphique de avant/après sur une période, un changeset ou, à défaut, sur un id en particulier. a suivre __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] parking entouré d'une barrière
2012/10/15 Philippe Verdy verd...@wanadoo.fr: Non, par défaut un way fermé est une surface, sauf pour les highway=*; waterway=* (sauf riverbank), et railway=* qui par défaut sont filaires (et qui justifient alors qu'on mette area=yes dans les très cas rares où il faut changer l'interprétation par défaut de ces éléments comme du filaire) Euh... un waterway fermé avec area=yes ? Il faudrait me donner un exemple concret, même très rare. Pour railway, pareil. Il y avait un cas, celui du railway/highway=platform mais je me suis beaucoup battu pour faire admettre sur le wiki que ça n'était justifié que pour satisfaire Mapnik. Sinon, c'est toujours une surface. (dans le cas d'une plateforme en boucle, elle dessert plusieurs lignes et nécessite plusieurs sections). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 850000 membres... et autres stats...
Oui, juste sur la France (avec des petits débordements aux frontières bien sûr, mais ça doit jouer à la marge). Le 15 octobre 2012 18:10, Nicolas Moyroud nmoyr...@free.fr a écrit : Salut Christian, Merci beaucoup pour ces stats ! Je vais poser une question très bête, mais c'est pour être sûr : les stats que tu as donné sur le réseau routier c'est bien seulement pour la France ? a+ Nicolas ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [osm-fr CA] Rendez vous avec la Direction de l'IGN
Bonsoir, Alors, à chaud comment ça s'est passé? Romain Le 27 septembre 2012 17:53, RatZilla$ ratzil...@gmail.com a écrit : Bonjour à tou[te]s, Mardi dernier au Data Tuesday j'ai invité l'IGN à travailler avec la communauté OSM.Le directeur général lui même a cordialement confirmé son intérêt pour notre beau projet. J'ai reçu une invitation officielle de sa part pour une rencontre lundi 15 octobre. Christian et moi nous rendrons à Saint Mandé pour amorcer les discussions. Nous sommes à votre écoute pour toute remarque ou doléance à remonter à l'IGN ;) C'est un début on avance doucement, mais sûrement ;) Librement, Gaël ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmosea changéde peau
Le 10/10/2012 07:28, Francescu GAROBY écrivait : C'était déjà le cas avant : tout s'affichait si rien était sélectionné. Perso, je suis pas fan : ça fait charger un tas d'infos inutilement (si on veut tout voir, on clique sur tout), et ça peut perturber l'utilisateur, qui se retrouve face à un comportement imprévu. Oui c'est vrai, c'est un vieux bug que je n'ai pas corrigé dans l'évol de la nouvelle peau. Je m'étais bêtement dit : pourquoi aller sur osmose si c'est pour masquer toutes les erreurs, dans ce cas on peut aussi décocher le layer erreurs osmose dans le layer-switcher en haut à droite. ;) -- Nicolas BOUTHORS ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmosea changéde peau
Le 10/10/2012 09:32, Stéphane Péneau écrivait : Dommage qu'il n'y ait pas le petit champs de recherche de lieu qu'on a sur openlayer. C'est dans la todo, version suivante probablement. A ce propos, quel est l'intérêt d'openlayer puisqu'on retrouve les même infos dans osmose ? Est-ce que ce ne serait pas plus judicieux de fusionner les 2 services ? C'est un point de vue ;) -- Nicolas BOUTHORS ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suivi des modifications : Comment visualiser simplement les objets modifiés ou détruits
Il serait intéressant d'adapter le concept de Data Mining où l'on peut cliquer sur un objet pour obtenir de l'info plus détaillée. Dans le Data Mining on peut aller, par exemple, de pays, à région, à ville, etc. Dans le cas qui nous intéresse, il serait possible de visualiser simultanément tous les objets d'un Changeset sur une carte, incluant ceux effacés qui pourraient être grisés. Puis de là, on devrait pouvoir comparer avec une carte montrant l'état précédent dans l'historique. Cela se fait déjà sous forme de tableau pour les attributs et les nodes. Il s'agirait d'adapter ou ajouter la possibilité de visualiser sur carte. Comme outil de suivi, la comparaison de deux cartes serait beaucoup plus efficace que de comparer deux tables listant les nodes. Et lacune particulière, quand un objet est effacé, il est souvent difficile de juste savoir ce qu'il représentait auparavant. Ceci permettrait de repérer beaucoup plus rapidement les grosses gaffes et d'annuler la modification ou corriger. Pierre De : Stéphane Péneau stephane.pen...@wanadoo.fr À : Pierre Béland infosbelas-...@yahoo.fr; Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Lundi 15 octobre 2012 15h25 Objet : Re: [OSM-talk-fr] Suivi des modifications : Comment visualiser simplement les objets modifiés ou détruits Je peste régulièrement contre l'impossibilité de voir vraiment ce qu'a apporté un changeset, donc oui, je pense qu'il y a beaucoup à faire de ce côté là. Il manque : - sur openstreetmap.org, un résumé du changeset comme on l'a sur whodidit avec les nodes/ways/relation créés/modifiés/supprimés. - Des infos plus pertinentes sur l'historique des id, un peu à la manière de Potlatch (création, déplacement de node, ajout de node, way coupé, way étendu, way joint, etc.) - Sur osm ou dans josm, une visualisation graphique de avant/après sur une période, un changeset ou, à défaut, sur un id en particulier. a suivre ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] parking entouré d'une barrière
Le 15 octobre 2012 21:53, Pieren pier...@gmail.com a écrit : 2012/10/15 Philippe Verdy verd...@wanadoo.fr: Non, par défaut un way fermé est une surface, sauf pour les highway=*; waterway=* (sauf riverbank), et railway=* qui par défaut sont filaires (et qui justifient alors qu'on mette area=yes dans les très cas rares où il faut changer l'interprétation par défaut de ces éléments comme du filaire) Euh... un waterway fermé avec area=yes ? Il faudrait me donner un exemple concret, même très rare. Ce que je veux dire c'est que des waterways fermés ne sont pas rares (on en trouve autour des champs) mais ca n 'est pas pour ça qu'il faut les prendre pour des surfaces. L'exception ce sont les waterway=riverbank, qui devraient être fermés (ou dans une relation fermée) et qui sont remplis par défaut (pas besoin de area=yes pour eux, et aucun cas où on aura besin de area=no). Mais justement avec les riverbanks on n'a plus besoin d'autre chose pour les waterways donnant une surface. sinon c'est du water=lake ou équivalent pas du waterway. Pour railway, pareil. Il y avait un cas, celui du railway/highway=platform un rail sur une surface... h... même si tu parles des plateformes tournantes, ce n'est qu'une intersection de rails entre les directions qui peuvent être prises, la surface plateforme elle-même n'est pas ferrée, il y a un rail linaire posé dessus.. Donc pour moi le dernier cas pratique qui reste pour justifier un area=yes c'est la place piétonne (qu'on ne devrait pas marquer comme highway=footway mais comme landuse=*), et ne ne vois pas dans quel cas on a besoin de area=no. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tagger du nucléaire [long]
Le lundi 15 octobre 2012 21:48:33 Philippe Verdy a écrit : Le 15 octobre 2012 13:04, Pierre-Alain Dorange pdora...@mac.com a écrit : Par exemple à coté de chez moi (Cognac) y'a plusieurs usines de cette boisson alcoolisée qui sont en Seveso Bas voir Haut pour certaines, la fiche du ministère ressemble par exemple à ça : http://www.installationsclassees.developpement-durable.gouv.fr/recherch eICForm.php Hennessy Bagnolet Régime Seveso : Seuil AS Priorité nationale : Oui IPPC : Non Nomenclature : 1434.1b, 2250.1, 2250.2, 2251.2, 2255.1, 2920.2b, 2921.2, 2925 A cause de quoi ? Des alambics ou des cuves de fermentation ? Dans le pays du vin, des cuves de fermentation on en a des tonnes un peu partout. Le risque se situe au niveau des milliers de mètre cube de spiritueux en cours de vieillissement qui pourrait être à l'origine d'un violent incendie. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmosea changéde peau
Le 15 octobre 2012 22:00, Nicolas Bouthors ni...@smile.fr a écrit : A ce propos, quel est l'intérêt d'openlayer puisqu'on retrouve les même infos dans osmose ? Est-ce que ce ne serait pas plus judicieux de fusionner les 2 services ? C'est un point de vue ;) A la base il ne devait y avoir que Layers.Openstreemap.fr Osmose se contente ici de reprendre le rendu déjà fait par Layers.OSM.fr, puisque les deux proposent une interface web OpenLayers (comme aussi openstreemap.org pour son rendu Mapnik). Mais c'est vrai que ça donne deux sites web pour les mêmes couches de rendus. Osmose ayant un menu à gauche en plus qui peut gêner certains. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâti et éoliennes
15/10/2012 16:35 Philippe Verdy: Un truc rond qui fait 4 mètres de large n'a aucune chance d'être un bâtiment ou une tour, quel qu'il soit. Et quand c'est carrée, comme celui là: http://www.openstreetmap.org/browse/way/81551822 ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâti et éoliennes
Le 15 octobre 2012 22:29, Rainer Kluge rklug...@web.de a écrit : 15/10/2012 16:35 Philippe Verdy: Un truc rond qui fait 4 mètres de large n'a aucune chance d'être un bâtiment ou une tour, quel qu'il soit. Et quand c'est carrée, comme celui là: http://www.openstreetmap.org/** browse/way/81551822 http://www.openstreetmap.org/browse/way/81551822 ? Ce serait pas un poste de transformation haute tension? Il m'arrive d'en trouver qu'y soit cadastré. Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmosea changéde peau
A ce propos, quel est l'intérêt d'openlayer puisqu'on retrouve les même infos dans osmose ? Est-ce que ce ne serait pas plus judicieux de fusionner les 2 services ? C'est un point de vue ;) Si tous les layers de http://layers.Openstreemap.fr sont repris sur osmose, qu'au final on a les même fonctionnalités que sur layers, j'adhère à l'idée que l'on peut supprimer la page de carte de layers et n'y laisser juste que le générateur de tuiles car cela (me)* fera un truc de moins à maintenir et un meilleur regroupement. (Même que le menu à gauche ne me gênerait pas) *Bon, ok, c'est plus vrai vu que c'est nicolas qui fait tout le boulot, donc à lui de dire. -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [osm-fr CA] Rendez vous avec la Direction de l'IGN
Très bonne réunion de plus d'une heure trente. Nous avons rencontré le directeur général de l'IGN, le dir. adjoint de la diffusion et de la valorisation ainsi que le directeur de la production. Nous avons présenté OSM en une douzaine de slides ce qui a généré quelques questions sur les motivations des contributeurs, cela surprends toujours certaines personnes que l'on puisse être si nombreux à contribuer sans en retirer de bénéfice direct en retour. J'ai senti de l'étonnement à la réponse mais vous êtes combien à valider les contributions... quand j'ai répondu zéro. Une première prise de contact avec beaucoup d'ouverture de la part de la direction de l'IGN qui, je pense, se rend compte que le monde change et qu'ils doivent s'y adapter. Le crowdsourcing les intrigue et les intéresse. Je pense qu'on a aussi réussit à montrer le sérieux du projet, la richesse des données et leur intérêt complémentaire par rapport à ce que fait l'IGN (la donnée de référence). On se revoit d'ici la fin de l'année. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendez vous avec la Direction de l'IGN
Le jeudi 27 septembre 2012 à 18:45 +0200, Eric SIBERT a écrit : Nous sommes à votre écoute pour toute remarque ou doléance à remonter à l'IGN ;) J'insiste : réellement libérer les données libres. Pour le cas des repères géodésiques : possibilité de consulter les fiches de manière automatisée. Voir de disposer d'un moyen d'être informé à chaque mise à jour d'une fiche. Comme ça, on ne sera pas obliger de retélécharger tout le répertoire qu'ils vont mettre à notre disposition chaque semaine :-) Photos aériennes brutes : on veut les photos actuelles, pas celles de 50 ans. Les photos actuelles ont déjà été numérisées pour l'orthophoto donc il n'y a aucune raison technique de ne pas les mettre à disposition. Les photos d'il y a 50 ans sont aussi intéressantes (je travaille sur l'Ariège, de nombreuses zones actuellement boisées ne l'était pas à cette époque, et de vielles photos permettent de voir des chemins qui existent encore mais ne sont plus visible sur les photos actuelles). Mais même les photos anciennes ne sont pas toujours disponibles, ce qui est particulièrement choquant car elles ont été payé par nos grands-parents et devraient à ce titre faire parti du patrimoine commun librement accessible. J'ai d'ailleurs commencé cet été à écrire une application d'orthorectification (MMT ASTER) dont on peut voir un exemple ici (mosaïque à partir de plusieurs images, projeté en Lambert II avec superposition OSM) Pleine résolution (77.7Mb) : http://ubuntuone.com/2qHmVR2SCWu5vYaQ1qHUNI Résolution réduite (7.2Mb) : http://ubuntuone.com/7Dw2byZFNfYNziaRz4QfNc Faire un inventaire des données sous licence libres dont dispose l'IGN. La suite pour les prochaines réunions. Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Quelqu'un de dispo pour l'Ubuntu Party 17-18 novembre à Paris...
Il faudrait animer un exposé de 30-35 minutes pour présenter le projet, suivi (après une pause) d'un atelier pratique de 2h sur comment contribuer... C'est à la Cité des Sciences comme d'habitude. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâti et éoliennes
Ce que je veux dire c'est que les bâtiments du cadastre tout petits de moins de 5 mètres de large dans leur plus grande dimension, pourraient être traités dans une liste à part, à valider de meilleure façon que de les importer par défaut en tant que building (de quoi mieux satisfaire le DWG qui nous reproche ces imports non qualifiés). Cela ne gènerait pas la travail sur les rues et routes, et cela permettrait un travail aussi en plusieurs phases, ces petites constructions nécessitant une visualisation (imagerie Bing) au minimum pour les identifier. Les bâtiments ronds de plus de 5 mètres ont de grrandes chances d'être des châteeaux d'eau ou des tours d'émetteurs, ils sont très repérables et essentiels au repérage sur le terrain, on doit les mettre dans OSM, mais eux aussi devraient être mieux qualifiés. Ils sont assez peu nombreux pour qu'on les mette clairement à part pour qu'ils soient identifiés en priorité même sur les autres constructions. Les petits bâtiments rectangulaires de moins de 5 mètres sont effectivemnt assez souvent des postes de transformation ou petits locaux techniques similaires. Dans certains cas (quand on les trouve dans un terrain résidentiel à côté d'un autre bâtiment) ce sont souvent des garages ou appentis. En milieu rural ce peuvent être des puits. En ville, ce peuvent être des kiosques, des toilettes publiques, des abris bus/taxi en dur. Dans les gares, difficile de savoir ce que c'est entre les bâtiments techniques, postes de transformation, abris, kiosques... Mais je crois que les gares sont déjà très bien cartographiées dans OSM et tout y est bien répertorié, simpelment car ce sont des lieux connus et très visités. Quand le milieu urbain est dense, avec des tas de bâtiments quasi jointifs, l'import en tant que building ne me choque pas, car les immeubles sont à usages multiples et changeants et ce n'est pas plus mal de devoir ensuite les qualifier en positionnant dessus les POIs pour les commerces, le reste étant par défaut résidentiel (les zones landuse peuvent aider à savoir qu'on est en zone résidentielle ou en zone industrielle et commerciale, souvent en périphérie des villes, avec des bâtiments souvent très différents en majorité en constructions métallique plus légère, plus espacés, rarement jointifs entre eux, et avec des tas de parkings autour). Mais comme on travaille normalement sur des imports localisés par quartiers à peu près homogènes, les classifications par défaut pour le gros des constructions peuvent être différentes. Maintenant je DWG ne devrait pas être réellement gêné si les données importées et intégrées n'ont qu'une partie des données qualifiantes. Si elles sont correctes géométriquement et donnent une info utile, le reste sera complété aussi au fur et à mesure par la méthode incrémentale inhérente au projet collaboratif. Il me semble en revanche que ce qu'on demande c'est déviter les doublons et s'assurer de la localisation (donc le bon calage initial des feuilles cadastrales, en vérifiant aussi le calage des l'imagerie, et vérifiant les points géodésiques). Et ne pas laisser des intersections des bâtiments intégrés avec les voies existantes pour que cela soit cohérent en terme de positions relatives des objets (souvent c'est une rue ou route qu'il faudra ajuster avec plus de précision en zone urbaine). Sinon le positionnement ultérieur des POIs sera pénible ou ambigu, ou générera ses propres erreurs (si on doit recaler les bâtiments et rues, que faire des POIs qui ont été mis dessus par collaboration incrémentale ?). Le 15 octobre 2012 22:31, Romain MEHUT romain.me...@gmail.com a écrit : Le 15 octobre 2012 22:29, Rainer Kluge rklug...@web.de a écrit : 15/10/2012 16:35 Philippe Verdy: Un truc rond qui fait 4 mètres de large n'a aucune chance d'être un bâtiment ou une tour, quel qu'il soit. Et quand c'est carrée, comme celui là: http://www.openstreetmap.org/browse/way/81551822 ? Ce serait pas un poste de transformation haute tension? Il m'arrive d'en trouver qu'y soit cadastré. Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import des cantons
Le 15 octobre 2012 21:42, Nicolas Bouthors nicolas.bouth...@smile.fr a écrit : Bonsoir à tous, bonsoir Philippe, Le 15/10/2012 16:46, Philippe Verdy écrivait : Ha, d'ailleurs, si tu avais regardé les liens fournit tu aurais pu y voir une carte sur layer représentant les cantons et les circonscriptions différemment. Mais je veux bien concevoir qu'il était plus judicieux de commencer par râler, par précaution. Ca vient de changer alors. C'est exact. Nous avons ajouté le calque sur Layers rapidement ce midi avec Fred pour proposer un outil de suivi de l'import à venir. Toujours pas visible... Qui m'a dit que je n'ai pas regardé ??? Certes il y a maintenant en plus Cantons et politique (qui mélange cantons et circonscriptions), mais en quoi cette nouvelle couche est différente de l'option juste au dessus boundary_political (qui était ce qu'on avait seulement jusqu'à présent), tout en gardant encore ce qui est la couche boundary_election (vide actuellement car plus utilisée du tout dans la base, boundary=electoral ayant été migré dans OSM vers boundary=political, alors que cela aurait du être logiquement l'inverse !!!) ? En fait ce que j'aurais vu c'est aussi une classification par niveau de ce second découpage parallèle au découpage administratif, avec pour la France un mapping: niveau 3.5 = circonscription européenne (euro_const ? proposé mais pas encore utilisé car mal documenté), niveau 6.5 = circonscription législative, niveau 7.5 = canton. Le plus simple restant en France encore d'utiliser boundary=electoral pour les cantons (il y en a très peu encore, on peut les changer) pour les séparer dans leur calque Layers/Osmose des circonscriptions législatives. Parce que jusqu'à présent (et même encore maintenant) je ne vois pas de sélection possible pour ne voir que les uns ou les autres. Si seule la couleur fait la différence, alors je ne vois pas ces différences de couleur[...] J'accorde facilement que le choix des couleurs est plutôt malheureux, et il y a clairement des moyens d'améliorer la forme. De ce que je lis Philippe tu est bien placé pour suggérer une forme qui permettrait d'avoir un seul calque pour ces deux information en maximisant la lisibilité pour tous. Quel serait à ton avis une bonne stratégie de rendu ? Il suffit de me/nous donner deux couleurs html #XXYYZZ et c'est bon. Ce n'est pas qu'une question de couleur, les cantons sont tout un peu plus petits par rapport aux circonscriptions législatives qui les regroupent par paquets de 4 ou 5 (et les arrondissements qui les regroupent par paquet de 7 ou 8), et cela restera difficile à interpréter. La couleur n'apporte pas une réelle distinction, même si on les distingue. De manière plus globale, les calques de rendu de layers peuvent sans-doute être améliorés facilement par vos conseils z'éclairés à tous ! N'hésitez pas à suggérer des améliorations, voire à carément poster des styles XML mapnik que vous jugeriez nécessaires/amusants/intéressants plutôt que de regretter les (nombreux) manques et défauts des calques actuels. Quant au fond : c'est moi qui ai souhaité regrouper en un calque unique les cantons et les polygones circonscription législatives plutôt que de faire deux calques distincts. Je pense que le rapport entre les deux choses est suffisamment logique pour les faire apparaître ensemble. Pas bon si c'est illisible... Ce nouveau calque (qui vient seulement d'apparaitre, et ce n'est pas faute d'avoir vidé le cache du navigateur avant) n'est absolument pas différent de ce qu'on avait avait dans le calque boundary_political (encore présent), sauf que tu y as changé le mapping des couleurs de remplissage et de bordure (mais pas vraiment de quoi les distinguer facilement), au lieu d'utiliser la même. Bref tu as ajouté un calque, ce qui prend des ressources en plus sur le serveur, sans pourtant créer de distinction réelle. J'aurais plutôt laissé dans la couche boundary_political tout les boundary=political, sauf les cantons que tu distingues dans la nouvelle couche. Dans ce cas le problème de choix des couleurs et de l'accessibilité était accessoire. De la même manière, je suis partisan qu'on regroupe/fusionne certains calques de layers, ou à tout le moins qu'on propose des calques synthétiques (par exemple un calque qui regrouperait les admin-level 6, 7 et 8). Raison à cela : multiplier les calques ne fait que multiplier les ressources utilisées sur les serveurs OSM.fr pour les gérer, et n'ajoute rien à la lisibilité (bien au contraire). Les circonscriptions législatives étant composées de cantons, et les arrondissements étant aussi composés de cantons, comment identifier les trous ? De route façon tu as déjà un calque electoral qui ne sert plus à rien sur le serveur (en terme de ressources serveur pour les tuiles, ce sont déjà des tuiles vierges, autant utiliser cette couche pour les cantons). On peut s'attendre cependant à d'autres découpages
Re: [OSM-talk-fr] Import des cantons
Le 15 octobre 2012 21:42, Nicolas Bouthors nicolas.bouth...@smile.fr a écrit : De la même manière, je suis partisan qu'on regroupe/fusionne certains calques de layers, ou à tout le moins qu'on propose des calques synthétiques (par exemple un calque qui regrouperait les admin-level 6, 7 et 8). Mais pourquoi pas ensemble les niveaux: - 2 (pays), 3 (superrégions ou états d'une fédération, niveau pas utilisé en France mais qui pourrait être celui des ZEAT / NUTS-2 utilisées aussi comme European constituency) ; - 4 (régions) , 5 (pas utilisé en France) - 6 (départements) et 7 (arrondissements) Je garderais le niveau 8 à part (quitte à le regrouper avec les niveaux 9 et 10 optionnels des arrondissements/super-quartiers et des quartiers). Ce niveau 8 est la brique de base OSM pour construire presque tout le reste, d'autant plus que tu y as mis un mapping de couleur variable dessus selon leur nouveauté dans la base, ce qui na facilite pas les distinctions de niveaux (d'autant plus qu'au niveau 9, utilisé par exemple en Belgique pour les sections de communes, ou en Espagne pour les localités d'un municipio, et dans d'autres pays dont les municipalités ont été massivement fusionnées en entités plus grandes pour leur gestion administrative, on n'a pas de distinction facile des noms). Pense aussi à l'Allemagne qui nécessite plein de niveaux, plus qu'en France. Raison à cela : multiplier les calques ne fait que multiplier les ressources utilisées sur les serveurs OSM.fr pour les gérer, et n'ajoute rien à la lisibilité (bien au contraire). Mauvais argument. La lisibilité est pire quand on mélange tout dans le même calque. La couleur n'aide pas plus que les libellés (d'autant plus qu'il n'y a pas de distinction des bordures). C'est tellement simple (et très lisible) de masquer sélectivement un calque selon ce qu'on veut voir ou pas. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâti et éoliennes
À cette taille, 18 nœuds pour un si petit cercle est excessif (ça donne une distance de 69 cm réels entre chaque paire de nœuds qui se suivent avec des angles presque plat de 160 degrés, mais à l'échelle de rendu du niveau de zoom maximum, on ne voit pas la différence des pixels avec un cercle puisque ce n'est même pas un seul pixel d'écart visible entre le polygone obtenu et un cercle idéal — en effet la distance réelle maximale entre une corde du polygone et le cercle parfait, est inférieure aux 10 centimètres critiques de la précision des données de géolocalisation). En témoigne aussi la taille de l'icône d'éolienne qu'on met dessus (avec un pied qui sort malheureusement du cercle puisque l'icône plus grande que le cercle est positionnée sur le centre de son rectangle de définition, et non celle du pied du mat dessiné sur l'icône : Mapnik ne sait pas encore associer à chaque icône un point de référence autre que le centre de son rectangle de définition). 6 ou 8 nœuds suffiraient largement (on en trouve souvent moins pour les rond-points bien plus grands qui pourtant gagneraient à en avoir plus, avec au moins 3 nœuds par direction, donc 12 en tout au minimum pour la plupart d'entre eux, afin de bien raccorder les îlots séparateurs des voies de raccordement). Le 15 octobre 2012 12:02, Simon Miniou simon.min...@gmail.com a écrit : le mât en lui même a un diamètre de 4 m ; peut on considérer qu'une base ou un grand pylône est un bâtiment? (dans le dico, un bâti c'est pas ça !!!) pour l'instant j'ai modifié comme ça : http://www.openstreetmap.org/browse/way/172254302 18 nœuds ça va? (je vérifierai les autres bâti rond que j'ai intégré) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâti et éoliennes
Juste pour infos, cet écart maximum entre le cercle idéal de 4 mètres de diamètre, et une de ses cordes définie par un polygone régulier à 18 côtés est juste de 5,8 cm environ... Et on est TRES loin de positionner les éoliennes (et ce qui les avoisine) avec une telle précision, quand le positionnement n'est souvent qu'à 1 mètre près (on peut toujours affiner sur l'imagerie Bing, à condition qu'elle soit bien orthorectifiée, mais même dans ce cas, l'erreur de géolocalisation est encore voisine de 15 centimètres, trois fois plus que cette erreur de corde polygonale). Si on va voir une éolienne de près sur place, je ne suis même pas sûr que ce soit un cercle aussi parfait (on trouve des mats ovoïdes, profilés en fonction de la direction des plus forts vents dominants). De plus ils sont souvent construits sur des pieds en béton de forme carrée et non ronde ! simplement parce que c'est plus simple de faire le coffrage pour couler ce béton et parce que l'assise est meilleure sans augmentation réelle de l'emprise au sol, le sube ayant un côté parallèle à la voie de service qui le borde) Le 16 octobre 2012 06:21, Philippe Verdy verd...@wanadoo.fr a écrit : À cette taille, 18 nœuds pour un si petit cercle est excessif (ça donne une distance de 69 cm réels entre chaque paire de nœuds qui se suivent avec des angles presque plat de 160 degrés, mais à l'échelle de rendu du niveau de zoom maximum, on ne voit pas la différence des pixels avec un cercle puisque ce n'est même pas un seul pixel d'écart visible entre le polygone obtenu et un cercle idéal — en effet la distance réelle maximale entre une corde du polygone et le cercle parfait, est inférieure aux 10 centimètres critiques de la précision des données de géolocalisation). En témoigne aussi la taille de l'icône d'éolienne qu'on met dessus (avec un pied qui sort malheureusement du cercle puisque l'icône plus grande que le cercle est positionnée sur le centre de son rectangle de définition, et non celle du pied du mat dessiné sur l'icône : Mapnik ne sait pas encore associer à chaque icône un point de référence autre que le centre de son rectangle de définition). 6 ou 8 nœuds suffiraient largement (on en trouve souvent moins pour les rond-points bien plus grands qui pourtant gagneraient à en avoir plus, avec au moins 3 nœuds par direction, donc 12 en tout au minimum pour la plupart d'entre eux, afin de bien raccorder les îlots séparateurs des voies de raccordement). Le 15 octobre 2012 12:02, Simon Miniou simon.min...@gmail.com a écrit : le mât en lui même a un diamètre de 4 m ; peut on considérer qu'une base ou un grand pylône est un bâtiment? (dans le dico, un bâti c'est pas ça !!!) pour l'instant j'ai modifié comme ça : http://www.openstreetmap.org/browse/way/172254302 18 nœuds ça va? (je vérifierai les autres bâti rond que j'ai intégré) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
