Re: [OSM-talk-fr] Re : Re : http://wiki.openstreetmap.org/wiki/Talk:WikiProject_France/Tour_de_France/ 2010
Le 25 avr. 10 à 02:18, Pieren a écrit : Tracer des ways supperposés n'est pas aisé même si c'est une méthode que je défends pour les limites administratives. Surtout que les itinéraires vont s'accumuler, se chevaucher et on aura deux puis trois puis X ways superposés contrairement à notre façon d'identifier les boundaries qui se limite à un seul way pour tous les niveaux administratifs. Pour les itinéraires, je l'ai déjà mentionné par le passé, il y aurait beaucoup plus simple à faire : la relation devrait collecter la liste des nodes du point de départ, d'arrivée et ceux des intersection où il y a changement de direction. Il n'y besoin de rien d'autre pour définir un itinéraire. Bien sûr, cela devient un peu plus compliqué pour les logiciels utilisateurs mais rien d'insurmontable. Et c'est plus facile à éditer puisqu'on ne coupe plus les rues/routes. C'est intéressant. Pour simplifier le calcul (logiciel utilisateur) il serait possible d'ajouter les ways (option permettant au logiciel de simplifier ces recherches) mais il faudrait surtout préciser le sens dans lequel faire la recherche peut être... Mais bon on dérive un peu du sujet d'origine. -- Pierre-Alain Dorange, Blog Citoyen de Cognac : http://cognac-citoyen.blogspot.com/ Twitter : https://twitter.com/padorange - Facebook : http://www.facebook.com/pa.dorange ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faire coïncider des polygones
Le vendredi 23 avril 2010 20:20:33, Damien Hardy a écrit : Bonsoir, Quelle est la meilleurs manières de faire coïncider les frontières de n polygones. (...) Existe t-il un moyen de mutualiser des nœuds entre les polygones de telle manière que quand je bouge ce nœud, tous les polygones dont il ferait partie soient modifiés ? Je suis surpris que personne n'ait mentionné la solution beaucoup plus simple d'utiliser une relation de type multipolygon qui est tout indiquée pour ce cas là : http://wiki.openstreetmap.org/wiki/Multipolygon#Advanced_multipolygons (figure 1) Ainsi tu mutualises non seulement les noeuds mais en fait l'ensemble du way qui forme le lac en indiquant que. ce n'est pas de la forêt (role inner) Cela permet également d'éviter d'avoir à faire les raccords bizarres présents au Nord-Ouest et à L'Est du lac qui bien que corrects visuellement, forment selon moi une erreur de représentation de l'objet forêt. Par exemple si je m'intéresse à la longueure du périmètre de la forêt, demander la longueure du way donnera un résultat érronné. -- sly ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] undefined
undefined___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] undefined
Le 25/04/2010 16:23, eric...@sfr.fr a écrit : Bonjour, Bonjour et bienvenue PS: J'ai par exemple depuis ajouté les stations de velib sur Valence (appelées Libello) mais je ne les vois pas apparaitre dans la carte. J'ai pourtant taggé les stationx amenity=bicycle_parking comme proposé par un mappeur. Qui est-il, qu'on lui coupe la tête ? Le tag est amenity=bicycle_rental amenity = bicycle_rental capacity = N name = NNN network = NNN ref = N Par exemple : http://www.openstreetmap.org/browse/node/447005960 Ca apparait dans les fichiers OSM etIMG mais pas lors de consultation en ligne. Je vais bosser tout ca, c'est assez complexe à prendre en mains :) Voila l'endroit pour poser les 78 questions, puis les autres à venir... -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] undefined
Merci pour l'info et désolé pour le undefined en sujet, en copiant/collant mon message initial, j'ai oublié de reprendre le sujet :( Quant à la source que j'avais trouvé, je préfère ne pas le citer si la peine encourue est à ce niveau :) Je vais corriger mes tags comme proposé. Le 25/04/2010 16:23, eric...@sfr.fr a écrit : Bonjour, Bonjour et bienvenue PS: J'ai par exemple depuis ajouté les stations de velib sur Valence (appelées Libello) mais je ne les vois pas apparaitre dans la carte. J'ai pourtant taggé les stationx amenity=bicycle_parking comme proposé par un mappeur. Qui est-il, qu'on lui coupe la tête ? Le tag est amenity=bicycle_rental amenity = bicycle_rental capacity = N name = NNN network = NNN ref = N Par exemple : http://www.openstreetmap.org/browse/node/447005960 Ca apparait dans les fichiers OSM etIMG mais pas lors de consultation en ligne. Je vais bosser tout ca, c'est assez complexe à prendre en mains Voila l'endroit pour poser les 78 questions, puis les autres à venir... -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Re : http://wiki.openstreetmap.org/wiki/Talk:WikiProject_France/Tour_de_France/ 2010
Pieren a écrit : () Pour les itinéraires, je l'ai déjà mentionné par le passé, il y aurait beaucoup plus simple à faire : la relation devrait collecter la liste des nodes du point de départ, d'arrivée et ceux des intersection où il y a changement de direction. Il n'y besoin de rien d'autre pour définir un itinéraire. Bien sûr, cela devient un peu plus compliqué pour les logiciels utilisateurs mais rien d'insurmontable. Et c'est plus facile à éditer puisqu'on ne coupe plus les rues/routes. Pieren Bonjour, J'aime bien cette solution et comme je viens de découvrir que les membres de relations sont ordonnés[1], c'est techniquement réalisable. J'ai cependant deux réserves : 1. Comment ça se saisit dans nos outils : en Potlatch, je ne sais pas contrôler l'ordre d'une relation autrement que par l'ordre de la saisie : ça veut dire qu'en cas d'oubli d'un nœud, je dois tout casser pour recommencer. Qu'en est-il de JOSM ? 2. La reconstitution de la route n'est pas triviale car il va falloir trouver tous les ways qui constituent le parcours entre deux points de référence et ordonner les ways trouvés. (Note à ce sujet, c'est un peu HS, mais je recherche une requête SQL pour ordonner une liste de ways sans retour arrière, sur le schéma OSM évidemment). PS : aucune réponse de ASO à cette heure. [1] : pour les plus observateurs, ça se voit là : http://wiki.openstreetmap.org/wiki/Database_schema#Relations dans la déclaration de la table current_relation_members : CREATE TABLE current_relation_members ( id bigint NOT NULL, -- primary key part 1/5; references current_relations(id) member_type nwr_enum NOT NULL, -- primary key part 2/5 member_id bigint NOT NULL, -- primary key part 3/5 member_role character varying(255) NOT NULL, -- primary key part 4/5 sequence_id integer DEFAULT 0 NOT NULL -- primary key part 5/5 --- c'est là ! ); -- Marc m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Re : http://wiki.openstreetmap.org/wiki/Talk:WikiProject_France/Tour_de_France/ 2010
Le 25 avr. 10 à 19:24, Marc Sibert a écrit : J'aime bien cette solution et comme je viens de découvrir que les membres de relations sont ordonnés[1], c'est techniquement réalisable. J'ai cependant deux réserves : 1. Comment ça se saisit dans nos outils : en Potlatch, je ne sais pas contrôler l'ordre d'une relation autrement que par l'ordre de la saisie : ça veut dire qu'en cas d'oubli d'un nœud, je dois tout casser pour recommencer. Qu'en est-il de JOSM ? JOSM permet l'ordonnancement des éléments des relations sans soucis. 2. La reconstitution de la route n'est pas triviale car il va falloir trouver tous les ways qui constituent le parcours entre deux points de référence et ordonner les ways trouvés. (Note à ce sujet, c'est un peu HS, mais je recherche une requête SQL pour ordonner une liste de ways sans retour arrière, sur le schéma OSM évidemment). C'est pourquoi je proposais de mettre (optionnellement) le way. Ce way ne serait pas gérer directement par le moteur logiciel mais comme aide pour se débrouiller avec les nœuds... -- Pierre-Alain Dorange, Blog Citoyen de Cognac : http://cognac-citoyen.blogspot.com/ Twitter : https://twitter.com/padorange - Facebook : http://www.facebook.com/pa.dorange ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Re : http://wiki.openstreetmap.org/wiki/Talk:WikiProject_France/Tour_de_France/ 2010
Le 25/04/2010 19:24, Marc Sibert a écrit : Pieren a écrit : () Pour les itinéraires, je l'ai déjà mentionné par le passé, il y aurait beaucoup plus simple à faire : la relation devrait collecter la liste des nodes du point de départ, d'arrivée et ceux des intersection où il y a changement de direction. Il n'y besoin de rien d'autre pour définir un itinéraire. Bien sûr, cela devient un peu plus compliqué pour les logiciels utilisateurs mais rien d'insurmontable. Et c'est plus facile à éditer puisqu'on ne coupe plus les rues/routes. Pieren Bonjour, J'aime bien cette solution et comme je viens de découvrir que les membres de relations sont ordonnés[1], c'est techniquement réalisable. J'ai cependant deux réserves : J'ajouterai qu'il ne suffit pas toujours de mentionner les intersections A et B pour déterminer la route. SI deux arcs passent par A et B, un point C intermédiaire est nécessaire pour la levée de doute. 1. Comment ça se saisit dans nos outils : en Potlatch, je ne sais pas contrôler l'ordre d'une relation autrement que par l'ordre de la saisie : ça veut dire qu'en cas d'oubli d'un nœud, je dois tout casser pour recommencer. Qu'en est-il de JOSM ? Il fait ça très bien. 2. La reconstitution de la route n'est pas triviale car il va falloir trouver tous les ways qui constituent le parcours entre deux points de référence et ordonner les ways trouvés. (Note à ce sujet, c'est un peu HS, mais je recherche une requête SQL pour ordonner une liste de ways sans retour arrière, sur le schéma OSM évidemment). Le 25/04/2010 20:10, Pierre-Alain Dorange a écrit : C'est pourquoi je proposais de mettre (optionnellement) le way. Ce way ne serait pas gérer directement par le moteur logiciel mais comme aide pour se débrouiller avec les nœuds...- Dans JOSM, si je demande à charger la relation N, il chargera la relation simple, c'est à dire la référence des points composant la relation. http://api.openstreetmap.org/api/0.6/relation/N Je charge alors ces points (n points). http://api.openstreetmap.org/api/0.6/node/X (n fois) Mais je n'ai pas encore chargé les ways passant par eux. Il faut alors une troisième requête pour charger les ways. 3 passes. http://api.openstreetmap.org/api/0.6/node/X/full (n fois) Certes, tous les ways utilisant le node X seront chargés, pas seulement ceux empruntés par la route : d'où une surcharge d'information. Pour un calcul de la relation, ce n'est pas gênant d'avoir du matériel en plus. Pour un travail sur JOSM, c'est chi...(censuré) Avec le schéma actuel, une requête suffit pour avoir tout et seulement le matériel. http://api.openstreetmap.org/api/0.6/relation/101593/full Bon l'api ne s'en sort pas encore très bien avec les relations de relation. http://api.openstreetmap.org/api/0.6/relation/154039/full ne fournit pas tout le matériel du réseau Ginko (bus des Besançon) alors que http://xapi.openstreetmap.org/api/0.6/relation[network=Ginko][bbox=5.8935,47.1981,6.1307,47.3125] le fait. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Re : http://wiki.openstreetmap.org/wiki/Talk:WikiProject_France/Tour_de_France/ 2010
Bonsoir, Vincent Pottier a écrit : Le 25/04/2010 19:24, Marc Sibert a écrit : Pieren a écrit : () Pour les itinéraires, je l'ai déjà mentionné par le passé, il y aurait beaucoup plus simple à faire : la relation devrait collecter la liste des nodes du point de départ, d'arrivée et ceux des intersection où il y a changement de direction. Il n'y besoin de rien d'autre pour définir un itinéraire. Bien sûr, cela devient un peu plus compliqué pour les logiciels utilisateurs mais rien d'insurmontable. Et c'est plus facile à éditer puisqu'on ne coupe plus les rues/routes. Pieren Bonjour, J'aime bien cette solution et comme je viens de découvrir que les membres de relations sont ordonnés[1], c'est techniquement réalisable. J'ai cependant deux réserves : J'ajouterai qu'il ne suffit pas toujours de mentionner les intersections A et B pour déterminer la route. SI deux arcs passent par A et B, un point C intermédiaire est nécessaire pour la levée de doute. +1 On arrive doucement à l'OpenLR de Tomtom (http://www.tomtom.com/page/openLR) : somme de + courts chemins avec passage par des points intermédiaires bien choisis pour éviter les ambiguïtés aux intersections. 1. Comment ça se saisit dans nos outils : en Potlatch, je ne sais pas contrôler l'ordre d'une relation autrement que par l'ordre de la saisie : ça veut dire qu'en cas d'oubli d'un nœud, je dois tout casser pour recommencer. Qu'en est-il de JOSM ? Il fait ça très bien. 2. La reconstitution de la route n'est pas triviale car il va falloir trouver tous les ways qui constituent le parcours entre deux points de référence et ordonner les ways trouvés. (Note à ce sujet, c'est un peu HS, mais je recherche une requête SQL pour ordonner une liste de ways sans retour arrière, sur le schéma OSM évidemment). Le 25/04/2010 20:10, Pierre-Alain Dorange a écrit : C'est pourquoi je proposais de mettre (optionnellement) le way. Ce way ne serait pas gérer directement par le moteur logiciel mais comme aide pour se débrouiller avec les nœuds...- Dans JOSM, si je demande à charger la relation N, il chargera la relation simple, c'est à dire la référence des points composant la relation. Dans JOSM, si tu passes par ce raccourci : Ctrl+Maj+O ou Fichier Télécharger un objet, la requête faite est bien de type full. Pour ton exemple, en prenant soin de cocher Télecharger les référants, j'ai 2 requêtes successives : GET http://api.openstreetmap.org/api/0.6/relation/101593/full GET http://api.openstreetmap.org/api/0.6/relation/101593/relations et au final tout ta ligne 1, une fois dans chaque sens, + la relation network Ginko incomplète. http://api.openstreetmap.org/api/0.6/relation/N Je charge alors ces points (n points). http://api.openstreetmap.org/api/0.6/node/X (n fois) Mais je n'ai pas encore chargé les ways passant par eux. Il faut alors une troisième requête pour charger les ways. 3 passes. http://api.openstreetmap.org/api/0.6/node/X/full (n fois) Certes, tous les ways utilisant le node X seront chargés, pas seulement ceux empruntés par la route : d'où une surcharge d'information. Pour un calcul de la relation, ce n'est pas gênant d'avoir du matériel en plus. Pour un travail sur JOSM, c'est chi...(censuré) Avec le schéma actuel, une requête suffit pour avoir tout et seulement le matériel. http://api.openstreetmap.org/api/0.6/relation/101593/full Bon l'api ne s'en sort pas encore très bien avec les relations de relation. http://api.openstreetmap.org/api/0.6/relation/154039/full ne fournit pas tout le matériel du réseau Ginko (bus des Besançon) alors que http://xapi.openstreetmap.org/api/0.6/relation[network=Ginko][bbox=5.8935,47.1981,6.1307,47.3125] le fait. -- FrViPofm vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] CartoSatCamp - Compte Rendu de Spot Image Labs
Bonsoir, Pieren a écrit : J'ai ajouté quelques idées sur le wiki sur les possibles utilisations des images SPOT: http://wiki.openstreetmap.org/wiki/FR:CartoSatCamp Je viens de mentionner sur cette page la dérogation à l'attention d'OSM annoncée au cours du BarCamp par Jean-François Faudi, responsable de la RD de Spot Image. En effet, cette dérogation apparaît désormais de manière explicite dans les « Conditions Générales d'Utilisation » : http://www.youmapps.org/cgu Par dérogation, Spot Image autorise les membres de la communauté Openstreetmap à exporter et/ou stocker les Contenus Créés à travers une Application développé sur le Site Web pour cette communauté Openstreetmap, sur la plateforme Openstreetmap où ils seront soumis à la licence Creative Commons CC-BY-SA 2.0 disponible sur le lien suivant : http://creativecommons.org/licenses/by-sa/2.0/fr/ ou à la licence OpenDbl disponible sur le lien suivant : http://wiki.openstreetmap.org/wiki/Open_Database_License. Pour ceux qui n'auraient pas suivi, il s'agit d'une dérogation car la licence normalement prévue par Spot Image est la CC-BY-SA-NC, dont les restrictions rendaient les données produites via la plate-forme Youmapps inutilisables dans le cadre d'OSM. À part cela, vous l'aurez compris, je suis en train de lire ces fameuses conditions générales d'utilisation. Si le statut des données fournies à OSM est désormais clair, il n'en va pas encore de même pour tout et, en l'état, certaines clauses ne manqueront pas de faire bondir les libristes. Je vais discuter avec nos interlocuteurs de ces « détails ». A++, Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://sebastien.dinot.free.fr/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] installation mapnik, probleme (ab)scons
Bonjour, pour les essais de rendu vélo, je suis en train d'installer mapnik je bloque sur le build de mapnik depuis les sources svn co svn://svn.mapnik.org/trunk mapnik-src cd mapnik-src python scons/scons.py PYTHON=/usr/bin/python PGSQL_INCLUDES=/usr/include/postgresql PGSQL_LIBS=/usr/lib/postgresql BOOST_INCLUDES=/usr/include/boost BOOST_LIBS=/usr/lib comme le build me disait que ma lib boost n'était pas assez récente j'ai compilé la lib depuis les sources elle a l'air d'être bien compilé (des .so sont crées et je n'ai pas d'erreur fatal dans la compile) mais même en changeant les chemins de la compile mapnik, il semble qu'il vas toujours chercher les lib a l'endroit de départ python scons/scons.py configure PYTHON=/usr/bin/python PGSQL_INCLUDES=/usr/include/postgresql PGSQL_LIBS=/usr/lib/postgresql BOOST_INCLUDES=/home/julien/slippy/boost/boost_1_42_0 BOOST_LIBS=/home/julien/slippy/boost/boost_1_42_0/stage/lib j'ai toujours le même message d'erreur Searching for boost libs and headers... (cached) louche *libs found: /usr/lib - pas le chemin passé en paramètre *headers found: /usr/include --pas le chemin passé en paramètre *no lib naming extension found Checking for Boost version = 1.41... no Boost version 1.41 or greater is requred J'ai vidé le cache scons rm .sconf_temp/ mais ca ne change rien j'ai aussi essayé tout un tas de paramètre pour scons pour qu'il vide ou ne tienne pas compte du cache, mais sans succès. Si quelqu'un a déjà installé mapnik sur une debian lenny et qu'il a noté la procédure qqpart, ca m'intéresse. -- JB ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] installation mapnik, probleme (ab)scons
Bonsoir, Sans convictions (jamais essayé sous Lenny) allez sur http://trac.mapnik.org/wiki/DebianInstallation Vous avez toutes les dépendances et le guide pour installer sous Lenny Vous avez suivi ces instructions ou bien il y a des erreurs non mentionnées dans la page? Cordialement ThomasG ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] CartoSatCamp - Compte Rendu de Spot Image Labs
2010/4/25 Sébastien Dinot sebastien.di...@free.fr Par dérogation, Spot Image autorise les membres de la communauté Openstreetmap à exporter et/ou stocker les Contenus Créés à travers une Application développé sur le Site Web pour cette communauté Openstreetmap, sur la plateforme Openstreetmap où ils seront soumis à la licence Creative Commons CC-BY-SA 2.0 Hmm, c'est assez vicieux comme licence. Si je l'interprète correctement, nous ne pouvons créer du contenu qu'à travers leur site et on aura juste le droit de l'exporter dans OSM dans un deuxième temps ? Le but serait donc de s'intercaler entre les contributeurs et la base de donnée OSM pour pouvoir récupérer ce travail à bon compte (séparer le bon grain de l'ivraie en quelque sorte). On pourrait penser qu'après tout, ça n'est pas bien grave puisque nos contributions se retrouvent au final dans OSM. En dehors des problèmes techniques que ça soulève, on peut juste se poser des questions sur l'éthique d'une telle démarche (sauf si j'ai mal compris et que la création de données peut s'effectuer directement dans OSM avec nos propres outils et des images Spot en toile de fond). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] installation mapnik, probleme (ab)scons
2010/4/25 julien balas jul...@krilin.org mais même en changeant les chemins de la compile mapnik, il semble qu'il vas toujours chercher les lib a l'endroit de départ python scons/scons.py configure PYTHON=/usr/bin/python PGSQL_INCLUDES=/usr/include/postgresql PGSQL_LIBS=/usr/lib/postgresql BOOST_INCLUDES=/home/julien/slippy/boost/boost_1_42_0 BOOST_LIBS=/home/julien/slippy/boost/boost_1_42_0/stage/lib La réponse se trouve peut être dans le fichier ./SConstruct: In effect /usr/lib is likely to come before /usr/local/lib which makes linking against custom built icu or boost impossible when those libraries are available in both places. Pourquoi tu ne déployes pas tes nouvelles librairies boost dans /usr/lib ? Tu veux garder les anciennes ? Si c'est le cas, toujours d'après SConstruct, il y aurait une variable qui permettrait de changer l'ordre de priorité des library path : LINK_PRIORITY Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
