Re: [OSM-talk-fr] Bogue d'Osmose (codage XML invalide provenant du serveur Backend)
Le 10 février 2012 15:02, Frédéric Rodrigo a écrit : >>> Mon dépôt osmose sur gitorious n'est pas vraiment une référence. >>> Regardes plutôt la branche dev de http://gitorious.org/osmose pour la >>> version de développement. >> >> J'ai regardé justement, mais je n'ai trouvé aucun contact, ou section >> en place sur le site pour signaler et suivre l'anomalie (par exemple >> Bugzilla). >> >> On trouve juste un endroit pour soumettre une branche, qui sera >> difficilement acceptée si on n'explique rien. Ce qui suppose qu'en >> fait ce repository n'a qu'un seul mainteneur qui travaille seul mais >> qui omet de fournir un point de contact. > > Actuellement seul Jocelyn commites sur le dépôt principal. Mais il y a > plusieurs clones, dont le mien. Sur le quel je fais beaucoup de > modifications et qui sont intégrées (et validé) par Jocelyn. > > Tu peux aussi te créer une clone et commiter dessus avec des > commentaires pour expliquer le pourquoi et proposer des modifications > à l'intégration d'osmose (c'est le principe fonctionnement de > gitorious). > Bien sur il est possible d'en discuter sur la ML-dev ou sur IRC. Multiplier les dépôts sans mettre en place un suivi centralisé des anomalies pour savoir qui fait quoi, c'est pas très utile. Tous les projets opensource ont un système comme Bugzilla pour remonter les anomalies, les reclasser, en gérer la planification et les tests d'intégration, et ne pas compter que sur les discussions. Je persiste ici à dire que c'est du au manque de versionnement central qu'une version incorrecte de Python a été installée sur le serveur Osmose.openstreetmap. Je me demande si vous savez quelles versions des bibliothèques Python sont installées et d'où elles viennent, puisque cela ne figure même pas dans vos repositories, qui ne documentent pas non plus les versions testées nécessaires. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bogue d'Osmose (codage XML invalide provenant du serveur Backend)
>> Mon dépôt osmose sur gitorious n'est pas vraiment une référence. >> Regardes plutôt la branche dev de http://gitorious.org/osmose pour la >> version de développement. > > J'ai regardé justement, mais je n'ai trouvé aucun contact, ou section > en place sur le site pour signaler et suivre l'anomalie (par exemple > Bugzilla). > > On trouve juste un endroit pour soumettre une branche, qui sera > difficilement acceptée si on n'explique rien. Ce qui suppose qu'en > fait ce repository n'a qu'un seul mainteneur qui travaille seul mais > qui omet de fournir un point de contact. Actuellement seul Jocelyn commites sur le dépôt principal. Mais il y a plusieurs clones, dont le mien. Sur le quel je fais beaucoup de modifications et qui sont intégrées (et validé) par Jocelyn. Tu peux aussi te créer une clone et commiter dessus avec des commentaires pour expliquer le pourquoi et proposer des modifications à l'intégration d'osmose (c'est le principe fonctionnement de gitorious). Bien sur il est possible d'en discuter sur la ML-dev ou sur IRC. Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bogue d'Osmose (codage XML invalide provenant du serveur Backend)
Le 10 février 2012 13:42, Philippe Verdy a écrit : > Ensuite regarde les historiques: tu verras qu'ils proviennent de "rawedit". D'ailleurs je suggère que les historiques de modifications indique dans le champ mentionnant le logiciel utilisé, non seulement la version de ce logiciel, mais aussi pour tous les éditeurs en ligne (Potlatch et rawedit inclus) l'indication du type de navigateur utilisé et sa version (le "user-agent") qui précise aussi la plateforme hôte du client (Windows, Mac, Linux...). Afin de repérer aussi les incompatiblités de certains navigateurs avec le code Javascript utilisé. Et de motiver aussi l'utilisation de jQuery au lieu d'un code "maison" oubliant de prendre en compte des problèmes de compatibilité. A mon avis, les utilisateurs de vieilles versions d'Internet Explorer avec ces éditeurs en ligne peuvent causer de sérieux problème de corruption de données, et la base OSM n'est pas suffisamment à l'abri d'attaques de type XSS (contre lesquelles jQuery du coté javascript client, et les frameworks associés côté serveur fournissent une meilleure protection, à condition que vous les gardiez à jour !) Méfiance avec les modules de frameworks Python dont les sources ne proviennent pas de repositories officiels, correctement maintenus et versionnés, ou le code "maison" sensé simplifier le code, surtout si vous ne pouvez pas tester vous même tous les problèmes connus de compatibilité avec ces navigateurs exotiques ou anciens et bogués mais encore utilisés (pour lesquels les frameworks maintenus fournissent une parade efficace, et tant pis si les vieux navigateurs sont à la peine question performance). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bogue d'Osmose (codage XML invalide provenant du serveur Backend)
Le 10 février 2012 12:56, Jocelyn Jaubert a écrit :
> Bonjour,
>
> (je redirige sur dev-fr où ça a plus sa place)
>
> Le 10 février 2012, Philippe Verdy a écrit :
>
>> 369 self._write(' %s=%s' % (name, quoteattr(value)))
>> 378 self._write(' %s=%s' % (name, quoteattr(value)))
>>
>> En effet, la fonction Python quoteattr() ne représente pas
>> correctement le caractère "&" qu'il laisse sous cette forme, alors
>> qu'il FAUT le réencoder sous la forme "&"
>>
>> La fonction quoteattr() est importée depuis le module Python
>> "sax.saxutils", absent dans les sources GIT d'Osmose. C'est elle qui
>> est ici en cause.
>
> Cette fonction fait parti de la librairie python standard, et sa
> documentation se trouve là:
>
> http://docs.python.org/library/xml.sax.utils.html
>
> D'après la doc, quoteattr() échappe bien les & < et >, donc je ne
> comprends pas le problème.
Tu as une doc à jour, mais pas le module Python à jour qui correspond,
sans doute un module de Python v1. Il y a eu de nombreuses corrections
de sécurité dedans (y compris une correction dans l'ordre de
substitution de "&", uniquement dans Python 2.1.1, puis ensuite des
tentatives "simplifications" du code sans utiliser escape() en
interne... suivi aussitôt d'une anomalie avec une attaque de sécurité
XSS sur un certain nombre de sites.
C'est pour ça que je t'ai fourni des liens vers des versions
correctes. Car je ne sais pas du tout quelle version tu as chargée et
utilisée (depuis quel repository Python ??? Il y en a plein, pas
toujours conformes à l'original ou ne prenant pas en compte les
corrections pourtant approuvées).
> Est-ce que tu pourrais donner un lien sur osmose.openstreetmap.fr qui
> montrerait le problème ? (avec le permalink en bas à droite)
Oui, mais j'ai corrigé un problème, il n'apparait plus dans Osmose là
où je l'ai vu la première fois.
J'en ai vu ailleurs dans les noms relations de sites géodésiques (dont
les membres sont des noeuds groupés sur une même collection dont la
relation donne une référence commune avec une URL vers le site de
géosésie de l'IGN, ces URL contenant des "&" puisqu'elles contiennent
des paramètres.
Et j'ai vu ces mêmes URL corrompues par endroit (j'aurais du regarder
l'historique, pour voir que cela venait bien de rawedit).
Si tu n'en voit pas, crée un point avec une erreur de tonomymie dans
JOSM qu'Osmose signalera (par exemple donne un nom comme "BOUTIQUE
C&A", Osmose ralera sur les majuscules, ouvre le noeud signalé. Tu
verras que même sans rien toucher, il refusera la modification. Mets
une URL en valeur contenant des paramètres de requêtes: dans JOSM il
n'est pas nécessaire et on ne doit rien substituer à l'écran, JOSM
fait correctement les encodages et décodage URL quand il utilise l'API
d'OSM (mais pas Osmose aussi bien dans ses URLs insérées dans le
Frontend HTML/CSS/JS que dans le code Javascript qui communique en XML
avec le Backend d'Osmose, qui vérifie la requête puis renvoie vers
l'API d'OSM).
>> Deuxième problème (lié au premier) ===
>>
>> Enfin je note que le code Javascript envoyé au client utilise le
>> constructeur: new XMLHttpRequest(), mais sans préciser le jeu de
>> caractères qui sera utilisé pour dialoguer avec le serveur :
>
> Le fait que la page html et le fichier .js soient encodées en UTF-8 via
> les headers HTTP ne suffit pas à informer le navigateur ?
>
>
> Et est-ce que tu peux donner un exemple d'objet "corrompu" sur OSM ?
Si tu charges une zones assez grande dans JOSM, il suffit de regarder
les valeurs chargées énumérées dans la liste de valeurs existantes
d'un attribut comme "source". Tu y verras des tas de caractères ""
noirs là où auraient du rester des caractères accentués, visiblement
édités sur un navigateur Macintosh; sélectionne cette valeur dans la
liste, uniquement pour la copier dans le presse-papier. Puis recherche
les objets contenant cette valeur incorrecte.
Tu vas en trouver beaucoup.
Ensuite regarde les historiques: tu verras qu'ils proviennent de "rawedit".
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bogue d'Osmose (codage XML invalide provenant du serveur Backend)
Pour le code source à jour de ce module:
http://svn.cs.brynmawr.edu/viewvc/Pyjama/trunk/IronPython/Lib/xml/sax/saxutils.py?view=markup&pathrev=9
ou (version 3)
http://www.opensource.apple.com/source/python/python-3/python/Lib/xml/sax/saxutils.py
ou
https://vmi.lmt.ei.tum.de/projects/ros/browser/trunk/vmi_cognitive_environment/ce_skype/src/sky2ros/Student/client/xml/sax/saxutils.py
Ce codage de quoteattr() est correct et n'oublie pas "&", puisqu'il
utilise escape() en interne, qui remplace systématiquement ce
caractère.
Le 10 février 2012 12:58, Philippe Verdy a écrit :
> Note, la doc Python du module SAX est là:
>
> http://docs.python.org/library/xml.sax.utils.html
>
> Elle précise bien que quoteattr() doit normalement encoder les mêmes
> caractères que:
>
> xml.sax.saxutils.escape(data[, entities])
>
> sans même avoir à passer un tableau entities (les caractères "&", "<"
> et ">" sont inclus par défaut), mais quoteattr() ajoute les guillemets
> (") et apostrophes ('), sans retirer pour autant le caractère "&" des
> entités de substitution définies par défaut.
>
> Visiblement c'est un problème de version du module "xml.sax.saxutils"
> que tu utilises (il faut une version 2.2 ou supérieure de Python pour
> avoir cette fonction). Note bien que quoteattr() a été conçu pour HTML
> ou SGML, pas pour la conformité XML ou XHTML (la conformité XML vient
> avec la version 2.3 il me semble, sinon il te faut passer un paramètre
> entities ; Python est actuellement en version 2.7)
>
>
> Le 10 février 2012 12:45, Philippe Verdy a écrit :
>> A mon avis le bogue est surtout à corriger dans la fonction
>> quoteattr() du module Python "sax.saxutils".
>>
>> Car ***même*** en HTML ou SGML (au lieu de XML ou XHTML) il faudrait
>> systématiquement recoder un "&" présent dans une valeur qu'on veut
>> encapsuler dans un attribut d'élément HTML (ou XML). Tout parseur HTML
>> ou SGML reconnait "&" automatiquement (sans avoir besoin de
>> définir l'entité), mais ***tolère*** (par compatibilité ascendante
>> avec les très vieux navigateurs HTML, d'avant même HTML4) des valeurs
>> contenant des entités mal codées (dans ce cas un parseur HTML a un
>> "fallback" lui permettant de réinterpréter la valeur donnée sans faire
>> le décodage des entités, mais PAS un parseur XML qui s'y refuse, car
>> c'est un trou de sécurité).
>>
>> Le code d'Osmose visiblement l'oublie quand il génère aussi d'autres
>> URLs "en dur" à d'autres endroits de la page HTML du frontend (mais ce
>> frontend est codé pour générer du HTML, pas du XHTML, ce qui autorise
>> le "fallback" pourtant pas recommandé du tout et dangereux).
>>
Mon dépôt osmose sur gitorious n'est pas vraiment une référence.
Regardes plutôt la branche dev de http://gitorious.org/osmose pour la
version de développement.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bogue d'Osmose (codage XML invalide provenant du serveur Backend)
Note, la doc Python du module SAX est là:
http://docs.python.org/library/xml.sax.utils.html
Elle précise bien que quoteattr() doit normalement encoder les mêmes
caractères que:
xml.sax.saxutils.escape(data[, entities])
sans même avoir à passer un tableau entities (les caractères "&", "<"
et ">" sont inclus par défaut), mais quoteattr() ajoute les guillemets
(") et apostrophes ('), sans retirer pour autant le caractère "&" des
entités de substitution définies par défaut.
Visiblement c'est un problème de version du module "xml.sax.saxutils"
que tu utilises (il faut une version 2.2 ou supérieure de Python pour
avoir cette fonction). Note bien que quoteattr() a été conçu pour HTML
ou SGML, pas pour la conformité XML ou XHTML (la conformité XML vient
avec la version 2.3 il me semble, sinon il te faut passer un paramètre
entities ; Python est actuellement en version 2.7)
Le 10 février 2012 12:45, Philippe Verdy a écrit :
> A mon avis le bogue est surtout à corriger dans la fonction
> quoteattr() du module Python "sax.saxutils".
>
> Car ***même*** en HTML ou SGML (au lieu de XML ou XHTML) il faudrait
> systématiquement recoder un "&" présent dans une valeur qu'on veut
> encapsuler dans un attribut d'élément HTML (ou XML). Tout parseur HTML
> ou SGML reconnait "&" automatiquement (sans avoir besoin de
> définir l'entité), mais ***tolère*** (par compatibilité ascendante
> avec les très vieux navigateurs HTML, d'avant même HTML4) des valeurs
> contenant des entités mal codées (dans ce cas un parseur HTML a un
> "fallback" lui permettant de réinterpréter la valeur donnée sans faire
> le décodage des entités, mais PAS un parseur XML qui s'y refuse, car
> c'est un trou de sécurité).
>
> Le code d'Osmose visiblement l'oublie quand il génère aussi d'autres
> URLs "en dur" à d'autres endroits de la page HTML du frontend (mais ce
> frontend est codé pour générer du HTML, pas du XHTML, ce qui autorise
> le "fallback" pourtant pas recommandé du tout et dangereux).
>
>>> Mon dépôt osmose sur gitorious n'est pas vraiment une référence.
>>> Regardes plutôt la branche dev de http://gitorious.org/osmose pour la
>>> version de développement.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bogue d'Osmose (codage XML invalide provenant du serveur Backend)
Bonjour,
(je redirige sur dev-fr où ça a plus sa place)
Le 10 février 2012, Philippe Verdy a écrit :
> 369 self._write(' %s=%s' % (name, quoteattr(value)))
> 378 self._write(' %s=%s' % (name, quoteattr(value)))
>
> En effet, la fonction Python quoteattr() ne représente pas
> correctement le caractère "&" qu'il laisse sous cette forme, alors
> qu'il FAUT le réencoder sous la forme "&"
>
> La fonction quoteattr() est importée depuis le module Python
> "sax.saxutils", absent dans les sources GIT d'Osmose. C'est elle qui
> est ici en cause.
Cette fonction fait parti de la librairie python standard, et sa
documentation se trouve là:
http://docs.python.org/library/xml.sax.utils.html
D'après la doc, quoteattr() échappe bien les & < et >, donc je ne
comprends pas le problème.
Est-ce que tu pourrais donner un lien sur osmose.openstreetmap.fr qui
montrerait le problème ? (avec le permalink en bas à droite)
> Deuxième problème (lié au premier) ===
>
> Enfin je note que le code Javascript envoyé au client utilise le
> constructeur: new XMLHttpRequest(), mais sans préciser le jeu de
> caractères qui sera utilisé pour dialoguer avec le serveur :
Le fait que la page html et le fichier .js soient encodées en UTF-8 via
les headers HTTP ne suffit pas à informer le navigateur ?
Et est-ce que tu peux donner un exemple d'objet "corrompu" sur OSM ?
Merci,
Jocelyn
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bogue d'Osmose (codage XML invalide provenant du serveur Backend)
A mon avis le bogue est surtout à corriger dans la fonction quoteattr() du module Python "sax.saxutils". Car ***même*** en HTML ou SGML (au lieu de XML ou XHTML) il faudrait systématiquement recoder un "&" présent dans une valeur qu'on veut encapsuler dans un attribut d'élément HTML (ou XML). Tout parseur HTML ou SGML reconnait "&" automatiquement (sans avoir besoin de définir l'entité), mais ***tolère*** (par compatibilité ascendante avec les très vieux navigateurs HTML, d'avant même HTML4) des valeurs contenant des entités mal codées (dans ce cas un parseur HTML a un "fallback" lui permettant de réinterpréter la valeur donnée sans faire le décodage des entités, mais PAS un parseur XML qui s'y refuse, car c'est un trou de sécurité). Le code d'Osmose visiblement l'oublie quand il génère aussi d'autres URLs "en dur" à d'autres endroits de la page HTML du frontend (mais ce frontend est codé pour générer du HTML, pas du XHTML, ce qui autorise le "fallback" pourtant pas recommandé du tout et dangereux). >> Mon dépôt osmose sur gitorious n'est pas vraiment une référence. >> Regardes plutôt la branche dev de http://gitorious.org/osmose pour la >> version de développement. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bogue d'Osmose (codage XML invalide provenant du serveur Backend)
Le 10 février 2012 12:11, Frédéric Rodrigo a écrit : > Bonjour, > Sincèrement je n'ai pas tout lu (vraiment beaucoup trop long, tu > pourrais proposer un résumé de tes mails en introduction ;) ). Justement chaque point a une présentation dès les premières lignes. La suite de chaque point, c'est pour expliquer pourquoi l'erreur survient. > Mon dépôt osmose sur gitorious n'est pas vraiment une référence. > Regardes plutôt la branche dev de http://gitorious.org/osmose pour la > version de développement. J'ai regardé justement, mais je n'ai trouvé aucun contact, ou section en place sur le site pour signaler et suivre l'anomalie (par exemple Bugzilla). On trouve juste un endroit pour soumettre une branche, qui sera difficilement acceptée si on n'explique rien. Ce qui suppose qu'en fait ce repository n'a qu'un seul mainteneur qui travaille seul mais qui omet de fournir un point de contact. Le bogue est facile à voir et reproduire : essaye de charger un point géodésique contenant une erreur dans Osmose (par exemple dans un toponyme) : le lien url fourni est mal encodé quand il est envoyé en format XML par le backend, alors même qu'on n'a aucune intention d'y toucher dans "rawedit", et la validation du XML édité échoue sur le serveur. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bogue d'Osmose (codage XML invalide provenant du serveur Backend)
Bonjour,
Sincèrement je n'ai pas tout lu (vraiment beaucoup trop long, tu
pourrais proposer un résumé de tes mails en introduction ;) ).
Mon dépôt osmose sur gitorious n'est pas vraiment une référence.
Regardes plutôt la branche dev de http://gitorious.org/osmose pour la
version de développement.
Frédéric
Le 10 février 2012 11:51, Philippe Verdy a écrit :
> Je viens de trouver un bogue dans Osmose, sur son serveur Backend.
>
> Premier problème (le plus sérieux) ===
>
> Cela se situe ici:
>
> https://gitorious.org/~frodrigo/osmose/frodrigo-osmose-backend/blobs/master/modules/OsmSax.py
>
> Aux deux lignes suivantes du module SaxWriter lorsqu'il génère le code
> des valeurs d'attributs des élements XML :
>
> 369 self._write(' %s=%s' % (name, quoteattr(value)))
> 378 self._write(' %s=%s' % (name, quoteattr(value)))
>
> En effet, la fonction Python quoteattr() ne représente pas
> correctement le caractère "&" qu'il laisse sous cette forme, alors
> qu'il FAUT le réencoder sous la forme "&"
>
> La fonction quoteattr() est importée depuis le module Python
> "sax.saxutils", absent dans les sources GIT d'Osmose. C'est elle qui
> est ici en cause.
>
> Cela affecte la modification des éléments contenant un caractère "&"
> dans leur valeur (par exemple les relations contenant un tag "url", ou
> certains tags "name" parfaitement valides).
>
> L'effet de ce bogue est que le XML reçu par le client et éditable par
> "rawedit" est invalide, et ne peut pas être revalidé tel quel !
> Sinon on reçoit un message affiché en rouge en haut de l'écran
> rawedit: "XML parser can't parse this data", et les données ne sont
> pas enregistrées.
>
> Pour contourner le problème, il faut soit même corriger le code XML
> qui a été reçu en remplaçant les "&" affichés dans l'éditeur dans les
> valeurs de tags par "&" avant de valider, même si on n'a pas
> réellement touché à la valeur.
>
> Le risque subsiste que même sans y toucher, l'absence de modification
> manuelle pour faire la correction risque parfois d'être acceptés comme
> du XML valide (par exemple quand un "&" littéral est suivi de
> quelquechose qui ressemble à une référence numérique de caractère ou
> une référene d'entité XML définie dans le schéma XML utilisé), ce qui
> corrompra les données qui n'avaient pas lieu d'être modifiées.
>
> Je ne sais pas si c'est la fonction quoteattr() du module sax.saxutils
> qui devrait être corrigée, ou si une autre fonction devrait plutôt
> être définie ou utilisée ici, ou si un paramètre supplémentaire
> optionnel de quoteattr() permet de préciser la conformité avec XML
> (car quoteattr() n'est pas obligé de remplacer ces "&" si la fonction
> est utilisée pour générer du HTML ou du SGML): dans ce cas il faut
> passer ce paramètre oublié.
>
> A ce sujet, quoteattr() recode toutes les apostrophes ASCII (') sous
> la forme ' alors que c'est inutile (et peu lisible) ici, étant
> donné que la chaine retournée sera encadrée de guillemets doubles
> ASCII ("). En revanche les quatre caractères suivants doivent être mis
> sous forme de référence à une des quatre seules entité de caractères
> XML prédéfinie :
>
> - les guillemets doubles ASCII (") sous la forme "
> - le signe inférieur (<) sous la forme <
> - le signe supérieur (>) sous la forme >
> - le signe et commercial (&) sous la forme &
>
> Et c'est tout ! Tout le reste peut (et devrait) rester sous leur forme
> littérale (même l'apostrophe ici, bien que XML prédéfinisse aussi une
> cinquième entité "'" puisque la syntaxe XML permet aussi aux
> valeurs d'attributs d'être encadrées par des apostrophes ASCII au lieu
> de guillemets ASCII).
>
>
> Deuxième problème (lié au premier) ===
>
> Enfin je note que le code Javascript envoyé au client utilise le
> constructeur: new XMLHttpRequest(), mais sans préciser le jeu de
> caractères qui sera utilisé pour dialoguer avec le serveur :
>
> function ApiDo(action)
> {
> var myReq = new XMLHttpRequest();
> if (myReq) {
> myReq.onreadystatechange = function (evnt) { if(myReq.readyState == 4) {
> res = myReq.responseText.split('\n');
> document.getElementById('osm_msg').innerHTML = res[0];
> tmp = res.shift();
> document.getElementById('osm_data').value = res.join('\n');
> } }
> myReq.open('POST', '/' + action + '/' + osm_type + '/' + osm_id, true);
> myReq.setRequestHeader("Content-type",
> "application/x-www-form-urlencoded");
> poststr = "osm_data=" +
> encodeURIComponent(document.getElementById("osm_data").value );
> myReq.send(poststr);
> }
> }
>
> Rien n'oblige actuellement le navigateur à supposer que cette requête
> se fera en codage UTF-8, même si la page web et le code javascript
> sont eux-même codés en UTF-8. Dans les faits, cette requête telle
> qu'elle est envoyée au serveur ne précise rien du tout, ce qui demande
> alors que les données incluses dans la valeur "osm_data=" ne soient
> que de l'ASCII pur.
>
> Ici le problème est
Re: [OSM-talk-fr] Bogue d'Osmose ?
Bonsoir, Etienne Chové a écrit : > Les extraits de geobabrik sont en pannes depuis hier... osmose a donc > des données datant du 11 au soir. Le dernier extrait dispo avait > toujours cette erreur. Merci pour cette réponse. Je pensais que l'outil tapait directement dans la base OSM, pas dans une autre. Le problème de synchronisation des données est donc plus vieux que ça puisque la dernière version en date est celle du 08 juin, et non celle du 10. Je vais donc attendre que les données soient derechef actualisées. Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://sebastien.dinot.free.fr/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bogue d'Osmose ?
Sébastien Dinot a écrit : > Bonjour à tous, > > Le 8 juin, constatant des tracés très approximatifs sur le site de l'INSA de > Toulouse, j'ai rectifié la position et la forme des bâtiments et des voies. > > Ce faisant, je suis devenu le dernier éditeur en date de la « way » 32599351 > et Osmos m'a donc attribué dès le lendemain la paternité d'une erreur de > nommage (qui n'est pas la mienne mais ça, mon ego y survivra). Cette erreur > indique : > > Element | Tags | Erreur > -+--+--- > way 32599351 | building=yes | Mot absent du dictionnaire > | name=INSA Génie Electronique | (Electronique => Électronique) > > Dès le 10, j'ai édité la voie en question et j'ai corrigé le nom. La > correction apparaît bien dans l'historique de la « way » : > > http://www.openstreetmap.org/browse/way/32599351/history > > Mais Osmose semble ignorer cette correction et, aujourd'hui encore, il signale > l'erreur. Si les développeurs d'Osmose sont sur cette liste, pourraient-ils > jeter un oeil à ce cas suspect ? Je les en remercie par avance. Les extraits de geobabrik sont en pannes depuis hier... osmose a donc des données datant du 11 au soir. Le dernier extrait dispo avait toujours cette erreur. bzcat data-2009-06-12-10-01.osm.bz2 | grep -A 20 32599351 -- Etienne ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
