Re: [OSM-talk-fr] Extraction parcours cyclable
Le 09/02/2013 10:53, Christian Quest a écrit : Ca c'est ce que t'affiche ton navigateur... mais le contenu complet que tu as reçu (en XML) contient toutes les data... il suffit de visualiser le source de la page. 2013/2/9 Claude claude.mar...@gmail.com: Le 09/02/2013 10:20, Christian Quest a écrit : ou en plus rapide: http://api.openstreetmap.fr/api/0.6/relation/31297/full Bonjour cette url renvoie juste The data included in this document is from www.openstreetmap.org. The data is made available under ODbL. normal? merci cordialement Claude ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Bonjour Effectivement j'avais regardé les sources de la pages mais j'avais pas attendu assez longtemps que les données s'affichent merci Claude -- Envoyé avec Mozilla Thunderbird --- ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise en place d'un miroir OSM
2013/2/9 Christian Quest cqu...@openstreetmap.fr: Ce système de proxy/cache c'est ce que nous avons mis en place sur 2 Je ne ferais pas la promotion de ce proxy/cache tant que le problème de la confidentialité des authentifications ne sera pas résolu. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise en place d'un miroir OSM
Une remarque au sujet de ces stats : l'utilisation des inodes à 30% dépasse largement l'utilisation du volume en terme d'espace (voisin de 8%), cela suggère que les tuiles stockées sont 4 fois trop petites et que le serveur de tuiles devrait soir retourner des tuiles 4 fois plus grandes en surface, soit stocker des tuiles 4 fois plus grandes en surface, quitte à faire un split à la volée (et vu l'usage de la CPU ce complément de travail ne devrait pas lui demander beaucoup d'effort, surtout si le redécoupage à la demande utilise aussi un autre cache disque qui n'a pas besoin d'être très gros non plus). Bref au lieu de stocker des tuiles 256x256, stocker des tuiles 512x512 serait plus optimal, même si le serveur continue de retourner aux clients des tuiles 256x256 (quarts d'image). Si cela ne marche pas (limite de CPU atteinte), un tuning du système de fichiers pour étendre le taux entre la taille de la table des inodes et la taille du volume pourrait être utile, afin de déterminer la bonne taille minimale du système de fichiers à utiliser pour le cache de tuiles. (Dans l'état actuel, ce cache de tuiles précalculées me semble très largement surdimensionné en taille totale de volume, et le serveur semble donc taillé déjà pour accueillir de nouvelles couches de rendu alternatif ; réduire ce système de fichiers à ce qui est suffisant permettrait même des optimisations en terme d'I/O, avec une taille plus réduite de la table d'inodes et de la bitmap d'allocation. D'autres optimisations sont encore possibles : utilisez-vous une config RAID5 pour la sécurité du cache ? Cela ne semble pas utile, aucune de ces données n'est critique, il me semble que la vraie limite sur les iops ne peut être résolue qu'en multipliant le nombre de disques dans la grappe et en utilisant des stripes assez petits pour bien équilibrer les charges entre les disques; des stripes de 4 ou 8Ko seraient suffisants pour les tuiles, plutôt que les classiques stripes de 64Ko, sachant que les tuiles PNG 256x256 ont une taille voisine de 16Ko ; cependant en quadruplant leur surface elles monteraient autour de 64Ko et les stripes monteraient à 16Ko aussi de façon quasi optimale). Reste alors à multiplier les disques en parallèle (pas nécessairement en RAID, on peut aussi les distribuer par un hachage sur une collection de petits systèmes de fichiers chacun sur des disques différents ; le reste des disques pourra servir à faire des volumes RAID pour les données critiques à préserver, mais pas pour les caches de tuiles sur disque, surtout qu'il y a de la marge en plus dans le cache en mémoire avant d'accéder à ces disques ; des baies RAID à 16 disques ne sont pas difficiles à trouver et monter, sur chacun on met un petit bout du cache de tuiles, et un processeur dédié pour les calculer en local, le reste est partagé; et on peut alors utiliser tout le reste des disques pour des tonnes d'autres volumes précieux sur divers agencements RAID entre les disques, par exemple pour la base de données qui prend un temps fou à charger, ou pour les services d'exports de données, les backups systèmes ou pour expérimenter des VMs supplémentaires) Le 9 février 2013 18:54, Christian Quest cqu...@openstreetmap.fr a écrit : Ce système de proxy/cache c'est ce que nous avons mis en place sur 2 de nos serveurs OSM-FR, la version monde tourne dans une VM et n'utilise que 512Mo de RAM (le reste sera utilisé par le cache disque), et 140Go de disque pour la DB. Voici ses stats: http://munin.openstreetmap.fr/osm11.free.org/osm103.openstreetmap.fr/index.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [forum-osm-fr] Ouverture des inscriptions en ligne pour SOTM-FR 2013
Le message suivant de : ## Voilà, les inscriptions sont ouvertes sur eventbrite: http://sotmfr2013.eventbrite.fr/ Une participation aux frais d'organisation de 30 euros est demandée, elle inclu les petits-déjeuner et les pique-nique de samedi et dimanche, ainsi que les goodies. Pour samedi soir, un diner optionnel est organisé. Vous pouvez régler par carte bancaire sur le site eventbrite ou par chèque, voir sur place (avec un supplément de 5 euros). a été posté sur le forum http://forum.openstreetmap.fr/viewtopic.php?f=6t=500 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 meilleures 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] Mise en place d'un miroir OSM
A part le fait que tu es complètement hors sujet dans ce fil de discussion, je suppose que tu t'es monté ton propre serveur de tuiles pour tester. Tu peux nous dire les perfs que tu obtiens pour comparer ? Le dimanche 10 février 2013 à 12:49 +0100, Philippe Verdy a écrit : Une remarque au sujet de ces stats : l'utilisation des inodes à 30% dépasse largement l'utilisation du volume en terme d'espace (voisin de 8%), cela suggère que les tuiles stockées sont 4 fois trop petites et que le serveur de tuiles devrait soir retourner des tuiles 4 fois plus grandes en surface, soit stocker des tuiles 4 fois plus grandes en surface, quitte à faire un split à la volée (et vu l'usage de la CPU ce complément de travail ne devrait pas lui demander beaucoup d'effort, surtout si le redécoupage à la demande utilise aussi un autre cache disque qui n'a pas besoin d'être très gros non plus). Bref au lieu de stocker des tuiles 256x256, stocker des tuiles 512x512 serait plus optimal, même si le serveur continue de retourner aux clients des tuiles 256x256 (quarts d'image). Si cela ne marche pas (limite de CPU atteinte), un tuning du système de fichiers pour étendre le taux entre la taille de la table des inodes et la taille du volume pourrait être utile, afin de déterminer la bonne taille minimale du système de fichiers à utiliser pour le cache de tuiles. (Dans l'état actuel, ce cache de tuiles précalculées me semble très largement surdimensionné en taille totale de volume, et le serveur semble donc taillé déjà pour accueillir de nouvelles couches de rendu alternatif ; réduire ce système de fichiers à ce qui est suffisant permettrait même des optimisations en terme d'I/O, avec une taille plus réduite de la table d'inodes et de la bitmap d'allocation. D'autres optimisations sont encore possibles : utilisez-vous une config RAID5 pour la sécurité du cache ? Cela ne semble pas utile, aucune de ces données n'est critique, il me semble que la vraie limite sur les iops ne peut être résolue qu'en multipliant le nombre de disques dans la grappe et en utilisant des stripes assez petits pour bien équilibrer les charges entre les disques; des stripes de 4 ou 8Ko seraient suffisants pour les tuiles, plutôt que les classiques stripes de 64Ko, sachant que les tuiles PNG 256x256 ont une taille voisine de 16Ko ; cependant en quadruplant leur surface elles monteraient autour de 64Ko et les stripes monteraient à 16Ko aussi de façon quasi optimale). Reste alors à multiplier les disques en parallèle (pas nécessairement en RAID, on peut aussi les distribuer par un hachage sur une collection de petits systèmes de fichiers chacun sur des disques différents ; le reste des disques pourra servir à faire des volumes RAID pour les données critiques à préserver, mais pas pour les caches de tuiles sur disque, surtout qu'il y a de la marge en plus dans le cache en mémoire avant d'accéder à ces disques ; des baies RAID à 16 disques ne sont pas difficiles à trouver et monter, sur chacun on met un petit bout du cache de tuiles, et un processeur dédié pour les calculer en local, le reste est partagé; et on peut alors utiliser tout le reste des disques pour des tonnes d'autres volumes précieux sur divers agencements RAID entre les disques, par exemple pour la base de données qui prend un temps fou à charger, ou pour les services d'exports de données, les backups systèmes ou pour expérimenter des VMs supplémentaires) Le 9 février 2013 18:54, Christian Quest cqu...@openstreetmap.fr a écrit : Ce système de proxy/cache c'est ce que nous avons mis en place sur 2 de nos serveurs OSM-FR, la version monde tourne dans une VM et n'utilise que 512Mo de RAM (le reste sera utilisé par le cache disque), et 140Go de disque pour la DB. Voici ses stats: http://munin.openstreetmap.fr/osm11.free.org/osm103.openstreetmap.fr/index.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christophe Merlet (RedFox) signature.asc Description: This is a digitally signed message part ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Asso OSM-FR : Je VEUX payer ma cotise !
Bonsoir, derrière l'objet un rien provocateur, se cache le besoin de connaître certaines infos sur l'asso. En particulier, les coordonnées du Trésorier et les références du compte bancaire. Comme ça les adhérents n'auront plus besoin de râler, pourront faire des virements et le Trésorier sera tout content de n'avoir pas à gérer des piles de chèques, hein Jeff ? Je n'ai rien trouvé sur les pages relatives à l'asso, en partant de là : http://wiki.openstreetmap.org/wiki/WikiProject_France/OSM-FR mais j'ai peut-être mal cherché. Alors, comment que je paye ma cotise ? Amitiés, -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Asso OSM-FR : Je VEUX payer ma cotise !
Et voila :) http://openstreetmap.fr/adherer Le 10 février 2013 20:37, Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net a écrit : Bonsoir, derrière l'objet un rien provocateur, se cache le besoin de connaître certaines infos sur l'asso. En particulier, les coordonnées du Trésorier et les références du compte bancaire. Comme ça les adhérents n'auront plus besoin de râler, pourront faire des virements et le Trésorier sera tout content de n'avoir pas à gérer des piles de chèques, hein Jeff ? Je n'ai rien trouvé sur les pages relatives à l'asso, en partant de là : http://wiki.openstreetmap.org/**wiki/WikiProject_France/OSM-FRhttp://wiki.openstreetmap.org/wiki/WikiProject_France/OSM-FR mais j'ai peut-être mal cherché. Alors, comment que je paye ma cotise ? Amitiés, -- Jean-Francois Nifenecker, Bordeaux __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Asso OSM-FR : Je VEUX payer ma cotise !
Le 10/02/2013 20:47, Etienne Trimaille a écrit : Et voila :) http://openstreetmap.fr/adherer :-)) -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Asso OSM-FR : Je VEUX payer ma cotise !
Le 10/02/2013 20:47, Etienne Trimaille a écrit : Et voila :) http://openstreetmap.fr/adherer ok, mais je ne trouve pas les coordonnées bancaires :-P Ce serait bien de pouvoir faire des virements. -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Asso OSM-FR : Je VEUX payer ma cotise !
Ne te réjouis pas trop vite, je viens de voir qu'il n'y avait pas le rib, mais que les coordonnées de Jeff ;-) 2013/2/10 Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net Le 10/02/2013 20:47, Etienne Trimaille a écrit : Et voila :) http://openstreetmap.fr/**adherer http://openstreetmap.fr/adherer :-)) -- Jean-Francois Nifenecker, Bordeaux __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Asso OSM-FR : Je VEUX payer ma cotise !
Le 10/02/2013 20:56, Etienne Trimaille a écrit : Ne te réjouis pas trop vite, je viens de voir qu'il n'y avait pas le rib, mais que les coordonnées de Jeff ;-) hé hé... -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Asso OSM-FR : Je VEUX payer ma cotise !
Comme j'ai donné une mauvaise réponse, je me dois de rectifier : http://lists.openstreetmap.org/pipermail/talk-fr/2012-February/040851.html PDF en bas de la page :) Le 10 février 2013 20:58, Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net a écrit : Le 10/02/2013 20:56, Etienne Trimaille a écrit : Ne te réjouis pas trop vite, je viens de voir qu'il n'y avait pas le rib, mais que les coordonnées de Jeff ;-) hé hé... -- Jean-Francois Nifenecker, Bordeaux __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Asso OSM-FR : Je VEUX payer ma cotise !
Le 10/02/2013 21:05, Etienne Trimaille a écrit : Comme j'ai donné une mauvaise réponse, je me dois de rectifier : http://lists.openstreetmap.org/pipermail/talk-fr/2012-February/040851.html PDF en bas de la page :) \o/ - sur le site ? -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import SIG-AEV
Bonsoir, Le 09/02/2013 22:29, Christian Quest a écrit : Pas d'objection pour moi. J'ai les shapefiles d'origine pour regarde si ça vaut le coup et comment intégrer ça à l'existant... Le 9 février 2013 22:05, Vincent de Chateau-Thierry v...@laposte.net a écrit : J'ai reconstitué le jeu de données issu des 2 changesets. Je procèderai au revert (donc à l'effacement des données) demain soir, si pas d'objection. Les données ont été effacées : http://www.openstreetmap.org/browse/changeset/14986567 http://www.openstreetmap.org/browse/changeset/14986799 http://www.openstreetmap.org/browse/changeset/14987004 http://www.openstreetmap.org/browse/changeset/14987207 vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Asso OSM-FR : Je VEUX payer ma cotise !
Avant de publier ce RIB, t'es-tu assuré que ce compte ne permettait pas les virements en sens inverse (depuis ce compte vers un tiers) ? Sinon c'est risqué de publier ce RIB comme ça sur Internet ! A voir avec le Crédit Coopératif, car ce genre de compte publié pour recevoir de l'argent devrait être à part du compte principal (sécurisé et gardé secret) que l'asso utilise pour ses propres paiements. Le 10 février 2013 22:33, Olivier Griffet oliviergriffetli...@gmail.com a écrit : Bonjour à toutes et à tous. @Jean-Francois Nifenecker Voici en pièce-jointe le PDF du RIB ( Coordonnées de la banque de l'Association OpenStreetMap France ). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise en place d'un miroir OSM
Le 10 février 2013 13:44, Christophe Merlet red...@redfoxcenter.org a écrit : A part le fait que tu es complètement hors sujet dans ce fil de discussion, je suppose que tu t'es monté ton propre serveur de tuiles pour tester. Tu peux nous dire les perfs que tu obtiens pour comparer ? Usage purement local et certainement pas comparable en matière de matériel. Je n'ai tout bonnement pas besoin des mêmes performances, le nombre de requêtes à traiter est ridicule en comparaison. Au delà de ça, vous devez savoir comment optimiser le stockage sur vos serveurs, il n'y a de toute façon pas d'urgence de changer quelque chose au vu des ressources utilisées. Mais puisque vous avez donné ces stats pour répondre à la demande de quelqu'un pour lui suggérer de monter un serveur de tuiles, ces stats ne sont utiles que pour montrer les ressources réellement nécessaires. Bref ma réponse restait bien DANS le sujet. Si ce n'est pas le cas, alors même la réponse donnée avant moi au sujet de ces statistiques est également hors sujet. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise en place d'un miroir OSM
En plus mon serveur local n'a pas de table d'inodes puisque son stockage est sous Windows. Le tuning est tout à fait différent, même si c'est du RAID (que j'ai monté en stripes de 64 Ko classiques). Je n'ai pas encore tenté d'augmenter la taille des tuiles stockées (cela demanderait une modif du serveur pour qu'il en retourne des fragments de 256x256 au lieu de la tuile stockée 512x512, et une autre modif du code générant ces tuiles stockées). Ce n'est pas ridicule : rien que pour gérer jusqu'au niveau 12 les tuiles du monde entier, on monte très vite en nombre de fichiers, et cela impose une charge importange sur le système de fichiers si on stocke tout dans le même dossier cache. Répartir les fichiers sur des dossiers multiples aide beaucoup l'OS à gérer les modifications et recherches rapides dans ce dossier (on sait que NTFS devient particulièrement lent à partir du moment où on met plus de 2000 fichiers dans un même dossier, mais on a aussi le même problème avec FAT pour les recherches où c'est le temps d'accès qui devient de plus en plus long, avec une charge supplémentaire sur la taille du cache en mémoire, sans compter aussi des problème de verrous exclusifs lors des modifs par des processus ou threads concurrents). Je n'ai aucune idée de la façon dont vous organisez le stockage sur votre serveur, en terme d'organisation des fichiers. D'une façon générale les système de cache de stockage cherchent à diviser les fichiers en de nombreuses sous-collections (thème déjà abordé concernant le cache JTiles intégré à JOSM qui souffre sévèrement de ce problème de manque d'organisation et qui impose une charge trop importante à l'OS hôte). Ces solutions se retrouvent dans tout bon navigateur Internet (même l'installation la plus simple d'IE crée un cache divisé en au moins 4 ou 5 sous-dossiers avec une distribution pseudo-aléatoire des contenus entre les sous-dossiers ; on a la même solution dans le cache de déploiement Java, et dans les caches des autres navigateurs comme Firefox, Chrome, Opera, ou dans les caches de proxy frontaux comme Squid... Ca demande un peu de tuning si on veut maintenir des collections importantes de fichiers). Le 11 février 2013 04:53, Philippe Verdy verd...@wanadoo.fr a écrit : Le 10 février 2013 13:44, Christophe Merlet red...@redfoxcenter.org a écrit : A part le fait que tu es complètement hors sujet dans ce fil de discussion, je suppose que tu t'es monté ton propre serveur de tuiles pour tester. Tu peux nous dire les perfs que tu obtiens pour comparer ? Usage purement local et certainement pas comparable en matière de matériel. Je n'ai tout bonnement pas besoin des mêmes performances, le nombre de requêtes à traiter est ridicule en comparaison. Au delà de ça, vous devez savoir comment optimiser le stockage sur vos serveurs, il n'y a de toute façon pas d'urgence de changer quelque chose au vu des ressources utilisées. Mais puisque vous avez donné ces stats pour répondre à la demande de quelqu'un pour lui suggérer de monter un serveur de tuiles, ces stats ne sont utiles que pour montrer les ressources réellement nécessaires. Bref ma réponse restait bien DANS le sujet. Si ce n'est pas le cas, alors même la réponse donnée avant moi au sujet de ces statistiques est également hors sujet. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Asso OSM-FR : Je VEUX payer ma cotise !
N'ayant jamais eu d'accès en ligne à la banque il est difficile pour moi de suivre les virements et d'actualiser Galette. c'est pour cela que je n'ai pas diffusé le RIB tant que je n'avais d'accès pour suivre les mouvements. Jeff Le dimanche 10 février 2013 à 20:55 +0100, Jean-Francois Nifenecker a écrit : Le 10/02/2013 20:47, Etienne Trimaille a écrit : Et voila :) http://openstreetmap.fr/adherer ok, mais je ne trouve pas les coordonnées bancaires :-P Ce serait bien de pouvoir faire des virements. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] D'une usine a stub proposed
Bonjour, Je vous parle à propos de http://osm.org/go/0ApGprud2--, l'endroit nommé La Cartonnerie. Voici comment cet endroit était lorsque la google car y est passe : http://goo.gl/maps/XYSid Et voici comment l'endroit est en réalité aujourd'hui : http://flic.kr/p/dTZ5M1 ! J'ai passé les landuses de construction à brownfield. http://www.openstreetmap.org/browse/changeset/14954632 http://wiki.openstreetmap.org/wiki/Brownfield Cependant, on voit, si on parcourt les données de la carte, que ce terrain, qui parait constitué d'un seul bloc, est en fait constitué de 4 parcelles - merci au cadastre, je suppose. Ces parcelles n'ont aucune réalité sur le terrain ; de plus, le nom Cartonnerie n'est attaché sur la carte qu'à une seule de ces parcelles, alors qu'il concerne tout le terrain. Je m'étais dit que pour ce cas j'allais constituer ma PREMIÈRE RELATION, pour regrouper toutes ces parcelles ! Ne sachant trop que mettre comme type de relation, je subbodore que site http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site#Examples_of_sitesest celle qui va bien, mais malheureusement, c'est une Proposed Feature... ? Déjà que brownfleld était une page stub, ce qui m'a bien perturbé, si en pllus j'utilise une proposed feature... j'aurai donc tagué un espace vide en Stub Proposed Feature comme relation ??? Que faire, que penser, que dire ? Merci. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] D'une usine a stub proposed
Bonjour, Je te propose une solution plus simple: - Tu regroupes les polygones (Outils/Joindre les zones superposées (Maj-J). - Tu le nettoies un peu (nœuds inutiles, ajuster les bords, ...) - et tu supprimes ou ajoute les tags qui vont bien sur le polygone. Ou alors, tu supprimes ce qui n'existe plus. Et tu ajoutes ce qui y est maintenant. A+ Cedric Le 11/02/2013 08:38, Ista Pouss a écrit : Bonjour, Je vous parle à propos de http://osm.org/go/0ApGprud2--, l'endroit nommé La Cartonnerie. Voici comment cet endroit était lorsque la google car y est passe : http://goo.gl/maps/XYSid Et voici comment l'endroit est en réalité aujourd'hui : http://flic.kr/p/dTZ5M1 ! J'ai passé les landuses de construction à brownfield. http://www.openstreetmap.org/browse/changeset/14954632 http://wiki.openstreetmap.org/wiki/Brownfield Cependant, on voit, si on parcourt les données de la carte, que ce terrain, qui parait constitué d'un seul bloc, est en fait constitué de 4 parcelles - merci au cadastre, je suppose. Ces parcelles n'ont aucune réalité sur le terrain ; de plus, le nom Cartonnerie n'est attaché sur la carte qu'à une seule de ces parcelles, alors qu'il concerne tout le terrain. Je m'étais dit que pour ce cas j'allais constituer ma PREMIÈRE RELATION, pour regrouper toutes ces parcelles ! Ne sachant trop que mettre comme type de relation, je subbodore que site http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site#Examples_of_sites est celle qui va bien, mais malheureusement, c'est une Proposed Feature... ? Déjà que brownfleld était une page stub, ce qui m'a bien perturbé, si en pllus j'utilise une proposed feature... j'aurai donc tagué un espace vide en Stub Proposed Feature comme relation ??? Que faire, que penser, que dire ? Merci. ___ 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
