Re: [OSM-talk-fr] Bilan opendata RATP... (Christian Quest)
Peut être que l'on peut dire Une espèce d'espace ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti
Le 15/08/2012 08:28, Vincent de Chateau-Thierry a écrit : Bonjour, Le 14/08/2012 23:48, Plop76 a écrit : Typiquement, je m'intéresse à ces petites villes : http://www.openstreetmap.org/browse/changeset/12166522 et on arrive déjà à 8000 nœuds et 1300 chemins... J'aurais pu envoyer les modifications dans plusieurs changesets, mais ça aurait été purement artificiel puisque localement toute la zone était déjà effectuée. Je peux te proposer ce script : http://wiki.openstreetmap.org/wiki/User:Vincent_95/Outils/Split qui sert justement à morceler un gros fichier de buildings pour travailler par zones plus petites/légères, et les uploader séparément les unes des autres. Quand je m'en sers, mon seuil est de parvenir à des fichiers bruts de moins de 1 Mo. Si tu te veux/peux pas t'en occuper, je peux le faire tourner sur un fichier qui t'intéresse, et t'envoyer le résultat. Quelle est la licence de ce splitter ? Le must c'est une AGPLv3 selon moi, mais toute licence libre sera la bienvenue :-) Si la licence le permet, je l'ajouterai à l'interface de cadastre.openstreetmap.fr et éventuellement l'appliquerai d'autorité pour les fichiers trop volumineux (10Mo par exemple) Philippe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bilan opendata RATP...
Ca marche chez moi mais par sécurité j'ai modifié le zoom. Le 15 août 2012 21:48, Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net a écrit : Le mardi 14 août 2012 19:00:48 Christian Quest a écrit : J'ai écrit un billet de blog sur l'intégration que j'ai fait des stations du réseau ferré RATP la semaine passée. N'hésitez pas à signaler les fotes d'autograf ou d'autres remarques. Ton troisième lien XAPIViewer ne fonctionne pas chez moi car l'emprise est trop grande. Si on zoome 2 coups et attend le chargement des données, on peut alors dézoomer et voir tous les points. En fait la requête XAPI demande une emprise supérieure à la zone visible (tampon). Après, ça passe peut-être si la fenêtre n'est pas trop grande … -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ 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] Import bâti
Le 16/08/2012 08:50, Philippe Pary a écrit : Si la licence le permet, je l'ajouterai à l'interface de cadastre.openstreetmap.fr et éventuellement l'appliquerai d'autorité pour les fichiers trop volumineux (10Mo par exemple) Philippe +1, une très bonne idée ;) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti
Effectivement la solution c'est de faire une sélection rectangulaire dans JOSM et utiliser la fonction envoyer la sélection : on a un récapitulatif du nombre d'objets ajoutés/modifiés/supprimés qui vont être envoyés dans le changeset, ce qui permet de choisir une sélection plus petite. On peut donc facilement réduire le changeset. Je pense même qu'on devrait avoir quelquechose dans JOSM pour limiter la taille de l'envoi, afin qu'un changeset trop gros (trop d'objets) puisse être envoyé en divisant horizontales ou verticales la bounding box de tous les objets (sur la taille la plus grande) en 2 successivement en 2 moitiés, afin d'envoyer des zones rectangulaires. L'autre méthode basée sur un simple compteur qui s'arrête quand le nombre d'objets maximum a été envoyé produira des changesets moins lisibles car partiellement incomplets et qui poseront plus de conflits à résoudre car les objets à envoyer couvriront aléatoirement une zone plus étendue. Si JOSM n'est pas modifié, on pourrait envisager la création d'un plugin afin d'expérimenter cette méthode d'envoi de changesets partiels, avant que cela devienne la méthode standard, où la seule configuration possible serait d'indiquer le nombre d'objets maximum à envoyer (le plugin s'occupant tout seul de découper la box en zones rectangulaires par divisions successives de la bounding box jusqu'à ce que le plafond d'objets ne soit pas dépassé) On peut réutiliser le même commentaire d'envoi pour les changesets succesifs, mais ils devraient chacun couvrir des bounding box qui se recouvrent le moins possible ce qui permet de les distinguer (cela facilite aussi le travail en cas de revert d'un changeset pour réparer une zone). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti
tracer un polygone artificiel n'est pas très pratique s'il est ajouté avec la sélection générée. De plus on risque de l'oublier en passant à la zone suivante. car il faudra le supprimer. A mon avis il est plus pratique de sélectionner un objet existant réel (par exemple une relation boundary. Mais comme l'import du bâti se fait à priori commune par commune et qu'il est rare qu'on ait cartographié des boundaries plus petites que la commune entière (les planches cadastrales ne sont pas nécessairement coupées sur des limites administratives) on n'a pas toujours une relation significative servant de bounding box. La méthode par sélection rectangulaire sera plus souple. Quand on croit avoir fini toutes les sélections rectangulaire, on essaye juste alors de faire un envoi normal pour voir combien d'objets qui auraient été oubliés par les sélections successives. Et on fait l'envoi de ce dernier changeset en envoyant tout normalement Le 15 août 2012 13:31, Christian Quest cqu...@openstreetmap.fr a écrit : Donc tracer un polygone, pour sélectionner des objets dedans, puis le supprimer après... ok, pas des plus pratique, mais c'est déjà bien ! Le 15 août 2012 13:09, Vincent Privat vincent.pri...@gmail.com a écrit : Yes ça marche ! Il faut d'abord sélectionner un polygone puis Selection - All Inside (Alt-Shift-I) -- 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] Import bâti
Le 16 août 2012 11:27, Philippe Verdy verd...@wanadoo.fr a écrit : tracer un polygone artificiel n'est pas très pratique s'il est ajouté avec la sélection générée. De plus on risque de l'oublier en passant à la zone suivante. car il faudra le supprimer. C'est pour ça que j'ai mis pas des plus pratique. Le plugin qui ajoute cette fonction devrait juste être modifié pour supprimer le polygone si il n'a aucun attribut et un id nul (nouvel objet)... comme ça on trace (temporairement) et on sélectionne... en attendant un vrai outil de sélection par polygone (une modification du lasso pourrai se faire). -- 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] Bilan opendata RATP... (Christian Quest)
J'ai terminé de compléter les liens wikipédia. Ils toutes les stations métro et RER sont maintenant liées à leur article wikipédia respectif. Prochaine étape... vérifier l'harmonie des noms... -- 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] Bilan opendata RATP... (Christian Quest)
Tant qu’à être précis… Devant les ponctuations hautes, on ajoute l’espace insécable ; entre les guillemets français et le texte qu’ils entourent il faut aussi cette espace insécable, les puristes préféreront l’espace fine insécable. Ceci dit, peut-être qu’on peut considérer que le type d’espace, voire même les espaces autour des ponctuations relèvent de la mise ne forme et pas de la donnée, ainsi pourrait-on laisser le soin de remplacer ces mises en forme aux moteurs de rendu ? Le 16 août 2012 08:07, Ista Pouss ista...@gmail.com a écrit : Peut être que l'on peut dire Une espèce d'espace ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Cordialement, -- Mikaël Cordon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bilan opendata RATP... (Christian Quest)
Le 15 août 2012 19:03, Éric Piel e.a.b.p...@tudelft.nl a écrit : On 15/08/12 18:01, Pieren wrote: 2012/8/15 Vincent Pottier vpott...@gmail.com: http://fr.wikipedia.org/wiki/Espace_typographique#cite_ref-L148-149_0-0 (ça, ça valait plus que 0,02 €. Non ?) Je cite le wiki: L'Académie française classe ce mot dans le genre masculin, le féminin ne désignant que la pièce de métal servant à l'imprimerie.. Alors comme moi, mon clavier est en plastique et pas en plomb avec une feuille de papier en dessous, je dis un espace. Désolé pour les puristes, les snobs du langage et les nostalgiques de Gutenberg. Pour continuer dans le chipotage, je citerai le reste de la page wiki: Le mot espace est féminin pour désigner le caractère, c'est-à-dire l'élément physique, caractère en plomb ou électronique (suite de bits) [...]. Donc, c'est plutôt une lorsque l'on parle d'insérer un caractère dans un texte, y compris électronique. La définition dans le wiktionnaire suit cette idée: http://fr.wiktionary.org/wiki/espace Je suis aussi d'accord là-dessus. Même si on n'utilise plus la caractères en plomb, en typographie le caractère désignant une espace est féminin, pour le distinguer des autres formes d'espaces (par exemple l'intervalle inclus dans le caractère avant et après son œil, et qui s'inclut donc dans sa chasse incompressible, ainsi que les espaces (qui sont eux au masculin) de justification ajoutés entre les caractères (y compris à droite ou à gauche de la chasse d'une espace). La tradition du féminin persiste dans l'expression une espace fine (souvent abrégé en disant une fine) : c'est ce type d'espace (féminin) qui est normalement accolé avant ou après une ponctuation, même si ici on code seulement une espace standard. Cette fine est normalement d'une chasse moins large qu'une espace standard (de l'ordre de la moitié) et est également insécable. En Unicode la fine est codée NARROW NON-BREAKING SPACE (NNBSP), mais on utilise souvent la version non NARROW avec le code U+00A0 (NBSP) dans une page HTML (pour éviter des problèmes de rendus avec certaines polices ou moteurs de rendus qui ne supportent pas NNBSP), mais si on fait un document final (Docx ou PDF par exemple) c'est bien NNBSP qu'on doit utiliser (soit avec la bonne police, soit en réduisant la taille de police courante entre 50 et 67% autour du caractère NBSP, par une opération de substitution automatique ou une feuille de style contextuelle cachant traiter spécialement des caractères spécifiques comme NNBSP). En pratique toutefois, les logiciels de préparation typographiques (pas les navigateurs web) savent automatiquement réduire la chasse d'un NBSP accolé à une ponctuation (comme avant les deux-points ou du côté intérieur des guillemets). Les logiciels utilisés par la presse écrite ou les éditeurs de livres savent saisir directement et distinctement les fines. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tags adresses
Je suis le seul à trouver ça assez embêtant d'avoir plusieurs méthodes? Du coup j'ai cartographié assez peu de numéro depuis que j'ai constaté cet état de fait. Y'a vraiment aucune méthode privilégiée? 2012/8/15 Christian Quest cqu...@openstreetmap.fr Lorsqu'à la même adresse on a plusieurs commerces, ceux si sont souvent positionné séparément, car chaque commerce est à un emplacement différent (tant qu'on reste en 2D). Ils sont dans le même bâtiment qui lui a une adresse, liée plus ou moins à la parcelle cadastrale. C'est parce que le commerce est dans ce bâtiment qu'il a cette adresse... je préfère donc avoir des données qui collent au plus près de cette réalité, c'est à dire mettre l'adresse sur le bâtiment, pas sur le commerce. C'est à une échelle différente la même logique que le is_in. D'ailleurs, dans la majorité des cas addr:city, addr:postcode et addr:country ne sont pas indiqués systématiquement car ils se déduisent, addr:street et addr:housenumber peuvent aussi se déduire donc pas plus de raison suffisante pour moi pour les doublonner. Peut être d'ailleurs qu'un nouveau type de relation pourrait permettre de faire le regroupement si il y a ambiguité (absence de bâtiment par exemple, position différente entre le POI et sa boite à lettre, son entrée piéton voiture ou livraison, etc). Le risque à tagguer les adresses sur les POI c'est qu'un déplacement de POI déplace l'adresse... or déplacer un commerce est tout à fait envisageable, déplacer une adresse ou un bâtiment beaucoup moins. Le 15 août 2012 12:04, Romain MEHUT romain.me...@gmail.com a écrit : Le 14 août 2012 18:52, Christian Quest cqu...@openstreetmap.fr a écrit : Peut être mais ça n'est qu'une seule et même adresse. Si ces différents addr:housenumber figurent sur des noeuds qui ont des positions différentes... laquelle est la position de l'adresse ? Ben la position de chaque noeud. Un postier aura besoin de savoir la position de chaque boite aux lettres, non? -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Je soutiens le Logiciel Libre, j'adhère à l'APRIL ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Wiki et système de traduction semi-automatisé
L'extension n'est pas faite pour traduire TOUTE une page wiki mais au maximum un paragraphe. On prépare la page à traduire en la marquant avec des commentaires spéciaux marquant les zones successives à traduire pour lui donner un nom de ressource. La forme resource/fr en sous-pages sera alors utilisée et ira renseigner l'espace de nommage Mediawiki: mais la page traduite complète générée par l'outil restera de la forme FR:nom de page. En effet on ne peut pas naviguer facilement dans l'espace de nommage spécial Mediawiki: Le 15 août 2012 19:45, David Crochet david.croc...@online.fr a écrit : Bonjour Je reviens sur l'idée que j'ai balancé ici sur la gestion semi-automatisé de traduction des pages du wiki. L'extension est celle-ci et vous y trouver (en anglais bien entendu) l'explication du fonctionnement de cette extension : https://www.mediawiki.org/wiki/Help:Extension:Translate cela impose des contraintes : - 1 langue doit être défini comme langue de base, et c'est à partir de celle-ci que les autres seront traduites : Donc si une modification doit être apporté, elle est faite dans la page de la langue défini comme base - le format de la page traduite est (a priori) /page/langue donc les pages de type : FR:tag:amenty deviendront alors de la forme tag:amenty/fr. Je me renseigne pour savoir sir le format actuel pourrait être conserver. et ce site utilise cette extension, donc vous pouvez voir comment cela se passe directement sur ladite page : -- Cordialement David Crochet http://fr.wikiversity.org : Communauté pédagogique libre à laquelle chacun peut prendre part ! http://www.wikimedia.fr : Aidons la diffusion de la connaissance libre ___ 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] Wiki et système de traduction semi-automatisé
Bonjour Le 16/08/2012 11:51, Philippe Verdy a écrit : L'extension n'est pas faite pour traduire TOUTE une page wiki mais au maximum un paragraphe. Donc, si je comprend bien, on sélectionne à partir de la page maître les sections autorisées à être traduites par les autres langues. Donc le système permet d'avoir un section de la langue d'origine qui n'as pas besoin d'être traduites, mais est-ce qu'elle apparaît quand même non traduites dans les pages des autres langues ? Et est-ce que ce système permet à une langues d'ajouter une section spécifique uniquement pour cette langue ? On prépare la page à traduire en la marquant avec des commentaires spéciaux marquant les zones successives à traduire pour lui donner un nom de ressource. Oui, c'est ce que j'ai vu sur le site mediawiki justement [1] La forme resource/fr en sous-pages sera alors utilisée et ira renseigner l'espace de nommage Mediawiki: mais la page traduite complète générée par l'outil restera de la forme FR:nom de page. En effet on ne peut pas naviguer facilement dans l'espace de nommage spécial Mediawiki: « Mediawiki: » ? hum, ce ne serait pas plutôt « Translations: » ? [1] https://www.mediawiki.org/w/index.php?title=Help:Extension:Translateaction=edit -- Cordialement David Crochet http://fr.wikiversity.org : Communauté pédagogique libre à laquelle chacun peut prendre part ! http://www.wikimedia.fr : Aidons la diffusion de la connaissance libre ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tags adresses
Même si il n'y en a aucune de privilégiée, il ne faut pas se restreindre pour cette raison. On pourra toujours tout basculer automatiquement vers l'un ou l'autre. Il faut juste que les ré-utilisateurs connaissent les 2 méthodes actuellement employée. Il y a d'autres exemple où le tag a évolué. Prend l'exemple de public_transport... il y a la méthode lourde, et la méthode ancienne plus light. La lourde indique bien qu'il faut considérer la light par des équivalences. Le 16 août 2012 11:50, Tenshu ten...@gmail.com a écrit : Je suis le seul à trouver ça assez embêtant d'avoir plusieurs méthodes? Du coup j'ai cartographié assez peu de numéro depuis que j'ai constaté cet état de fait. Y'a vraiment aucune méthode privilégiée? 2012/8/15 Christian Quest cqu...@openstreetmap.fr Lorsqu'à la même adresse on a plusieurs commerces, ceux si sont souvent positionné séparément, car chaque commerce est à un emplacement différent (tant qu'on reste en 2D). Ils sont dans le même bâtiment qui lui a une adresse, liée plus ou moins à la parcelle cadastrale. C'est parce que le commerce est dans ce bâtiment qu'il a cette adresse... je préfère donc avoir des données qui collent au plus près de cette réalité, c'est à dire mettre l'adresse sur le bâtiment, pas sur le commerce. C'est à une échelle différente la même logique que le is_in. D'ailleurs, dans la majorité des cas addr:city, addr:postcode et addr:country ne sont pas indiqués systématiquement car ils se déduisent, addr:street et addr:housenumber peuvent aussi se déduire donc pas plus de raison suffisante pour moi pour les doublonner. Peut être d'ailleurs qu'un nouveau type de relation pourrait permettre de faire le regroupement si il y a ambiguité (absence de bâtiment par exemple, position différente entre le POI et sa boite à lettre, son entrée piéton voiture ou livraison, etc). Le risque à tagguer les adresses sur les POI c'est qu'un déplacement de POI déplace l'adresse... or déplacer un commerce est tout à fait envisageable, déplacer une adresse ou un bâtiment beaucoup moins. Le 15 août 2012 12:04, Romain MEHUT romain.me...@gmail.com a écrit : Le 14 août 2012 18:52, Christian Quest cqu...@openstreetmap.fr a écrit : Peut être mais ça n'est qu'une seule et même adresse. Si ces différents addr:housenumber figurent sur des noeuds qui ont des positions différentes... laquelle est la position de l'adresse ? Ben la position de chaque noeud. Un postier aura besoin de savoir la position de chaque boite aux lettres, non? -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Je soutiens le Logiciel Libre, j'adhère à l'APRIL ! ___ 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] Import bâti
J'ai créé un ticket de proposition d'amélioration: http://josm.openstreetmap.de/ticket/7967 -- 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] Tags adresses
Il n'y a pas que le postier qui s'intéresse aux numéros, et même lui . Pour une livraison à domicile ou pour recevoir un recommandé, ou pour savoir où aller quand on est invité quelque part, la position de la boîte n'est franchement pas idéale. La position du numéro se met donc à l'entrée ou au point d'accès principal, sur la limite entre l'espace public et l'espace privé (pas forcément non plus la porte d'entrée qui nécessite pour y arriver d'emprunter un chemin privé ou traverser un jardin, dans ce cas c'est au début de ce chemin qu'on met le point d'adresse), plutôt qu'à celle de la boite aux lettres (d'autant plus que souvent les boites aux lettres sont regroupées pour plusieurs numéros dans les résidences comportant plusieurs immeubles, et d'autre part ces boites peuvent être placées dans les parties communes d'un emplacement privé). Le 15 août 2012 12:04, Romain MEHUT romain.me...@gmail.com a écrit : Le 14 août 2012 18:52, Christian Quest cqu...@openstreetmap.fr a écrit : Peut être mais ça n'est qu'une seule et même adresse. Si ces différents addr:housenumber figurent sur des noeuds qui ont des positions différentes... laquelle est la position de l'adresse ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] MissingCommunes à nouveau opérationnel
Le 25 juin 2012 16:09, Cyrille Giquello cyrill...@gmail.com a écrit : Salut, Juste pour prévenir que j'ai mis en mode maintenance le petit service MissingCommunes car les données n'étaient plus à jour suite au problème rencontré sur le serveur OSM8.openstreetmap.fr qui semble alimenter les données d'OSM7 qui sert de base à MissingCommunes. A suivre donc. Salut Voilà le site est reactivé. Merci Nicolas ! http://lab.cyrille.giquello.fr/carto/CommunesDB/web/MissingCommunes Cyrille. -- Cyrille. -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] MissingCommunes à nouveau opérationnel
Visiblement le script détecte correctement les communes récemment ajoutées, mais PAS leur admin_center qui est pourtant bel et bien présent dans les relations (il y a trop de points bleus sur la carte, qui devraient être verts) ! Le 16 août 2012 12:12, Cyrille Giquello cyrill...@gmail.com a écrit : Le 25 juin 2012 16:09, Cyrille Giquello cyrill...@gmail.com a écrit : Salut, Juste pour prévenir que j'ai mis en mode maintenance le petit service MissingCommunes car les données n'étaient plus à jour suite au problème rencontré sur le serveur OSM8.openstreetmap.fr qui semble alimenter les données d'OSM7 qui sert de base à MissingCommunes. A suivre donc. Salut Voilà le site est reactivé. Merci Nicolas ! http://lab.cyrille.giquello.fr/carto/CommunesDB/web/MissingCommunes Cyrille. -- Cyrille. -- Cyrille. ___ 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] MissingCommunes à nouveau opérationnel
Visiblement cet outil n'est pas le seul affecté (c'est le cas aussi de Layers.Openstreetmap.fr), on dirait bien que XAPI oublie des tas d'objets récents et ne se synchronise plus correctement (il manque aussi des nouvelles communautés de communes, des cantons, un arrondissement, des communes corrigées dont la relation oubliait certains ways). Malgré la date de mise à jour indiquée par ces outils (dans les 30 dernières minutes) pour les données XAPI, il ne figure aucun des ajouts et corrections effectuées dans la base OSM depuis au moins une grosse semaine. Le 16 août 2012 12:36, Philippe Verdy verd...@wanadoo.fr a écrit : Visiblement le script détecte correctement les communes récemment ajoutées, mais PAS leur admin_center qui est pourtant bel et bien présent dans les relations (il y a trop de points bleus sur la carte, qui devraient être verts) ! Le 16 août 2012 12:12, Cyrille Giquello cyrill...@gmail.com a écrit : Le 25 juin 2012 16:09, Cyrille Giquello cyrill...@gmail.com a écrit : Salut, Juste pour prévenir que j'ai mis en mode maintenance le petit service MissingCommunes car les données n'étaient plus à jour suite au problème rencontré sur le serveur OSM8.openstreetmap.fr qui semble alimenter les données d'OSM7 qui sert de base à MissingCommunes. A suivre donc. Salut Voilà le site est reactivé. Merci Nicolas ! http://lab.cyrille.giquello.fr/carto/CommunesDB/web/MissingCommunes Cyrille. -- Cyrille. -- Cyrille. ___ 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] MissingCommunes à nouveau opérationnel
Le 16/08/2012 12:53, Philippe Verdy a écrit : Visiblement cet outil n'est pas le seul affecté (c'est le cas aussi de Layers.Openstreetmap.fr), on dirait bien que XAPI oublie des tas d'objets récents et ne se synchronise plus correctement (il manque aussi des nouvelles communautés de communes, des cantons, un arrondissement, des communes corrigées dont la relation oubliait certains ways). Ce n'est pas comme ça que ça marche. Malgré la date de mise à jour indiquée par ces outils (dans les 30 dernières minutes) pour les données XAPI, il ne figure aucun des ajouts et corrections effectuées dans la base OSM depuis au moins une grosse semaine. Rien a voir. Mais effectivement, il y un problème avec la bases osmosis de osm7 qui ne se met plus à jour. http://munin.openstreetmap.fr/pole-aquinetic.fr/osm7.openstreetmap.fr/osm_replication_lag_osmosis.html Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] MissingCommunes à nouveau opérationnel
De même, est-il possible dans l'outil sur l'état des communes qu'on y indique aussi les autres collectivités ou subdivisions et regroupements dont elle fait partie ? - canton(s) - arrondissement - département - région - EPCI à fiscalité propre (ME, CU, CA, CC, SAN) - autres EPCI ? (SIVU, SIVOM, syndicats de pays) - académie et zones scolaires, zone hospitalière, arrondissement judiciaire (tribunal d'instance ?), arrondissement de police ? http://openstreetmap.fr/outils/etat-commune Le 16 août 2012 12:53, Philippe Verdy verd...@wanadoo.fr a écrit : Visiblement cet outil n'est pas le seul affecté (c'est le cas aussi de Layers.Openstreetmap.fr), on dirait bien que XAPI oublie des tas d'objets récents et ne se synchronise plus correctement (il manque aussi des nouvelles communautés de communes, des cantons, un arrondissement, des communes corrigées dont la relation oubliait certains ways). Malgré la date de mise à jour indiquée par ces outils (dans les 30 dernières minutes) pour les données XAPI, il ne figure aucun des ajouts et corrections effectuées dans la base OSM depuis au moins une grosse semaine. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] MissingCommunes à nouveau opérationnel
Le 16 août 2012 13:08, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Mais effectivement, il y un problème avec la bases osmosis de osm7 qui ne se met plus à jour. http://munin.openstreetmap.fr/pole-aquinetic.fr/osm7.openstreetmap.fr/osm_replication_lag_osmosis.html Donc effectivement plus rien n'est pris en compte depuis le 10 août sur OSM7. OSM8 a peut-être été remis en route, mais ne voit pratiquement rien si ses données viennent encore d'Osmosis sur OSM7. Je me demandais pourquoi aucune de mes corrections depuis plus d'une semaine n'apparaissait. Les statistiques indiquent un lag depuis depuis le 10 août, mais il y a encore des données en retard datant de plusieurs jours avant (au moins j'en vois encore du 3 août qui ne sont toujours pas prises en compte). Bref, les statuts doivent être interrogés un par un (pour ça j'utilise OSM Inspector qui donne des liens comme analyse1 (et là son analyse XAPI est à jour dans la minute elle interroge directement la base OSM sans aucun lag) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tags adresses
2012/8/16 Christian Quest cqu...@openstreetmap.fr: Même si il n'y en a aucune de privilégiée, il ne faut pas se restreindre pour cette raison. On pourra toujours tout basculer automatiquement vers l'un ou l'autre. Il faut juste que les ré-utilisateurs connaissent les 2 méthodes actuellement employée. Comme souvent dans OSM, les deux méthodes présentent des avantages et inconvénients (que je pourrais lister sur demande). C'est pourquoi personne ne pousse pour en supprimer une des deux. Maintenant, certains préfèrent adopter la méthode la plus populaire. Pour le savoir, on peut utiliser les stats de taginfo (qui est faire pour ça, justement): Monde: - addr:street : 14.080.304 - type=associatedStreet : 75.102 France: - addr:street : 439.859 - type=associatedStreet : 23.373 Proportionnellement, la France utilise 10 fois plus la relation que dans l'ensemble du monde (et représente 1/3 des utilisateurs). De là à dire que le plugin cadastre-fr y est pour quelque chose... Mais partout, la version sans relation reste largement dominante. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] MissingCommunes à nouveau opérationnel
2012/8/16 Frédéric Rodrigo fred.rodr...@gmail.com: Mais effectivement, il y un problème avec la bases osmosis de osm7 qui ne se met plus à jour. http://munin.openstreetmap.fr/pole-aquinetic.fr/osm7.openstreetmap.fr/osm_replication_lag_osmosis.html Effectivement, je vois ça. Je vais voir ce que je peux faire. À noter que layers.openstreetmap.fr utilise la base de donnée mondiale de osm102, qui est à jour. -- Jocelyn ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Wiki et système de traduction semi-automatisé
Le 16 août 2012 12:02, David Crochet david.croc...@online.fr a écrit :
Bonjour
Le 16/08/2012 11:51, Philippe Verdy a écrit :
L'extension n'est pas faite pour traduire TOUTE une page wiki mais au
maximum un paragraphe.
Donc, si je comprend bien, on sélectionne à partir de la page maître les
sections autorisées à être traduites par les autres langues.
Donc le système permet d'avoir un section de la langue d'origine qui n'as
pas besoin d'être traduites, mais est-ce qu'elle apparaît quand même non
traduites dans les pages des autres langues ?
Et est-ce que ce système permet à une langues d'ajouter une section
spécifique uniquement pour cette langue ?
Directement non, pas en terme de traduction, mais on peut créer une
ressource vide (décrite comme pouvant accueillir un contenu libre avec
un titre de section d'extension propre à la langue, et du texte
quelconque contenant éventuellement des sous-sections, voire plus
facilement un appel de modèle {{Template:FR:}} qu'il ne sera pas
nécessaire de maintenir sur le serveur de traduction lui-même, et
servant de placeholder permettant d'insérer un contenu spécifique.
On prépare la page à traduire en la marquant avec des commentaires
spéciaux marquant les zones successives à traduire pour lui donner un
nom de ressource.
Oui, c'est ce que j'ai vu sur le site mediawiki justement [1]
La forme resource/fr en sous-pages sera alors utilisée et ira
renseigner l'espace de nommage Mediawiki: mais la page traduite
complète générée par l'outil restera de la forme FR:nom de page. En
effet on ne peut pas naviguer facilement dans l'espace de nommage
spécial Mediawiki:
« Mediawiki: » ? hum, ce ne serait pas plutôt « Translations: » ?
Il y a les deux types sur le serveur de traductions. Cela fait partie
de jeux de données séparés, effectivement. Les traductions de
l'interface MediaWiki et de ses extensions étant stockées dans
MediaWiki: car ces traductions sont communes à plein de wikis
différents, et les autres traductions gérées directement sur le
serveur wiki lui-même étant à part sans passer par un serveur externe.
Le système est en place depuis un moment sur Wikimedia Meta.
Au début il n'y avait pas d'espace Translations: cela se faisait sur
Mediawiki: car tout passait par un service externe (d'ailleurs pas
hébergé par la Fondation Wikimedia et servant aussi à des traductions
diverses pour tout logiciel compatible avec GNU gettext, y compris des
logiciels divers écrits en Java et PHP où Gettext a été porté, par
exemple JOSM et certains logiciels pour Ubuntu non supportés
directement par Ubuntu qui dispose de son propre service de traduction
; chaque logiciel choisit son service de traduction en ligne et gère
ses imports vers son repository pour les versions suivantes).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] MissingCommunes à nouveau opérationnel
Le 16 août 2012 13:29, Jocelyn Jaubert jocelyn.jaub...@gmail.com a écrit : 2012/8/16 Frédéric Rodrigo fred.rodr...@gmail.com: Mais effectivement, il y un problème avec la bases osmosis de osm7 qui ne se met plus à jour. http://munin.openstreetmap.fr/pole-aquinetic.fr/osm7.openstreetmap.fr/osm_replication_lag_osmosis.html Effectivement, je vois ça. Je vais voir ce que je peux faire. À noter que layers.openstreetmap.fr utilise la base de donnée mondiale de osm102, qui est à jour. Désolé de te contredire, mais layers.openstreetmap.fr a exactement le même problème de lag depuis début août avec là encore des données manquantes sur les communes, cantons, arrondissements, EPCI. Le problème doit alors être plus haut qu'Osmosis. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import bâti
Salut Philippe, De : Philippe Pary Le 15/08/2012 08:28, Vincent de Chateau-Thierry a écrit : Je peux te proposer ce script : http://wiki.openstreetmap.org/wiki/User:Vincent_95/Outils/Split Quelle est la licence de ce splitter ? Le must c'est une AGPLv3 selon moi, mais toute licence libre sera la bienvenue :-) Dont acte pour la licence. Si la licence le permet, je l'ajouterai à l'interface de cadastre.openstreetmap.fr et éventuellement l'appliquerai d'autorité pour les fichiers trop volumineux (10Mo par exemple) Sur le principe, à titre personnel, je suis bien sûr pour l'usage de ce programme (sinon je ne l'aurais pas écrit :-) ). Cependant, je vois 2 bémols pour un usage du programme en l'état de façon systématique sur les gros fichiers de cadastre.openstreetmap.fr : - sur le plan technique, ça n'est pas très robuste, du moins avec ma config, ce qui fait que pour de trop gros fichiers ( 15 Mo) je n'ai pas pu le faire marcher (c'est paradoxal mais c'est comme ça). Le source marche bien pour des fichiers de quelques Mo. Encore une fois, ce script n'a au départ comme but que de répondre à mon propre besoin (et avec mes seules compétences en dev). Si Pinaraf veut en faire une bouchée en C++ faut pas hésiter :-). - sur le principe même de proposer des morceaux (n fichiers) plutôt qu'un tout comme actuellement : certes ça devrait limiter les besoins de gros reverts, dans la mesure où les uploads seraient chacun de taille réduite. Néanmoins, ça implique une méthode de travail que chacun ne souhaite pas forcément adopter. On voit dans le présent fil (et c'était la même chose quand j'ai proposé ce script la première fois [1]) que travailler en découpant selon les axes routiers (= en pâtés de maisons) est plus naturel. vincent [1] : http://lists.openstreetmap.org/pipermail/talk-fr/2010-September/027266.html Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tags adresses
De : Pieren 2012/8/16 Christian Quest : Même si il n'y en a aucune de privilégiée, il ne faut pas se restreindre pour cette raison. On pourra toujours tout basculer automatiquement vers l'un ou l'autre. Il faut juste que les ré-utilisateurs connaissent les 2 méthodes actuellement employée. Comme souvent dans OSM, les deux méthodes présentent des avantages et inconvénients (que je pourrais lister sur demande). C'est pourquoi personne ne pousse pour en supprimer une des deux. Maintenant, certains préfèrent adopter la méthode la plus populaire. Pour le savoir, on peut utiliser les stats de taginfo (qui est faire pour ça, justement): Monde: - addr:street : 14.080.304 - type=associatedStreet : 75.102 France: - addr:street : 439.859 - type=associatedStreet : 23.373 Proportionnellement, la France utilise 10 fois plus la relation que dans l'ensemble du monde (et représente 1/3 des utilisateurs). De là à dire que le plugin cadastre-fr y est pour quelque chose... Mais partout, la version sans relation reste largement dominante. Chaque méthode étant suffisamment populaire, côté contributeur en effet il n'y a pas lieu de se censurer. Comme souligné par Christian, côté consommateurs de la donnée, ce qui est inévitable, c'est d'appréhender les deux modélisations pour ne pas passer à côté d'un pan entier de données. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] MissingCommunes à nouveau opérationnel
À noter que layers.openstreetmap.fr utilise la base de donnée mondiale de osm102, qui est à jour. Désolé de te contredire, Il n'y a pas contradiction, jocelyn a dit que layers.openstreetmap.fr utilise la base de donnée mondiale de osm102 ce qui est vrai, et, moins une erreur, cette base est à jour. Donc, s'il y a une erreur, à nous de la trouver : mais layers.openstreetmap.fr a exactement le même problème de lag depuis début août avec là encore des données manquantes sur les communes, cantons, arrondissements, EPCI. Peux tu donner un lien vers une zone qui indique le problème, et me donner l'id de la relation qui manquerait ? Afin que je puisse vérifier. Le problème doit alors être plus haut qu'Osmosis. Tu as remarqué un problème, tu nous en fais part, c'est sympa de nous aider à le résoudre, mais je suggère de ne pas essayer d'imaginer une raison ou cause qui rend la recherche de problème plus difficile car nous devons démêler ce qui est de ce que tu imagines. (la base osmosis n'ayant aucun rapport avec layers.openstreetmap.fr qui utilise une base osm2pgsql) -- 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
Re: [OSM-talk-fr] Tags adresses
2012/8/16 Vincent de Chateau-Thierry v...@laposte.net: Chaque méthode étant suffisamment populaire, Modèle relation : 0.05% des contributions; l'autre : 99.95%. Comme souligné par Christian, côté consommateurs de la donnée, ce qui est inévitable, Certes, mais la question était posée par un producteur ;-) Pour les consommateurs, je suis sûr qu'ils préféreraient aussi qu'il n'y ait qu'une seule méthode. Ce qui pourrait arriver un jour ou l'autre si on se mettait tous d'accord. Et on sait déjà laquelle serait choisie. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tags adresses
Le 16 août 2012 13:24, Pieren pier...@gmail.com a écrit : Monde: - addr:street : 14.080.304 - type=associatedStreet : 75.102 France: - addr:street : 439.859 - type=associatedStreet : 23.373 On ne peut pas compter comme çà :) La relation regroupe plusieurs numéros de rue. Alors que addr:street est répété à chaque numéro de rue ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tags adresses
De : Pieren Chaque méthode étant suffisamment populaire, Modèle relation : 0.05% des contributions; l'autre : 99.95%. Bon ok, on peut faire dire ce qu'on veut aux chiffres :-). Je ne parlais pas de relatif (tes pourcentages disent tout) mais d'absolu : 75.000 occurrences de relation associatedStreet, ça n'est pas rien. Sans oublier qu'une relation représente n adresses. Sur une base d'il y a quelques semaines, focalisée sur Paris, je compte à l'instant 398 relations mais quand même 10500 rôles house associés : une relation pour 25 adresses, ça change un peu les proportions, même si le modèle addr:street reste largement majoritaire, sans discussion. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] MissingCommunes à nouveau opérationnel
Le 16 août 2012 13:52, sly (sylvain letuffe) li...@letuffe.org a écrit : À noter que layers.openstreetmap.fr utilise la base de donnée mondiale de osm102, qui est à jour. Désolé de te contredire, Il n'y a pas contradiction, jocelyn a dit que layers.openstreetmap.fr utilise la base de donnée mondiale de osm102 ce qui est vrai, et, moins une erreur, cette base est à jour. Donc, s'il y a une erreur, à nous de la trouver : mais layers.openstreetmap.fr a exactement le même problème de lag depuis début août avec là encore des données manquantes sur les communes, cantons, arrondissements, EPCI. Peux tu donner un lien vers une zone qui indique le problème, et me donner l'id de la relation qui manquerait ? Afin que je puisse vérifier. Regarde par exemple l'arrondissement de Sarreguemines (que j'ai créé, en Moselle), et plusieurs communes marquées comme absentes autour (qui sont pourtant là), ainsi que les cantons (seul le canton de Bitche apparaît, tous les autres cantons de l'arrondissement sont pourtant complets). Layers ne les voit toujours pas, pas plus qu'aucun autre outil. Certains sont là depuis plus d'une semaine. On a la même chose en plein d'endroits autour (en Belgique, au Luxembourg, à la frontière franco-allemande en Alsace, et sur des communes allemandes). Si on fouille un peu avec l'outil donnant l'état des communes, plein sont marquées en bleu (admin_centre manquant) alors que les admin_centre sont bien là (et avec le bon code INSEE). Le problème doit alors être plus haut qu'Osmosis. Tu as remarqué un problème, tu nous en fais part, c'est sympa de nous aider à le résoudre, mais je suggère de ne pas essayer d'imaginer une raison ou cause qui rend la recherche de problème plus difficile car nous devons démêler ce qui est de ce que tu imagines. (la base osmosis n'ayant aucun rapport avec layers.openstreetmap.fr qui utilise une base osm2pgsql) Pourquoi ce ton désobligeant ? Et puis où ai-je écrit que Layers utilise Osmosis ? Puisque justement je dis le contraire en demandant à chercher ailleurs. Et ce la ne concerne pas que mes modifs. Dans les faits, on peut ajouter ou corriger des tas de communes, et attendre cela n'apparaît toujours pas avec pourtant des données supposées à jour (si on consulte la date de référence de l'import affichée dans les outils d'analyse). Je ne sais pas pourquoi ces données ne se mettent plus à jour depuis plus d'une semaine. Un des outils d'import (peu importe lequel) semble les ignorer pour une raison que je ne comprend pas. Je n'ai pas le détail de l'architecture des divers imports et API (qui changent régulièrement et ne correspondent pas non plus à la doc affichée qui souvent est obsolète). Alors oui les serveurs OSM7, et OSM8 ont du retard, mais ce ne sont pas les seuls, et OSM102 en a aussi. Si ce n'est pas Osmosis justement plus haut on a quoi ? Une API ou encore un autre outil de conversion ou d'extraction de données ? Ou encore un problème de place de stockage pour les données nouvelles et des fichiers oubliés ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] MissingCommunes à nouveau opérationnel
Peux tu donner un lien vers une zone qui indique le problème, et me donner l'id de la relation qui manquerait ? Afin que je puisse vérifier. Regarde par exemple l'arrondissement de Sarreguemines (que j'ai créé, en Moselle), Je n'ai aucune idée d'où ça se trouve et je ne connais pas du tout la moselle, serait il possible d'avoir le numéro de la relation, ce serait bien plus simple pour moi ? et plusieurs communes marquées comme absentes autour (qui sont pourtant là) Pareil, tu pourrais me donner leur numéro (ID) ça me gagnerait du temps , ainsi que les cantons (seul le canton de Bitche apparaît, tous les autres cantons de l'arrondissement sont pourtant complets). idem La liste des id impliqués me permet de vérifier si les données sont bien dans la base, et on peut aussi plus facilement passer l'analyser : http://analyser.openstreetmap.fr/cgi-bin/index.py dessus et voir s'il y a un problème avec les données ou pas -- 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
Re: [OSM-talk-fr] Tags adresses
Le 16 août 2012 14:20, Etienne Trimaille etienne.trimai...@gmail.com a écrit : Le 16 août 2012 13:24, Pieren pier...@gmail.com a écrit : Monde: - addr:street : 14.080.304 - type=associatedStreet : 75.102 France: - addr:street : 439.859 - type=associatedStreet : 23.373 On ne peut pas compter comme çà :) La relation regroupe plusieurs numéros de rue. Alors que addr:street est répété à chaque numéro de rue ! Oui effectivement, il faudrait compter le total du nombre de membres dans les relations type=associatedStreet. Maintenant en terme de place dans la base de données, la différence n'est pas énorme : la relation a besoin de place pour stocker un noeud membre de plus pour chaque point d'adresse, là où l'attribut addr:street sur un noeud nécessite la place du nom et de la valeur de l'attribut pour chaque point d'adresse. Mais la relation reste tout de même plus économe et évite la redondance des noms, et facilite les traductions (les rues ont parfois des noms dans plusieurs langues). Cependant en terme de maintenant la relation est plus simple. Et surtout il n'est pas simple du tout de chercher toutes les adresses d'une même rue étant donné que les points d'adresse sont situés dans une zone buffer autour de la rue, mais de largeur non précisée. La recherche par bounding box totale de la rue risque de manquer des points près des deux extrémités voire même partout si la rue est quasiment sur un axe cardinal Nord-Sud ou Est-Ouest. Si on recherche cette fois dans la commune, on va en oublier aussi, car des rues sont communes à plusieurs communes (les rues frontalières ou les rues traversant plusieurs communes). En revanche une relation associatedStreet peut exister pour chaque segment (où côté de rue) spécifique à une commune donnée. Sur combien de communes va-t-on chercher ? Faut-il alors calculer des intersections entre les rues et les frontières adminsitratives ? Le résultat sera assez complexe. Si on fait une requête de recherche d'adresse en mentionnant la ville, le nom d'une rue et un numéro, c'est bien plus facile de trouver avec la relation. La recherche purement géométrique a de grande chances d'échouer et on risque au mieux de ne trouver que la rue sans localiser le numéro. La relation a donc bien des avantages étant donné la façon dont on trace la géométrie des rues (uniquement un trait sans aucune largeur précisée et qui ne passe jamais par un des points d'adresse), d'autant plus que la rue peut avoir entre elle et le point d'adresse des voies secondaires (chemins piétons, voies bus, pistes cyclables...). Rien dans la géométrie des rues ne permet même de savoir quel est le côté pair ou impair. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] MissingCommunes à nouveau opérationnel
(pas vu la deuxième partie) Pourquoi ce ton désobligeant ? Non, pas désobligeant, ou alors je me suis mal exprimé, je voulu juste indiquer qu'un rapport de bug gagne en clarté si on expose juste les constats, où ils sont vus et comment je peux moi aussi constater la même chose. Le reste n'est que spéculation pas toujours utile ou en tout cas qui n'intervient que dans un second temps. -- 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
Re: [OSM-talk-fr] MissingCommunes à nouveau opérationnel
Le 16 août 2012 14:58, sly (sylvain letuffe) li...@letuffe.org a écrit : Peux tu donner un lien vers une zone qui indique le problème, et me donner l'id de la relation qui manquerait ? Afin que je puisse vérifier. Regarde par exemple l'arrondissement de Sarreguemines (que j'ai créé, en Moselle), Je n'ai aucune idée d'où ça se trouve et je ne connais pas du tout la moselle, serait il possible d'avoir le numéro de la relation, ce serait bien plus simple pour moi ? Un cartographe qui ne connait pas la géographie de base... Consulte la carte, c'est pas dur à trouver. Même la fonction recherche du site OpenStreemap te dit où c'est. Sarreguemines est sur la frontière franco-allemande, en Lorraine. Regarde Layers dans ce secteur. L'arrondissement est toute la partie est de la Moselle qui forme une encoche entre l'Alsace à l'est et au sud, et l'Allemagne au Nord). Tous ses cantons sont présents. Et les communes qui touchent l'arrondissement et marquées manquantes (pas de vert sur Layers) sont tracées aussi. Tu peux zoomer sur le noeud de la ville de Sarreguemines qui est l'admin_centre de la ville (qui est elle-même un canton aussi présent) et l'admin_centre de l'arrondissement. Dans les outils d'analyse des communes manquantes, pioche au hasard les communes marquées d'un point bleu en Ille-et-Vilaine : elles devraient presque toutes être en vert et non en bleu. Là encore ce sont des données oubliées. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[forum-osm-fr]De l'usage du p�destrian
Le message suivant de JB: ## Bonjour, Les area=yes associées aux highway=pedestrian me font parfois tiquer, et elles ont tendance à se répandre dans Grenoble. Dans ce cas : http://osm.org/go/0CASD5RNA--?layers=C , une intersection importante avec beaucoup de traffic, des feux piétons et des larges trottoirs, est-ce que l'utilisation de la surface pedestrian est abusive ? Ou est-ce que c'est juste moi qui suis maniaque ? Le wiki (http://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dpedestrian) semble dire que oui, et que pedestrian est réservé aux places habituellement sans circulation. JB a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=2 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] contacter un contributeur espagnol
Visiblement il utilise les liens vers Wikipédia en espagnol comme source des noms. Et laisse les soulignés présents dans les URL au lieu de mettre les espaces. Il ne se pose pas de question et met tout alt_name:es sans regarder si c'est un nom secondaire synonyme pour l'espagnol. Il ne respecte pas non plus la capitatlisation normale. Et laisse la redondance précisant la ville (utile dans un lien d'article Wikipédia pour éviter une homonymie globale, mais sans utilité dans OSM car on ne précise pas le nom de la ville pour le nom donné au POI (sauf si ça fait partie de son nom, par exemple souvent les clubs de sport). Exemple : Chemin : Basilique du Sacré-Coeur (30163817) Modifié le :14 août 2012 21:16:09 Modifié par : Gonzalo_Pires Version : 9 Dans le groupe de modifications : 12732095 Commentaire : Areas de interes Balises : alt_name:es = bacilica_Nacional_du_Sacré-Coeur_de_Koekelberg name = Basilique du Sacré-Coeur - Basiliek van het Heilig Hart name:fr = Basilique du Sacré-Coeur name:nl = Basiliek van het Heilig Hart Certains noms sont assez cocasses dans la façon dont il a transformé les URLs. Le 15 août 2012 15:58, didier2020 didier2...@free.fr a écrit : merci! Le mercredi 15 août 2012 à 08:26 +0200, Jo a écrit : Je lui ai envoyé le message suivant: Hola Gonzalo, En la lista francesa hay alguien que ha pedido que te contactemos: il ajoute des informations mais avec de mauvais tags pour des areas de interes - il crée de nouveaux points alors qu'ils existent parfois a coté - utilisation du tag suburb - utilisation de alt_name:es (alors que name:es serait plus correct ?) Traducción: Esta agregando informaciones, pero con los tags equivocados - Esta creando nuevos puntos, cuando ya existia punto al lado - Uso del tag suburb - Uso de alt_name:es (cuando name:es seria más corecto ?) Entonces: Si no hay nombre todavia: Agrega el nombre en name= Si ya hay name, name:fr o name:nl, usa name:es Tampoco es necesario de usar _ en vez de espacios en los nombres. Seria amable si podrías revisar todas tus contribuciones. Chau y gracias, Polyglot 2012/8/15 didier2...@free.fr bonjour, pour contacter ce contributeur: http://www.openstreetmap.org/user/Gonzalo_Pires/edits mon anglais ne me permet pas de le faire quand a l'espagnol ... il ajoute des informations mais avec de mauvais tags pour des areas de interes - il cré de nouveau point alors qu'ils existent parfois a coté - utilisation du tag suburb - utilisation de alt_name:es (alors que name:es serait plus corect ?) merci d'avance -- didier --mapeur amateur-- ___ 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] MissingCommunes à nouveau opérationnel
De : Philippe Verdy Le 16 août 2012 14:58, sly (sylvain letuffe) a écrit : Peux tu donner un lien vers une zone qui indique le problème, et me donner l'id de la relation qui manquerait ? Afin que je puisse vérifier. Regarde par exemple l'arrondissement de Sarreguemines (que j'ai créé, en Moselle), Je n'ai aucune idée d'où ça se trouve et je ne connais pas du tout la moselle, serait il possible d'avoir le numéro de la relation, ce serait bien plus simple pour moi ? Un cartographe qui ne connait pas la géographie de base... Consulte la carte, c'est pas dur à trouver. Même la fonction recherche du site OpenStreemap te dit où c'est. Sarreguemines est sur la frontière franco-allemande, en Lorraine. Regarde Layers dans ce secteur. L'arrondissement est toute la partie est de la Moselle qui forme une encoche entre l'Alsace à l'est et au sud, et l'Allemagne au Nord). Tous ses cantons sont présents. Et les communes qui touchent l'arrondissement et marquées manquantes (pas de vert sur Layers) sont tracées aussi. Tu peux zoomer sur le noeud de la ville de Sarreguemines qui est l'admin_centre de la ville (qui est elle-même un canton aussi présent) et l'admin_centre de l'arrondissement. Dans les outils d'analyse des communes manquantes, pioche au hasard les communes marquées d'un point bleu en Ille-et-Vilaine : elles devraient presque toutes être en vert et non en bleu. Là encore ce sont des données oubliées. Philippe, c'est si difficile de donner un lien ? Surtout quand c'est ce qui t'es demandé ? Ce genre de chose, là : http://www.openstreetmap.org/browse/relation/2347554 Je constate au passage que cette relation (le canton de Sarreguemines) est ajouté avec un rôle subarea à la relation http://www.openstreetmap.org/browse/relation/2349599 (l'arrondissement de Sarreguemines) et a par ailleurs comme membre, entre autres, la commune de Sarreguemines, toujours en subarea. Autant dire une modélisation absolument pas consensuelle, pour laquelle il t'a été maintes fois demandé de ne pas la mélanger à la modélisation actuelle (modélisation par limites). Autant parler dans le vide. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [forum-osm-fr]De l'usage du pédestrian
Effectivement, il y a confusion entre la notion géographique de place (en français) et celle d'espace piéton *dans* cette place (laquelle est traversée par des rues pour bus et automobiles ou contient des places de stationnement et du mobilier urbain ou des kiosques et accueille souvent des commerces itinérants, et peut aussi inclure des espaces cultivés, fontaines, statues, monuments...). Un espace piéton peut remplir aussi autre chose qu'une place, ce peut être toute la rue, qui dès lors passe en highway=pedestrian, sans nécessiter pour autant une surface fermée. Une place (en français) devrait en revanche pouvoir être cartographiée par un polygone de type place=locality, jusqu'au bord des batiments, avec son nom, afin d'inclure toute son étendue, sans en faire nécessairement un espace dédié aux piétons. Le 16 août 2012 15:24, fo...@letuffe.org a écrit : Le message suivant de JB: ## Bonjour, Les area=yes associées aux highway=pedestrian me font parfois tiquer, et elles ont tendance à se répandre dans Grenoble. Dans ce cas : http://osm.org/go/0CASD5RNA--?layers=C , une intersection importante avec beaucoup de traffic, des feux piétons et des larges trottoirs, est-ce que l'utilisation de la surface pedestrian est abusive ? Ou est-ce que c'est juste moi qui suis maniaque ? Le wiki (http://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dpedestrian) semble dire que oui, et que pedestrian est réservé aux places habituellement sans circulation. JB a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=2 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] MissingCommunes à nouveau opérationnel
J'ai utilisé ça le temps de la modélisation pour ne rien oublier. C'est la façon de construire dans TOUS les pays et c'est un super outil de maintenance qui facilite énormément les recherches et le travail. Ce n'est pas la raison pour laquelle il n'apparait pas car le canton de Bitche apparaît aussi. Cela ne remet pas en cause le tracé des ways de frontières qui sont tous là ! Le 16 août 2012 15:35, Vincent de Chateau-Thierry v...@laposte.net a écrit : De : Philippe Verdy Le 16 août 2012 14:58, sly (sylvain letuffe) a écrit : Peux tu donner un lien vers une zone qui indique le problème, et me donner l'id de la relation qui manquerait ? Afin que je puisse vérifier. Regarde par exemple l'arrondissement de Sarreguemines (que j'ai créé, en Moselle), Je n'ai aucune idée d'où ça se trouve et je ne connais pas du tout la moselle, serait il possible d'avoir le numéro de la relation, ce serait bien plus simple pour moi ? Un cartographe qui ne connait pas la géographie de base... Consulte la carte, c'est pas dur à trouver. Même la fonction recherche du site OpenStreemap te dit où c'est. Sarreguemines est sur la frontière franco-allemande, en Lorraine. Regarde Layers dans ce secteur. L'arrondissement est toute la partie est de la Moselle qui forme une encoche entre l'Alsace à l'est et au sud, et l'Allemagne au Nord). Tous ses cantons sont présents. Et les communes qui touchent l'arrondissement et marquées manquantes (pas de vert sur Layers) sont tracées aussi. Tu peux zoomer sur le noeud de la ville de Sarreguemines qui est l'admin_centre de la ville (qui est elle-même un canton aussi présent) et l'admin_centre de l'arrondissement. Dans les outils d'analyse des communes manquantes, pioche au hasard les communes marquées d'un point bleu en Ille-et-Vilaine : elles devraient presque toutes être en vert et non en bleu. Là encore ce sont des données oubliées. Philippe, c'est si difficile de donner un lien ? Surtout quand c'est ce qui t'es demandé ? Ce genre de chose, là : http://www.openstreetmap.org/browse/relation/2347554 Je constate au passage que cette relation (le canton de Sarreguemines) est ajouté avec un rôle subarea à la relation http://www.openstreetmap.org/browse/relation/2349599 (l'arrondissement de Sarreguemines) et a par ailleurs comme membre, entre autres, la commune de Sarreguemines, toujours en subarea. Autant dire une modélisation absolument pas consensuelle, pour laquelle il t'a été maintes fois demandé de ne pas la mélanger à la modélisation actuelle (modélisation par limites). Autant parler dans le vide. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ 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] roles subarea et Verdy_p qui y retourne - ( était : MissingCommunes à nouveau =?iso-8859-1?q?_op=E9rationnel?=)
Un cartographe qui ne connait pas la géographie de base... Consulte la carte, c'est pas dur à trouver. Même la fonction recherche du site OpenStreemap te dit où c'est. Sarreguemines est sur la frontière franco-allemande, en Lorraine. C'est quand même toi qui a commencé à parler de layers.openstreetmap.fr, j'imaginais un peu de coopération de ta part car si je demande les id c'est parce que justement ce n'est pas simple à trouver pour moi entre la commune, le canton, l'arrondissement et que sais-je encore parce que toutes tes remarques n'étaient pas claires pour moi et je demandais des précisions. Après, si tu ne veux pas m'aider, tant pis, je me contenterais de dire que tu t'es sûrement trompé et que la base est bien à jour car je ne vois pas le problème, en attendant plus d'information qui puisse me prouver que la base est bien en retard. Toutefois, après avoir fini par tomber sur la relation d'id 2347554 qui, en effet, ne s'affiche pas sur layers, on peut, grâce à son id, constater ça : http://www.openstreetmap.org/browse/relation/2347554/history Et je peux dire alors que le problème vient bien des données, car tu as, à nouveau, et contre l'avis de tous, recommencé à rentrer des relations pyramidales avec des role subarea Donc layers marche bien, il est à jour, il est prévu ainsi et il il ne traite volontairement pas cette construction qu'il considère invalide car, pour l'instant, un consensus existe pour dire qu'en france nous ne voulons pas utiliser de role subarea Par contre, toi tu es buggé, et tu te fout de la gueule de ceux avec qui tu avais discuté il y a quelques mois sur le thème des subarea -- 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
Re: [OSM-talk-fr] [forum-osm-fr]De l'usage du pédestrian
Les area=yes associées aux highway=pedestrian me font parfois tiquer, et elles ont tendance à se répandre dans Grenoble. Dans ce cas : http://osm.org/go/0CASD5RNA--?layers=C , une intersection importante avec beaucoup de traffic, des feux piétons et des larges trottoirs, est-ce que l'utilisation de la surface pedestrian est abusive ? Ou est-ce que c'est juste moi qui suis maniaque ? Le wiki (http://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dpedestrian) semble dire que oui, et que pedestrian est réservé aux places habituellement sans circulation. C'est une question assez délicate parce que dans nos paysages urbains, on trouve un peu de tout pour ce qu'on baptise une place en français. Il existe des places largement piétonnes mais qui laissent le passage aux voitures (souvent à vitesse très réduite). Dans ce cas, on peut accepter l'usage du polygone pedestrian+area. Mais dans le cas que tu pointes, on est dans la grosse intersection avec voitures, tram et trottoirs. L'usage du pedestrian+area pourrait être considéré comme abusif. Reste la question de comment faire pour identifier et nommer l'endroit correctement. On peut assimiler les places aux classiques rues linéaires et c'est souvent taggué de la même manière lorsque la place comporte ses propres voies de circulation (on nomme alors la place sur le(s) way(s) highway). Mais dans cet exemple, c'est une place de type intersection qui n'a pas ses propres voies de circulation. On ne peut donc pas choisir un des highway existant pour identifier le nom de la place. Je vois plusieurs solutions à ce type de problème : - on coupe un bout de toutes les rues aboutissant au noeud d'intersection et au lieu de garder le nom de la rue qui y arrive, on donne le nom de la place. Problème : on perd la connexion directe entres rues. C'est pas joli et je n'ai jamais vu ce cas concrètement. - on marque uniquement l'espace piéton avec pedestrian+area du nom de la place. Ca permet une géolocalisation de la place mais on a une vision un peu limitée de celle-ci (la place n'est connue et reconnue qu'en tant que place piétonne). Et il faut qu'il y ait un espace piéton suffisament important - supèrieur à un trottoir (dans cet exemple, l'espace au sud-ouest pourrait jouer ce rôle). - on trace un polygone sur l'emprise de l'intersection mais uniquement sur la partie automobile avec residential+area (ou unclassified, secondary, etc). C'est le pendant de la version pedestrian+area mais cette fois-ci, on choisit d'identifier la partie automobile si la partie piétonne est manquante ou minoritaire. C'est cette option que j'ai choisi sur plusieurs places à Paris. Et c'est celle que je choisirais dans ton exemple. Certains mettent la place sur le noeud d'intersection lui-même. Mais il faut alors aussi mettre un highway sinon on a un noeud avec un nom mais pas de classification (on ne sait pas ce que c'est). D'autres tracent un polygone avec le nom de la place et area mais là encore, sans highway, on ne sait pas que c'est une place (mais ça permet son affichage avec Mapnik, c'est un peu tagguer pour le rendu). L'option proposée par Philippe avec place=locality est mauvaise à mon avis car on désigne généralement par ce biais un lieu-dit. Certains utilisent aussi locality pour désigner les noms de quartiers en ville. On voit qu'on est loin du nom d'une place qu'on devrait tagguer comme une rue, amha (c.a.d attaché à un highway ouvert ou fermé). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] roles subarea et Verdy_p qui y retourne - ( était : MissingCommunes à nouveau =?iso-8859-1?q?_op=E9rationnel?=)
Désolé, mais le problème existe ailleurs aussi où il n'y en a pas. J'ai utilisé cela le temps de la constrution et j'attendais que cela apparaisse. Dans d'autres endroits où j'ai fait des corrections je n'en ai pas ajouté et les reltions n'apparaissent toujours pas. Dans tous les autres pays où les subareas onstutilisés cela apparait correctement. Ce n'est pas une construction invalide, il n'y a qu'à ignorer les membres pour tracer le contour et vérifier que les frontières sont fermées, comme c'est fait partout ailleurs. C'est un outil d'analyse et de navigation, pas un outil de construction géométrique. C'est très pratique pour justement corriger les ways manquants en retrouvant les relations voisines, ou pour détecter les intersections de surfaces ou des morceaux de surface oubliées entre deux zones qui devraient être voisines. Sinon l'Espagne ou la Belgique ou la Suisse ne s'afficheraient pas du tout dans Layers. Il n'y a pas de raison que ces relations soient ignorées du fait qu'il y a des membres supplémentaires qui peuvent être eux seuls ignorés pour l'usage qui est fit de ces outils. On met des tas de tags qui sont ignorés par des tas d'outils et utilisés seulement par d'autres. Notamment des tags de suivi. les quelques membres en plus des relations ne sont pas un problème quand ils sont clairement connus en plus. Ce n'est pas mon intention de me foutre de la gueule des gens comme tu dis. Mais je ne vois pas qui ça gêne. Sinon on peut virer des tas de trucs dans la base, y compris tous les tags de suivi et même les FIXME pour la plupart qui expliquent un travail en cours (alors qu'on a d'autres outils aussi pour faire du suivi). Et je n'aime pas le ton agressif et impoli que tu prends ici pour répondre. Car le problème que j'ai évoqué n'est pas que là. Mais tu n'y réponds pas et tu veux feindre de l'ignorer. Le 16 août 2012 15:49, sly (sylvain letuffe) li...@letuffe.org a écrit : Un cartographe qui ne connait pas la géographie de base... Consulte la carte, c'est pas dur à trouver. Même la fonction recherche du site OpenStreemap te dit où c'est. Sarreguemines est sur la frontière franco-allemande, en Lorraine. C'est quand même toi qui a commencé à parler de layers.openstreetmap.fr, j'imaginais un peu de coopération de ta part car si je demande les id c'est parce que justement ce n'est pas simple à trouver pour moi entre la commune, le canton, l'arrondissement et que sais-je encore parce que toutes tes remarques n'étaient pas claires pour moi et je demandais des précisions. Après, si tu ne veux pas m'aider, tant pis, je me contenterais de dire que tu t'es sûrement trompé et que la base est bien à jour car je ne vois pas le problème, en attendant plus d'information qui puisse me prouver que la base est bien en retard. Toutefois, après avoir fini par tomber sur la relation d'id 2347554 qui, en effet, ne s'affiche pas sur layers, on peut, grâce à son id, constater ça : http://www.openstreetmap.org/browse/relation/2347554/history Et je peux dire alors que le problème vient bien des données, car tu as, à nouveau, et contre l'avis de tous, recommencé à rentrer des relations pyramidales avec des role subarea Donc layers marche bien, il est à jour, il est prévu ainsi et il il ne traite volontairement pas cette construction qu'il considère invalide car, pour l'instant, un consensus existe pour dire qu'en france nous ne voulons pas utiliser de role subarea Par contre, toi tu es buggé, et tu te fout de la gueule de ceux avec qui tu avais discuté il y a quelques mois sur le thème des subarea -- 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] roles subarea et Verdy_p qui y retourne - ( était : MissingCommunes à nouveau =?iso-8859-1?q?_op=E9rationnel?=)
Toutefois, après avoir fini par tomber sur la relation d'id 2347554 qui, en effet, ne s'affiche pas sur layers, on peut, grâce à son id, constater ça : http://www.openstreetmap.org/browse/relation/2347554/history Oui et c'est lors de la construction de l'arrondissement qu'il est apparu. Mais il est depuis longtemps pour les membres de l'arrondissement de Bitche (qui lui apparait bel et bien, preeuve que ce n'est pas le problème que j'ai évoqué ici, et donc que tu ne réponds pas au problème). Le canton de Bitche (le plus à l'est dans l'arrondissement) a seulement été créé avant le début de la période de désynchronisation et il est encore là et pas marqué comme manquant, ni ayant le moindre problème. J4ai parlé aussi des communes d'Ille-et-Vilaine qui affichent toujours un statut en bleu alors qu'elles ont bien un admin_center défini (et depuis longtemps). Revenons au sujet : pourquoi cela ne se synchronise pas. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [forum-osm-fr]De l'usage du pédestrian
Le 16 août 2012 16:28, Pieren pier...@gmail.com a écrit : L'option proposée par Philippe avec place=locality est mauvaise à mon avis car on désigne généralement par ce biais un lieu-dit. Une place publique est bien souvent un lieu-dit ! Cernée par des rues ayant des noms différents. Mais généralement on met place=locality sur un seul noeud, mais rien n'empêche que cela soit sur un polygone. C'est assez précis alors pour désigner toute la place publique et ce qu'elle contient, et ce qui la traverse ou la rejoint. Et dans laquelel on peut encore tracer une ou plusieurs zones piétonnes (sans même avoir à les nommer : sont nommées les rues autour ou qui y arrivent, le nom de la place vient du polygone place=locality qui n'a pas besoin d'autre chose. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] roles subarea et Verdy_p qui y retourne - ( était : MissingCommunes à nouveau opérationnel)
De : Philippe Verdy Désolé, mais le problème existe ailleurs aussi où il n'y en a pas. J'ai utilisé cela le temps de la constrution et j'attendais que cela apparaisse. Le temps de la construction, je ne suis pas sûr de comprendre. Si c'était pour t'aider à vérifier ton travail, tu dois pouvoir, désormais, supprimer ces membres de relation. Faut-il rappeler que pour ce type de construction (les relations de type multipolygon basées sur des limites admins) il existe ComcomMaker : http://osm7.openstreetmap.fr/~vincentpottier/comcom/ qui a été pensé pour ça, et qui le fait bien. Une raison de plus pour ne pas t'appuyer, même temporairement, sur les subareas. Ce n'est pas mon intention de me foutre de la gueule des gens comme tu dis. Mais je ne vois pas qui ça gêne. Ne pas voir, c'est gonflé, vues les discussions du début d'année. Tu peux toujours relire ce fil : http://lists.openstreetmap.org/pipermail/talk-fr/2012-January/039589.html vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Tags point crottes de chiens !
Salut, Désolé pour le message terre-à-terre, si j'ose dire... Comment taggeriez-vous ceci : https://tuxdomain.dyndns.org/osm-garmin/view.php?file=France/DSC00330.JPGdl=1 Description : - Panneau avec une représentation de chien - Distributeur de sac pour ramasser... - Poubelle pour recueillir l'objet du déli^ ramassage. @+ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] roles subarea et Verdy_p qui y retourne - ( était : MissingCommunes à nouveau opérationnel)
ComcomMaker ne marche pas pour les zones incomplètes pour lesquelles il manque encore des frontières. On se débrouille très bien sans en commençant par lister les communes membres (d'abord en cherchant les noeuds centre, puis en les remplaçant par leur relation frontière après avoir vérifié son existance, même si elle est incomplète. On va vérifier les composantes une par une, on les ferme. On valide en plusieurs étapes pour limiter les conflits. quand une zone est complète on revérifie le tout. Je ne vois pas qui ça gêne d'avoir les subareas en plus (et non pas à la place) des ways frontières qui sont en construction ou maintenance. C'est une donnée stable, facile à garder à jour et vérifier. ComcomMaker ne marche pas du tout pour ce que je fais. Et même dans les cas où il marche, il n'est pas plus pratique ni plus rapide, il a même tendance à casser ce qui était correct. Le 16 août 2012 16:55, Vincent de Chateau-Thierry v...@laposte.net a écrit : De : Philippe Verdy Désolé, mais le problème existe ailleurs aussi où il n'y en a pas. J'ai utilisé cela le temps de la constrution et j'attendais que cela apparaisse. Le temps de la construction, je ne suis pas sûr de comprendre. Si c'était pour t'aider à vérifier ton travail, tu dois pouvoir, désormais, supprimer ces membres de relation. Faut-il rappeler que pour ce type de construction (les relations de type multipolygon basées sur des limites admins) il existe ComcomMaker : http://osm7.openstreetmap.fr/~vincentpottier/comcom/ qui a été pensé pour ça, et qui le fait bien. Une raison de plus pour ne pas t'appuyer, même temporairement, sur les subareas. Ce n'est pas mon intention de me foutre de la gueule des gens comme tu dis. Mais je ne vois pas qui ça gêne. Ne pas voir, c'est gonflé, vues les discussions du début d'année. Tu peux toujours relire ce fil : http://lists.openstreetmap.org/pipermail/talk-fr/2012-January/039589.html vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ 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] mkgmap fichier *.TYP et building
Le 14/08/2012 12:53, Eric a écrit : As tu quelque chose comme # building tag should be last building=* [0x13 resolution 20] oui j'ai # building tag should be last building=* | man_made=* | amenity=* | tourism=* [0x13 resolution 24] en derniere ligne de ton fichier polygon de mkgmap ? Sinon, tu peux essayer de jouer sur le Draworder du TYP pour les landuse et les buildings mais normalement c'est pas nécessaire. ben visiblement là ils sont masqué par un landuse dans les zones urbaines et ils apparaissent bien ailleurs ... Moi j'ai plutot le pb inverse je voudrais que les buildings ne s'affichent que sur les niveaux de zoom max hors ils s'affichent presque tout le temps ce qui provoque des temps d'affichage monstrueux en milieu urbain. mon problème n'est pas le niveau de zoom (le resolution 24 est là pour ça) mais bien de super-position des couches. Tu peux essayer de compiler avec le mien pour voir si ca fait pareil. en fait je pars du fichier TYP que tu m'as indiqué l’autre fois, et c'est le seul truc qui ne marche pas comme je le voudrais :-) merci pour tout, philippe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] MissingCommunes à nouveau opérationnel
Le 16/08/2012 14:58, sly (sylvain letuffe) a écrit : serait il possible d'avoir le numéro de la relation, ce serait bien plus simple pour moi ? si on jette un coup d'oeuil sur mon compte : http://www.openstreetmap.org/user/HelenePETIT/edits on vois que je continue à rentrer des limites de communes (bos suetus aratro) ; je ne vois plus mon travail avancer sur layer, je me suis dit que ça allait s'arranger, mais non, ça dure une peu ; http://layers.openstreetmap.fr/?zoom=12lat=43.05275lon=-0.00204layers=BFFTFFF Cheust (2350375) http://www.openstreetmap.org/browse/relation/2350375 Juncalas (2352629) http://www.openstreetmap.org/browse/relation/2352629 Ourdon (2352627) http://www.openstreetmap.org/browse/relation/2352627 Ourdis-Cotdoussan (2349061) http://www.openstreetmap.org/browse/relation/2349061 En passant au zoom 14, seul Juncalas manque à l'appel ; A tous les zoom il y a des bout de tuiles coloriées en gris foncé, ça n'est pas trop gênant, je n'y pase pas la nuit non plus. Quant à Missing commune , Id: 534938452 name: Saint-Pastous il ne montre pas la relation que j'ai créé le 11 août : Saint-Pastous (2343528) ; en tous cas pas au zoom dont je me sers. J'écris toutes mes relations sur le même modèle (assez simplifié) depuis plusieurs mois : un point place avec le rôle admin_centre, et des ways portant boundary=administrative. Voilà, voilà ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] MissingCommunes à nouveau opérationnel
au zoom 10 : http://layers.openstreetmap.fr/?zoom=10lat=42.99339lon=0.03191layers=BFFTFFF les communes sont panachées suivant les tuiles, et les dernières relations que j'ai rentrés ne sont pas coloriées. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tags point crottes de chiens !
Le 16 août 2012 17:02, Stéphane MARTIN st3ph.mar...@laposte.net a écrit : Description : - Panneau avec une représentation de chien - Distributeur de sac pour ramasser... - Poubelle pour recueillir l'objet du déli^ ramassage. Excellente idée à cartographier ! Pour le distributeur : cf. http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dvending_machine amenity=vending_machine vending=excrement_bags payment:none=yes operator=Nom de l'organisme opérateur ref=numéro s'il y en a un Pour la poubelle : cf. http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dwaste_basket amenity=waste_basket Damouns ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Affichage des communes sur layers.openstreetmap.fr en retard ( était : MissingCommunes à nouveau =?iso-8859-1?q?_op=E9rationnel?=)
si on jette un coup d'oeuil sur mon compte : http://www.openstreetmap.org/user/HelenePETIT/edits on vois que je continue à rentrer des limites de communes (bos suetus aratro) ; je ne vois plus mon travail avancer sur layer, je me suis dit que ça allait s'arranger, mais non, ça dure une peu ; http://layers.openstreetmap.fr/?zoom=12lat=43.05275lon=-0.00204layers=B0 000FFTFFF Vu. Ce que tu as fais est bon, c'est layers qui a changé de fonctionnement il n'y a pas longtemps pour que l'affichage se fasse plus rapidement qu'avant (meilleurs performances) mais n'est plus à jour temps réél comme avant Ce n'est pas moi qui est géré, mais il me semble qu'il faut attendre 24h00 pour que le rendu se remette à jour après un premier passage de consultation dans la zone. C'est donc moins au fil de l'eau, mais le serveur utilisé était tout le temps saturé et on à dû agir. Si tu zoom suffisamment pour atteindre un zoom où personne n'était allé avant, tu devrais d'ailleurs les voir apparaître A tous les zoom il y a des bout de tuiles coloriées en gris foncé, ça n'est pas trop gênant, je n'y pase pas la nuit non plus. Un dommage collatéral du nouveau système qu'on a pas réussi à régler -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [forum-osm-fr]De l'usage du pédestrian
Reste la question de comment faire pour identifier et nommer l'endroit correctement. Je pense comme lui que mettre pedestrian sur un carrefour routier n'est pas la bonne manière de tagguer, mais il n'y a pour l'instant pas vraiment de solution pour tagguer une place, donc je compati avec ceux qui font ça. N'ayant pour l'instant pas trouvé chaussure à mon pied, ce que je fais c'est tracer le contour de la place avec un polygone, je mets un name=Place des seigneurs sith et un fixme=ceci est une place avec un nom mais n'est pas uniquement piétonne donc pas de pedestrian et rien d'autre. Un jour peut être on aura un tag pour dire que c'est une place, indépendamment de l'utilisation (piéton, parc, parking, tram, carrefour, rond point ou un mixe de tout ça) et alors je reviendrais sur mes place... si j'y pense. L'option proposée par Philippe avec place=locality est mauvaise à mon avis car on désigne généralement par ce biais un lieu-dit. Certains utilisent aussi locality pour désigner les noms de quartiers en ville. On voit qu'on est loin du nom d'une place qu'on devrait tagguer comme une rue, amha (c.a.d attaché à un highway ouvert ou fermé). Pareil : pas locality, c'est pas fait pour, et ce serait tagguer pour le rendu. De plus je ne suis pas tout à fait d'accord avec ton raccourcis locality c'est (généralement) pour les lieux-dits place=locality c'est à utiliser pour un lieu, ayant un nom, n'ayant pas de population et pour lequel aucun autre tag existant ne s'applique. (c'est un bouche trou quoi) -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tags point crottes de chiens !
Au passage, une idée pour les espaces chien aussi ? Petits espaces fermés en terre ou gravier où ils peuvent se soulager (par exemple à Grenoble). Bruno Le 16 août 2012 18:02, Damouns damo...@gmail.com a écrit : Le 16 août 2012 17:02, Stéphane MARTIN st3ph.mar...@laposte.net a écrit : Description : - Panneau avec une représentation de chien - Distributeur de sac pour ramasser... - Poubelle pour recueillir l'objet du déli^ ramassage. Excellente idée à cartographier ! Pour le distributeur : cf. http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dvending_machine amenity=vending_machine vending=excrement_bags payment:none=yes operator=Nom de l'organisme opérateur ref=numéro s'il y en a un Pour la poubelle : cf. http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dwaste_basket amenity=waste_basket Damouns ___ 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] Tags point crottes de chiens !
Vending_machine ? Dans la plupart des municipilatés (au moins celles qui ont un plan environnement pour obtenir un label) c'est gratuit. Sinon personne l'utilisera et les crottes de chiens resteront dans le caniveau (au mieux) ou sur les trottoirs. Il y a aussi les sanidogs, ou d'autres mots-valises du même genre (des bacs à sable fait exprès parce que les chiens préfèrent crotter dans un truc qu'il peuvent faire semblant d'enterrer, mais aussi parce que ça permet d'absorber les odeurs en drainant les liquides. Normalement les propriétaires sont aussi sensés ramasser mais souvent les crottes restent sur le sable.) En revanche pour faire pisser un chien ailleurs que sur un mur, un poteau ou une roue de voiture... on peut s'accrocher. Peu de propriétaires apprennent à leur chien le caniveau (ils les laissent uriner où ils veulent) même ça dégouline sur les trottoirs. Certaines municipalités mettent des matériaux absorbants au pied des arbres, mais trop souvent on goudronne jusqu'au bord, ou des carrés verts en friche pour faire courir les chiens et les laisser faire leurs besoins sur place (ce n'est pas ramassé quand c'est une friche humide, la nature fait le travail d'assainissement et d'absorbtion dans le sol et de traitement par les végétaux et insectes). Ça donne des zones ouvertes aux chiens (et signalées). A cartographier aussi les zones protégées interdites aux chiens, même en laisse (très souvent les plages, dunes et forêts d'agrément près des zones de loisir ; peu de plages sont ouvertes aux chiens, mais là normalement les propriétaires sont sensés ramasser et on trouve les distributeurs de sachets et poubelles). Le 16 août 2012 19:03, Bruno Besson bruno.bes...@gmail.com a écrit : Au passage, une idée pour les espaces chien aussi ? Petits espaces fermés en terre ou gravier où ils peuvent se soulager (par exemple à Grenoble). Bruno Le 16 août 2012 18:02, Damouns damo...@gmail.com a écrit : Le 16 août 2012 17:02, Stéphane MARTIN st3ph.mar...@laposte.net a écrit : Description : - Panneau avec une représentation de chien - Distributeur de sac pour ramasser... - Poubelle pour recueillir l'objet du déli^ ramassage. Excellente idée à cartographier ! Pour le distributeur : cf. http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dvending_machine amenity=vending_machine vending=excrement_bags payment:none=yes operator=Nom de l'organisme opérateur ref=numéro s'il y en a un Pour la poubelle : cf. http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dwaste_basket amenity=waste_basket Damouns ___ 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] [forum-osm-fr]De l'usage du pédestrian
Le 16 août 2012 18:42, sly (sylvain letuffe) li...@letuffe.org a écrit : Reste la question de comment faire pour identifier et nommer l'endroit correctement. Je pense comme lui que mettre pedestrian sur un carrefour routier n'est pas la bonne manière de tagguer, mais il n'y a pour l'instant pas vraiment de solution pour tagguer une place, donc je compati avec ceux qui font ça. N'ayant pour l'instant pas trouvé chaussure à mon pied, ce que je fais c'est tracer le contour de la place avec un polygone, je mets un name=Place des seigneurs sith et un fixme=ceci est une place avec un nom mais n'est pas uniquement piétonne donc pas de pedestrian et rien d'autre. Un jour peut être on aura un tag pour dire que c'est une place, indépendamment de l'utilisation (piéton, parc, parking, tram, carrefour, rond point ou un mixe de tout ça) et alors je reviendrais sur mes place... si j'y pense. L'option proposée par Philippe avec place=locality est mauvaise à mon avis car on désigne généralement par ce biais un lieu-dit. Certains utilisent aussi locality pour désigner les noms de quartiers en ville. On voit qu'on est loin du nom d'une place qu'on devrait tagguer comme une rue, amha (c.a.d attaché à un highway ouvert ou fermé). Pareil : pas locality, c'est pas fait pour, et ce serait tagguer pour le rendu. Je ne suis pas d'accord, place=locality désigne tout lieu petit avec un voisinage imprécis. C'est le cas des places dont on ne sait pas exactement où elles commencent si ce n'est devant les limites de parcelles privées. Une place convient très bien au plan sémantique c'est une petite zone qui a un nom. De plus je ne suis pas tout à fait d'accord avec ton raccourcis locality c'est (généralement) pour les lieux-dits place=locality c'est à utiliser pour un lieu, ayant un nom, n'ayant pas de population et pour lequel aucun autre tag existant ne s'applique. (c'est un bouche trou quoi) Pas de population ?? La plupart des lieux-dits ont quelques habitations voire une seule (c'est plus petit qu'un hameau). Regardez la plupart des fermes dans les campagnes. C'est d'elles que viennent les noms de lieux-dits (même si aujourd'hui ils ne sont plus habités). Ou alors tu veux utiliser place=isolated_dwelling pour les bâtiments isolés. ou noms de résidences qu'on trouve en campagne ou en périphérie rurbaine. D'ailleurs plein de quartiers (souvent non clairement délimités administrativement) sont tagués avec place=locality. On y trouve souvent les points d'information et plans de ville, c'est souvent d'ailleurs sur une petite place, formé par un carrefour) même si souvent on n'y a tagué que les rues (parce que la place elle-même n'a pas de nom). Si la place a un nom et a ce point d'information, elle donne aussi le nom du lieux-dits. Sinon on peut proposer place=square... ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Affichage des communes sur layers.openstreetmap.fr en retard ( était : MissingCommunes à nouveau =?iso-8859-1?q?_op=E9rationnel?=)
Le 16/08/2012 18:29, sly (sylvain letuffe) a écrit : Ce n'est pas moi qui est géré, mais il me semble qu'il faut attendre 24h00 pour que le rendu se remette à jour après un premier passage de consultation dans la zone. Nan ! le premier lien que j'ai donné : http://layers.openstreetmap.fr/?zoom=12lat=42.97819lon=-0.05513layers=BFFTFFF est dans mes signet depuis deux semaines, et je l'affiche chaque matin, depuis le 11 aout dans l'espoir de le voir se remettre en route, ce qui n'arrive pas. Si tu zoom suffisamment pour atteindre un zoom où personne n'était allé avant, tu devrais d'ailleurs les voir apparaître Je ne comprends pas la logique de la chose Cet outils me servaient à mieux choisir l'ordre dans lequel je rentre les communes, en fonction de la forme des trous et de la présence ou non de repères ; 24h de délai de mise à jour, ça rend l'outil totalement inutile pour mon travail. Je perds désormai beaucoup de temps à tatonner pour trouver les trous ; tant pis. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Affichage des communes sur layers.openstreetmap.fr en retard ( était : MissingCommunes à nouveau =?iso-8859-1?q?_op=E9rationnel?=)
2012/8/16 Hélène PETIT h...@free.fr: Nan ! le premier lien que j'ai donné : http://layers.openstreetmap.fr/?zoom=12lat=42.97819lon=-0.05513layers=BFFTFFF est dans mes signet depuis deux semaines, et je l'affiche chaque matin, depuis le 11 aout dans l'espoir de le voir se remettre en route, ce qui n'arrive pas. Effectivement, le lien http://layers.openstreetmap.fr/admin8/12/2047/1505.png/status montrait qu'il n'avait pas été mis à jour depuis le 10 aout. J'ai lancé une mise à jour avec http://layers.openstreetmap.fr/admin8/12/2047/1505.png/dirty, ce qui a fonctionné, mais je ne vois pas vraiment de différence sur l'image. En tout cas, ça devrait normalement se mettre à jour tout seul: je vais regarder si les différents paramètres utilisés par mod_tile+renderd sont corrects. Merci, Jocelyn ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tags point crottes de chiens !
Le jeudi 16 août 2012 19:35:46 Philippe Verdy a écrit : Vending_machine ? Dans la plupart des municipilatés (au moins celles qui ont un plan environnement pour obtenir un label) c'est gratuit. Sinon personne l'utilisera et les crottes de chiens resteront dans le caniveau (au mieux) ou sur les trottoirs. […] TL;DR Pour le distributeur : cf. http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dvending_machine amenity=vending_machine vending=excrement_bags payment:none=yes operator=Nom de l'organisme opérateur ref=numéro s'il y en a un RTFM !! (et zut, j'ai marché dedans) -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [forum-osm-fr]De l'usage du pédestrian
2012/8/16 Philippe Verdy verd...@wanadoo.fr: Sinon on peut proposer place=square... Bon alors, à l'attention des moins anciens qui pourraient se troubler à la lecture de ce fil de discussion, il faut dire que Philippe se trompe complètement (une fois de plus). On a d'un côté la clé place, genre: place=city, town, village, hamlet, isolated_dwelling, locality pour désigner une grande ville, petite ville, village, hameau, habitation isolée ou lieux-dit inhabité (lire le wiki svp) De l'autre, on a la clé highway, genre: highway=residential, pedestrian, unclassified pour désigner les voies de circulation résidentielles, rues piétonnes, voies non-classées, etc Un square piéton est taggué partout dans le monde avec highway=pedestrian + area=yes. A chacun de voir ce qui est le plus logique. Et de regarder un peu comment font les autres contributeurs dans leur région ou les grandes villes (et pas qu'en France). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Affichage des communes sur layers.openstreetmap.fr en retard ( était : MissingCommunes à nouveau =?iso-8859-1?q?_op=E9rationnel?=)
2012/8/16 Hélène PETIT h...@free.fr: Je ne comprends pas la logique de la chose Cet outils me servaient à mieux choisir l'ordre dans lequel je rentre les communes, en fonction de la forme des trous et de la présence ou non de repères ; 24h de délai de mise à jour, ça rend l'outil totalement inutile pour mon travail. Je perds désormai beaucoup de temps à tatonner pour trouver les trous ; tant pis. Je comprend la frustration d'Hélène. Mais j'adhère aussi totalement à la suppression de l'ancien système qui était super-lent (rendu calculé en live à chaque fois). N'y aurait-il pas moyen d'adopter le système utilisé pour le rendu standard avec Mapnik, c.a.d que les tuiles sont marquées à refaire par osm2pqsql lorsque de nouvelles données arrivent mais que la tuile n'est redessinée que si quelqu'un veut la voir avec son navigateur ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tags point crottes de chiens !
2012/8/16 Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net: payment:none=yes Quand même, j'avais pas encore remarqué ce tag. Faut vraiment avoir l'esprit tordu. C'est comme si on remplaçait les oneway=no par oneway:none=yes ^^ Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tags point crottes de chiens !
Le 16/08/2012 23:02, Pieren a écrit : 2012/8/16 Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net: payment:none=yes Quand même, j'avais pas encore remarqué ce tag. Faut vraiment avoir l'esprit tordu. C'est comme si on remplaçait les oneway=no par oneway:none=yes ^^ Pieren http://taginfo.openstreetmap.org/keys/payment:none#map Ils ne connaissent pas le tag fee=no ? Je croyais que Pourquoi faire simple quand on peut faire compliqué ? c'était une devise shadock. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [forum-osm-fr]De l'usage du pédestrian
Le 16 août 2012 22:50, Pieren pier...@gmail.com a écrit : 2012/8/16 Philippe Verdy verd...@wanadoo.fr: Sinon on peut proposer place=square... Bon alors, à l'attention des moins anciens qui pourraient se troubler à la lecture de ce fil de discussion, il faut dire que Philippe se trompe complètement (une fois de plus). Tu n'as pas lu le reste ... Encore une réponse inutilement agressive !?! On a d'un côté la clé place, genre: place=city, town, village, hamlet, isolated_dwelling, locality pour désigner une grande ville, petite ville, village, hameau, habitation isolée ou lieux-dit inhabité (lire le wiki svp) De l'autre, on a la clé highway, genre: highway=residential, pedestrian, unclassified pour désigner les voies de circulation résidentielles, rues piétonnes, voies non-classées, etc Un square piéton est taggué partout dans le monde avec highway=pedestrian + area=yes. Sauf que justement on revient au problème : la place (française) n'est pas QUE piétonne. Ce qu'on appelle place en français n'est pas lié à la seule fonction de se déplacer et surtout pas à un seul moyen de transport (pédestre) mais désigne bien le **lieu**, la localité, auquel on donne un nom local. autrement dit exactement ce qu'on appelle un lieu-dit, notion géographique, et non liée aux transport. Il s'agit ici bien d'un **toponyme**, pas d'une rue; certainement pas un highway, mais une zone plus petite qu'un quartier, sans délimitation adminstrative, et surtout ici qui contient un ensemble de rues et chemins qui traversent ou bordent ladite place. Ce lieu n'incluent en lui-même AUCUNE habitation (les habitations sont à l'adresse de la rue qui les borde, et non pas **dans** la place. Lieu nommé, inhabité. Parfait donc pour un lieu-dit. Parfait pour place=locality. Et peu importe d'ailleurs que ce lieu doit inclus dans un autre place=* (la ville, le village). D'ailleurs on utilse place=town pour une commune qui en borde une autre, les deux étant pourant dans la même aggglomération qui porte aussi un nom. Si la notion d'habitation et d'habitants était pertinente, on ne devrait même pas utiliser place=* pour les communes, mais seulement pour les agglomérations. et pourtant on met sur la carte des tas de place=locality pour les lieux-dits en pleine campagne alors qu'ils sont EUX AUSSI inclus dans le territoire de la commune (qu'on a pourtant tagué avec place=town, place=village...) Cherchez la cohérence ! L'incohérence n'est pas dans ce que j'ai mis mais alors dans le fait d'avoir utilisé place=* pour les communes. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Déplacement bâti par erreur...
Bonjour, En regardant sur ma page osmose je me suis rendu compte d'un truc pas joli...j'ai manifestement déplacé (fausse manip) différents bâtiments sur la nationale 20... Comment puis-je revenir à l'emplacement d'origine ? Merci d'avance. ++ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Déplacement bâti par erreur...
Bonjour, Le 17/08/2012 07:14, Eric Pommereau a écrit : En regardant sur ma page osmose je me suis rendu compte d'un truc pas joli...j'ai manifestement déplacé (fausse manip) différents bâtiments sur la nationale 20... Comment puis-je revenir à l'emplacement d'origine ? Tu en as beaucoup dans ce cas ? Sur quelle étendue ? Si le déplacement est homogène, on peut imaginer leur faire faire le chemin inverse en une fois, le souci étant de bien les sélectionner. Pour ça, une fois la zone chargée, tu peux essayer par leur n° de changeset (taper changeset: building dans l'outil de recherche de JOSM, où est le n° de changeset), à combiner éventuellement au diagnostic du Validator : j'imagine que si Osmose les détecte, c'est à cause du chevauchement de ces bâtiments avec une route. Tu peux aussi voir du côté du plugin Reverter : http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Reverter pour faire marche arrière. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
