Re: [OSM-talk-fr] détection de bugs dans la cartographie ferroviaire
Je pense que Firefox en fait ne restreint pas l'accès à 127.0.0.1 si c'est vers un port non privilégié : il doit juste se contenter de restreindre les ports < 1024 (et quelques autres ports connus sensibles pour des services locaux sensibles propre à l'OS où il est installé), mais ce n'est plus du tout recommandé. Il peut aussi se mettre à l'écoute des ports déclarés en UPnP pour les applis pair-à-pair, ce qui permet à des sites web de joindre par exemple une appli d'instant messaging, à condition que celle-ci soit active et qu'elle fonctionne à l'écoute son numéro de port normal: Firefox dans ce cas fait confiance à la sécurité interne de cette appli pour faire le filtrage des connexions indésirables non sécurisées, avec son propre protocole. L'accès aux ressources locales par des sites tiers ne devrait en fait jamais être autorisé sans autorisation explicite donnée par l'utilisateur (via l'interface du navigateur) au site/domaine qui en fait la demande, pas plus que ces sites ne devraient pouvoir consulter les fichiers locaux des pages en cache et cookies venant de sites tiers. Les ressources locales sont très dangereuses à autoriser aux sites tiers et au minimum il devrait y avoir une fenêtre locale bloquante demandant l'autorisation à l'utilisateur avec l'identification précise et infalsifiable du site tiers qui en fait la demande, avec toutes les infos nécessaires: adresse IP, nom de domaine, protocole HTTPS activé ou pas, évaluation de sécurité du nom de domaine contre les noms déguisés qui remplacent des lettres latines par des lettre cyrilliques par exemple, etc. Sinon les détournements de données sont beaucoup trop faciles). De même le fait d'accorder l'autorisation devrait être temporaire (uniquement le temps de la session internet du site visité, mais devrait avoir une date de péremption ne dépassant pas quelques mois, et devrait pouvoir être retirée à tout moment et le navigateur doit proposer une fonction de purge de ces autorisations maintenues dans un cache consultable du navigateur) Le mar. 11 sept. 2018 à 14:33, Pierre Beyssac a écrit : > On Tue, Sep 11, 2018 at 01:53:27PM +0200, Philippe Verdy wrote: > > C'est normal que ça bloque : ce n'est pas parce que le lien est activé > dans > > un navigateur local que la source de ce lien vient du domaine local : la > > page vient d'un site tiers et le navigateur tient compte de l'origine de > la > > page et de ses scripts, qui est le site web consulté affichant les liens. > > > > Sinon c'est trop facile pour une site web malveillant d'insérer des liens > > "127.0.0.1" pour passer outre les autorisations et obtenir directement > des > > Oui, bien sûr, mais le mécanisme n'est pas si simple que ça, vu que > ça marche avec le lien Edit d'openstreetmap.org, qui, en fait, fait > exactement la même chose au final (accès 127.0.0.1 etc). > > Firefox a apparement certaines exceptions "en dur" pour 127.0.0.1 > (mais pas pour localhost, et apparemment pas toujours pour > xmlHttpRequest, on s'y perd un peu). > -- > Pierre Beyssac p...@eriomem.net > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] détection de bugs dans la cartographie ferroviaire
Le 2018-09-11 14:31, Pierre Beyssac a écrit : On Tue, Sep 11, 2018 at 11:59:50AM +0200, Julien Lepiller wrote: Quand je clique sur un lien JOSM, j'ai ça dans la console : http://127.0.0.1:8111/load_and_zoom?zoom_mode=download=1.8996611795158609=47.91660184082002=1.900610014653254=47.91723775722602=way81016796,way297346084 edit.js:56:9 Blocage d’une requête multiorigines (Cross-Origin Request) : la politique « Same Origin » ne permet pas de consulter la ressource distante située sur Ah, c'était donc ça. Merci. Ça marche via l'edit sur openstreetmap.org, j'ai réimplémenté leur méthode (création d'iframe au lieu de xmlHttpRequest), ça devrait donc corriger le problème cette fois, peux-tu réessayer ? Ça a l'air de marcher, bravo ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] détection de bugs dans la cartographie ferroviaire
On Tue, Sep 11, 2018 at 01:53:27PM +0200, Philippe Verdy wrote: > C'est normal que ça bloque : ce n'est pas parce que le lien est activé dans > un navigateur local que la source de ce lien vient du domaine local : la > page vient d'un site tiers et le navigateur tient compte de l'origine de la > page et de ses scripts, qui est le site web consulté affichant les liens. > > Sinon c'est trop facile pour une site web malveillant d'insérer des liens > "127.0.0.1" pour passer outre les autorisations et obtenir directement des Oui, bien sûr, mais le mécanisme n'est pas si simple que ça, vu que ça marche avec le lien Edit d'openstreetmap.org, qui, en fait, fait exactement la même chose au final (accès 127.0.0.1 etc). Firefox a apparement certaines exceptions "en dur" pour 127.0.0.1 (mais pas pour localhost, et apparemment pas toujours pour xmlHttpRequest, on s'y perd un peu). -- Pierre Beyssac p...@eriomem.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] détection de bugs dans la cartographie ferroviaire
On Tue, Sep 11, 2018 at 11:59:50AM +0200, Julien Lepiller wrote: > Quand je clique sur un lien JOSM, j'ai ça dans la console : > > http://127.0.0.1:8111/load_and_zoom?zoom_mode=download=1.8996611795158609=47.91660184082002=1.900610014653254=47.91723775722602=way81016796,way297346084 > >edit.js:56:9 > > Blocage d’une requête multiorigines (Cross-Origin Request) : la > politique « Same Origin » ne permet pas de consulter la ressource > distante située sur Ah, c'était donc ça. Merci. Ça marche via l'edit sur openstreetmap.org, j'ai réimplémenté leur méthode (création d'iframe au lieu de xmlHttpRequest), ça devrait donc corriger le problème cette fois, peux-tu réessayer ? -- Pierre Beyssac p...@eriomem.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] détection de bugs dans la cartographie ferroviaire
Le mar. 11 sept. 2018 à 11:58, Pierre Beyssac a écrit : > On Mon, Sep 10, 2018 at 04:24:17PM +0200, Julien Lepiller wrote: > > Probablement un coup de la sécurité de firefox, j'ai le même souci avec > > HOT. En gros, il aime pas qu'on fasse une requête en HTTP depuis une > > page en HTTPS, donc il bloque. D'ailleurs, j'ai ce message (pas le même > > que HOT) en plus : > > > Blocage d’une requête multiorigines (Cross-Origin Request) : la > > politique « Same Origin » ne permet pas de consulter la ressource > > distante située sur > > > http://127.0.0.1:8111/load_and_zoom?zoom_mode=download=1.8996612=47.9166018=1.90061=47.9172378=way81016796,way297346084. > > > Raison : échec de la requête CORS. > > Ça peut être bloqué pour raisons de "Content Security Policy" en > effet mais normalement (selon leur propre doc) dans les Firefox > récents 127.0.0.1 est une exception qui ne devrait pas bloquer (je > n'ai pas essayé ::1). > C'est normal que ça bloque : ce n'est pas parce que le lien est activé dans un navigateur local que la source de ce lien vient du domaine local : la page vient d'un site tiers et le navigateur tient compte de l'origine de la page et de ses scripts, qui est le site web consulté affichant les liens. Sinon c'est trop facile pour une site web malveillant d'insérer des liens "127.0.0.1" pour passer outre les autorisations et obtenir directement des privilèges locaux (le javascript ne nécessaite pas forcément un clic de l'utilisateur pour se déclencher, le blocage est pour tous les scripts et liens). Bref si on veut éviter le blocage c'est à l'utilisateur d'ajouter une exception pour un site spécifique et l'autoriser à référencer des ressources locales (ou directement utiliser des fichiers locaux via 127.0.0.1 et rapporter le tout immédiatement au serveur web qui volerait les données). Le navigateur bloque donc tout à fait normalement ces scripts et si Firefox laisser passer, c'est une passoire, un gros trou de sécurité ! Bref le visiteur du site DOIT ajouter spécifiquement une autorisation pour permettre à un domaine web de suivre un lien local. En attendant ces liens sont désactivés et bloqués. Normalement le navigateur doit afficher une alerte de ce blocage (au minimum une icone dans la barre en haut), et pas seulement mettre une trace dans la console (qui n'est que très rarement affichée par la plupart des utilisateurs des navigateurs): cliquer cette icone doit indiquer la raison du blocage, et offrir un bouton éventuel pour permettre d'ajouter une exception pour le site web auquel l'utilisateur accorde sa confiance. Attention toutefois à ne PAS accorder une exemption totale de tous les sites web (IP, domaines, ou URL quelconques) pour leur donner accès au domaine local. La protection CORS est maintenant une nécessité absolue : chaque page, chaque script, chaque image est associée à un domaine qui définit son propre "royaume" de sécurité. Un site web peut déclarer qu'il ajoute des sites tiers à son royaume, mais n'a pas le droit de déclarer 127.0.1 ou d'autres ressources locales comme étant dans son domaine : une telle déclaration serait malveillante et le site web sera traité lui-même comme malveillant dans tout bon navigateur et ne pourra utiliser que ses propres ressources issues de son propre domaine ! Il y a d'autres restrictions aussi concernant non seulement les domaines mais aussi les protocoles : un site HTTPS ne doit plus accorder par défaut de droit aux ressources HTTP, même issues de son propre domaine, et donc le navigateur doit les bloquer: il appartient au site web de mettre toutes les ressources qu'il demande d'utiliser aussi en HTTPS ou dans un protocole sécurisé utilisant les mêmes certificats avec les autorisations compatibles et sinon s'assurer que les ressources de sites tiers (souvent des traqueurs, des pubs, des outils de géolocalisation) sont aussi en HTTPS si le site principal est en HTTPS (on voit l'anomalie récente sur les wikis de Wikimedia et OSM où un script de géolocalisation utilisait un site HTTPS qui maintenant va fermer et redirige vers une page en HTTP: ce script, bien, bien qu'hébergé par le wiki et chargé en HTTPS, et référençant une ressource HTTPS, ne peut pas honorer la redirection vers HTTP et se fait donc bloquer très légitimement par le navigateur, et c'est une très bonne chose à mon avis que les navigateurs renforcent l'isolation des sites en les séparant chacun dans leur propre bac à sable qu'ils ne peuvent "ouvrir" qu'en étant très strict sur la déclaration explicite des autorisations qu'ils accordent **eux-mêmes** à des tiers, sous leur propre responsabilité y compris légale). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] détection de bugs dans la cartographie ferroviaire
Le 2018-09-11 11:54, Pierre Beyssac a écrit : On Mon, Sep 10, 2018 at 04:15:02PM +0200, deuzeffe wrote: On 10/09/2018 11:32, Pierre Beyssac wrote: > Ah voilà merci, c'est exactement ce qu'il me fallait ! Ça devrait > être facile. Et si tu ajoutes target="_blank" dans ton , ça ouvrira bien OSM/iD-Potlach dans un nouvel onglet. Mis ça hier soir. Rassure-moi, il n'est pas encore opérationnel le lien "load" (in JOSM, je suppose). Parce que "chez moi, ça pas marche". Il devrait. Par exemple, avec osmose, le lien pour modifier un objet dans josm, c'est : http://localhost:8111/load_object?objects=n5747831782 Une fois JOSM lancé, l'objet y est bien chargé (rien touché à la config. de base de josm, pas folle). Chez moi le lien marche bien (avec FF). Ça fait une requête pareil vers 127.0.0.1:8111 (etc). Essaie d'activer la console Javascript de FF pour voir si tu as un message d'erreur. Quand je clique sur un lien JOSM, j'ai ça dans la console : http://127.0.0.1:8111/load_and_zoom?zoom_mode=download=1.8996611795158609=47.91660184082002=1.900610014653254=47.91723775722602=way81016796,way297346084 edit.js:56:9 Blocage d’une requête multiorigines (Cross-Origin Request) : la politique « Same Origin » ne permet pas de consulter la ressource distante située sur http://127.0.0.1:8111/load_and_zoom?zoom_mode=download=1.8996611795158609=47.91660184082002=1.900610014653254=47.91723775722602=way81016796,way297346084. Raison : échec de la requête CORS. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] détection de bugs dans la cartographie ferroviaire
On Mon, Sep 10, 2018 at 04:24:17PM +0200, Julien Lepiller wrote: > Probablement un coup de la sécurité de firefox, j'ai le même souci avec > HOT. En gros, il aime pas qu'on fasse une requête en HTTP depuis une > page en HTTPS, donc il bloque. D'ailleurs, j'ai ce message (pas le même > que HOT) en plus : > Blocage d’une requête multiorigines (Cross-Origin Request) : la > politique « Same Origin » ne permet pas de consulter la ressource > distante située sur > http://127.0.0.1:8111/load_and_zoom?zoom_mode=download=1.8996612=47.9166018=1.90061=47.9172378=way81016796,way297346084. > > Raison : échec de la requête CORS. Ça peut être bloqué pour raisons de "Content Security Policy" en effet mais normalement (selon leur propre doc) dans les Firefox récents 127.0.0.1 est une exception qui ne devrait pas bloquer (je n'ai pas essayé ::1). Ça peut différer suivant les navigateurs. -- Pierre Beyssac p...@eriomem.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] détection de bugs dans la cartographie ferroviaire
On Mon, Sep 10, 2018 at 04:15:02PM +0200, deuzeffe wrote: > On 10/09/2018 11:32, Pierre Beyssac wrote: > > > Ah voilà merci, c'est exactement ce qu'il me fallait ! Ça devrait > > être facile. > > Et si tu ajoutes target="_blank" dans ton , ça ouvrira bien > OSM/iD-Potlach dans un nouvel onglet. Mis ça hier soir. > Rassure-moi, il n'est pas encore opérationnel le lien "load" (in JOSM, > je suppose). Parce que "chez moi, ça pas marche". Il devrait. > Par exemple, avec osmose, le lien pour modifier un objet dans josm, > c'est : http://localhost:8111/load_object?objects=n5747831782 Une fois > JOSM lancé, l'objet y est bien chargé (rien touché à la config. de base > de josm, pas folle). Chez moi le lien marche bien (avec FF). Ça fait une requête pareil vers 127.0.0.1:8111 (etc). Essaie d'activer la console Javascript de FF pour voir si tu as un message d'erreur. -- Pierre Beyssac p...@eriomem.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] détection de bugs dans la cartographie ferroviaire
On 10/09/2018 16:24, Julien Lepiller wrote: Probablement un coup de la sécurité de firefox, j'ai le même souci avec HOT. En gros, il aime pas qu'on fasse une requête en HTTP depuis une page en HTTPS, donc il bloque. D'ailleurs, j'ai ce message (pas le même que HOT) en plus : Avec osmose en http, ça fonctionne (même si c'est mal). Pour HOT, je peux cliquer sur le cadenas dans la barre d'adresse puis sur « désactiver la protection ». Là je ne sais pas. Le problème, c'est que le lien pour "LOAD" est (par ex.) https : // signal.eu.org/osm/bugs/#47.3841291/0.7417059 (grrr, free qui refuse d'envoyer le mail sous prétexte qu'il détecte du spam, obligée de charcuter l'url, désolée) À part recopier ce lien dans la barre d'url, ça ne fait pas grand chose d'autre. Ou c'est mon FF 60 ESR qui ne comprend pas ? -- deuzeffe, dubitative. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] détection de bugs dans la cartographie ferroviaire
Le 2018-09-10 16:15, deuzeffe a écrit : On 10/09/2018 11:32, Pierre Beyssac wrote: Ah voilà merci, c'est exactement ce qu'il me fallait ! Ça devrait être facile. Et si tu ajoutes target="_blank" dans ton , ça ouvrira bien OSM/iD-Potlach dans un nouvel onglet. J'ai déjà ça pour JOSM, qui est similaire en paramètres, mais en URL de connexion directe via localhost. Rassure-moi, il n'est pas encore opérationnel le lien "load" (in JOSM, je suppose). Parce que "chez moi, ça pas marche". Par exemple, avec osmose, le lien pour modifier un objet dans josm, c'est : http://localhost:8111/load_object?objects=n5747831782 Une fois JOSM lancé, l'objet y est bien chargé (rien touché à la config. de base de josm, pas folle). HTH Probablement un coup de la sécurité de firefox, j'ai le même souci avec HOT. En gros, il aime pas qu'on fasse une requête en HTTP depuis une page en HTTPS, donc il bloque. D'ailleurs, j'ai ce message (pas le même que HOT) en plus : Blocage d’une requête multiorigines (Cross-Origin Request) : la politique « Same Origin » ne permet pas de consulter la ressource distante située sur http://127.0.0.1:8111/load_and_zoom?zoom_mode=download=1.8996612=47.9166018=1.90061=47.9172378=way81016796,way297346084. Raison : échec de la requête CORS. Pour HOT, je peux cliquer sur le cadenas dans la barre d'adresse puis sur « désactiver la protection ». Là je ne sais pas. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] détection de bugs dans la cartographie ferroviaire
On 10/09/2018 11:32, Pierre Beyssac wrote: Ah voilà merci, c'est exactement ce qu'il me fallait ! Ça devrait être facile. Et si tu ajoutes target="_blank" dans ton , ça ouvrira bien OSM/iD-Potlach dans un nouvel onglet. J'ai déjà ça pour JOSM, qui est similaire en paramètres, mais en URL de connexion directe via localhost. Rassure-moi, il n'est pas encore opérationnel le lien "load" (in JOSM, je suppose). Parce que "chez moi, ça pas marche". Par exemple, avec osmose, le lien pour modifier un objet dans josm, c'est : http://localhost:8111/load_object?objects=n5747831782 Une fois JOSM lancé, l'objet y est bien chargé (rien touché à la config. de base de josm, pas folle). HTH -- deuzeffe, qui aime bien enfoncer des portes ouvertes, ça rafraîchit, par ce temps. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] détection de bugs dans la cartographie ferroviaire
Le 10/09/2018 à 11:57, Pierre Beyssac a écrit : Je compte diffuser tout le code en libre (c'est du Go essentiellement) quand il sera à peu près stabilisé Je peux filer le code "en vrac" tel quel à qui veut regarder aussi mais c'est pas forcément un cadeau :-P La vérification la plus subtile c'est prendre un nœud à n branches et suivant les angles essayer de déterminer si c'est : 3 chemins -> aiguille normale... ou pas 4 chemins -> aiguiille triple ou "croisement" plus -> bizarre, à examiner Désolé, mais non spécialiste du sujet j'ai un peu de mal à comprendre de quoi tu parle. Je ne sais pas si Osmose peut faire, j'imagine que oui. Il y a des millions de trucs pas faits et à faire avec l'opendata SNCF aussi (vérifications d'import), mais évidemment ça ne concernera que la France, alors que ce qui précède je l'applique partout. Voilà déjà ce qu'a Osmose sur le sujet: http://osmose.openstreetmap.fr/fr/map/#tags=railway À quels jeux de données OpenData tu penses ? Il a toute une partie d'Osmose dédié à la comparaison avec l'Opendata. Une autre solution, Osmose peut aussi servir à afficher les résultats de contrôle fait à l'extérieur d'Osmose. Il y en a déjà des fait comme ça. Ah ça peut être un bon début oui... il y a de la doc là dessus ? https://wiki.openstreetmap.org/wiki/Osmose#Issues_reporting_API ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] détection de bugs dans la cartographie ferroviaire
On Mon, Sep 10, 2018 at 10:22:14AM +0200, Frédéric Rodrigo wrote: > Le 10/09/2018 à 09:23, Erik Amzallag a écrit : > > Bonjour, > > > > Serait-il possible d'avoir plus de précisions sur la nature des > > erreurs ? Ce qu'elles signifient, et éventuellement des propositions > > de corrections. > > > > Merci ! > > > > Erik > > Le code est quelque part ou tu peux décrire les contrôles que tu fais > (et avec quoi) pour voir si l'on peut implémenter ça dans osmose ? Je compte diffuser tout le code en libre (c'est du Go essentiellement) quand il sera à peu près stabilisé Je peux filer le code "en vrac" tel quel à qui veut regarder aussi mais c'est pas forcément un cadeau :-P La vérification la plus subtile c'est prendre un nœud à n branches et suivant les angles essayer de déterminer si c'est : 3 chemins -> aiguille normale... ou pas 4 chemins -> aiguiille triple ou "croisement" plus -> bizarre, à examiner Je ne sais pas si Osmose peut faire, j'imagine que oui. Il y a des millions de trucs pas faits et à faire avec l'opendata SNCF aussi (vérifications d'import), mais évidemment ça ne concernera que la France, alors que ce qui précède je l'applique partout. > Une autre solution, Osmose peut aussi servir à afficher les résultats de > contrôle fait à l'extérieur d'Osmose. Il y en a déjà des fait comme ça. Ah ça peut être un bon début oui... il y a de la doc là dessus ? -- Pierre Beyssac p...@eriomem.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] détection de bugs dans la cartographie ferroviaire
On Mon, Sep 10, 2018 at 09:23:17AM +0200, Erik Amzallag wrote: > Bonjour, > > Serait-il possible d'avoir plus de précisions sur la nature des erreurs ? > Ce qu'elles signifient, et éventuellement des propositions de corrections. Oui je compte écrire ça. Par exemple pour les "3-way" (aiguilles triples) : - soit c'est vraiment une aiguille triple, dans ce cas c'est bien de la marquer en railway=switch et railway:switch=three_way, ensuite mon vérificateur la considère vérifiée et l'ignore (j'en ai fait pas mal en France hier soir). - soit c'est 2 aiguilles normales, ou une aiguille "quasi-triple" où les 2 déviations sont assez clairement séparées, ou une zone inexacte faite à l'arrache (fréquent) et dans ce cas on corrige en 2 aiguilles normales (et on peut affiner la zone par ailleurs si on a envie :-P) De même pour les "weird", ça peut être une plaque tournante, dans ce cas on marque en railway=turntable, ou encore une zone faite à l'arrache à n aiguilles classiques cumulées en un gros nœud à n branches, etc. -- Pierre Beyssac p...@eriomem.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] détection de bugs dans la cartographie ferroviaire
On Mon, Sep 10, 2018 at 09:32:37AM +0200, PanierAvide wrote: > Et tu peux faire varier les paramètres : > > - node= pour pointer directement sur un objet, peut aussi être > way=XXX ou relation=XXX, tu peux aussi simplement ne pas l'indiquer si > tu n'as pas de référence précise > - map=zoom/latitude/longitude à personnaliser au besoin (pas nécessaire > si tu as indiqué un paramètre node/way/relation) Ah voilà merci, c'est exactement ce qu'il me fallait ! Ça devrait être facile. J'ai déjà ça pour JOSM, qui est similaire en paramètres, mais en URL de connexion directe via localhost. -- Pierre Beyssac p...@eriomem.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] détection de bugs dans la cartographie ferroviaire
Le 10/09/2018 à 09:23, Erik Amzallag a écrit : Bonjour, Serait-il possible d'avoir plus de précisions sur la nature des erreurs ? Ce qu'elles signifient, et éventuellement des propositions de corrections. Merci ! Erik Le code est quelque part ou tu peux décrire les contrôles que tu fais (et avec quoi) pour voir si l'on peut implémenter ça dans osmose ? Une autre solution, Osmose peut aussi servir à afficher les résultats de contrôle fait à l'extérieur d'Osmose. Il y en a déjà des fait comme ça. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] détection de bugs dans la cartographie ferroviaire
Le 10/09/2018 à 00:23, Pierre Beyssac a écrit : Je ne sais pas démarrer iD dans une page web. Si quelqu'un me donne l'incantation, pourquoi pas (pas trouvé en ligne). Mais s'il faut une copie d'iD sur mon site, je préfère éviter:) Tu peux assez simplement mettre un lien web classique, dans lequel tu appelles l'URL avec le format suivant : https://www.openstreetmap.org/edit?node=2445458408#map=20/48.13276/-1.63256 Et tu peux faire varier les paramètres : - node= pour pointer directement sur un objet, peut aussi être way=XXX ou relation=XXX, tu peux aussi simplement ne pas l'indiquer si tu n'as pas de référence précise - map=zoom/latitude/longitude à personnaliser au besoin (pas nécessaire si tu as indiqué un paramètre node/way/relation) De cette façon, tu peux faire afficher à peu près ce que tu veux à iD, sans avoir besoin de faire grand chose ;-) Cordialement, Adrien. -- PanierAvide Géomaticien & développeur ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] détection de bugs dans la cartographie ferroviaire
Bonjour, Serait-il possible d'avoir plus de précisions sur la nature des erreurs ? Ce qu'elles signifient, et éventuellement des propositions de corrections. Merci ! Erik Le dim. 9 sept. 2018 à 22:43, Pierre Beyssac a écrit : > Bonsoir, > > Cela fait un moment que je contribue à OSM et lis cette liste > épisodiquement sans avoir grand chose à y dire... > > Cette fois je voudrais signaler mon petit projet de ce week-end, > dérivé de travaux précédents que j'ai préséntés à SOTM-FR 2018, qui > peut intéresser les contributeurs OSM "ferrovipathes". > > C'est là : > https://signal.eu.org/osm/bugs/ > > C'est simplement une page qui affiche des marqueurs (avec pointeurs > directs vers OSM ou chargement JOSM si vous utilisez ce dernier) > de "problèmes" (notion subjective, long débat). > > Ce n'est pas parfait mais comme on dit, "balance tôt, balance souvent". > > Avis bienvenus :) > > PS pour répondre à une FAQ : certaines choses signalées par ma page > le sont aussi ou pourraient l'être par Osmose (angles élevés dans > les courbes, par exemple) mais je suis bien incapable d'écrire un > plug-in Osmose pour y importer toutes ces vérifications. > -- > Pierre Beyssac p...@eriomem.net > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] détection de bugs dans la cartographie ferroviaire
On Sun, Sep 09, 2018 at 11:17:51PM +0200, deuzeffe wrote: > Le 09/09/2018 à 22:42, Pierre Beyssac a écrit : > > > C'est simplement une page qui affiche des marqueurs (avec pointeurs > > directs vers OSM ou chargement JOSM si vous utilisez ce dernier) > > Rq de useuse de base : ouvrir osm/iD dans une nouvelle fenêtre ? > (pas testé ce que ça donne avec josm, c'est trop tard :p) Je ne sais pas démarrer iD dans une page web. Si quelqu'un me donne l'incantation, pourquoi pas (pas trouvé en ligne). Mais s'il faut une copie d'iD sur mon site, je préfère éviter :) -- Pierre Beyssac p...@eriomem.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] détection de bugs dans la cartographie ferroviaire
Le 09/09/2018 à 22:42, Pierre Beyssac a écrit : C'est simplement une page qui affiche des marqueurs (avec pointeurs directs vers OSM ou chargement JOSM si vous utilisez ce dernier) Rq de useuse de base : ouvrir osm/iD dans une nouvelle fenêtre ? (pas testé ce que ça donne avec josm, c'est trop tard :p) PS pour répondre à une FAQ : certaines choses signalées par ma page le sont aussi ou pourraient l'être par Osmose (angles élevés dans les courbes, par exemple) mais je suis bien incapable d'écrire un plug-in Osmose pour y importer toutes ces vérifications. Oh comme c'est bien dommage. C'est justement ce que j'allais te proposer ;p Ou du moins voir s'il n'y a pas déjà des trucs (tu sembles dire que oui) ? Ou bien lister les erreurs/défauts qui pourraient éventuellement être mis en évidence. -- deuzeffe - Taquine, moi ? Ja-Mais ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
