Re: [OSM-dev-fr] Conversion en batch de fichier OGR vers OSM...

[Philippe Verdy]

Cette page ne parle que de l'encoding, tel que défini dans une
bibliothèque de base Python. Elle ne parle pas des objets "chaines de
caractères" qui sont triatés en interne par Python. Ma remarque était
juste car tu disais "Python utilise en interne" ce qui est faux
justement car en interne il est totalement neutre au regard des
encodages et ne vot ces chaines QUE comme des chaines d'octets sans
rien imposer de plus.

Ce qui fait alors que justement Pythin peut travailler avec des tas de
codages différents, y compris incompatibles avec Unicode, et même
manipuler des fichiers binaires comme des images bitmap au sein même
de ses chaines, ou via ses API I/O. En cela Python n'est pas différent
non plus de C/C++, Java, PHP, Javascrript, etc

Et ce n'est donc pas un "problème" comme tu le dis, mais plutôt une
fonctionnalité qui le rend très versatile (mais alors il faut faire
attention aux APIs utilisées qui peuvent ou non imposer un encodage
particulier si on doit les utiliser pour traiter du texte). Quand àç
son langage de programmation, il offre quelques facilités syntaxiques
pour Unicode mais c'est lié au compilateur, pas au traitement interne
à l'exécution.

(Notes: Javascript est un peu particulier car il n'a pas d'objet
"chaine d'octets" mais juste "chaine de mots 16-bits" ; Java n'a pas
directement de "chaines" d'octets mais sait gérer des "ByteBuffers"
dans des tableaux d'octets signés, alors que son type String est à la
base un tableau de mots 16-bits non signés, eux aussi non restreints à
l'Unicode seul ; un problème de Java est cependant que son type
"String" est malheureusement déclaré "final" donc non dérivable en une
sous-classe pour éviter d'avoir à suivre l'encodage utilisé dans les
APIs dans une variable séparée, avec poir conséquence que toutes les
conversions d'encodage doivent être explicités à chaque fois).

Le 28 mars 2013 23:13, Sylvain Maillard  a écrit :
> http://docs.python.org/2/howto/unicode.html
>
> "Encodings don’t have to handle every possible Unicode character, and most
> encodings don’t. For example, Python’s default encoding is the ‘ascii’
> encoding. The rules for converting a Unicode string into the ASCII encoding
> are simple; for each code point:
>
> If the code point is < 128, each byte is the same as the value of the code
> point.
> If the code point is 128 or greater, the Unicode string can’t be represented
> in this encoding. (Python raises a UnicodeEncodeError exception in this
> case.)"
>
> => ça ressemble quand même vachement au problème initial ...
>
> Il s'agit peut-être d'un problème d'api au sein de python, je n'ai pas été
> regarder, mais le résultat est le même : tout appel à un module qui n'est
> pas explicitement écrit de manière à gérer l'unicode, utilisera l'encodage
> par défaut qui est l'ascii et générera ce genre d'erreurs !

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Conversion en batch de fichier OGR vers OSM...

[Sylvain Maillard]

http://docs.python.org/2/howto/unicode.html

"Encodings don’t have to handle every possible Unicode character, and most
encodings don’t. For example, Python’s default encoding is the ‘ascii’
encoding. The rules for converting a Unicode string into the ASCII encoding
are simple; for each code point:

   1. If the code point is < 128, each byte is the same as the value of the
   code point.
   2. If the code point is 128 or greater, the Unicode string can’t be
   represented in this encoding. (Python raises a
UnicodeEncodeErrorexception
in this case.)"

=> ça ressemble quand même vachement au problème initial ...

Il s'agit peut-être d'un problème d'api au sein de python, je n'ai pas été
regarder, mais le résultat est le même : tout appel à un module qui n'est
pas explicitement écrit de manière à gérer l'unicode, utilisera l'encodage
par défaut qui est l'ascii et générera ce genre d'erreurs !


Sylvain


Le 28 mars 2013 21:10, Philippe Verdy  a écrit :

> Le 28 mars 2013 17:36, Sylvain Maillard  a
> écrit :
> > Salut,
> >
> > oui, ce problème est clairement lié à l'encodage des caractère !
> > En interne Python 2 utilise par défaut l'ascii
>
> Faux, Python en interne n'utitile que des chaines d'octets sans savoir
> rien de plus sur le codage, ni me^me si cela contient effectivement du
> texte. Ce support des encagages est apporté par les librairies Python
> selon leur propre API et l'usage qu'elle font de ces chaines d'octets.
>
> Pytonh gère aussi des chaines dites "Unicode" sauf que ces chaines
> n'ont aucune obligation à être réellement codées selon Unicode, mais
> juste fr pouvoir coder un caractère Unicode dans une position unique.
> Dans les faits Pythin utilise alors pour cela en interne des chaines
> de mots 32-bits. Il peut aussi gérer des chaines de mots 16 bits.
>
> Il faut aussi distinguer ce que fait Python en interne dans le moteur
> de sa VM, de sa syntaxe de programmation qui elle ne dépend pas de
> Python lui-même mais d'une API aussi, celle de son analyseur
> lexico-syntaxique qui soumet ses analyses à son compilateur. Là encore
> ne pas confondre le langage de programmation avec ce pourquoi il est
> utilisé dans une application.
>
> Ces remarques ne sont pas spécifiques à Python, on les retrouve aussi
> dans d'autres langages (compilés ou non) : C/C++, Java, C#, PHP,
> JavaScript/ECMAScript (ne pas confondre Javascript avec HTML qui a ses
> propres spécifications en terme de codage, ce que n'a pas Javascript
> lui-même qui en est séparé)...
>
> Bref ne pas tout mélanger
>
> ___
> dev-fr mailing list
> dev-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev-fr
>
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Conversion en batch de fichier OGR vers OSM...

[Philippe Verdy]

Le 28 mars 2013 17:36, Sylvain Maillard  a écrit :
> Salut,
>
> oui, ce problème est clairement lié à l'encodage des caractère !
> En interne Python 2 utilise par défaut l'ascii

Faux, Python en interne n'utitile que des chaines d'octets sans savoir
rien de plus sur le codage, ni me^me si cela contient effectivement du
texte. Ce support des encagages est apporté par les librairies Python
selon leur propre API et l'usage qu'elle font de ces chaines d'octets.

Pytonh gère aussi des chaines dites "Unicode" sauf que ces chaines
n'ont aucune obligation à être réellement codées selon Unicode, mais
juste fr pouvoir coder un caractère Unicode dans une position unique.
Dans les faits Pythin utilise alors pour cela en interne des chaines
de mots 32-bits. Il peut aussi gérer des chaines de mots 16 bits.

Il faut aussi distinguer ce que fait Python en interne dans le moteur
de sa VM, de sa syntaxe de programmation qui elle ne dépend pas de
Python lui-même mais d'une API aussi, celle de son analyseur
lexico-syntaxique qui soumet ses analyses à son compilateur. Là encore
ne pas confondre le langage de programmation avec ce pourquoi il est
utilisé dans une application.

Ces remarques ne sont pas spécifiques à Python, on les retrouve aussi
dans d'autres langages (compilés ou non) : C/C++, Java, C#, PHP,
JavaScript/ECMAScript (ne pas confondre Javascript avec HTML qui a ses
propres spécifications en terme de codage, ce que n'a pas Javascript
lui-même qui en est séparé)...

Bref ne pas tout mélanger

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Conversion en batch de fichier OGR vers OSM...

[Sylvain Maillard]

Salut,

oui, ce problème est clairement lié à l'encodage des caractère !
En interne Python 2 utilise par défaut l'ascii, du coup si le module
utilisé (ou un module appelé) ne gère pas correctement les chaîne en
unicode, il y a fréquemment ce genre de crash ...

Donc soit comme le propose Pieren tu modifie le script pour qu'il utilise
le latin1 à la place d'utf8, soit tu t'arrange pour avoir tous tes fichiers
d'entrée en utf8 ... en tout cas sur une conversion par lot j'espère que
tous les fichiers utilisent le même encodage !

Sylvain



2013/3/28 Pieren 

> 2013/3/28 Christian Quest :
>
> > UnicodeDecodeError: 'utf8' codec can't decode byte 0xe0 in position 0:
> > unexpected end of data
>
> Peut-être que ça peut t'aider:
> http://lists.openstreetmap.org/pipermail/imports/2012-March/001233.html
>
> Pieren
>
> ___
> dev-fr mailing list
> dev-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev-fr
>
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Conversion en batch de fichier OGR vers OSM...

[Pieren]

2013/3/28 Christian Quest :

> UnicodeDecodeError: 'utf8' codec can't decode byte 0xe0 in position 0:
> unexpected end of data

Peut-être que ça peut t'aider:
http://lists.openstreetmap.org/pipermail/imports/2012-March/001233.html

Pieren

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

[OSM-dev-fr] Conversion en batch de fichier OGR vers OSM...

[Christian Quest]

Quel est le moyen le plus propre pour convertir un gros lot de
fichiers ouvrables par gdal/ogr en fichiers osm ?

Tout est ici ? http://wiki.openstreetmap.org/wiki/Import/Shapefile

J'ai testé ogr2osm et ça semble fonctionner sur mon Mac à un petit
souci près au milieu de la conversion d'un fichier:


Traceback (most recent call last):
  File "ogr2osm.py", line 741, in 
w.element("tag", k=tagKey.decode("utf-8"), v=tagValue.decode("utf-8"))
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/encodings/utf_8.py",
line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xe0 in position 0:
unexpected end of data


Les fichiers sont en EDIGEO ;)

-- 
Christian Quest - OpenStreetMap France
Synthèse du Week-end "SOTM-FR" à Lyon : http://openstreetmap.fr/synthese-sotmfr

___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr