[OSM-talk-nl] Onderschriften straatnaambordjes
Hoi allemaal, Is er in OSM ook de mogelijkheid om onderschriften op straatnaambordjes zoals Vlaamse barokschilder 1577 - 1640 op te slaan? Groeten, Pander ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
[Talk-de] In JOSM nur den name-Tag von Waypoints anzeigen
Hallo, Ihr müßt meinem Gedächntnis einmal auf die Sprünge helfen. Ich habe einen verschiedene Waypoint aufgezeichnet. Wenn ich diese in JOSM anzeigen lasse, werden zusätzlich zu dem Name-Tack eines Waypoints noch zusätzliche angezeigt. Ich weiß irgendwa gibt es einen Schalter in JOSM (7588) dies zu unterbinden. Ich finde ihn aber nicht mehr. Auch die Suche in div. Foren hat mir bis jetzt nicht weiter geholfen. Gruß hike39 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] In JOSM nur den name-Tag von Waypoints anzeigen
In den JOSM Einstellungen gleich die erste Seite die auf geht unten Waypoint labeling. Ich glaube das suchst du. VG Klumbumbus Am 11.10.2014 14:59, schrieb hike39: Hallo, Ihr müßt meinem Gedächntnis einmal auf die Sprünge helfen. Ich habe einen verschiedene Waypoint aufgezeichnet. Wenn ich diese in JOSM anzeigen lasse, werden zusätzlich zu dem Name-Tack eines Waypoints noch zusätzliche angezeigt. Ich weiß irgendwa gibt es einen Schalter in JOSM (7588) dies zu unterbinden. Ich finde ihn aber nicht mehr. Auch die Suche in div. Foren hat mir bis jetzt nicht weiter geholfen. Gruß hike39 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] In JOSM nur den name-Tag von Waypoints anzeigen
Danke Klumbumbus, Am 11.10.2014 um 14:59 schrieb simson.gert...@gmail.com: In den JOSM Einstellungen gleich die erste Seite die auf geht unten Waypoint labeling. Ich glaube das suchst du. VG Klumbumbus wie kann man nur so blind sein. Diese Einstellung kommt natürlich nur im ExpertenModus. Der war bei mir nicht aktiviert. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-es] Actualización de Modificaciones
Hola a todos. Subí unas modificaciones y actualizaciones desde JOSM hace 4 días y todavía no aparecen. Anteriormente subí otras con menos volumen y ya están actualizadas. ¿En que plazo se suelen actualizar? Me he unido a osm hace poco y todavía no conozco el proceso de verificación. Saludos ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
[Talk-es] ¿Cómo mapear las salidas de autopista?
Hola mapeadores, a raiz de que k1wi nos haya facilitado revisar las autopistas con CheckAutopistas, he comprobado algunas de las que ya había modificado hace algún tiempo y he encontrado que otros mapeadores tenían un criterio diferente sobre dónde colocar el nodo motorway_junction (¡bienvenido a la lista!, polkillas). La documentación en español dice que Hay que colocarlo en el punto (nodo) en el que el carril comienza a separarse de la autopista/autovía. En inglés es más vago y dice: This node should be positioned as the last point before the splay at which it is still possible to make a smooth turn, es decir en el último punto en el aún se pueda salir del carril con un giro suave. ¿Podemos considerar el carril de salida (y el de entrada) de una autopista como un carril más de la vía? En ocasiones el carril de entrada se prolonga durante cientos de metros hasta unirse con el carril de salida siguiente. Sin embargo, los carriles de aceleración y deceleración están separados de la vía principal por una línea blanca longitudinal discontinua de trazos más anchos y cortos que los de las líneas de separación de carriles normales de circulación. En mi opinión, estos carriles no se pueden considerar carriles de la vía principal sino vías diferentes, motorway_link en este caso. Además, según mi manual de circulación, para tomar el carril de deceleración debemos Estar atentos a la señalización que anuncia la salida, colocándonos con antelación en el carril de la derecha. Por eso procuro colocar el nodo motorway_junction en el punto de la carretera en el que se anuncia la salida y que suele coincidir con el comienzo del carril de deceleración. En resumen, tengo dos preguntas para esta comunidad: - ¿dónde hay que colocar el nodo motorway_junction? - ¿cómo hay que mapear las vías de aceleración y deceleración de las autopistas? Saludos. ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] ¿Cómo mapear las salidas de autopista?
El nodo motorway_junction yo lo pongo siempre en el nodo donde se separan las vías según lo mapeamos, vamos en donde esta dibujado el principio de la vía de desaceleración, la motorway_link. Es lo que detecta el CheckAutopistas y eso creo que no habría duda de que es así. En cuanto a como considerar los carriles en todo momento se deberían considerar carriles fuera de la vía principal. Como indicas son motorway_link, sino vaya cachondeo tendría de carriles la autopista. Lo que yo siempre he tenido la duda es donde empiezan y terminan los carriles de aceleración y desaceleración. Yo normalmente los he pintado cerca del primer punto donde se juntan cuando es carril de aceleración o del punto donde se separan definitivamente cuando es de desaceleración, cosa que no tengo clara que este bien. Vamos pienso que muy probablemente este mal, que se debe dibujar donde empieza el carril de desaceleración pero nunca lo he tenido claro y por eso no he modificado nunca esos casos. Saludos. El 11 de octubre de 2014, 21:56, Roberto geb roberto...@gmail.com escribió: Hola mapeadores, a raiz de que k1wi nos haya facilitado revisar las autopistas con CheckAutopistas, he comprobado algunas de las que ya había modificado hace algún tiempo y he encontrado que otros mapeadores tenían un criterio diferente sobre dónde colocar el nodo motorway_junction (¡bienvenido a la lista!, polkillas). La documentación en español dice que Hay que colocarlo en el punto (nodo) en el que el carril comienza a separarse de la autopista/autovía. En inglés es más vago y dice: This node should be positioned as the last point before the splay at which it is still possible to make a smooth turn, es decir en el último punto en el aún se pueda salir del carril con un giro suave. ¿Podemos considerar el carril de salida (y el de entrada) de una autopista como un carril más de la vía? En ocasiones el carril de entrada se prolonga durante cientos de metros hasta unirse con el carril de salida siguiente. Sin embargo, los carriles de aceleración y deceleración están separados de la vía principal por una línea blanca longitudinal discontinua de trazos más anchos y cortos que los de las líneas de separación de carriles normales de circulación. En mi opinión, estos carriles no se pueden considerar carriles de la vía principal sino vías diferentes, motorway_link en este caso. Además, según mi manual de circulación, para tomar el carril de deceleración debemos Estar atentos a la señalización que anuncia la salida, colocándonos con antelación en el carril de la derecha. Por eso procuro colocar el nodo motorway_junction en el punto de la carretera en el que se anuncia la salida y que suele coincidir con el comienzo del carril de deceleración. En resumen, tengo dos preguntas para esta comunidad: - ¿dónde hay que colocar el nodo motorway_junction? - ¿cómo hay que mapear las vías de aceleración y deceleración de las autopistas? Saludos. ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es -- Jorge Sanz Sanfructuoso - Sanchi Blog http://blog.jorgesanzs.com/ ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-at] Wien Prater Hauptallee: Revert?
Hi, der User Hatti hat die Änderungen mit dem iD-Editor durchgeführt. Ich hab’s gerade nachgestellt, der Editor warnt nicht, wenn durch einen Join Tags mit mehreren Werten rauskommen oder dadurch Relationen zerstört werden. Ich hab auf Github mal ein Issue eintegragen: https://github.com/openstreetmap/iD/issues/2393 Der User Hatti hat übrigens auf meine Nachricht noch nicht reagiert, und am selben Tag außerdem noch eine Änderung gemacht (https://www.openstreetmap.org/changeset/25954196), die zu einem Multi-Value-Tag (maxspeed=30;50) geführt hat (habs schon ausgebessert, daher v2 und der alte maxspeed-Wert). Ich hab ihn heute nochmals angeschrieben, ob er die Nachricht bekommen hat. Bin gespannt. Mir fehlt ein bisschen das Verständnis dafür, auf solche Nachrichten überhaupt nicht zu reagieren und dann gleich weiterzumachen. Es sollte ja jeder Benutzer E-Mail-Benachrichtigungen bekommen oder? Wird die E-Mail-Adresse bei der Registrierung verifiziert? Schöne Grüße Thomas Am 09.10.2014 um 08:44 schrieb Thomas Konrad tkon...@gmx.net: Hallo, Changesets https://www.openstreetmap.org/changeset/25917049 und https://www.openstreetmap.org/changeset/25917096 sind jetzt auch korrigiert, Benutzer Hatti wurde informiert (Text siehe unten, darf gerne bei ähnlichen Fällen wiederverwertet werden). Schöne Grüße Thomas Hallo Hatti, erstmal danke für deine Beiträge auf OSM, ich habe gesehen du hast in letzter Zeit einiges beigetragen! Ich schreibe dir, um dich auf einige Probleme hinzuweisen, die ein paar deiner Änderungen in letzter Zeit verursacht haben, und zwar im Bezug auf das Zusammenführen von Wegen. 1.) Prater Hauptallee. Hier hat das Zusammenführen der beiden Teilstücke dazu geführt, dass Tags mit Doppelwerten in der Datenbank waren (z.B. highway=unclassified;residential oder motor_vehicle=no;private). Ein highway kann nicht gleichzeitig unklassifiziert und eine Wohnstraße sein. Das hat auch dazu geführt, dass sich der Mapnik-Renderer nicht mehr auskannte und die Hauptallee von der OpenStreetMap-Hauptkarte verschwunden ist. Ich habe das Problem gestern Abend behoben, die Tags sollten jetzt wieder stimmen. 2.) Mauerbachstraße. Das ist schon ein wenig komplizierter. Hier haben die Teilstücke jenen Sinn, dass unterschiedliche Stücke Teil verschiedener sogenannten Relationen sind. Eine Relation ist ein Zusammenschluss mehrerer Wege (ways), Punkte (nodes) etc. zu einer Einheit. Das sind zum Beispiel: Wanderwege, Bus- und Straßenbahnlinien, Grenzen, Mountainbikestrecken und so weiter. Bei den Stücken, die du zusammengefügt hast, was das der Fall. Konkret wird zum Beispiel das kleine Stück zwischen Vorderhainbach und Hohe-Wand-Gasse (http://www.openstreetmap.org/#map=19/48.23068/16.19986) sehr oft als Teil von Wanderwegen und Mountainbikestrecken verwendet. Durch deine Änderungen wurden daher leider folgende Relationen fehlerhaft: NÖ Landesrundwanderweg, Voralpenweg, Wienerwald Verbindungsweg Mödling - Grinzing, Millenium-Strecke (Mountainbike), Hadersdorf Bhf. - Vorderhainbach (Fußweg). Außerdem hatten die Teilstücke, die zu zusammengeführt hast, unterschiedliche Geschwindigkeitsbegrenzungen (30 bzw. 50 km/h). Das wurde dann zu maxspeed=30;50, was keinen Sinn macht. Ich habe die falschen Tags und die Relationen gerade eben korrigiert. Du siehst schon, so kleine Änderungen können große Auswirkungen haben. Ich bitte dich daher, nächstes mal genau auf folgende Dinge zu achten, wenn du Teilstücke zusammenführst: Haben die Teilstücke unterschiedliche Tags (z.B. highway oder maxspeed)? Wenn ja, kann man die Stücke möglicherweise nicht zusammenführen. Der Editor iD reiht die Tag-Werte in einem solchen Fall einfach mit Strichpunkt getrennt aneinander, was in den meisten Fällen zu keinen sinnvollen Tag-Werten führt. Sind die Wegstücke Teil unterschiedlicher Relationen? Wenn ja, die Wegstücke auf keinen Fall zusammenführen, da die Relationen dadurch fehlerhaft werden. Im Editor iD siehst du Relationen übrigens, wenn du im Objekt bearbeiten-Dialog links ganz nach unten scrollst (Alle Relationen). Wenn du Fragen hast, kannst du dich gerne an die Mailingliste (hier wurde das Problem übrigens auch diskutiert, siehe https://lists.openstreetmap.org/pipermail/talk-at/2014-October/006999.html) oder wenn du möchtest auch gerne direkt an mich wenden. Schöne Grüße Thomas Am 08.10.2014 um 18:01 schrieb Thomas Konrad tkon...@gmx.net: Hallo! Da ich kein Problem mit Relationen sehe habe ich jetzt die Hauptallee mal als ein Stück gelassen und die Tags nach bestem Wissen und Gewissen upgedated: ALT-SUEDOST * bicycle=yes foot=yes highway=unclassified lanes=2 lcn=yes maxspeed=50 motor_vehicle=no name=Hauptallee surface=asphalt ALT-NORDWEST *** surface=asphalt name=Hauptallee highway=residential foot=yes bicycle=yes NACH
Re: [Talk-at] Wien Prater Hauptallee: Revert?
On 10/11/2014 06:04 PM, Thomas Konrad wrote: Hi, der User Hatti hat die Änderungen mit dem iD-Editor durchgeführt. Ich hab’s gerade nachgestellt, der Editor warnt nicht, wenn durch einen Join Tags mit mehreren Werten rauskommen oder dadurch Relationen zerstört werden. Ich hab auf Github mal ein Issue eintegragen: https://github.com/openstreetmap/iD/issues/2393 iD ist so userfreundlich, dass man keine Ahnung hat was man eigentlich macht. Ich tu mir schwer Leuten das vorzuwerfen, die mit dem Bedienkonzept scheitern, aber ich mag iD wirklich überhaupt nicht. Die Fehleranfälligkeit der iD Änderungen ist glaub ich ein Hauptkritikpunkt an dem Editor aber gefühlt verbessert sich daran seit es ihn gibt nichts. Mag sein, dass meine Wahrnehmung da etwas verzerrt ist, da ich auch Potlatch schon nicht gemocht hab und immer ein Fan von Offline Editoren war. Der User Hatti hat übrigens auf meine Nachricht noch nicht reagiert, und am selben Tag außerdem noch eine Änderung gemacht (https://www.openstreetmap.org/changeset/25954196), die zu einem Multi-Value-Tag (maxspeed=30;50) geführt hat (habs schon ausgebessert, daher v2 und der alte maxspeed-Wert). Ich hab ihn heute nochmals angeschrieben, ob er die Nachricht bekommen hat. Bin gespannt. Mir fehlt ein bisschen das Verständnis dafür, auf solche Nachrichten überhaupt nicht zu reagieren und dann gleich weiterzumachen. Es sollte ja jeder Benutzer E-Mail-Benachrichtigungen bekommen oder? Wird die E-Mail-Adresse bei der Registrierung verifiziert? Ich weiß nicht ob das verifiziert werden muss. Aber wenn es öfter vorkommt dann gibt's die Möglichkeit einer Sperre, bis er die Meldung sicher gelesen hat. Sollte man also im Auge behalten. Das seh ich gar nicht bös, aber wer auf die Message und Email nicht reagiert (aus welchem Grund auch immer) muss halt ev. darauf aufmerksam gemacht werden. Also wenn das nochmal vorkommt würd ich da einfach die Data Working Group um eine kurze Sperre bitten, dann kann er nicht mehr editieren ohne das zu lesen. Und Bösartigkeit steckt da sicher keine dahinter, ich denk er kriegt die Mails und Nachrichten nur einfach nicht mit. Norbert ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Wien Prater Hauptallee: Revert?
Thomas Konrad wrote: der User Hatti hat die Änderungen mit dem iD-Editor durchgeführt. Ich hab’s gerade nachgestellt, der Editor warnt nicht, wenn durch einen Join Tags mit mehreren Werten rauskommen oder dadurch Relationen zerstört werden. Ich hab auf Github mal ein Issue eintegragen: https://github.com/openstreetmap/iD/issues/2393 Merkaartor macht übrigens genau dasselbe (sowohl die kommentarlosen Mehrfachtags, als auch die kommentarlos zerstörten Relationen), wahrscheinlich haben die iD-Autoren diese Art der Konfliktlösung auch von dort. Die ist halt für die Zielgruppe von iD noch ungeeigneter als für die Zielgruppe von Merkaartor. Kevin Kofler ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk-fr] Osmose et détection d'erreurs sur l'élévation des sommets
Le 10/10/2014 11:02, Nicolas Moyroud a écrit : - un m à la fin n'est tout simplement pas une erreur, c'est juste l'unité par défaut. Non. Même si le wiki ne dit pas explicitement que c'est une erreur, tout le suggère : http://wiki.openstreetmap.org/wiki/Key:ele «Elevation of a point in metres in WGS84.» Voir aussi les exemples cités. On ne met pas capacity=10 places JB. Tout à fait d'accord. En plus l'erreur osmose s'appelle valeur numérique. Une lettre représentant une unité n'a donc rien à y faire. Voilà c'est à jour : http://osmose.openstreetmap.fr/fr/errors/?country=france_languedoc_roussillonitem=3091 Par contre ça autorise toujours une unité (c'est même le propre de cette analyse) https://github.com/osm-fr/osmose-backend/blob/master/plugins/Number.py Tu peux voir le détail des tags d'un objet en erreur en cliquant sur le E, mais je pense que ça ne va pas t'aider plus que ça Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose : erreur de commune pour le géocodage d'un Monument historique non intégré
Le 07/10/2014 18:50, Yves Pratter a écrit : Bonsoir, Le château de Malans https://fr.wikipedia.org/wiki/Ch%C3%A2teau_de_Malans est proposé en intégration par Osmose sur la commune de Malans dans le Doubs http://osmose.openstreetmap.fr/fr/map/#zoom=17lat=47.047664lon=6.02994layer=Mapnikoverlays=FFFTitem=8010,8011level=1,2,3tags=fixable=bbox=6.0033416748046875,47.02579108605617,6.112775802612305,47.05942265793944, alors qu’il s’agit de Malans dans la Haute-Sâone http://osmose.openstreetmap.fr/fr/map/#item=8xxxlevel=tags=fixable=bbox=5.52783966064453,47.2525530441804,5.637273788452148,47.28604144759514layer=Mapnikzoom=15lat=47.26433lon=5.59365. Fiche méritée PA00102218 http://www.culture.gouv.fr/public/mistral/mersri_fr?ACTION=CHERCHERFIELD_1=REFVALUE_1=PA00102218 Est-ce un problème de données ou un bogue dans Osmose ? En entre les deux. Les monuments ont été géocodé en 2012 avec nominatime (donc données OSM). Il faudrait refaire le géocodage ou refaire le point sur les données données disponible aujourd'hui sur le sujet. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Nouveau sur la liste] Bonjour à tous !
Salut Frem, rebienvenu! On Oct 10, 2014 3:07 PM, frem mjnpodq.f...@harmon.fr wrote: Je me présnete : frem (frem-eu sur osm), actif en région Poitou-Charentes, avec qqes années de contributions derrière moi (depuis 2008). J’ai recommencé à contribuer de façon plus active et je vous rejoins pour discuter des problématique encore non-résolues et du projet en général. À bientôt frem ___ 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] Géocacheurs...
Salut, Nouveau sur la liste, j'habite prés de Libourne, contributions OSM locales autour de chez moi. Je confirme geocaching et OSM font bon ménage. J'ai commencé par le geocaching. Les Geocacheurs ont leur GPS allumé tout le temps et je voulais que mes traces servent à quelque chose. J'ai découvert OSM qui me permet : - de mieux préparer mes sorties Geocaching en étudiant la carte existante - de trouver des nouveaux spots pour placer des caches. - de rajouter une activité en en route entre la voiture et la cache. Une promotion par objets voyageur est une bonne idée car chaque objet à une mission = une page web que chaque géocacheur consulte à le découverte de l'objet. Sur ces pages il est possible de déposer une description de OSM et liens vers plus d'info. La mission peut même être rajouter un chemin ou un tag sur OSM... Laudge On 2014-10-07 19:56, Eric Debeau wrote: Salut Je suis aussi un peu loin aussi. C'est vrai que ce serait une bonne idée de créer des objets voyageurs OSM. Bon courage et bonne promo de OSM. Eric 2014-10-07 19:14 GMT+02:00 Sylvain Maillard sylvain.maill...@gmail.com: Salut, un peu loin également ce week-end ... bon courage pour les innombrables questions ;) Sylvain Le 7 octobre 2014 16:35, Yves Pratter yves.prat...@gmail.com a écrit : Le 7 oct. 2014 à 16:18, Christian Quest cqu...@openstreetmap.fr a écrit : Je n'ai eu aucun retour pour cet évènement qui se déroulera ce week-end.Je suis trop loin géographiquement mais le coeur y est :-) Je pense que c'est un belle opportunité à saisir pour faire venir à OSM des géocacheurs, mais à moi tout seul je vais avoir un peu de mal à assurer le week-end !As-tu pensé à mettre des goodies dans les géocaches ? Pour ceux qui ne sont pas « initiés », les organisateurs d’un rassemblement de géocacheurs mettent des petits cadeaux/souvenirs pour les FTF (first to find) dans les nouvelles caches. Ça peut être un pins, badge… il suffit que ça tienne dans la boite ;-) Il est aussi possible de mettre des objets plus « précieux » et particuliers : les « objets voyageurs » (travel bug) ou des « géo-monnaies » (geocoin). Ceux-ci sont souvent offerts au FTF lors des rassemblement. De toutes façon, ils sont destinés à voyager. On peut ainsi voir leurs trajets sur une carte (OSM ;-) Le « top » et d’en faire réaliser des personnalisé pour l’occasion ou pour promouvoir une cause (lutte contre le diabète… et au hasard : OSM). Quelques exemples : « simples [1] » « sophistiqués [2] »… il n’y a pas de limites ! — Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr [3] ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr [3] Links: -- [1] http://www.cache-aventure.com/epages/box13593.sf/fr_FR/?ObjectPath=/Shops/box13593/Categories/GEOCOINS/micro_geocoins [2] http://www.cache-aventure.com/epages/box13593.sf/fr_FR/?ObjectPath=/Shops/box13593/Categories/GEOCOINS/geocoins_navigation [3] 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
[OSM-talk-fr] Intégration des pharmacies en France avec Osmose
Bonjour, L'entreprise Celtipharm à mise à disposition son recensement des pharmacies en France. Les données ont été collectées sur le terrain depuis 2000. Il y a donc près de 14 ans de métier ;) dans ces données. Ils ont été séduit par OSM et y voient une opportunité de moderniser leur système d'information avec une publication en OpenData sous licence ODbL. Après un test et des retours sur leurs données, l'intégration est maintenant possible sur Osmose : http://osmose.openstreetmap.fr/fr/errors/?source=7406item= Pharmacies dans OSM sans référence ref:FR:FINESS : http://osmose.openstreetmap.fr/fr/map/#item=7150 Pharmacie non intégré, en OpenData mais référence non retrouvé dans OSM http://osmose.openstreetmap.fr/fr/map/#item=8210 Proposition de rapprochement entre l'OpenData et l'OSM : http://osmose.openstreetmap.fr/fr/map/#item=8211 Le travail préliminaire à cette intégration à Osmose à soulevé des questions sur la liste CA, que je vous livres dans un soucie de transparence : - le tag type:FR:FINESS est aussi utilisé 216 fois. Désolé, mais là par contre je ne vois pas l'intérêt de mettre ça dans OSM. On a déjà des tags pour mettre en correspondance de ces numéros. Sauf si le type fait partie de l'identifiant, mais dans ce cas il ne faudrait pas un tag séparé. Il y a même une page sur le wiki : http://wiki.openstreetmap.org/wiki/FR:Key:type:FR:FINESS [moi] - Le problème, c'est que ces intégrations osmose ne sont pas documentées depuis osmose et très mal dans le wiki et qu'il y a en a de plus en plus. D'ailleurs, le fait même que cette discussion se passe sur la liste ca@ et non sur la liste talk-fr@ est aussi symptomatique. [Pieren] - Je serais d'ailleurs curieux de connaitre la réaction à la demande d'ajouter… 9000 ? tag ref:FR:FINESS pour une valeur ajoutée… légère ? d'un point de vue contributeur/réutilisateur basique ? J'ai encore du mal avec ces rapprochements de bdd séparées uniquement à l'aide d'un identifiant unique, alors qu'avec une position géographique, un nom, une adresse, on doit pouvoir rapprocher la quasi-totalité des existantes dans OSM (du moins sur l'échantillon représentatif d'une dizaine regardée du coté de Troyes). On parle de pharmacies, pas d'arbres ou de batiments, quand même… Bon, non, j'ai pas les doigts dans le code. [JB] Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Prix des carburants ?
Le 10 oct. 2014 à 23:38, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : L'analyse est donc maintenant disponible et avec plus de tags supportés. Merci :-) Si vous être curieux de voir la mapping de tags c'est là : https://github.com/osm-fr/osmose-backend/blob/2cd5c8238124c405a98e78052a015b0ce1e7172e/analysers/analyser_merge_fuel_FR.py opening_hours=* n’est traité pour le moment que dans le cas de l’ouverture 24h/24 et 7j/7 Je vais essayer de traiter les autres cas. Comme je n’ai pas accès au serveur, je vais remplir à la main les valeur de debut, fin et saufjour. Est-ce qu’elles restent telles que dans le fichier xml ou reformates-tu leur contenu ? res[debut] = ’07:00’ res[fin] = ’20:00’ res[saufjour] = ‘Samedi;Dimanche’ J’ai vu que tu ne proposes pas d’attribut ref. Il y en a un, mais ne sachant pas à quoi il correspond, mais je ne l'ai pas prit. Ben, c’est un identifiant unique utilisé par la DGCCRF ? Il est utilisé dans le code HTML des pages du site du ministère : http://www.prix-carburants.economie.gouv.fr/recherche/ Exemple : STATION AVIA - GARAGE BEUCLER Avia 82 Rue du Général de Gaulle 25420 BART tr class=data charged show id=25420005 » Au passage, on doit pourvoir faire un tag2link vers une station ? En mettant les bons paramètres dans les paramètres de la requête post vers cette page… Et c’est pratique, on peut vérifier d’autres données comme le nom, la marque … — Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Intégration des pharmacies en France avec Osmose
Date: Sat, 11 Oct 2014 12:25:33 +0200 From: fred.rodr...@gmail.com To: talk-fr@openstreetmap.org Subject: [OSM-talk-fr] Intégration des pharmacies en France avec Osmose Bonjour, L'entreprise Celtipharm a mise à disposition son recensement des pharmacies en France. Les données ont été collectées sur le terrain depuis 2000. Il y a donc près de 14 ans de métier ;) dans ces données. Ils ont été séduits par OSM et y voient une opportunité de moderniser leur système d'information avec une publication en OpenData sous licence ODbL. Après un test et des retours sur leurs données, l'intégration est maintenant possible sur Osmose : Bonjour Frédéric,J'ai reçu ton annonce en même temps qu'une de ces erreurs via RSS alors j'ai jeté un oeil. J'ai plusieurs remarques : - Le géocodage est bizarre, le marqueur n'est pas situé sur ou à proximité du point adresse dans OSM mais sur la rue correspondante, et même pas au droit de l'adresse.- ref:FR:FINESS c'est quoi ? le Wiki OSM ne connait pas.- Toutes les erreurs Intégration portent un tag name rempli, par défaut avec le nom du propriétaire. 1) Ça ne correspond pratiquement jamais avec ce qu'on peut lire sur le terrain. 2) Le nom de famille est parfois répété 3) Le nom est en majuscules, j'ai souvenir que ce n'est pas correct du point de vue des conventions typographiques. Pour moi, name doit contenir le nom vu sur le terrain en devanture, pas le nom professionnel utilisé dans les déclarations administratives.- J'ai des propositions d'intégration pour des pharmacies déjà présentes avec ou pas le nom identique à la proposition d'intégration. Exemple sur un quartier qui contient 4 pharmacies : http://osmose.openstreetmap.fr/fr/map/#item=8210zoom=18lat=48.845012lon=2.40489layer=Mapnikoverlays=FFFTbbox=2.402781844139099%2C48.84406629555003%2C2.408929467201233%2C48.84597266461056level=3tags=fixable= 4 propositions d'intégrations, 3 pharmacies déjà présentes. Dans les 4 cas, les points adresse existent mais ne sont pas utilisés pour placer les marqueurs. 2 proposent un tag name rempli avec le nom du pharmacien (Diaz et Haddad) mais qui n'est pas le nom affiché sur la devanture. 1 propose un tag name Pharmacie CENTRALE SAINT MANDE alors que la devanture indique seulement Pharmacie. George___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Prix des carburants ?
Le 11/10/2014 12:26, Yves Pratter a écrit : Le 10 oct. 2014 à 23:38, Frédéric Rodrigo fred.rodr...@gmail.com mailto:fred.rodr...@gmail.com a écrit : L'analyse est donc maintenant disponible et avec plus de tags supportés. Merci :-) Si vous être curieux de voir la mapping de tags c'est là : https://github.com/osm-fr/osmose-backend/blob/2cd5c8238124c405a98e78052a015b0ce1e7172e/analysers/analyser_merge_fuel_FR.py opening_hours=* n’est traité pour le moment que dans le cas de l’ouverture 24h/24 et 7j/7 Je vais essayer de traiter les autres cas. Comme je n’ai pas accès au serveur, je vais remplir à la main les valeur de debut, fin et saufjour. Est-ce qu’elles restent telles que dans le fichier xml ou reformates-tu leur contenu ? res[debut]= ’07:00’ res[fin]= ’*20:00*’ res[saufjour] = ‘*Samedi;Dimanche*’ Comme déjà dit je pense que l'on ne peut que accorder qu'un confiance limité en ça. Ça produit un tag osm opening_hours, c'est con son format : http://wiki.openstreetmap.org/wiki/Key:opening_hours Je ne suis pas trop pour intégrer des données peu fiable et inmaintenable. J’ai vu que tu ne proposes pas d’attribut ref. Il y en a un, mais ne sachant pas à quoi il correspond, mais je ne l'ai pas prit. Ben, c’est un identifiant unique utilisé par la DGCCRF ? Il est utilisé dans le code HTML des pages du site du ministère : http://www.prix-carburants.economie.gouv.fr/recherche/ Exemple : STATION AVIA - GARAGE BEUCLER Avia 82 Rue du Général de Gaulle 25420 BART tr class=data charged show id=*25420005* » Pour c'est juste un identifiant interne et pas de référence. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [Osmose] Analyse sur la voirie en forêt
Bonjour, Je profite qu'Osmose soit le sujet de cette liste en ce moment pour proposer 2 analyses sur la voirie en forêt. Ça fait suite à des cas que j'ai souvent rencontrés : 1) Nom de carrefourDans les forêts, repérer les noeuds à l'intersection de ways highway=* et portant uniquement un tag name=*. Proposer de rajouter junction=yes avec comme message à l'utilisateur : Junction=yes manquant pour le nom du carrefour. 2) Abréviation de Route ForestièreDans les forêts, repérer les ways highway=* avec name=RF * et proposer à l'utilisateur de changer ce name en Route forestière * Des remarques, des avis sur ces analyses ? George ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Intégration des pharmacies en France avec Osmose
Le 11/10/2014 13:25, George Kaplan a écrit : Date: Sat, 11 Oct 2014 12:25:33 +0200 From: fred.rodr...@gmail.com To: talk-fr@openstreetmap.org Subject: [OSM-talk-fr] Intégration des pharmacies en France avec Osmose Bonjour, L'entreprise [bougiboulga] devanture indique seulement Pharmacie. George Si les données étaient parfaite on le importeraient. Là on les intègre à la main une par une. C'est justement parce qu'il y a des ajustement à faire et un besoin de discernement humain. Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Osmose] Analyse sur la voirie en forêt
Le 11/10/2014 13:35, George Kaplan a écrit : Bonjour, Je profite qu'Osmose soit le sujet de cette liste en ce moment pour proposer 2 analyses sur la voirie en forêt. Ça fait suite à des cas que j'ai souvent rencontrés : 1) Nom de carrefourDans les forêts, repérer les noeuds à l'intersection de ways highway=* et portant uniquement un tag name=*. Proposer de rajouter junction=yes avec comme message à l'utilisateur : Junction=yes manquant pour le nom du carrefour. 2) Abréviation de Route ForestièreDans les forêts, repérer les ways highway=* avec name=RF * et proposer à l'utilisateur de changer ce name en Route forestière * Des remarques, des avis sur ces analyses ? George C'est tout a fait sensé et réalisable. Tu peux, si possible et s'il te plait, créer ces demandes sur https://github.com/osm-fr/osmose-backend/issues Pour un meilleur suivit. Merci. Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Osmose] Analyse sur la voirie en forêt
Le 11 oct. 2014 à 13:40, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : C'est tout a fait sensé et réalisable. Tu peux, si possible et s'il te plait, créer ces demandes sur https://github.com/osm-fr/osmose-backend/issues Pour un meilleur suivit. Merci. Frédéric. C'est fait. J'ai aussi au passage arrêter d'utiliser la joueuse interface d'Hotmail qui fait sauter les retours à la ligne de mes messages. George ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Intégration des pharmacies en France avec Osmose
Renvoyé pour la lisibilité. Le 11 oct. 2014 à 12:25, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Bonjour, L'entreprise Celtipharm à mise à disposition son recensement des pharmacies en France. Les données ont été collectées sur le terrain depuis 2000. Il y a donc près de 14 ans de métier ;) dans ces données. Ils ont été séduit par OSM et y voient une opportunité de moderniser leur système d'information avec une publication en OpenData sous licence ODbL. Après un test et des retours sur leurs données, l'intégration est maintenant possible sur Osmose : Bonjour Frédéric, J'ai reçu ton annonce en même temps qu'une de ces erreurs via RSS alors j'ai jeté un oeil. J'ai plusieurs remarques : - Le géocodage est bizarre, le marqueur n'est pas situé sur ou à proximité du point adresse dans OSM mais sur la rue correspondante, et même pas au droit de l'adresse. - ref:FR:FINESS c'est quoi ? le Wiki OSM ne connait pas. - Toutes les erreurs Intégration portent un tag name rempli, par défaut avec le nom du propriétaire. 1) Ça ne correspond pratiquement jamais avec ce qu'on peut lire sur le terrain. 2) Le nom de famille est parfois répété 3) Le nom est en majuscules, j'ai souvenir que ce n'est pas correct du point de vue des conventions typographiques. Pour moi, name doit contenir le nom vu sur le terrain en devanture, pas le nom professionnel utilisé dans les déclarations administratives. - J'ai des propositions d'intégration pour des pharmacies déjà présentes avec ou pas le nom identique à la proposition d'intégration. Exemple sur un quartier qui contient 4 pharmacies : http://osmose.openstreetmap.fr/fr/map/item=8210zoom=18lat=48.845012lon=2.40489layer=Mapnikoverlays=FFFTbbox=2.402781844139099%2C48.84406629555003%2C2.408929467201233%2C48.84597266461056level=3tags=fixable= 4 propositions d'intégrations, 3 pharmacies déjà présentes. Dans les 4 cas, les points adresse existent mais ne sont pas utilisés pour placer les marqueurs. 2 proposent un tag name rempli avec le nom du pharmacien (Diaz et Haddad) mais qui n'est pas le nom affiché sur la devanture. 1 propose un tag name Pharmacie CENTRALE SAINT MANDE alors que la devanture indique seulement Pharmacie. George ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Intégration des pharmacies en France avec Osmose
Le 11/10/2014 13:59, George Kaplan a écrit : Renvoyé pour la lisibilité. J'ai reçu ton annonce en même temps qu'une de ces erreurs via RSS alors j'ai jeté un oeil. J'ai plusieurs remarques : - Le géocodage est bizarre, le marqueur n'est pas situé sur ou à proximité du point adresse dans OSM mais sur la rue correspondante, et même pas au droit de l'adresse. Le coordonnées sont fourni en OpenData, ce n'est pas un géocoage base sur OSM. - ref:FR:FINESS c'est quoi ? le Wiki OSM ne connait pas. Si, si le wiki connait. http://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FINESS - Toutes les erreurs Intégration portent un tag name rempli, par défaut avec le nom du propriétaire. 1) Ça ne correspond pratiquement jamais avec ce qu'on peut lire sur le terrain. 2) Le nom de famille est parfois répété 3) Le nom est en majuscules, j'ai souvenir que ce n'est pas correct du point de vue des conventions typographiques. Pour moi, name doit contenir le nom vu sur le terrain en devanture, pas le nom professionnel utilisé dans les déclarations administratives. - J'ai des propositions d'intégration pour des pharmacies déjà présentes avec ou pas le nom identique à la proposition d'intégration. Oui, il faut ajuster à la main lors de l'intégration. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Intégration des pharmacies en France avec Osmose
Le 11 octobre 2014 12:25, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : - le tag type:FR:FINESS est aussi utilisé 216 fois. Désolé, mais là par contre je ne vois pas l'intérêt de mettre ça dans OSM. On a déjà des tags pour mettre en correspondance de ces numéros. Sauf si le type fait partie de l'identifiant, mais dans ce cas il ne faudrait pas un tag séparé. Il y a même une page sur le wiki : http://wiki.openstreetmap.org/ wiki/FR:Key:type:FR:FINESS [moi] Tout d'abord, l'argument du nombre d'occurences n'est pas pertinent. Pour n'importe quel tag, on peut toujours trouver un moment où le nombre d'occurences était faible... Personnellement, j'ajoute le tag ref:FR:FINESS quand je peux. Cela permet d'ajouter de l'information à peu de frais sur certains établissements de soins, pour lesquels les tags osm ne sont pas assez riches (social_facility=* et social_facility:for=* ne suffisent souvent pas à décrire précisément la fonction d'un établissement). Je l'ajoute aussi pour les pharmacies, même si effectivement, tout le monde comprend bien la fonction d'une pharmacie. (et juste pour comprendre la logique : pourquoi considérer que ce tag n'a pas sa place alors que ref:FR:LaPoste, ref:UAI font l'objet d'analyse d'absence dans osmose ?) PY ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Intégration des pharmacies en France avec Osmose
Le 11/10/2014 14:34, Pierre-Yves Berrard a écrit : Le 11 octobre 2014 12:25, Frédéric Rodrigo fred.rodr...@gmail.com mailto:fred.rodr...@gmail.com a écrit : - le tag type:FR:FINESS est aussi utilisé 216 fois. Désolé, mais là par contre je ne vois pas l'intérêt de mettre ça dans OSM. On a déjà des tags pour mettre en correspondance de ces numéros. Sauf si le type fait partie de l'identifiant, mais dans ce cas il ne faudrait pas un tag séparé. Il y a même une page sur le wiki : http://wiki.openstreetmap.org/__wiki/FR:Key:type:FR:FINESS http://wiki.openstreetmap.org/wiki/FR:Key:type:FR:FINESS [moi] Tout d'abord, l'argument du nombre d'occurences n'est pas pertinent. Pour n'importe quel tag, on peut toujours trouver un moment où le nombre d'occurences était faible... Personnellement, j'ajoute le tag ref:FR:FINESS quand je peux. Cela permet d'ajouter de l'information à peu de frais sur certains établissements de soins, pour lesquels les tags osm ne sont pas assez riches (social_facility=* et social_facility:for=* ne suffisent souvent pas à décrire précisément la fonction d'un établissement). Je l'ajoute aussi pour les pharmacies, même si effectivement, tout le monde comprend bien la fonction d'une pharmacie. (et juste pour comprendre la logique : pourquoi considérer que ce tag n'a pas sa place alors que ref:FR:LaPoste, ref:UAI font l'objet d'analyse d'absence dans osmose ?) PY La comptage n'est qu'une constant. Attention la question pour sur type:FR:FINESS et non ref:FR:FINESS. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Intégration des pharmacies en France avec Osmose
Le 11 octobre 2014 14:56, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Attention la question pour sur type:FR:FINESS et non ref:FR:FINESS. Désolé, j'ai lu trop vite. Donc effectivement pour une pharmacie c'est peu probant car toutes les pharmacies auront le même type:FR:FINESS. En revanche, pour d'autres établissements sociaux ou sanitaires très spécialisés, je maintiens une certaine valeur ajoutée ;-) PY ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Pertes de contrôle du clavier : anomalie trop fréquente de JOSM
De plus en plus souvent je constate des pertes inopinées de contrôle du clavier ou de la souris dans JOSM; rendant l'interface inopérante. Par exemple : - les touches + et - (qu'on les tape sur le pavé numérique ou le clavier alpha) du zoom cessent de répondre (dans ce cas aussi cela ne marche plus non plus avec le menu ni un raccourci posé sur une icone de la barre d'icones (c'est le cas le plus fréquent) Et pourtant le zoom sur la sélection fonctionne encore et le zoom avec + ou - dans le dialogue de téléchargement d'une zone fonctionne encore. - quand on ouvre un dialogue; le focus sur le champ de saisie ne fonctionne pas et impossible de taper un texte dedans parfois aussi la sélection à la souris d'un morceau du texte ne marche plus (en revanche les autres boutons, y compris le triangle du sélecteur d'une combobox) fonctionne encore. La fermeture du dialogue et sa réouverture suffit parfois à rétablir la fonction; mais pas toujours... - la suppression et le remise d'une icone de raccourci sur la barre d'icone fonctionne, mais le bouton ne produit toujours rien quand on clique dessus. Il semble qu'il y a un bogue dans la bibliothèque qui gère les bindings attachant des événements clavier ou souris à un gestionnaire d'événement; comme si le gestionnaire avait été perdu par perte de référence (allocation en weak pointer et effet du garbage collector, ou mauvaise synchronisation de l'ordre des événements en cas de modification dynamique de la liste des bindings (modification non atomique, comme si la suppression de référence au gestionnaire d'événement dans une liste de gestionnaires a eu lieu *avant* l'insertion de ce même gestionnaire dans une autreliste pour un autre élément d'interface utilisateur). Je me demande si c'est un bogue de JOSM lui-même ou d'une de ses bibliothéques de construction d'UI; ou si la modification dyna,ique de l'interface a oublié de mettre un verrou entre plusieurs threads faisant des modifications concurrentes de l'UI (par exemple un thread s'occupant de la construction d'un nouveau dialogue tandis qu'un autre thread s'occupe encore de celui de la fenêtre principale; ou bien l'événement à réassigner est encore en cours de traitement par le thread principal qui gère la liste ordonnée des événements UI et synchronise les rafraichissements écran). Seule parade : sauver les modifs en cours dans un fichier local, fermer JOSM et le relancer pour charger le fichier à nouveau. Mais à je suis tombé sur un cas où c'était la fonction sauvegarder qui ne fonctionnait plus aussi bien au clavier (CTRL+S), qu'à la souris en cliquant l'icone de la barre d'icones ou par le menu fichier. C'est de plus en plus gênant car l'anomalie se reproduit de plus en plus souvent et aboutit à des pertes de modifs en cours (très gênant quand on a eu besoin de charger beaucoup de données et vérifier des jeux compliqués de relations interdépendantes, comme la vérification des cours d'eau, des lignes de bus, vérifier le routage, refermer les trous dans des relations (par exemple par ceux qui remplacent sans faire attention des routes ou transforment un carrefour simple en rond-point tracé n'importe comment et ne tenant pas compte de l'existant qui s'y connecte (ceux-là ne connaissent pas CTRL+ALT+D dans JOSM et sont totalement perdus dans iD qui presque tout le temps fait n'importe quoi et est très peu utiisable pour autre chose que d'ajouter des tags ou faire un tracé sommaire ou ajouter un POI ou affiner le tracé existant; mais pas pour transformer des objets: d'ailleurs les mêmes beaucoup trop souvent ne s'embarassent pas de transformer l'existant, ils retracent et suppri,ent tout ce qui les gêne et ne fait doublon qu'avec leur nouveau tracé, ou qui passe une route simple bidirectionnelle en routes à deux voies unidirectionnelles séparées et oublient de router la ligne de bus en sens inverse qui passait par la première voie laissée mais devenue sens unique; créant des routes impossibles). D'une façon générale JOSM a de plus en plus souvent des soucis de rafraichissement partiel de l'écran et semble souffrir de bogue de synchronisation entre ses threads de plus en plus nombreux (chez moi la moindre session prend maintenant plus de 400 threads parallèles, alors que j'tilise un jeu très réduit de plugins parmi les plus stables. Je détecte cette anomalie depuis début août, mais cela s'aggrave maintenant Note: je suis toujours à jour des versions, je lance JOSM par JNLP sur la dernière version en release stable. Et ceci quelque soit le PC utilisé (sous Windows 7 ou 8.1); avec la dernière versions stable de Java (en version Hotspot Server VM 64 bits en Java 6 ou 7; pas la version 32 bits qui limite trop la mémoire maxi utilisée alors que j'ai beaucoup de mémoire, et sollicite énormément le garbage collector ce qui fait des pauses beaucoup trop souvent, en 64 bits mes VM Java montent sans problème à 2 gigas, et le garbage collector utilise des threads en arrière-plan qui ne font jamais aucune pause; et
Re: [OSM-talk-fr] Pertes de contrôle du clavier : anomalie trop fréquente de JOSM
C'est long, mais j'ai le même, mais ça se provoque de manière aléatoire et sauvegarder son travail devient ridiculement compliqué. Pour moi ça apparaît avec le plugin cadastre. Le 11 oct. 2014 16:11, Philippe Verdy verd...@wanadoo.fr a écrit : De plus en plus souvent je constate des pertes inopinées de contrôle du clavier ou de la souris dans JOSM; rendant l'interface inopérante. Par exemple : - les touches + et - (qu'on les tape sur le pavé numérique ou le clavier alpha) du zoom cessent de répondre (dans ce cas aussi cela ne marche plus non plus avec le menu ni un raccourci posé sur une icone de la barre d'icones (c'est le cas le plus fréquent) Et pourtant le zoom sur la sélection fonctionne encore et le zoom avec + ou - dans le dialogue de téléchargement d'une zone fonctionne encore. - quand on ouvre un dialogue; le focus sur le champ de saisie ne fonctionne pas et impossible de taper un texte dedans parfois aussi la sélection à la souris d'un morceau du texte ne marche plus (en revanche les autres boutons, y compris le triangle du sélecteur d'une combobox) fonctionne encore. La fermeture du dialogue et sa réouverture suffit parfois à rétablir la fonction; mais pas toujours... - la suppression et le remise d'une icone de raccourci sur la barre d'icone fonctionne, mais le bouton ne produit toujours rien quand on clique dessus. Il semble qu'il y a un bogue dans la bibliothèque qui gère les bindings attachant des événements clavier ou souris à un gestionnaire d'événement; comme si le gestionnaire avait été perdu par perte de référence (allocation en weak pointer et effet du garbage collector, ou mauvaise synchronisation de l'ordre des événements en cas de modification dynamique de la liste des bindings (modification non atomique, comme si la suppression de référence au gestionnaire d'événement dans une liste de gestionnaires a eu lieu *avant* l'insertion de ce même gestionnaire dans une autreliste pour un autre élément d'interface utilisateur). Je me demande si c'est un bogue de JOSM lui-même ou d'une de ses bibliothéques de construction d'UI; ou si la modification dyna,ique de l'interface a oublié de mettre un verrou entre plusieurs threads faisant des modifications concurrentes de l'UI (par exemple un thread s'occupant de la construction d'un nouveau dialogue tandis qu'un autre thread s'occupe encore de celui de la fenêtre principale; ou bien l'événement à réassigner est encore en cours de traitement par le thread principal qui gère la liste ordonnée des événements UI et synchronise les rafraichissements écran). Seule parade : sauver les modifs en cours dans un fichier local, fermer JOSM et le relancer pour charger le fichier à nouveau. Mais à je suis tombé sur un cas où c'était la fonction sauvegarder qui ne fonctionnait plus aussi bien au clavier (CTRL+S), qu'à la souris en cliquant l'icone de la barre d'icones ou par le menu fichier. C'est de plus en plus gênant car l'anomalie se reproduit de plus en plus souvent et aboutit à des pertes de modifs en cours (très gênant quand on a eu besoin de charger beaucoup de données et vérifier des jeux compliqués de relations interdépendantes, comme la vérification des cours d'eau, des lignes de bus, vérifier le routage, refermer les trous dans des relations (par exemple par ceux qui remplacent sans faire attention des routes ou transforment un carrefour simple en rond-point tracé n'importe comment et ne tenant pas compte de l'existant qui s'y connecte (ceux-là ne connaissent pas CTRL+ALT+D dans JOSM et sont totalement perdus dans iD qui presque tout le temps fait n'importe quoi et est très peu utiisable pour autre chose que d'ajouter des tags ou faire un tracé sommaire ou ajouter un POI ou affiner le tracé existant; mais pas pour transformer des objets: d'ailleurs les mêmes beaucoup trop souvent ne s'embarassent pas de transformer l'existant, ils retracent et suppri,ent tout ce qui les gêne et ne fait doublon qu'avec leur nouveau tracé, ou qui passe une route simple bidirectionnelle en routes à deux voies unidirectionnelles séparées et oublient de router la ligne de bus en sens inverse qui passait par la première voie laissée mais devenue sens unique; créant des routes impossibles). D'une façon générale JOSM a de plus en plus souvent des soucis de rafraichissement partiel de l'écran et semble souffrir de bogue de synchronisation entre ses threads de plus en plus nombreux (chez moi la moindre session prend maintenant plus de 400 threads parallèles, alors que j'tilise un jeu très réduit de plugins parmi les plus stables. Je détecte cette anomalie depuis début août, mais cela s'aggrave maintenant Note: je suis toujours à jour des versions, je lance JOSM par JNLP sur la dernière version en release stable. Et ceci quelque soit le PC utilisé (sous Windows 7 ou 8.1); avec la dernière versions stable de Java (en version Hotspot Server VM 64 bits en Java 6 ou 7; pas la version 32 bits qui
Re: [OSM-talk-fr] Pertes de contrôle du clavier : anomalie trop fréquente de JOSM
Bonjour, Idem pour moi, je n'utilise plus la touche pour télécharger le cadastre (F10 ou F11 suivant paramétrage) car au bout de trois à quatre utilisations je perds le clavier, c'est systématique, par contre la souris fonctionne dans tous les cas. ça fait bien un an que c'est comme ça pour moi mais je n'ai pas eu le temps de chercher une explication/solution. Sous Gnu/Linux Ubuntu dernière version (64 bits) et testé avec Java 6 ou 7. Le 11/10/2014 16:54, Jean-Baptiste Holcroft a écrit : C'est long, mais j'ai le même, mais ça se provoque de manière aléatoire et sauvegarder son travail devient ridiculement compliqué. Pour moi ça apparaît avec le plugin cadastre. Le 11 oct. 2014 16:11, Philippe Verdy verd...@wanadoo.fr mailto:verd...@wanadoo.fr a écrit : De plus en plus souvent je constate des pertes inopinées de contrôle du clavier ou de la souris dans JOSM; rendant l'interface inopérante. Par exemple : - les touches + et - (qu'on les tape sur le pavé numérique ou le clavier alpha) du zoom cessent de répondre (dans ce cas aussi cela ne marche plus non plus avec le menu ni un raccourci posé sur une icone de la barre d'icones (c'est le cas le plus fréquent) Et pourtant le zoom sur la sélection fonctionne encore et le zoom avec + ou - dans le dialogue de téléchargement d'une zone fonctionne encore. - quand on ouvre un dialogue; le focus sur le champ de saisie ne fonctionne pas et impossible de taper un texte dedans parfois aussi la sélection à la souris d'un morceau du texte ne marche plus (en revanche les autres boutons, y compris le triangle du sélecteur d'une combobox) fonctionne encore. La fermeture du dialogue et sa réouverture suffit parfois à rétablir la fonction; mais pas toujours... - la suppression et le remise d'une icone de raccourci sur la barre d'icone fonctionne, mais le bouton ne produit toujours rien quand on clique dessus. Il semble qu'il y a un bogue dans la bibliothèque qui gère les bindings attachant des événements clavier ou souris à un gestionnaire d'événement; comme si le gestionnaire avait été perdu par perte de référence (allocation en weak pointer et effet du garbage collector, ou mauvaise synchronisation de l'ordre des événements en cas de modification dynamique de la liste des bindings (modification non atomique, comme si la suppression de référence au gestionnaire d'événement dans une liste de gestionnaires a eu lieu *avant* l'insertion de ce même gestionnaire dans une autreliste pour un autre élément d'interface utilisateur). Je me demande si c'est un bogue de JOSM lui-même ou d'une de ses bibliothéques de construction d'UI; ou si la modification dyna,ique de l'interface a oublié de mettre un verrou entre plusieurs threads faisant des modifications concurrentes de l'UI (par exemple un thread s'occupant de la construction d'un nouveau dialogue tandis qu'un autre thread s'occupe encore de celui de la fenêtre principale; ou bien l'événement à réassigner est encore en cours de traitement par le thread principal qui gère la liste ordonnée des événements UI et synchronise les rafraichissements écran). Seule parade : sauver les modifs en cours dans un fichier local, fermer JOSM et le relancer pour charger le fichier à nouveau. Mais à je suis tombé sur un cas où c'était la fonction sauvegarder qui ne fonctionnait plus aussi bien au clavier (CTRL+S), qu'à la souris en cliquant l'icone de la barre d'icones ou par le menu fichier. C'est de plus en plus gênant car l'anomalie se reproduit de plus en plus souvent et aboutit à des pertes de modifs en cours (très gênant quand on a eu besoin de charger beaucoup de données et vérifier des jeux compliqués de relations interdépendantes, comme la vérification des cours d'eau, des lignes de bus, vérifier le routage, refermer les trous dans des relations (par exemple par ceux qui remplacent sans faire attention des routes ou transforment un carrefour simple en rond-point tracé n'importe comment et ne tenant pas compte de l'existant qui s'y connecte (ceux-là ne connaissent pas CTRL+ALT+D dans JOSM et sont totalement perdus dans iD qui presque tout le temps fait n'importe quoi et est très peu utiisable pour autre chose que d'ajouter des tags ou faire un tracé sommaire ou ajouter un POI ou affiner le tracé existant; mais pas pour transformer des objets: d'ailleurs les mêmes beaucoup trop souvent ne s'embarassent pas de transformer l'existant, ils retracent et suppri,ent tout ce qui les gêne et ne fait doublon qu'avec leur nouveau tracé, ou qui passe une route simple bidirectionnelle en routes à deux voies unidirectionnelles séparées et oublient de router la ligne de bus en sens inverse qui passait par la première voie laissée mais devenue sens unique;
Re: [OSM-talk-fr] Revoir l'extraction des adresses du cadastre (était [import lieux-dits (avec fixme)])
Vincent de Château-Thierry wrote Overpass renvoie 56883 nodes avec le même fixme=à vérifier Un tel volume ne rime à rien avec ce tag. Je suis d'avis de supprimer ces points, car je prends le pari qu'ils ne seront pas revus un par un avant une éternité. Si pas d'opposition, je peux me charger de cette suppression dans la semaine. 3 mois sont passés et le nombre est passé à 55792. Il n'y avait pas eu d'opposition à cette suppression mais Vincent a peut-être oublié de le faire. Et j'ai peur que plus on attend et plus on aura de cas de gens qui : - repositionnent mais oublient d'enlever le fixme - auraient pû l'ajouter manuellement au bon endroit mais ne le font pas car un libellé existe déjà Bref, je m'en occupe par la suppression des noeuds avec ce fixme. -- View this message in context: http://gis.19327.n5.nabble.com/Revoir-l-extraction-des-adresses-du-cadastre-etait-import-lieux-dits-avec-fixme-tp5812917p5820048.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] Revoir l'extraction des adresses du cadastre (était [import lieux-dits (avec fixme)])
sylvain letuffe wrote Bref, je m'en occupe par la suppression des noeuds avec ce fixme. Oups, non, pas là tout de suite maintenant, je m'en occupe d'ici quelques jours s'il n'y a pas d'opposition sur la bases de nouveaux éléments -- View this message in context: http://gis.19327.n5.nabble.com/Revoir-l-extraction-des-adresses-du-cadastre-etait-import-lieux-dits-avec-fixme-tp5812917p5820049.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] Revoir l'extraction des adresses du cadastre (était [import lieux-dits (avec fixme)])
Bonsoir, Le 11/10/2014 19:19, sylvain letuffe a écrit : sylvain letuffe wrote Bref, je m'en occupe par la suppression des noeuds avec ce fixme. Oups, non, pas là tout de suite maintenant, je m'en occupe d'ici quelques jours s'il n'y a pas d'opposition sur la bases de nouveaux éléments Oops statu quo en effet. Personnellement je n'ai pas changé d'avis (mais rien fait non plus) sur le sujet donc je vote toujours pour une suppression. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pertes de contrôle du clavier : anomalie trop fréquente de JOSM
Bonsoir, Je ne sais pas si ça a un rapport (mais peut-être que si, d'où mon message), mais chez moi, c'est la souris (j'utilise peu le clavier), en l'occurrence le trackpad qui pose problème. Je crois l'avoir déjà signalé, c'est en fait la fenêtre qui devient transparente à la souris, ou autrement dit, les actions de la souris continuent de s'appliquer à la précédente fenêtre utilisée, même si elle est en arrière plan. La parade que j'ai fini par trouver, vraiment par hasard, c'est de (sur le trackpad) simuler avec 2 doigts la molette de la souris, et de faire des mouvements rapides de haut en bas. Au bout de quelques secondes, la fenêtre visible est prise en compte par le pointeur, et on peut continuer à travailler normalement. Là où c'est moins marrant, c'est quand on change sans cesse de fenêtre (boîtes de dialogues successives, par exemple). Mais c'est devenu chez moi un réflexe, et je commence peu à peu à oublier que ça pourrait marcher mieux Envoyé de mon iPhone Le 11 oct. 2014 à 18:03, Bruno pa...@free.fr a écrit : Bonjour, Idem pour moi, je n'utilise plus la touche pour télécharger le cadastre (F10 ou F11 suivant paramétrage) car au bout de trois à quatre utilisations je perds le clavier, c'est systématique, par contre la souris fonctionne dans tous les cas. ça fait bien un an que c'est comme ça pour moi mais je n'ai pas eu le temps de chercher une explication/solution. Sous Gnu/Linux Ubuntu dernière version (64 bits) et testé avec Java 6 ou 7. Le 11/10/2014 16:54, Jean-Baptiste Holcroft a écrit : C'est long, mais j'ai le même, mais ça se provoque de manière aléatoire et sauvegarder son travail devient ridiculement compliqué. Pour moi ça apparaît avec le plugin cadastre. Le 11 oct. 2014 16:11, Philippe Verdy verd...@wanadoo.fr a écrit : De plus en plus souvent je constate des pertes inopinées de contrôle du clavier ou de la souris dans JOSM; rendant l'interface inopérante. Par exemple : - les touches + et - (qu'on les tape sur le pavé numérique ou le clavier alpha) du zoom cessent de répondre (dans ce cas aussi cela ne marche plus non plus avec le menu ni un raccourci posé sur une icone de la barre d'icones (c'est le cas le plus fréquent) Et pourtant le zoom sur la sélection fonctionne encore et le zoom avec + ou - dans le dialogue de téléchargement d'une zone fonctionne encore. - quand on ouvre un dialogue; le focus sur le champ de saisie ne fonctionne pas et impossible de taper un texte dedans parfois aussi la sélection à la souris d'un morceau du texte ne marche plus (en revanche les autres boutons, y compris le triangle du sélecteur d'une combobox) fonctionne encore. La fermeture du dialogue et sa réouverture suffit parfois à rétablir la fonction; mais pas toujours... - la suppression et le remise d'une icone de raccourci sur la barre d'icone fonctionne, mais le bouton ne produit toujours rien quand on clique dessus. Il semble qu'il y a un bogue dans la bibliothèque qui gère les bindings attachant des événements clavier ou souris à un gestionnaire d'événement; comme si le gestionnaire avait été perdu par perte de référence (allocation en weak pointer et effet du garbage collector, ou mauvaise synchronisation de l'ordre des événements en cas de modification dynamique de la liste des bindings (modification non atomique, comme si la suppression de référence au gestionnaire d'événement dans une liste de gestionnaires a eu lieu *avant* l'insertion de ce même gestionnaire dans une autreliste pour un autre élément d'interface utilisateur). Je me demande si c'est un bogue de JOSM lui-même ou d'une de ses bibliothéques de construction d'UI; ou si la modification dyna,ique de l'interface a oublié de mettre un verrou entre plusieurs threads faisant des modifications concurrentes de l'UI (par exemple un thread s'occupant de la construction d'un nouveau dialogue tandis qu'un autre thread s'occupe encore de celui de la fenêtre principale; ou bien l'événement à réassigner est encore en cours de traitement par le thread principal qui gère la liste ordonnée des événements UI et synchronise les rafraichissements écran). Seule parade : sauver les modifs en cours dans un fichier local, fermer JOSM et le relancer pour charger le fichier à nouveau. Mais à je suis tombé sur un cas où c'était la fonction sauvegarder qui ne fonctionnait plus aussi bien au clavier (CTRL+S), qu'à la souris en cliquant l'icone de la barre d'icones ou par le menu fichier. C'est de plus en plus gênant car l'anomalie se reproduit de plus en plus souvent et aboutit à des pertes de modifs en cours (très gênant quand on a eu besoin de charger beaucoup de données et vérifier des jeux compliqués de relations interdépendantes, comme la vérification des cours d'eau, des lignes de bus, vérifier le routage, refermer les trous dans des relations (par exemple par ceux qui remplacent sans faire
Re: [OSM-talk-fr] Prix des carburants ?
Le 11 oct. 2014 à 13:32, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Comme déjà dit je pense que l'on ne peut que accorder qu'un confiance limité en ça. Brice a précisé que ça ne marche pas pour tous les cas, un certains nombre — combien exactement 1%, 10%, 90% ? —seront incomplètes, mais pas erronées ? Sur cette liste il y a d’un côté — des « perfectionnistes » qui veulent des donnée fiables à 100%, maintenables et utiles — et de l’autres, des personnes qui préfèrent des données moins fiables et leur ’amélioration itérative, plutôt qu’une carte blanche. Ça produit un tag osm opening_hours, opening_hours: lambda res: 24/7 if res[debut] != and res[debut] == res[fin] and res[saufjour] == else None, Si je comprends bien le code source, ça produit opening_hours=24/7 uniquement si début=fin est que saufjour est vide. Dans les autres cas, l’attribut opening_hours n’est pas exporté ? c'est con son format : http://wiki.openstreetmap.org/wiki/Key:opening_hours Je ne comprends pas ce que tu veux dire ? con : simple ? Ce format est en fait une grammaire qui permet de gérer tous les cas. Simple dans les cas triviaux, mais complexe dans certains cas. Voici un traitement simple qui fonctionne dans tous les cas (je ne connais pas python) : remplacer ‘;' par ‘,' dans res['saufjour’] remplacer [‘Lundi’,’Mardi’,’Mercredi’,’Jeudi’,’Vendredi’,’Samedi’,’Dimanche’] par [‘Lundi’,’Mardi’,’Mercredi’,’Jeudi’,’Vendredi’,’Samedi’,’Dimanche’] dans res[‘saufjour'] note : Je ne sais pas coder les étapes 1 et 2 en python renvoyer la concaténation du tout : 'opening_hours': res['debut'] + ‘-‘ + res[‘fin'] + ‘ open ; ‘ + res[‘saufjour’] + ‘closed’ ouverture debut=08:30 fin=20:00 saufjour=Lundi;Dimanche/ donnera opening_hours='08:30-20:00 open; Mo,Su closed’ Je ne suis pas trop pour intégrer des données peu fiable et inmaintenable. Je laisse e choix de trancher à la personne qui fait l’intégration ;-) id='25420005' Pour c'est juste un identifiant interne et pas de référence. Je ne vois pas la différence. Et il est publié dans les données ouvertes donc pas si interne que ça. Tu voulais un identifiant bien « officiel » comme un SIRET ? Bonne soirée et bon dimanche, — Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose : erreur de commune pour le géocodage d'un Monument historique non intégré
Le 11 oct. 2014 à 10:55, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : En entre les deux. Les monuments ont été géocodé en 2012 avec nominatime (donc données OSM). Ok, merci pour la réponse. Il faudrait refaire le géocodage ou refaire le point sur les données données disponible aujourd'hui sur le sujet. Donc refaire le géocodage avec BANO ;-) — Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] BANO : pas de rapprochement à cause du nom du lieu-dit - La Crèche 79
Bonsoir, Un grand nombre de voies FANTOIR de la ville de La Crèche ne sont pas rapprochées avec les rues OSM. Le nom du hameau (plus ou moins tronqué) est ajouté à la fin du nom de rue dans cette ville : 790480446U CHE DE L HOMME DU MOULIN CHAVA Chemin de l'Homme du Moulin 790480298H CHE DE LA DIBE CHAVAGNE Chemin de la Dibe 790480357X CHE DE LA FOUGEOIRE CHAVAGNE 790480388F CHE DE LA GRAND CHAUME CHAVAGN etc. Il y en a un grand nombre sur les 151 voies FANTOIR avec adresses sans rapprochement OSM. — Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pertes de contrôle du clavier : anomalie trop fréquente de JOSM
Autre cas assez fréquent qui semble lié: CTRL+F (ou accès par le menu) pour ouvrir une requête de sélection (j'utilise énormément pour faire des sélections par critère et filtrer des listes d'objets en combinant plusieurs recherches ou suppri,er certains objets dans une longue liste d'objets). Très souvent le dialogue s'ouvre mais il est impossible de taper dans la zone de saisie (tous les boutons fonctionnent). Là encore il semble que ce soit le focus est resté captif sur un autre objet dans une autre fenêtre, alors que le champ de saisie est dans un état qui pour lui semblerait disposer du focus. Là encore il faut refermer le dialogue et retaper CTRL+F. Le transfert du focus d'une fenêtre à l'autre semble ne pas fonctionner de façon ordonnée (une fenetre ou un objet de cette fenêtre ne peut pas recevoir le focus et passer l'objet en tant qu'objet actif, tant que la demande de perte de focus n'a pas été traitée par l'objet initial qui en dispose et que cet objet est passé en état inactif). Tout semble lié à un problème de synchronisation/sérialisation des événements qui ne s'exécutent pas dans le bon ordre et cela semblerait lié au fait que l'UI n'est pas gérée dans JOSM uniquement par le thread principal; et sur un CPU multicoeur il peut y avoir facilement plusieurs threads actifs simultanément qui manipulent l'état de l'UI. Si le problème s'aggrave maintenant, c'est parce que le no,bre de threads dans JOS? a littéralement explosé (de façon excessive à mon avis : les thread pools sont mal réglés certains pools de worker threads peuvent avoir des centaines de threads inactifs: un thread pool peut améliorer les performances et la réactivité, mas pourquoi avoir autant de threads dormants... en principe on limite les thread pools qui servent surtout à pouvoir gérer de nombreuses sessions clientes d'un service et qui fonctionnent réellement de façon asynchrone entre elles; par exemple des threads d'écoute s'un port de connexion à un serveur; ,ais je ne vois pas du tout l'intérêt quand il n'y a qu'un seul utilisateur client: on peut admettre d'avoir un thread d'arrière-plan pour s'occuper du rafraichissement de la carte à l'écran mais ce thread ne doit surtout pas influer sur l'état du focus ni en dépendre alors qu'il n'y a qu'un seul utilisateur avec un seul focus pour tout le monde, une seule fenêtre modale active, une seule file d'événements pour l'UI d'entrée qui doit rester ordonnée; même si les entrées peuvent avoir des threads pour gérer en interne leur propre état asynchrone, par exemple l'état propre au clavier, indépendant de celui de la souris: la consommation des sources doit passer vers une autre file de synchronisation) En tout cas ces anomalies sont totalement imprévisibles, pour exactement la même interaction utilisateur (si on ignore la position légèremetn différente de la souris à l'écran même si on ne clique pas) et les mêmes données chargées en mémoire. Autre chose qui semble lié: le rafraichissement de la carte en arrière-plan ne suit pas toujours la sélection courante et laisse visible comme sélectionné (ombrage rouge) des objets qui ne le sont plus; même chose quand on a un dialogue ouvert montrant les membres d'une relation et si on utilise charger les membres incomplets dans la fenêtre derrière : le dialogue ne se rafraihit pas correctement pour afficher le nouvel état des membres. Il y a plusieurs threads distincts pour gérer l'UI et ces threads ne se synchronisent pas ou manipulent l'état d'objets dont ils ne sont normalement pas chargés puisque c'est un autre thread qui est sensé s'en occuper et gérer leurs changements ordonnés d'état. Tant que c'est un bogue de rafraichissement ce n'est pas méchant, mais le plus problématique c'est le transfert du focus d'une fenêtre à l'autre (et il n'est pas commode d'utiliser des fenêtres natives séparées pour leur faire adopter un comportement non modal ou le focus peut passer librement d'une fenêtre à l'autre selon la fenêtre active chaque fenêtre ayant don propre objet de focus avec un focus dormant sur l'objet tant que la fenêtre n'est pas active (et Swing n'a pas réellement écrit pour supporter un co,portement non modal des fenêtres multiples; il ne dispose qu'aucun systéme de sychrnisation et sérialisation d'événements. En tut cas merci pour vos réponses, je vois que je ne suis pas seul et que ces problèmes inopinés surviennent aussi avec d'autres installations différentes et sur d'autres OS. Le 11 octobre 2014 16:54, Jean-Baptiste Holcroft jb.holcr...@gmail.com a écrit : C'est long, mais j'ai le même, mais ça se provoque de manière aléatoire et sauvegarder son travail devient ridiculement compliqué. Pour moi ça apparaît avec le plugin cadastre. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-ja] reconciling MLIT Shapefile with Japan Post CSV
Please excuse me for posting to this list in English. I am not a Japanese speaker, but have recently been examining the availability of Japanese open data for geocoding addresses. This process has been difficult due to my unfamiliarity with the language and character set. My hope is to share a summary of my work here and receive criticism from experts. My code can be found here: https://github.com/sbma44/japan_geodata_research My conclusions and the narrative behind them are present in the README.md file, which should display at the bottom of the page when you follow that link. In short: I was surprised to find that Japan Post and MLIT seem to use a shared ID scheme, allowing postal codes to be mapped, many-to-one, to the boundaries of administrative districts offered in a country-wide Shapefile by MLIT. It might be that this is already common knowledge -- if so, I would be glad to know that, too! If not, perhaps this will prove useful to others. I would be particularly glad to hear suggestions from Japanese speakers as to what each column in the postal code CSV should be properly called in English and/or in the existing OSM tagging scheme for Japan; and whether the difference between the oogaki and kogaki files offered by Japan Post represent a concern. Please do not hesitate to ask questions or point out problems with my analysis. Tom Lee ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [diversity-talk] OSM code of conduct: starting points
2014-10-11 23:48 GMT+01:00 Darrell Fuhriman darr...@garnix.org: On Oct 10, 2014, at 19:45, Paul Norman penor...@mac.com wrote: One last thought - where would the forums fit in this? They're on openstreetmap.org, but not run by the OSMF, so the forum admins would be perfectly capable of saying no to any code of conduct. What would happen then? Does OSMF not have any control over what’s on openstreetmap.org? What’s wrong with saying “You can agree to the code of conduct, or you can get off of openstreetmap.org and we’ll replace the forums”? Probably in theory that's possible, but such a stand-off situation is extremely unlikely, given the social and admin structure of OSM/OSMF, in particular OSMF's oft-stated ambition to support rather than control OSM. But more importantly, we don't need to worry about these particular hypotheticals, since we have no need to ensure roll-out across all channels. As others have said, it makes more sense to develop our CoC usage incrementally rather than as a top-down dictat, for many reasons. It wouldn't worry me if the gatekeepers to one particular channel decide against adopting/enforcing a particular CoC. We can develop the approach in other channels, and try to spread good practice as we go, learning from the experience we accumulate. Here’s my question, and this needs to be clarified (probably deserves its own thread): Who is responsible for deciding what action needs to be taken in the case of CoC violations? A CoC without a body willing and able to enforce it is just window dressing. Well I disagree that it would be just window dressing: written guidelines can often serve as community norms, even with no official enforcers. Having said that, it definitely helps to have some responsiblity for making it happen. But we already have that! It seems likely that the people who moderate the individual components of OSM (forum moderators, mailing list moderators, the Data Working Group) would decide, just as they decide now when to block spammers/vandals or whatever. We already have these moderators, and the responsibility is decentralised across them. Best Dan ___ diversity-talk mailing list diversity-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/diversity-talk
