-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issues with encoding in windows batch #8
Comments
Thanks for your bug report. This issue looks like a duplicate of pnorman#15 but your solution is different and you have found a testcase where the current method has issues. Some observations:
Given the last observation ogr2osm is supposed to output UTF-8 at the moment, eventually translating from the input file encoding if necessary. To obtain consistent behaviour across different operating systems it is as such necessary to pass I can confirm the testcases still pass on Linux with your suggested modification. Can you verify if the testcases pass under Windows as well? |
Thanks for the fast answer!
After making these changes everything runs smooth in the batch. |
Ok. I am not sure if the cram tests can be run as is under Windows, but can you try to convert at least test/shapefiles/japanese.shp and confirm if the formatted result matches test/japanese.xml? In the test script the output is formatted using xmllint before comparing:
|
Meanwhile I managed to test the modification in Windows, the test is conclusive. The proposed changes have been merged into master. |
Hi,
I was trying to use ogr2osm in a windows batch but had a lot of encoding problems, because the batch always created ANSI-encoded files, but my workflow needs utf-8 encoded files. I managed to solve my issue by changing the following line:
self.f = open(self.filename, 'w', buffering = -1)
to
self.f = open(self.filename, 'w', buffering = -1, encoding="utf-8")
there is already a parameter called "encoding" but it seems it is only used for the source file, could we extend this "encoding" to be used in the destination file as well? or could we introduce another parameter for that? what are your thoughts? or do you have a tip how I can force the windows batch to output utf-8 without changing ogr2osm?
thanks for this awesome tool =)
The text was updated successfully, but these errors were encountered: