Re: [OSM-talk-fr] [BANO] rapprochement sur les lieu-dits /voisinage/ quartier
Chouette ! Comme quoi, quand on voit quoi aller pister, les nombres s'améliorent (98.5% des voies avec numéro ok dans Troyes, le reste étant inexistant sur le terrain, contre 40% de celles sans numéro…). On peut avoir les liens d'édition de carte pour les nouvelles colonnes aussi ? JB. Le 15/10/2014 23:49, Vincent de Château-Thierry a écrit : Bonsoir, Le 14/10/2014 14:31, Vincent de Château-Thierry a écrit : C'est bien prévu oui. Je voulais le faire la semaine dernière, mais un sujet est venu par dessus dans la pile : les rues sans adresses [1], quelle que soit la source. Pour l'instant, le rendu carto comme la page de listes de voies ne considèrent que les rues avec au moins 1 adresse, côté Cadastre ou côté OSM. Or un paquet de voies sont sur le terrain dépourvues de n°, de plaques adresses. Le constat qu'on fait pour l'instant, tant sur les tuiles que via les listes, n'est donc qu'un sous-ensemble des rues existantes. Mon travail de ces jours-ci vise à pouvoir lister ces rues non adressées, en distinguant 3 ensembles : - celles rapprochées de FANTOIR, - celles connues uniquement d'OSM, - celles connues uniquement de FANTOIR Ces 2 derniers groupes nous donneront pas mal de matière, car elles indiqueront de potentiels manques côté OSM : manque de géométrie, manque de nommage, typos, ou tout simplement divergence de nommage avec FANTOIR. Ce nouveau paquet (les rues sans adresses) va donner lieu à de nouveaux onglets dans les listes, et aussi à une nouvelle sortie de contenu depuis BANO : chaque rue connue à la fois d'OSM et de FANTOIR deviendra dans BANO un point, permettant de se situer sur la voie. BANO est ici à la fois un outil d'amélioration d'OSM et un consommateur de ces améliorations Des résultats de ce chantier, côté listes, dans les prochains soirs. Je viens d'ajouter 2 listes de voies sur : http://cadastre.openstreetmap.fr/fantoir/ Elles reprennent ce que j'évoquais hier (ci-dessus), à savoir les listes de voies où aucune adresse n'est connue, listes séparées entre voies connues de Fantoir, et les autres. Ça s'appuie sur le tout nouveau contenu de BANO qui représente chaque voie par un point, en s'affranchissant des n°, contenu à peine sec (première production la nuit dernière). Parmi les points à traiter sur ces listes : ajouter la capacité d'afficher les cartes et d'éditer, comme pour les voies numérotées. Je compte utiliser les parcelles pour déterminer la zone de cadrage, vu qu'ici par définition on ne peut pas utiliser la géométrie des n° d'adresses. À suivre et vos retours bienvenus. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [BANO] rapprochement sur les lieu-dits /voisinage/ quartier
Salut Vincent, Il n'y aurait pas une erreur d'intitulé sur les colonnes ? Je lis dans le désordre voies FANTOIR sans rapprochement OSM voies FANTOIR sans rapprochement OSM voies FANTOIR avec rapprochement OSM voies FANTOIR avec rapprochement OSM Ou alors certaines sous-colonnes ne sont pas au bon endroit Stf Le 15/10/2014 23:49, Vincent de Château-Thierry a écrit : Je viens d'ajouter 2 listes de voies sur : http://cadastre.openstreetmap.fr/fantoir/ Elles reprennent ce que j'évoquais hier (ci-dessus), à savoir les listes de voies où aucune adresse n'est connue, listes séparées entre voies connues de Fantoir, et les autres. Ça s'appuie sur le tout nouveau contenu de BANO qui représente chaque voie par un point, en s'affranchissant des n°, contenu à peine sec (première production la nuit dernière). Parmi les points à traiter sur ces listes : ajouter la capacité d'afficher les cartes et d'éditer, comme pour les voies numérotées. Je compte utiliser les parcelles pour déterminer la zone de cadrage, vu qu'ici par définition on ne peut pas utiliser la géométrie des n° d'adresses. À suivre et vos retours bienvenus. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [BANO] rapprochement sur les lieu-dits /voisinage/ quartier
Tu as 2 grandes colonnes: avec ou sans adresses et pour chaque avec ou sans rapprochement OSM, du coup ça fait 2x2=4... Le 16 octobre 2014 08:24, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : Salut Vincent, Il n'y aurait pas une erreur d'intitulé sur les colonnes ? Je lis dans le désordre voies FANTOIR sans rapprochement OSM voies FANTOIR sans rapprochement OSM voies FANTOIR avec rapprochement OSM voies FANTOIR avec rapprochement OSM Ou alors certaines sous-colonnes ne sont pas au bon endroit Stf Le 15/10/2014 23:49, Vincent de Château-Thierry a écrit : Je viens d'ajouter 2 listes de voies sur : http://cadastre.openstreetmap.fr/fantoir/ Elles reprennent ce que j'évoquais hier (ci-dessus), à savoir les listes de voies où aucune adresse n'est connue, listes séparées entre voies connues de Fantoir, et les autres. Ça s'appuie sur le tout nouveau contenu de BANO qui représente chaque voie par un point, en s'affranchissant des n°, contenu à peine sec (première production la nuit dernière). Parmi les points à traiter sur ces listes : ajouter la capacité d'afficher les cartes et d'éditer, comme pour les voies numérotées. Je compte utiliser les parcelles pour déterminer la zone de cadrage, vu qu'ici par définition on ne peut pas utiliser la géométrie des n° d'adresses. À suivre et vos retours bienvenus. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sites de routage basés sur OSM : numéros de rue?
___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [BANO] rapprochement sur les lieu-dits /voisinage/ quartier
Le 16 oct. 2014 à 08:09, JB jb...@mailoo.org a écrit : On peut avoir les liens d'édition de carte pour les nouvelles colonnes aussi ? +1 C’est difficile de retrouver une rue Mais je cros que Vincent y travaille ;-) Parmi les points à traiter sur ces listes : ajouter la capacité d'afficher les cartes et d'éditer, comme pour les voies numérotées. Je compte utiliser les parcelles pour déterminer la zone de cadrage, vu qu'ici par définition on ne peut pas utiliser la géométrie des n° d’adresses. Merci, — Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [BANO] rapprochement sur les lieu-dits /voisinage/ quartier
Le 16/10/2014 08:51, Christian Quest a écrit : Tu as 2 grandes colonnes: avec ou sans adresses et pour chaque avec ou sans rapprochement OSM, du coup ça fait 2x2=4... Je me doutais que c'était un truc dans le genre. Avec Chrome, c'est Ok, mais pas avec Firefox (cache vidé) ni avec internet explorer, tout est réuni sous la colonne avec adresse. Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Josm 7588] Un message d'erreur que je ne comprends pas bien
2014-10-15 23:55 GMT+02:00 Vincent de Château-Thierry osm.v...@free.fr: Ça interpelle les débutants, soit. Mais, si je te suis, il faudrait préconiser 2 manières de tagguer, en fonction de l'analyse faite sur les tags des membres. À expliquer et à assimiler, c'est pire... Au moins, statuer que pour _tous_ les multipolygons les tags sont sur la relation, c'est constant, donc au final, à mon avis, plus simple. Pas forcément. On pourrait aussi dire que la valeur du polygone se définit toujours sur le/les ways extérieurs (outer), qu'il soit simple ou multi. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sites de routage basés sur OSM : numéros de rue?
Bonjour, Perso j'utilise souvent OpenRouteService, qui permet de choisir les itinéraires les plus sûrs à vélo, d'exporter en GPX, de définir des zones à éviter ou des points par lesquelles passer, de créer un profil d'élévation du parcours défini. Il n'est pas parfait mais il s'en sort plutôt bien je trouve. Grâce à cet, j'ai trouvé des itinéraires cyclables que je n'aurais pas trouvé par moi-même et que Google ne connaissait pas non plus. OSMR est bien pour un trajet en voiture mais il ne permet pas de passer par des tronçons interdits aux bagnoles. Bonne journée, Maxime 2014-10-16 9:01 GMT+02:00 desgranges.p...@neuf.fr: Pour préparer des sorties vélo et dessiner des parcours, voir le dénivelé, les pourcentage de pente etc, je me sers de openrunner. Vraiment pas mal ! Je cherche une solution simple et légère pour dessiner des parcours à vélo (important : j'aimerais pouvoir forcer le passage même si NOK pour voitures): 1. Je tape l'adresse source, l'adresse destination 2. Il affiche un parcours, que je peux personnaliser en tirant dessus 3. Export en KML. Merci. -- View this message in context: http://gis.19327.n5.nabble.com/Sites-de-routage-bases-sur-OSM-numeros-de-rue-tp5820443.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [BANO] rapprochement sur les lieu-dits /voisinage/ quartier
Le 16/10/2014 09:18, Yves Pratter a écrit : Parmi les points à traiter sur ces listes : ajouter la capacité d'afficher les cartes et d'éditer, comme pour les voies numérotées. Je compte utiliser les parcelles pour déterminer la zone de cadrage, vu qu'ici par définition on ne peut pas utiliser la géométrie des n° d’adresses. Oups, lu trop vite… Juste un carré de 50m*50m autour du point central (celui repéré par Bano), ça me suffirait… Après, on peut toujours télécharger plus large si nécessaire ? JB. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sites de routage basés sur OSM : numéros de rue?
Le jeudi 16 octobre 2014 09:55:56 Maxime Résibois a écrit : Bonjour, Perso j'utilise souvent OpenRouteService, qui permet de choisir les itinéraires les plus sûrs à vélo, d'exporter en GPX, de définir des zones à éviter ou des points par lesquelles passer, de créer un profil d'élévation du parcours défini. Il n'est pas parfait mais il s'en sort plutôt bien je trouve. Grâce à cet, j'ai trouvé des itinéraires cyclables que je n'aurais pas trouvé par moi-même +1 -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [BANO] rapprochement sur les lieu-dits /voisinage/ quartier
Selon Stéphane Péneau stephane.pen...@wanadoo.fr: Avec Chrome, c'est Ok, mais pas avec Firefox (cache vidé) ni avec internet explorer, tout est réuni sous la colonne avec adresse. Je reproduis avec FF :( Privilégiez Chrome pour l'instant, si vous pouvez vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Josm 7588] Un message d'erreur que je ne comprends pas bien
Selon Pieren pier...@gmail.com: Pas forcément. On pourrait aussi dire que la valeur du polygone se définit toujours sur le/les ways extérieurs (outer), qu'il soit simple ou multi. Oui mais là on tourne en rond, vu que pour les multipolygones c'est exactement cette modélisation qui pose problème, car rien n'empêche une incohérence entre les tags des différents ways outer. À partir de là, l'exploitation de l'objet complet représenté par la relation devient un cauchemar et une loterie. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sites de routage basés sur OSM : numéros de rue?
2014-10-15 23:56 GMT+02:00 Shohreh codecompl...@free.fr: Avant de passer plus de temps là-dessus, j'aimerais vérifier une chose : apparemment, OSM souffre du manque de numéros de rues parce que ça demande un gros boulot pour rentrer ces infos. Si c'est le cas, c'est rédhibitoire quand on veut dessiner des parcours en ville. Pouvez-vous confirmer? Quelle ville ? Tu peux vérifier par toi-même si les numéros sont déjà dans OSM pour ta ville de prédilection en regardant simplement la carte principale et en zoomant pour voir les détails. Si tu vois que ça manque, tu peux soit te lancer dans l'ajout des numéros toi-même, soit chercher un membre de la communauté plus aguerri qui acceptera de le faire à ta place. Si c'est dans beaucoup de petites villes/villages, ça prendra aussi beaucoup plus de temps. Mais la navigation à la rue près, c'est déjà pas mal (à condition de mettre les noms de rues manquants dans OSM, mais ça, tu peux aussi certainement le faire toi-même). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [BANO] rapprochement sur les lieu-dits /voisinage/ quartier
En effet, Il y a un problème de taille sur les balises TR et TD. Faire un dimensionnement en 100% sur le tableau, 50% sur les TD du header, et 25% sur les colonnes TD en dessous ça évitera les problèmes Le 16 octobre 2014 10:01, JB jb...@mailoo.org a écrit : Le 16/10/2014 09:18, Yves Pratter a écrit : Parmi les points à traiter sur ces listes : ajouter la capacité d'afficher les cartes et d'éditer, comme pour les voies numérotées. Je compte utiliser les parcelles pour déterminer la zone de cadrage, vu qu'ici par définition on ne peut pas utiliser la géométrie des n° d’adresses. Oups, lu trop vite… Juste un carré de 50m*50m autour du point central (celui repéré par Bano), ça me suffirait… Après, on peut toujours télécharger plus large si nécessaire ? JB. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Josm 7588] Un message d'erreur que je ne comprends pas bien
Si on met les tags juste sur les ways outer, les autres ways inner risquent de ne pas être chargés et on va obtenir un rendu ou une analyse incorrecte sur les zones couvertes par les enclaves où le tag ne s'applique pas. De plus il arrive assez souvent que les tags applicable au multipolygone entier ne puisse PAS s'appliquer sans conflit sur les ways outer qui sont aussi des way outer d'autres multipolygone (il y a souvent des conflits d'interprétation entre les valeurs de tag selon la présence d'autres tags ou selon le type de multipolygone (notamment les highway=*, waterway=*; natural=*; man_made=* qui sont un peu trop fourre-tout) Il est logique de ne plus utiliser des tags sur des ways qui ne sont pas interprétables correctement hors du multipolygone complet qui seul définit la géométrie applicable sur l'objet complètement délimité. De plus en terme de maintenance on évite une redondance de données, l'info est centralisée au bon endroit sans avoir besoin d'être dupliquée et maintenue de façon cohérente dans tous les membres outer (d'autant plus qu'il arrive fréquemment que lors de correction de précision, des ways changent de role outer/inner (et nombre d'utilisateurs oublient de changer ce rôle qui est surtout informatif dans les relations multipolygon, boundary et similaires décrivant des surfaces) Il faut absolument apprendre aux utilisateurs qu'un chemin seul même s'il ne semble pas avoir de tags utile, peut être lié à des relations qui définissent son usage. Mais du fait que les éditeurs si,ples pour débutant dissimulent trop ces informations (iD est horrible, il rend ces infos quasi invisibles), on doit encore mettre quelques infos minimales redondantes sur les ways. Ce problème existe tout autant quand on consulte un objet sur le site ou son historique: sans cette redondance minimale (ou un tag informatif de note) ces objets ne sont pas facilement repérable dans des longues listes d'objet pour faciliter leur sélection correcte lors de l'édition. Bref on doit mettre tous les tags utile sur les polygones et non sur les ways si ces tags sont implicitement interprétés comme applicables, et surtout si ces ways sont fermés. On doit supprier ces tags des ways pour éviter aussi des conflits de valeurs de tags entre la valeur donnée dns le multipolygone et celle sur le way. Pour le reste on peut mettre un peu de redondance mais à caractère informatif sur le way. L'ennui est que pour certains tags, il est tout à fait normal d'avoir une différence de valeur entre le tag de la relation et celui du way; notamment sur les tags name qui autorisent d'avoir un nom local approprié différent de celui de la relation complète. Dans d'autres cas c'est tout bonnement incorrect d'avoir le tag sur le way outer, notamment sur les ways partagés par des relations décrivant des surfaces adjascentes et toutes deux avec le rôle outer, car le tag sera bon pour une relation mais pas pour l'autre. Le seul moyen de résoudre le conflit d'interprétation est de mettre les tags appropriés pour chaque surface dans chaque relation et pas du tout sur le way mitoyen (où ne peut figurer qu'un tag informatif qui ne doit jamais être interprété comme modifiant localement l'interprétation donnée par les relations complètes, et sans ce cas on n'a souvent qu'un seul moyen, celui d'une note informative mais surtout pas avec les mêmes tags avec des valeurs locales différentes). Le 16 octobre 2014 09:53, Pieren pier...@gmail.com a écrit : 2014-10-15 23:55 GMT+02:00 Vincent de Château-Thierry osm.v...@free.fr: Ça interpelle les débutants, soit. Mais, si je te suis, il faudrait préconiser 2 manières de tagguer, en fonction de l'analyse faite sur les tags des membres. À expliquer et à assimiler, c'est pire... Au moins, statuer que pour _tous_ les multipolygons les tags sont sur la relation, c'est constant, donc au final, à mon avis, plus simple. Pas forcément. On pourrait aussi dire que la valeur du polygone se définit toujours sur le/les ways extérieurs (outer), qu'il soit simple ou multi. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Josm 7588] Un message d'erreur que je ne comprends pas bien
Le problème par rapport au logiciel SIG sur le mutipolygones c'est de considérer qu'un Inner peut être différent du polygon englobant... En fait il faudrait faire que les way inner et outer. Puis créer le mutipolygone à la fin et le qualifier. Exmeple: Comme pour les lacs à élément multiple contenant des ilots de terre. Et traiter ça comme une seule couche. Puis dessiner ensuite dans les trous les landuses sur les noeuds existant. ça fait un double traitement mais ça c'est propre et simple à convertir sur d'autre SIG. Là, sur OSM, on considère que tout est mélangeable (empilable) pour avoir des objets imbriquable à souhait. C'est là que pose le problème et c'est une logique qu'un sigiste n'a pas car l'ensemble des autres soft ne focntionnent pas ainsi mais par couches séparées ou par objet séparé et jointif. Donc non imbriqué. 9a c'est lié au format XML ou JSON Le 16 octobre 2014 10:36, Philippe Verdy verd...@wanadoo.fr a écrit : Si on met les tags juste sur les ways outer, les autres ways inner risquent de ne pas être chargés et on va obtenir un rendu ou une analyse incorrecte sur les zones couvertes par les enclaves où le tag ne s'applique pas. De plus il arrive assez souvent que les tags applicable au multipolygone entier ne puisse PAS s'appliquer sans conflit sur les ways outer qui sont aussi des way outer d'autres multipolygone (il y a souvent des conflits d'interprétation entre les valeurs de tag selon la présence d'autres tags ou selon le type de multipolygone (notamment les highway=*, waterway=*; natural=*; man_made=* qui sont un peu trop fourre-tout) Il est logique de ne plus utiliser des tags sur des ways qui ne sont pas interprétables correctement hors du multipolygone complet qui seul définit la géométrie applicable sur l'objet complètement délimité. De plus en terme de maintenance on évite une redondance de données, l'info est centralisée au bon endroit sans avoir besoin d'être dupliquée et maintenue de façon cohérente dans tous les membres outer (d'autant plus qu'il arrive fréquemment que lors de correction de précision, des ways changent de role outer/inner (et nombre d'utilisateurs oublient de changer ce rôle qui est surtout informatif dans les relations multipolygon, boundary et similaires décrivant des surfaces) Il faut absolument apprendre aux utilisateurs qu'un chemin seul même s'il ne semble pas avoir de tags utile, peut être lié à des relations qui définissent son usage. Mais du fait que les éditeurs si,ples pour débutant dissimulent trop ces informations (iD est horrible, il rend ces infos quasi invisibles), on doit encore mettre quelques infos minimales redondantes sur les ways. Ce problème existe tout autant quand on consulte un objet sur le site ou son historique: sans cette redondance minimale (ou un tag informatif de note) ces objets ne sont pas facilement repérable dans des longues listes d'objet pour faciliter leur sélection correcte lors de l'édition. Bref on doit mettre tous les tags utile sur les polygones et non sur les ways si ces tags sont implicitement interprétés comme applicables, et surtout si ces ways sont fermés. On doit supprier ces tags des ways pour éviter aussi des conflits de valeurs de tags entre la valeur donnée dns le multipolygone et celle sur le way. Pour le reste on peut mettre un peu de redondance mais à caractère informatif sur le way. L'ennui est que pour certains tags, il est tout à fait normal d'avoir une différence de valeur entre le tag de la relation et celui du way; notamment sur les tags name qui autorisent d'avoir un nom local approprié différent de celui de la relation complète. Dans d'autres cas c'est tout bonnement incorrect d'avoir le tag sur le way outer, notamment sur les ways partagés par des relations décrivant des surfaces adjascentes et toutes deux avec le rôle outer, car le tag sera bon pour une relation mais pas pour l'autre. Le seul moyen de résoudre le conflit d'interprétation est de mettre les tags appropriés pour chaque surface dans chaque relation et pas du tout sur le way mitoyen (où ne peut figurer qu'un tag informatif qui ne doit jamais être interprété comme modifiant localement l'interprétation donnée par les relations complètes, et sans ce cas on n'a souvent qu'un seul moyen, celui d'une note informative mais surtout pas avec les mêmes tags avec des valeurs locales différentes). Le 16 octobre 2014 09:53, Pieren pier...@gmail.com a écrit : 2014-10-15 23:55 GMT+02:00 Vincent de Château-Thierry osm.v...@free.fr: Ça interpelle les débutants, soit. Mais, si je te suis, il faudrait préconiser 2 manières de tagguer, en fonction de l'analyse faite sur les tags des membres. À expliquer et à assimiler, c'est pire... Au moins, statuer que pour _tous_ les multipolygons les tags sont sur la relation, c'est constant, donc au final, à mon avis, plus simple. Pas forcément. On pourrait aussi dire que la valeur du polygone se définit toujours sur le/les ways
Re: [OSM-talk-fr] [Josm 7588] Un message d'erreur que je ne comprends pas bien
2014-10-16 10:29 GMT+02:00 Vincent de Château-Thierry osm.v...@free.fr: Oui mais là on tourne en rond, vu que pour les multipolygones c'est exactement cette modélisation qui pose problème, car rien n'empêche une incohérence entre les tags des différents ways outer. À partir de là, l'exploitation de l'objet complet représenté par la relation devient un cauchemar et une loterie. Les incohérences, ça se détecte et ça se corrige. La relation n'empêche pas non plus les incohérences si des ways portent des tags différents du multipolygon. C'est juste une question de choix. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Avancement du rapprochement des rues OSM avec Fantoir
Bonjour, Avec l'arrivée dans BANO des points représentant non des adresses mais des rues, apparaît un nouveaux chiffre sur le rapprochement entre voies OSM et FANTOIR. On a en effet 104520 voies sans aucune adresse (ni au Cadastre ni dans OSM) pour lesquelles le nom OSM a permis de trouver un code FANTOIR. Le rapprochement ici : http://munin.openstreetmap.fr/osm12.free.org/osm104.openstreetmap.fr/bano_rapproche.html ne tien t compte que des voies avec adresses. On peut donc considérer que le nombre total de voies rapprochées est plutôt autour de 76 actuellement. Grâce au même contenu points de rues, on comptabilise 25 voies de source OSM non reconnues côté FANTOIR. 76 + 25 : on aurait donc, dès à présent, plus d'1 million de rues nommées en France dans OSM. (on a le droit de s'applaudir, là ? :) ) Le nombre de voies dans FANTOIR étant autour de 150, on est donc aux 2/3 du trajet vers un inventaire exhaustif des rues de France dans OSM. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)
Philippe ça revient à ce que je vient de dire. C'est pas à considérer comme une erreur mais comme un travail en cours. Comme tu le proposais, 1) Il faudrait générer les relations même si le nom n'est pas affiché en mettant le FIXME que tu proposais. Ainsi la cohérence serait parfaite. Mais il n'y a pas d'erreur à proprement parlé de tag ou de saisie. Juste des relations non réalisées. Ça ne change pas le problème que l'on fait remonté (sur plusieurs sujet) concernant la gestion et la saisie de cette informations en tant que place (node, way) et celle de boundary. Je vous invite donc à voir mon message précédent car comme David je me retrouve confronté à savoir comment saisir ces infos. Certains n'ont pas attendu et j'aimerai compléter le wiki pour éviter d'avoir dans la base des saisies complètement différentes pour la même information. Le 15 octobre 2014 18:06, Philippe Verdy verd...@wanadoo.fr a écrit : remonte au way du mail initial (détecté par Osmose comme fragment de frontière isolé). http://www.openstreetmap.org/way/306246629 il n'est utilisé par aucune relation contrairement à tous les autres, c'est un morceau oublié qui devrait fermer une relation manquante, il est au milieu d'une zone encore vierge, mais il est connecté aux extrémités aux autres limites de relations existantes. Le 15 octobre 2014 17:14, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : * Même lieu-dit, mais sur plusieurs feuilles cadastrales. L'idée est de les fusionner par la suite lorsque l'approche * * typographique est identique*. Après vu que c'est la même zone sur les planches il est tout à fait envisageable et plus correcte d'enlever les limites inutiles pour avoir qu'une seule zone Pour Overpass je viens de vérifier http://overpass-turbo.eu/s/5tv et il n'y pas de gap dans les relations présentés. Je vois donc pas de quoi tu parles. Philippe, peux-tu me montrer un exemple sur le cas en cours via une requête enregistrée? . Moi j'ai juste des trous car les zones n'ont pas été générées avec de relations pour avoir une cohérence totale sur la commune (PS c'est frais aussi donc on peut aussi attendre qu'il finisse ;-) ) et voir aussi apparaître un FIXME sur les noms manquants. Reste que cela remonte le problème des toponymes locaux dont deux possibilités sont offertes en France et sans cohérence ou précision particulière à la saisie d'une par les *boundary *en way + relation (+ node *admin_center)* d'autre part *place *en way closed (+/ou node d'étiquette central) En sachant que boundary au level 10 la doc dit *limites des quartiers utilisés pour la démocracie locale* Pour moi c'est vague et ça dit tous et rien... et que dans la doc *places http://wiki.openstreetmap.org/wiki/FR:Places*on doit: Pour un toponyme correspondant à une aire administrative http://wiki.openstreetmap.org/wiki/FR:Places#Fronti.C3.A8res_administratives : *D'ailleurs on ne devrait pas renvoyer sur boundary directement???* 1. *Créer un chemin fermé autour du périmètre de l'aire utilisant un ou plusieurs chemins. déjà la on devrait parler de chemin relié aux deux extrémités ou fermé car fermé sous-entend fermé sur lui même comme les polygones* 2. Mettre l'attribut boundary http://wiki.openstreetmap.org/wiki/Key:boundary=administrative http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative avec ce chemin et avec le niveau approprié admin_level http://wiki.openstreetmap.org/wiki/Key:admin_level=*. 3. Ajouter ces chemins à la relaltion administrative Relation:boundary http://wiki.openstreetmap.org/wiki/Relation:boundary. 4. Ajouter l'attribut boundary http://wiki.openstreetmap.org/wiki/Key:boundary=administrative http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative et le niveau administratif approprié admin_level http://wiki.openstreetmap.org/wiki/Key:admin_level=* à la relation. 5. Fixer le rôle de chaque chemins qui sont à 'l'extérieur' à moins que se soit une enclave, dans laquelle il n'y a plus qu'a mettre le rôle inner. 6. On peut optionnellement mettre un noeud au centre de l'aire administrative et lui donner le rôle de centre administratif admin_centre. Doit-on faire un choix, doit-on mettre des règles de saisie pour ce niveau? Car pour moi c'est pas explicite et me semble quand même important car ce sont des lieu-dit locaux employés régulièrement certes pas facile à extraire du cadastre d'où l'ajout d'un simple tag place. Pour la limites des lieux-dit Pieren, je sais dans quelle région tu es mais sur les plans cadastraux c'est quand même clairement délimité! On ne parle pas juste des panneaux qui eux ne correspond à rien d'autre que des besoins de circulation. Le cadastre n'est peut-être pas aussi propre dans toutes les régions mais là c'est quand même bien clair. Quand tu dit que rien ne délimite précisement... Je te dis juste regarde le plan cadastral et tu verra que
Re: [OSM-talk-fr] [Josm 7588] Un message d'erreur que je ne comprends pas bien
Selon Pieren pier...@gmail.com: Les incohérences, ça se détecte et ça se corrige. La relation n'empèche pas non plus les incohérences si des ways portent des tags différents du multipolygon. C'est juste une question de choix. Non. L'idée c'est de ne considérer _que_ les tags de la relation, ce qui évite de se demander s'il y a cohérence avec les tags des ways outer. D'où l'incitation dans le message de JOSM. Ce fil [1] traitait du sujet l'année dernière. vincent [1] : https://lists.openstreetmap.org/pipermail/talk/2013-September/068189.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pour les amateurs de beaux rendus, même pour les cyclistes
Le 16/10/2014 02:36, Shohreh a écrit : Je voudrais qu'une fois que le parcours a été dessiné, les segments s'affichent d'une couleur différente selon le dénivellé. Quelqu'un à déjà réalisé un calculateur qui affiche le résultat avec ce que tu demande. RV, http://bit.ly/1w8EGb9 le calcul est assez long, mais le temps de parcours correspond tout à fait à celui effectué, les pentes sont affichées, le vent est pris en compte, etc. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [BANO] rapprochement sur les lieu-dits /voisinage/ quartier
Cela fait bien trop longtemps que je n'ai pas fait de CSS pour comprendre ce qui pose problème, mais si je supprime le float:left du style .rubrique, alors ça passe correctement avec Firefox et IE. Stf Le jeudi 16 octobre 2014 10:36:37, Jérôme Seigneuret a écrit : En effet, Il y a un problème de taille sur les balises TR et TD. Faire un dimensionnement en 100% sur le tableau, 50% sur les TD du header, et 25% sur les colonnes TD en dessous ça évitera les problèmes Le 16 octobre 2014 10:01, JB jb...@mailoo.org mailto:jb...@mailoo.org a écrit : Le 16/10/2014 09:18, Yves Pratter a écrit : Parmi les points à traiter sur ces listes : ajouter la capacité d'afficher les cartes et d'éditer, comme pour les voies numérotées. Je compte utiliser les parcelles pour déterminer la zone de cadrage, vu qu'ici par définition on ne peut pas utiliser la géométrie des n° d’adresses. Oups, lu trop vite… Juste un carré de 50m*50m autour du point central (celui repéré par Bano), ça me suffirait… Après, on peut toujours télécharger plus large si nécessaire ? JB. _ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.__org/listinfo/talk-fr https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Avancement du rapprochement des rues OSM avec Fantoir
J'ajouterai une petite limite. Une petite pondération car tu dois avoir 10% de voies correspondant soit à du Alt_name soit à du old_name... et des voies nommées sur la base des lieu-dits... Dans les voies non rapprochées et sans adresse j'ai pas mal d’erreurs d'orthographe et d'anciens noms de route ou de rue. C'est 25% dans mon village. D'ailleurs j'ai remarqué aussi que dans BANO les noms des lieux-dit sont tronqués... La taille du champs de stockage est trop restrictive soit dans BANO soit c'est la source qui est déjà tronqué. Mais sinon c'est cool ;-) Le 16 octobre 2014 11:05, Vincent de Château-Thierry osm.v...@free.fr a écrit : Bonjour, Avec l'arrivée dans BANO des points représentant non des adresses mais des rues, apparaît un nouveaux chiffre sur le rapprochement entre voies OSM et FANTOIR. On a en effet 104520 voies sans aucune adresse (ni au Cadastre ni dans OSM) pour lesquelles le nom OSM a permis de trouver un code FANTOIR. Le rapprochement ici : http://munin.openstreetmap.fr/osm12.free.org/osm104.openstreetmap.fr/bano_rapproche.html ne tien t compte que des voies avec adresses. On peut donc considérer que le nombre total de voies rapprochées est plutôt autour de 76 actuellement. Grâce au même contenu points de rues, on comptabilise 25 voies de source OSM non reconnues côté FANTOIR. 76 + 25 : on aurait donc, dès à présent, plus d'1 million de rues nommées en France dans OSM. (on a le droit de s'applaudir, là ? :) ) Le nombre de voies dans FANTOIR étant autour de 150, on est donc aux 2/3 du trajet vers un inventaire exhaustif des rues de France dans OSM. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [BANO] rapprochement sur les lieu-dits /voisinage/ quartier
Selon Stéphane Péneau stephane.pen...@wanadoo.fr: Cela fait bien trop longtemps que je n'ai pas fait de CSS pour comprendre ce qui pose problème, mais si je supprime le float:left du style .rubrique, alors ça passe correctement avec Firefox et IE. Le jeudi 16 octobre 2014 10:36:37, JérÃŽme Seigneuret a écrit : En effet, Il y a un problème de taille sur les balises TR et TD. Merci pour vos pistes :) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Avancement du rapprochement des rues OSM avec Fantoir
Selon Jérôme Seigneuret jseigneuret-...@yahoo.fr: D'ailleurs j'ai remarqué aussi que dans BANO les noms des lieux-dit sont tronqués... La taille du champs de stockage est trop restrictive soit dans BANO soit c'est la source qui est déjà tronqué. J'aimerais bien que le problème vienne de BANO sur ce coup là. Malheureusement c'est à la source : le libellé de voie dans FANTOIR plafonne à 26 caractères, cf. p6 de la doc : http://www.collectivites-locales.gouv.fr/files/files/gestion_locale_dgfip/national/FANTOIR_Descriptif.pdf C'est un peu court pour caser ce genre de nom sans abréviations... : http://www.openstreetmap.org/way/39043386 vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Avancement du rapprochement des rues OSM avec Fantoir
Les lieu-dit sont considérés comme des Voies? J'ai pas vue de description spécifique au lieu-dit. C'est pas un point avec une étiquette du toponyme? Je comprends pour les abréviations mais là c'est pas ça, c'est une troncature des données (fin de libellé avec nom coupé) Le 16 octobre 2014 11:41, Vincent de Château-Thierry osm.v...@free.fr a écrit : Selon Jérôme Seigneuret jseigneuret-...@yahoo.fr: D'ailleurs j'ai remarqué aussi que dans BANO les noms des lieux-dit sont tronqués... La taille du champs de stockage est trop restrictive soit dans BANO soit c'est la source qui est déjà tronqué. J'aimerais bien que le problème vienne de BANO sur ce coup là. Malheureusement c'est à la source : le libellé de voie dans FANTOIR plafonne à 26 caractères, cf. p6 de la doc : http://www.collectivites-locales.gouv.fr/files/files/gestion_locale_dgfip/national/FANTOIR_Descriptif.pdf C'est un peu court pour caser ce genre de nom sans abréviations... : http://www.openstreetmap.org/way/39043386 vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Josm 7588] Un message d'erreur que je ne comprends pas bien
2014-10-16 11:18 GMT+02:00 Vincent de Château-Thierry osm.v...@free.fr: Non. L'idée c'est de ne considérer _que_ les tags de la relation, ce qui évite de se demander s'il y a cohérence avec les tags des ways outer. D'où l'incitation dans le message de JOSM. Ce fil [1] traitait du sujet l'année dernière. Bah non, le message dit bien not the outer way. Il cherche donc à éviter les doublons/incohérences. Mais ce test pourrait aussi se limiter à vérifier que tous les ways outer sont portent les mêmes tags de polygon (quand il y en a plusieurs). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [BANO] rapprochement sur les lieu-dits /voisinage/ quartier
Le 16 oct. 2014 à 11:36, Vincent de Château-Thierry osm.v...@free.fr a écrit : Merci pour vos pistes :) ça marche toujours aussi bien avec Safari, Chrome mais le résultat est moche sous Firefox (test sous Mac OS X 10.9) Avec Firefox, Voies avec adresses fait 4 colonnes de large et Voies sans adresses fait une colonne de large et dépasse du tableau. Ce qui est curieux, c’est que dans le code source de Firefox, il rajoute des tbody dans les tableaux. Je constate que tu as 5 tableau,celui de l’entête suivi de 4 tableaux que tu montres ou caches en fonction des cliques ? Ça serait plus logique de mettre un seul tableau avec la partie entête thead et dedans 1 colonne qui contient tes tableaux que tu masques ou affiches en fonction des cliques. — Yves___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [BANO] rapprochement sur les lieu-dits /voisinage/ quartier
Concernant les 4 nombres donnés dans les en-têtes de colonnes, il semble que seul celui de la première colonne (Voies avec adresses - voies FANTOIR sans rapprochement OSM) est affiché sur la carte BANO http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#13/49.1722/-0.3608. Ne serait-il pas intéressant soit d'afficher aussi celui de la troisième colonne (Voies sans adresses - voies FANTOIR sans rapprochement OSM) à coté (manque XX + YY voies) ? Soit d'afficher l'addition de ces 2 valeurs ? Francescu Le 16 octobre 2014 14:01, Yves Pratter yves.prat...@gmail.com a écrit : Le 16 oct. 2014 à 11:36, Vincent de Château-Thierry osm.v...@free.fr a écrit : Merci pour vos pistes :) ça marche toujours aussi bien avec Safari, Chrome mais le résultat est moche sous Firefox (test sous Mac OS X 10.9) Avec Firefox, *Voies avec adresses* fait 4 colonnes de large et *Voies sans adresses* fait une colonne de large et dépasse du tableau. Ce qui est curieux, c’est que dans le code source de Firefox, il rajoute des tbody dans les tableaux. Je constate que tu as 5 tableau,celui de l’entête suivi de 4 tableaux que tu montres ou caches en fonction des cliques ? Ça serait plus logique de mettre un seul tableau avec la partie entête thead et dedans 1 colonne qui contient tes tableaux que tu masques ou affiches en fonction des cliques. — Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [BANO] rapprochement sur les lieu-dits /voisinage/ quartier
Selon Francescu GAROBY windu...@gmail.com: Concernant les 4 nombres donnés dans les en-têtes de colonnes, il semble que seul celui de la première colonne (Voies avec adresses - voies FANTOIR sans rapprochement OSM) est affiché sur la carte BANO http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#13/49.1722/-0.3608. Ne serait-il pas intéressant soit d'afficher aussi celui de la troisième colonne (Voies sans adresses - voies FANTOIR sans rapprochement OSM) Ã coté (manque XX + YY voies) ? Soit d'afficher l'addition de ces 2 valeurs Tout à fait, histoire de donner un panorama plus complet des manques par commune. Le préalable est le même que pour proposer les liens de visu et d'édition en fin de ligne : il faut une géométrie (au moins 1 point) pour ces voies. Or, étant sans numéros, on ne peut pas déduire leur géométrie des n° trouvés dans le cadastre. Étant (par définition) sans rapprochement OSM, on ne peut s'appuyer sur la géométrie OSM. Restent les parcelles, dont on connaît la géométrie et le nom. C'est ce que je vais mettre à contribution = à suivre. Pour répondre à Jérôme : voies et lieux-dits sont stockés dans la même table côté FANTOIR, c'est l'attribut Type de voie qui donne la distinction. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [BANO] rapprochement sur les lieu-dits /voisinage/ quartier
Ok, Je comprends mieux Le 16 octobre 2014 15:07, Vincent de Château-Thierry osm.v...@free.fr a écrit : Selon Francescu GAROBY windu...@gmail.com: Concernant les 4 nombres donnés dans les en-têtes de colonnes, il semble que seul celui de la première colonne (Voies avec adresses - voies FANTOIR sans rapprochement OSM) est affiché sur la carte BANO http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#13/49.1722/-0.3608 . Ne serait-il pas intéressant soit d'afficher aussi celui de la troisième colonne (Voies sans adresses - voies FANTOIR sans rapprochement OSM) Ã coté (manque XX + YY voies) ? Soit d'afficher l'addition de ces 2 valeurs Tout à fait, histoire de donner un panorama plus complet des manques par commune. Le préalable est le même que pour proposer les liens de visu et d'édition en fin de ligne : il faut une géométrie (au moins 1 point) pour ces voies. Or, étant sans numéros, on ne peut pas déduire leur géométrie des n° trouvés dans le cadastre. Étant (par définition) sans rapprochement OSM, on ne peut s'appuyer sur la géométrie OSM. Restent les parcelles, dont on connaît la géométrie et le nom. C'est ce que je vais mettre à contribution = à suivre. Pour répondre à Jérôme : voies et lieux-dits sont stockés dans la même table côté FANTOIR, c'est l'attribut Type de voie qui donne la distinction. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)
Ca vaut quand même le coup de se poser la question de l'opportunité et de la modélisation de ces informations. Si on généralise cette méthode, ce sont plusieurs millions de relations qui seraient nécessaires pour décrire tout ces lieux dits de cette façon... est-ce donc la bonne approche ? L'emprise de ceux-ci n'est pas précisément définit par les parcelles, c'est plutôt la parcelle qui est rattachée à un nom de lieux-dit. Alors définir des limites aussi précises pour quelques chose à l'origine d'assez flou, ça me fait bizarre. On est de plus dans une situation très différente des découpages administratifs, qui eux sont (en principe) précisément définis et conservés dans le COG et les découpages subcommunaux de l'INSEE (la notion de quartiers/grand quartiers ou d'IRIS et de TRIRIS). Pour moi boundary=administrative + admin_level=10 ne me semblent pas du tout adaptés. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)
Ok dans ce cas: 1) doit-on ouvrir en France un vote sur cette pratique? 2) Doit-on requalifier les pages du wiki et supprimer ou repréciser le level 10 en France ou proposer un renvoi sur key:place pour ce type de niveau. 3) Pouvons-nous dire que les lieu-dits Cadastre aussi présent en toponyme dans BANO sont à qualifier en tant que *place=* (lieu-dit sans habitation, lieu-dit habité (max d'habitation 1 ou 2), hameau, voisinage, quartier)* et spécifier plus clairement la catégorie de *place *à appliquer avec des exemples concrets. pour éviter d'avoir autant de questions. Après tu dis que c'est flou :| J'ai pas l'impression encore une fois (Dans ce cas on peut considérer que sans pointage par un géomètre des limites tous est flou). et le cadastre est flou déjà de base vu le nombre de contentieux sur les limites de terrains (c'est fait à la chaîne d'arpentage à la base) C'est sur que la saisie des limites communales à déjà été chiant et très long. Je comprend que ce maillage ne soit pas indispensable et qu'il serrait assez difficile d'avoir quelque chose de cohérent sur tous le territoire. On doit donc décider de ne pas saisir cette donnée comme boundary et donc faire soit un noeud soit une zone pour qualifier cette information en tant que place si les limite sont connus. Ainsi c'est pas incohérent. Le 16 octobre 2014 15:47, Christian Quest cqu...@openstreetmap.fr a écrit : Ca vaut quand même le coup de se poser la question de l'opportunité et de la modélisation de ces informations. Si on généralise cette méthode, ce sont plusieurs millions de relations qui seraient nécessaires pour décrire tout ces lieux dits de cette façon... est-ce donc la bonne approche ? L'emprise de ceux-ci n'est pas précisément définit par les parcelles, c'est plutôt la parcelle qui est rattachée à un nom de lieux-dit. Alors définir des limites aussi précises pour quelques chose à l'origine d'assez flou, ça me fait bizarre. On est de plus dans une situation très différente des découpages administratifs, qui eux sont (en principe) précisément définis et conservés dans le COG et les découpages subcommunaux de l'INSEE (la notion de quartiers/grand quartiers ou d'IRIS et de TRIRIS). Pour moi boundary=administrative + admin_level=10 ne me semblent pas du tout adaptés. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)
Le 16/10/2014 15:47, Christian Quest a écrit : Ca vaut quand même le coup de se poser la question de l'opportunité et de la modélisation de ces informations. Tiens tiens, alors, elle en est où, la réflexion autour de l'import (ou intégration ou un autre mot moins polémique) de tout les « lieux-dits » de complément d'adresse en surfacique plutôt qu'en ponctuel ? Pour mémoire : https://lists.openstreetmap.org/pipermail/talk-fr/2014-June/069036.html et suivants, notamment : https://lists.openstreetmap.org/pipermail/talk-fr/2014-June/069042.html https://lists.openstreetmap.org/pipermail/talk-fr/2014-June/069044.html JB. PS : pour ma part, je pense toujours que ce sera plus un enfer qu'autre chose, mais bon… ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)
2014-10-16 16:35 GMT+02:00 JB jb...@mailoo.org: Tiens tiens, alors, elle en est où, la réflexion autour de l'import (ou intégration ou un autre mot moins polémique) de tout les « lieux-dits » de complément d'adresse en surfacique plutôt qu'en ponctuel ? Attention, il ne faut pas ajouter de la confusion à un problème déjà assez compliqué. Il y a deux types de surfaciques pour un hameau/lieu-dit: - celui du cadastre qui rattache des parcellles à un lieu-dit., des parcelles avec ou sans bâti - celui qu'on fait habituellement dans OSM en dessinant une grosse patate autour des buildings et en y ajoutant les tags landuse=residential et place=hamlet + name par exemple. Ce que Christian propose, c'est d'automatiser cette tâche en sélectionnant les parcelles rattachées à un lieux-dit ET avec bâti. La discussion qui nous intéresse ici concerne le premier type de patate (toutes les parcelles rattachées à un lieux-dit, avec ou sans bâti). Encore une fois, ce genre de rattachement est une décision de la dgfip qu'on ne peut pas vérifier sur le terrain, la limite étant souvent floue dans les zones entre deux, et qui n'a pas d'utilité pour nous s'il n'y a pas d'adresses (donc pas de bâti). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)
On n'est pas en train de la mener la réflexion ? ;) Le test de David me semble intéressant justement pour expérimenter et montrer quelques limites. Côté tags je pense que les choix ne sont pas les bons. Côté modélisation, je n'ai pas d'avis ou plutôt celui-ci évolue au fur et à mesure des réflexions... il n'y a que les imbéciles qui ne changent jamais d'avis, non ? Vu le volume envisagé, il me semble important de bien se poser les questions assez tôt, de se poser la question de l'intérêt du surfacique par rapport au ponctuel. Se limiter en surfacique aux lieux-dits bâtis (potentiellement habités) et rester en ponctuel sur le reste me semblerait un bon compromis. Le 16 octobre 2014 16:35, JB jb...@mailoo.org a écrit : Le 16/10/2014 15:47, Christian Quest a écrit : Ca vaut quand même le coup de se poser la question de l'opportunité et de la modélisation de ces informations. Tiens tiens, alors, elle en est où, la réflexion autour de l'import (ou intégration ou un autre mot moins polémique) de tout les lieux-dits de complément d'adresse en surfacique plutôt qu'en ponctuel ? Pour mémoire : https://lists.openstreetmap.org/pipermail/talk-fr/2014-June/069036.html et suivants, notamment : https://lists.openstreetmap.org/pipermail/talk-fr/2014-June/069042.html https://lists.openstreetmap.org/pipermail/talk-fr/2014-June/069044.html JB. PS : pour ma part, je pense toujours que ce sera plus un enfer qu'autre chose, mais bon... ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)
Il y a deux types de surfaciques pour un hameau/lieu-dit: - celui du cadastre qui rattache des parcellles à un lieu-dit., des parcelles avec ou sans bâti - celui qu'on fait habituellement dans OSM en dessinant une grosse patate autour des buildings et en y ajoutant les tags landuse=residential et place=hamlet + name par exemple. Pieren c'est clairement ça dans le premier cas! Mais je milite clairement pour ne pas mettre place=hamlet + name comme dans ton deuxième cas car un lieu dit c'est pas que le résidentiel mais aussi les terre de culture comme dans le cas de place=farm et assimilé Christian ça a l'air pas mal comme proposition. Ponctuel et zonale peuvent coexister si l'on garde le même tag pour nommer l'ensemble (cohérence oblige) donc encore une fois pas juste dans un landuse. Pour moi les zones peuvent me servir dans tous les cas car dans le milieu naturel (observation d'espèces par les groupe naturaliste) on utilise souvent cette données comme information de rattachement. Donc pour résumé on peut définir les choses ainsi : 1) un* place=** de type *polygone *pour les zones habitées quelques soit le landuse! car il peut y avoir du mitage et dans ce cas déssiner en plus des zones landuse=residential sans nom pour définir les limites des zone habitées sur la limite des parcelles concernées. 2) *place=locality* pour les zones non habitées sous la forme d'un noeud *précision*: un place=locality est-il seulement une zone sans bâti ou en ruine? (sans activité humaine en bâti) et l'on considère dans ce cas qu'un lieu-dit habité est une zone ou y il a du batî servant à une activité humaine (habitation, entrepot, usine ...)??? ou c'est juste lié à l'habitation Le 16 octobre 2014 17:10, Christian Quest cqu...@openstreetmap.fr a écrit : On n'est pas en train de la mener la réflexion ? ;) Le test de David me semble intéressant justement pour expérimenter et montrer quelques limites. Côté tags je pense que les choix ne sont pas les bons. Côté modélisation, je n'ai pas d'avis ou plutôt celui-ci évolue au fur et à mesure des réflexions... il n'y a que les imbéciles qui ne changent jamais d'avis, non ? Vu le volume envisagé, il me semble important de bien se poser les questions assez tôt, de se poser la question de l'intérêt du surfacique par rapport au ponctuel. Se limiter en surfacique aux lieux-dits bâtis (potentiellement habités) et rester en ponctuel sur le reste me semblerait un bon compromis. Le 16 octobre 2014 16:35, JB jb...@mailoo.org a écrit : Le 16/10/2014 15:47, Christian Quest a écrit : Ca vaut quand même le coup de se poser la question de l'opportunité et de la modélisation de ces informations. Tiens tiens, alors, elle en est où, la réflexion autour de l'import (ou intégration ou un autre mot moins polémique) de tout les « lieux-dits » de complément d'adresse en surfacique plutôt qu'en ponctuel ? Pour mémoire : https://lists.openstreetmap.org/pipermail/talk-fr/2014-June/069036.html et suivants, notamment : https://lists.openstreetmap.org/pipermail/talk-fr/2014-June/069042.html https://lists.openstreetmap.org/pipermail/talk-fr/2014-June/069044.html JB. PS : pour ma part, je pense toujours que ce sera plus un enfer qu'autre chose, mais bon… ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mapcraft sur l'import du bâti au Calvados
Bonjour à tous, Cet énorme Mapcraft est toujours en cours : http://mapcraft.nanodesu.ru/pie/426 Nous sommes actuellement à 283 communes intégrées (110 communes importées, c'est bien !), il reste donc du chemin. Pour rappel, importer les bâtiments est lié à différents usages : à aider au positionnement des tags pour les contributeurs, par exemple les adresses pour nos fous de BANO ;). L'OSMecum Intégrer le bâti rappelé par Jean-Francois Nifenecker peut aider : http://wiki.openstreetmap.org/w/images/2/2d/Osmecum_integration_bati_v020.pdf Pensez à dire ce que vous importé, ça stimule un peu les contributeurs de passage ;) Bonne intégration :) -- Jean-Baptiste Holcroft Le 2 juin 2014 12:36, Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net a écrit : Le 02/06/2014 10:49, Francescu GAROBY a écrit : Je compléterais en précisant que, parmi les bâtiments coupés par les limites de parcelles, il y a ceux coupés par les limites de communes. Coupure qu'on ne voit pas forcément de suite, si le bâti de la commune limitrophe n'a pas encore été importé. L'OSMecum Intégrer le bâti précise tout ça ;) http://wiki.openstreetmap.org/w/images/2/2d/Osmecum_integration_bati_v020.pdf -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sites de routage basés sur OSM : numéros de rue?
Merci. OpenRunner est basé sur Google. Dans le même genre, je préfère RideWithGPS. Pour des solutions OSM, je n'aime pas non plus OpenRouteService, en particulier par l'impossibilité de pouvoir tirer sur le parcours après coup. Le lien officiel vers OSRM affiche constamment Timed out, mais ce lien fonctionne pour le moment: http://map.project-osrm.org/ A priori, il fait tout ce que je voulais, à part exporter en KML, mais il est sans doute possible d'écrire un script pour automatiser la conversion de GPX en KML. Merci. -- View this message in context: http://gis.19327.n5.nabble.com/Sites-de-routage-bases-sur-OSM-numeros-de-rue-tp5820443p5820573.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sites de routage basés sur OSM : numéros de rue?
En fait toutes les briques sont là: - base BANO pour trouver les départ/arrivée au numéro - OSRM pour calculer l'itinéraires pour les vélos (avec un graphe calculé pour) - de la conversion GPX vers KM (ou autre) Il faut les assembler... Le 16 octobre 2014 21:29, Shohreh codecompl...@free.fr a écrit : Merci. OpenRunner est basé sur Google. Dans le même genre, je préfère RideWithGPS. Pour des solutions OSM, je n'aime pas non plus OpenRouteService, en particulier par l'impossibilité de pouvoir tirer sur le parcours après coup. Le lien officiel vers OSRM affiche constamment Timed out, mais ce lien fonctionne pour le moment: http://map.project-osrm.org/ A priori, il fait tout ce que je voulais, à part exporter en KML, mais il est sans doute possible d'écrire un script pour automatiser la conversion de GPX en KML. Merci. -- View this message in context: http://gis.19327.n5.nabble.com/Sites-de-routage-bases-sur-OSM-numeros-de-rue-tp5820443p5820573.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Sites de routage basés sur OSM : numéros de rue?
Un détail : Openrunner n'est pas basé sur Google. Il permet de consulter aussi bien des cartes sur des fonds Géoportail (Topo, Scan Express), OSM ( standard, OpenCycleMap, MapQuest, HikeBikemap), Google, Satellite. Bref, pour le simple utilisateur, c'est un outil précieux : la comparaison des informations d'origines variées vaudra toujours mieux qu'une info unique... Le 16 octobre 2014 21:29, Shohreh codecompl...@free.fr a écrit : Merci. OpenRunner est basé sur Google. Dans le même genre, je préfère RideWithGPS. Pour des solutions OSM, je n'aime pas non plus OpenRouteService, en particulier par l'impossibilité de pouvoir tirer sur le parcours après coup. Le lien officiel vers OSRM affiche constamment Timed out, mais ce lien fonctionne pour le moment: http://map.project-osrm.org/ A priori, il fait tout ce que je voulais, à part exporter en KML, mais il est sans doute possible d'écrire un script pour automatiser la conversion de GPX en KML. Merci. -- View this message in context: http://gis.19327.n5.nabble.com/Sites-de-routage-bases-sur-OSM-numeros-de-rue-tp5820443p5820573.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
