Re: [OSM-talk-fr] osm.fr limites-communales-a-importer
Le 14 avril 2012 08:54, Cyrille Giquello a écrit : > Bonjour, > > Peut-on me dire vite fait où cette page prend ses données ? > http://www.openstreetmap.fr/outils/limites-communales-a-importer > > Est-ce sur ? > http://suivi.openstreetmap.fr/communes/ > > Si oui, quel fichier ? Quelle fréquence ? > Le script part de ce fichier: http://suivi.openstreetmap.fr/communes/suivi-vectoriel.txt et vérifie ensuite via l'API si les communes n'ont pas été importée depuis. La fréquence ? C'est du live. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] api.fr ya eu un bug avec josm
Salut, Je viens d'essayer de charger des données avec josm 5174 et ça ne fonctionnait pas, avec api osm.org ça fonctionnait. Et pour écrire ce mail, je refais un essai et hop ça fonctionne à nouveau. L'erreur était du genre "prematured end of file". c'était vers 11h16. -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] api.fr ya eu un bug avec josm
Voilà que ça le refait. Copie d'écran de l'erreur ci-jointe. Le 14 avril 2012 11:18, Cyrille Giquello a écrit : > Salut, > > Je viens d'essayer de charger des données avec josm 5174 et ça ne > fonctionnait pas, avec api osm.org ça fonctionnait. > Et pour écrire ce mail, je refais un essai et hop ça fonctionne à nouveau. > L'erreur était du genre "prematured end of file". > c'était vers 11h16. > > -- > Cyrille. > > -- Cyrille. <>___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] osm.fr limites-communales-a-importer
Le samedi 14 avril 2012 09:48:40, Christian Quest a écrit : > Le script part de ce fichier: > http://suivi.openstreetmap.fr/communes/suivi-vectoriel.txt Dans le cas de traitement sur ces données, je rappel les divers choix dispo en csv : http://suivi.openstreetmap.fr/communes/ -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Logiciels de navigation pour Android
Le 13 avril 2012 23:27, sly (sylvain letuffe) a écrit : > Regarde osmand, ça ne fait pas tout de tes "préférences", mais c'est a mon > avis ce qui se fait de mieux pour l'instant. > L'interface est effectivement beaucoup plus intuitive. Par contre le routage hors-ligne sur 200km fait planter l'application. A surveiller donc. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] forum: Bien le bonjour...
Le message suivant : ## Bonjour à toute et tous depuis la terre de Picardie, Enseignant, j'ai participé avec des élèves au projet "Un Point c'est Tout" et c'est tout naturellement que je m'oriente vers openstreet map maintenant. Bien cordialement. xavier a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=10 Une réponse sur la liste directement n'est hélas pas transmise sur le forum, ce qui n'empeche pas une concertation avant réponse par email. Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour repondre. -- Tout commentaire sur ce message peut être demandé à sylvainaletuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] api.fr ya eu un bug avec josm
Le samedi 14 avril 2012 11:20:05, Cyrille Giquello a écrit : > Voilà que ça le refait. Copie d'écran de l'erreur ci-jointe. J'ai en effet constaté le problème qui se produit lorsque la machine est trop chargée, j'ai tenté de bidouiller des trucs pour voir si ça va mieux. A terme je devrais déplacer le service d'api sur un autre serveur ce qui devrait arranger les choses. -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] layers.openstreetmap.fr une fatigue ?
Bonjour, "NetworkError: 500 Internal Server Error - http://layers.openstreetmap.fr/tiles/renderer.py/admin8/11/1042/720.png"; etc... Un problème ? -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] layers.openstreetmap.fr une fatigue ?
Le samedi 14 avril 2012 18:27:32, Vincent Pottier a écrit : > Bonjour, > "NetworkError: 500 Internal Server Error - > http://layers.openstreetmap.fr/tiles/renderer.py/admin8/11/1042/720.png"; > etc... > > Un problème ? Oui ;-( Je sais pas encore trop d'où ça vient et que faire, mais le problème s'est manifesté il y a environ 3 jours et se reproduit de temps à autre. ça semble lié à des pics de "forte" affluence et le bidule se plante, rame et ne marche plus J'ai tout coupé pour analyse; ça devrait donc passer d'une erreur HTTP 500 Internal Server Error - à HTTP 403 - Ouste -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] osm.fr limites-communales-a-importer
Le 14 avril 2012 09:48, Christian Quest a écrit : > Le 14 avril 2012 08:54, Cyrille Giquello a écrit : > > Bonjour, > > > > Peut-on me dire vite fait où cette page prend ses données ? > > http://www.openstreetmap.fr/outils/limites-communales-a-importer > > > > Est-ce sur ? > > http://suivi.openstreetmap.fr/communes/ > > > > Si oui, quel fichier ? Quelle fréquence ? > > > > Le script part de ce fichier: > http://suivi.openstreetmap.fr/communes/suivi-vectoriel.txt > > et vérifie ensuite via l'API si les communes n'ont pas été importée depuis. > > La fréquence ? C'est du live. > Ha bon... Tu veux dire quand on charge la page ou que ça tourne en boucle ? -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] osm.fr limites-communales-a-importer
Le 14 avril 2012 20:50, Cyrille Giquello a écrit : > Le 14 avril 2012 09:48, Christian Quest a écrit > : > > Le 14 avril 2012 08:54, Cyrille Giquello a écrit : >> > Bonjour, >> > >> > Peut-on me dire vite fait où cette page prend ses données ? >> > http://www.openstreetmap.fr/outils/limites-communales-a-importer >> > >> > Est-ce sur ? >> > http://suivi.openstreetmap.fr/communes/ >> > >> > Si oui, quel fichier ? Quelle fréquence ? >> > >> >> Le script part de ce fichier: >> http://suivi.openstreetmap.fr/communes/suivi-vectoriel.txt >> >> et vérifie ensuite via l'API si les communes n'ont pas été importée >> depuis. >> >> La fréquence ? C'est du live. >> > > > Ha bon... Tu veux dire quand on charge la page ou que ça tourne en boucle ? > J'ai trouvé des communes qui restaient dans la liste et apparament ce n'est pas un problème de rafraîchissement mais des erreurs. En fait ton script fait aussi des vérifications de cohérence semble-t-il ? -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] superposition de frontières ( Était : =?utf-8?q?_Ari=C3=A8ge?=)
Comme je le disais, les superpositions de ways sont une plaie. On peut TOUJOURS s'en passer, même pour les cas les plus simples. Les relations permettent exactement la même chose qu'un way unique fermé, et permettent de découper les ways communs. En plus c'est nettement plus facile ensuite de travailler sur les ways et les affiner, les relations font le suivi (à condition que dans JOSM vous chargiez bien TOUTES les relations qui référencent le way, ce qui se fait en zoomant au maximum sur le point que vous voulez découper, et en chargeant la microzone rectanglaire autour de ce point: tous les ways (même superposés) passant par ce point sont chargés, de même que les relations qui les utilisent (cela ne charge pas tous les membres de ces relations, juste le nœud et les ways passant ou finissant par ce nœud) : La requête au serveur est très rapide en principe. Mais je vois que certains encore oublient de faire ce zoom et découpent des frontières en oubliant de charger toutes les relations qui y font référence : cela casse les frontières dans les deux cas: qu'elles soient dans une relation ou qu'elles soient superposées : Un zoom autour du point de découpe à ajouter est INDISPENSABLE, même si vous travaillez sur des zones très étendues que vous ne pouvez pas charger complètement (avec ce zoom la requête au serveur marche TOUJOURS). Le 12 avril 2012 13:54, sly (sylvain letuffe) a écrit : > >> Je ne sais pas si certains d'entre vous pratiquez déjà cette astuce >> (multipolygon), mais je trouve ça plus satisfaisant que ce que je faisais >> dernièrement (superposition) … > > +1 je n'utilise que ça ou presque. > J'ajoute que JOSM dispose d'un plugin appelé "multipoly-convert" qui permet de > transformer en un clic un way fermé classique en polygone "relation" > (en conservant le tag source sur le way, et en transférant les autres tags sur > la relation) > > > -- > 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] superposition de frontières ( Était : Ariège)
Entièrement d'accord, sauf en ce qui concerne les limites administratives et le cours central des rivières qui est aussi une ligne virtuelle, à l'exception de ses rives. Il n'y a aucun intérêt à tracer deux traits superposés pour ce cours central, mais c'est encore pire si on les superpose ! Pour moi un cours central de rivière se pose en suivant les points des rives et en utilisant Shift+B pour positionner un point central : avec assez de points sur la rive on obtient un joli cours central qui correspond assez bien au tracé des rives (moyennant certains ajustements par exemple dans les rias, où les rives varient selon la marée et laisse découvrir des zones humides, qu'on devrait pouvoir tracer séparément afin d'affiner les rives, le reste étant un type de landuse (landuse=wetland ? Il n'y a pas un autre meilleur type pour ces zones marécageuses à découvert, et inondées par marée haute). Pour le reste, une rivière, même son cours central ou ses rives, et une frontière administrative, ne devrait partager aucun nœud ni aucun chemin superposé. Il n'y a que les lignes de côtes qu'on utilise arbitraitrairement comme frontière administrative (alors que la définition des frontières administratives dépend de plusieurs définitions internationales : ligne de base, mer territoriale, ZEE, ou extension du plateau continental, l'utilisation de la ligne de côte mouvante ne posant pas trop de problème car elle se situe bien en deça des autres limites). Le 12 avril 2012 14:17, Vincent de Chateau-Thierry a écrit : > Bonjour, > >> Message du 12/04/12 13:55 >> De : "sly (sylvain letuffe)" > >> A : "Discussions sur OSM en français" >> Copie à : >> Objet : Re: [OSM-talk-fr] superposition de frontières ( Était : Ariège) >> >> >> > Je ne sais pas si certains d'entre vous pratiquez déjà cette astuce >> > (multipolygon), mais je trouve ça plus satisfaisant que ce que je faisais >> > dernièrement (superposition) … >> >> +1 je n'utilise que ça ou presque. >> J'ajoute que JOSM dispose d'un plugin appelé "multipoly-convert" qui permet >> de >> transformer en un clic un way fermé classique en polygone "relation" >> (en conservant le tag source sur le way, et en transférant les autres tags >> sur >> la relation) >> > > De mon côté, à l'exception des lignes de côte (natural=coastline), je trace > toujours des > ways distincts pour les limites (tag boundary=administrative), ce qui > n'empêche pas > d'utiliser tout ou partie des nodes existants sur des ways "physiques" : > rues, cours > d'eau. Ça correspond à la proposition #2 de ce paragraphe : > http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Tracer_les_ > limites_administratives#Limites_administratives_utilisant_des_.C3.A9l.C3.A9ments_physique > s > > Plusieurs raisons : > - le principe énoncé ici : > http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element même si on > n'est pas, > avec les limites administratives, en présence d'éléments visibles sur le > terrain, > > - une relation administrative qui inclut des rues, des cours d'eau, est plus > complexe à > "lire", elle a bien plus de membres que nécessaire. > > - la maintenance d'une telle relation est plus lourde. Je n'ai pas fait de > stats, mais > il m'arrive souvent de réparer des limites communales, et dans le lot des > erreurs > rencontrées, une grande majorité consiste en des polygones devenus invalides > suite à la > modification d'un élément physique inclus dans la relation : on retrace un > cours d'eau, > on allonge une rue, et le polygone défini dans la relation administrative > n'est plus > une boucle fermée. > > 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] Raccorder deux rivières
Oui mais la plupart du temps il est impossible de prédire quel nœud sera sélectionné en dernier quand ils sont déjà superposés. On les sélectionne alors à la souris dans un ordre quelconque et la fusion se fait vers le nœud le plus ancien (celui ayant le plus faible identifiant puisque c'est apparemment dans cet ordre que ce fait la sélection multiple avec un rectangle tracé à la souris dans JOSM : c'est le seul cas prédictible qui me convient bien car il préserve un maximum d'historiques, et je le préfère nettement à une sélection manuelle: je préfère déplacer les nœuds d'abord individuellement pour préserver la précision selon leur source : je préfère ne pas toucher aux positions des frontières administratives par exemple, ni surtout aux nœuds géodésiques, mais si ce sont des nœuds physiques, il n'y a aucune importance de précision puisque finalement on va l'ajuster selon la vue). Par principe aussi je ne fusionne jamais les nœuds géodésiques, même s'ils sont superposés (cela arrive quand ils sont à des élévations différentes, ils ont aussi des attributs en conflits dans ce cas sur leur numérotation de référence, désignation ou description). Le 12 avril 2012 07:24, Jo a écrit : > Car l'effet de la touche M est imprévisible : on ne sait jamais quels >> >> nœuds vont être déplacés vers la position d'un seul nœud qu'on veut >> conserver quand on a fait une sélection multiple. Il me fallit une >> commande pour superposer les points, ensuite la touche M seulement >> quand ils sont exactement à la même position pour que soit conservé >> alors le nœud plus ancien fusionnant ses attributs et ways connectés. > > > Si j'ai bien compris, c'est toujours vers le dernier noeud sélectionné > qu'ils sont déplacés ou en d'autre mots, c'est toujours ce dernier noeud qui > est préservé si on utlise la fonction merge. > > Jo ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] superposition ou pas des frontières administratives/éléments physiques ?
Le 12 avril 2012 15:09, sly (sylvain letuffe) a écrit : > 2)b) il est tétu (et il a bien raison) il re-dessine la rivière en laissant > là, ballante et désespérée, la limite de commune qui ne correspond plus alors > à son objet physique, on se retrouve alors avec deux ways presque côte à côte > de précision différente et là, on manque d'outil pour le détecter et la > frontière n'a pas profité de cette amélioration Et pourquoi ce comportement serait une anomalie ? La rivière est redessinée, la frontière administrative reste à part et c'est très bien comme ça. Même si elles sont proches se sont deux entités distinctes qui évoluent séparément l'une de l'autre. Dans les faits il y a peu d'intérêt à superposer les frontières administratives avec les tracés des rivières, routes. A la limite des objets peu importants comme les chemins de terre peuvent suivre la frontière administrative, historiquement d'ailleurs et légalement ces chemins communaux doivent être maintenus en l'état même si c'est à la charge d'un propriétaire. Il peut pour des raisons de convenance créer des raccourcis pour le passage de ses tracteurs ou véhiculer des troupeaux par un chemin plus pratique, tant que subsiste un chemin pas trop éloigné du chemin communal. Il peut avoir à la faire aussi pour faciliter les cultures quand ce tracé passe entre deux parcelles légales qu'un même fermier ou lotisseur exploite, il laissera juste en place les bornes cadastrales et demandera à en enlever une ou la placer ailleurs sur le tracé légal, en supposant qu'un géomètre ira d'abord étudier le placement de la nouvelle borne, ou prendra des mesures précises basées sur d'autres points de référence qui seront reportés au cadastre. Plus compliqué est le cas des terrains qui se sont déplacés par un lent glissement de terrain. Les terrains emportent tout ce qui est dessus, bornes cadastrales incluses. Les tracés et surfaces du cadastre peuvent ne plus correspondre exactement et doivent être remises à jour, mais tant que ce n'est pas fait, il n'y a pas de raison de déplacer les frontières administratives (à moins qu'on aille relever la nouvelle position exacte de la borne sur le terrain), alors qu'on peut déjà modifier les tracés des emplacements physiques (naturels et bâtis). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] layers.openstreetmap.fr une fatigue ?
Fuites mémoires très probables, ou boucle infinie quelquepart, bogue du logiciel donc, plus qu'un réel afflux. Le trafic n'est qu'une cause déclenchante du plantage, mais je ne crois pas du tout que ce soit une question de trafic, mais plus lié à des requêtes nécessitant un volume de données important, les fuites mémoires s'accélérant alors et finissant par planter le système. En attendant l'outil est toujours en panne. Le 14 avril 2012 19:33, sly (sylvain letuffe) a écrit : > Le samedi 14 avril 2012 18:27:32, Vincent Pottier a écrit : >> Bonjour, >> "NetworkError: 500 Internal Server Error - >> http://layers.openstreetmap.fr/tiles/renderer.py/admin8/11/1042/720.png"; >> etc... >> >> Un problème ? > > Oui ;-( > Je sais pas encore trop d'où ça vient et que faire, mais le problème s'est > manifesté il y a environ 3 jours et se reproduit de temps à autre. > > ça semble lié à des pics de "forte" affluence et le bidule se plante, rame et > ne > marche plus > > J'ai tout coupé pour analyse; ça devrait donc passer d'une erreur > HTTP 500 Internal Server Error - > à > HTTP 403 - Ouste > > > > -- > sly (sylvain letuffe) > > ___ > 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] Osmecum sur les tags liés aux handicaps
Je ne vois pas trop ce qu'on peut mapper concernant l'accessibilité pour ceux souffrant de déficit mental. Hormi les structures sociales et médicales d'accompagnement quand elles ont une adresse. Comment rendre une carte moins compliquée ? Pas avec de nouveaux tags, mais avec une interface permettant de montrer des sujets d'intérêt particulier. Autrement dit avec une carte sélective dérivée. Pour ça on a des sources dans les collectivités qui renseignent sur les services et associations d'aide disponibles. Y a-t-il des signalisations particulières sur le terrain ou des dispositifs techniques réellement destinées aux déficients mentaux, comme on peut avoir des marquages en relief au sol sur les carrefours et des bouton d'appel et signaux audibles aux feux de traversée pour les aveugles, ou des rampes d'accès et ascenseurs pour les personnes en fauteuil, et autres places de parking réservées aux conducteurs handicapés moteurs ou aux accompagnateurs reconnus de personnes ayant d'autres handicaps ? Concernant le handicap auditif, je crois que la signalisation visible pallie grandement le handicap. Après tout on est tous handicapés auditifs quand on est dans un véhicule, la signalisation est essentiellement visuelle ; c'est pour ça que le permis de conduire est conditionné à la vue ou à une correction contrôlée comme efficace, ainsi qu'à la maîtrise de son équilibre et de ses gestes et la faculté de réagir, comprendre et mémoriser correctement (Il y a d'autres critères médicaux contrôlés par la commission médicale du permis de conduire, la liste est assez impressionnante quand on la découvre maintenant, ce qui fait que mon propre permis de conduire n'a été renouvelé que pour un an, et que je vais devoir repasser la visite médicale en août à cause seulement d'une petite anomalie bénigne de formulation sanguine lors du dernier contrôle liée à ce que j'avais mangé la veille de l'examen. Il y a 20 ans on ne contrôlait pas ça du tout, il n'y avait que le fait qu'on disposait d'une correction visuelle contrôlée très sommairement et qu'on tenait apparemment debout tout seul...). Le 13 avril 2012 09:12, ZIMMY a écrit : > Il reste maintenant l'équivalent pour les autres types de handicap : > *auditif*, *visuel*, *mental*. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
