3liz
OSM name tag encoding
Helllo,
I am experiencing the same isuue as described here: https://github.com/3liz/QuickOSM/issues/39
Bug seems to be closed since 2015 so probably I am doing something wrong (I'm new to Qgis).
2021-12-01T14:35:47 INFO Query: natural_water
2021-12-01T14:35:47 INFO Encoded URL: https://lz4.overpass-api.de/api/interpreter?data=[out:xml] [timeout:25];%0A(%0A node[%22natural%22%3D%22water%22]( 42.31961,-8.00794,43.76536,-6.78239);%0A way[%22natural%22%3D%22water%22]( 42.31961,-8.00794,43.76536,-6.78239);%0A relation[%22natural%22%3D%22water%22]( 42.31961,-8.00794,43.76536,-6.78239);%0A);%0A(._;%3E;);%0Aout body;&info=QgisQuickOSMPlugin
2021-12-01T14:35:53 INFO Request completed
2021-12-01T14:35:53 INFO Checking OSM file content C:/Users//AppData/Local/Temp/request-IVhQgc.osm
2021-12-01T14:35:53 INFO The OSM file is: C:/Users//AppData/Local/Temp/request-IVhQgc.osm
2021-12-01T14:35:54 INFO Fixing geometries in layer: multipolygons
2021-12-01T14:35:54 INFO The OSM parser took: 00h 00m 01s
2021-12-01T16:08:57 INFO All OSM objects with the key 'natural'='water' in la extensión del lienzo o capa are going to be downloaded.
Environment
- QuickOSM version: 3.18.3
- QGIS version: 2.0.0
- OS: Windows 10
Thanks in advance
Hi there, Seems the bug has been fixed for point geometries but still persists for the other geometries.
Environment
QuickOSM version: 2.0.1
QGIS version: 3.16
OS: Windows 10
Can you send an OSM file ? (in this ticket, drag and drop) I can't replicate, I guess.
I doubt there is a difference between geometry types. The process is the same.
Hi there, Strangely, I can't reproduce it either, at least not all of it. Seems to be more complicated. I composed the query using the Quick Query feature. Yesterday it gave me bad character encodings in the "Name" column, today I reassembled it, it's ok. The funny thing is that I haven't even closed Qgis since yesterday. Today's result also has fewer columns. Also funny, when I run yesterday's saved query today, it gives me broken character encodings again. I used the same parameters yesterday to compose the query as I did today. There is a difference I can see as parts of today's query description are translated. Pretty weird.
Just save data layer encoded windows-1251. After save in layer properties set encoding UTF-8
I've had similar problem while using quickosm algorithms inside model. Adding "set layer encoding" after "string concatenation" fixed the problem.
Hello,
Thanks for the answers. Apologies for the delay in responding.
Attached fresh file, downloaded today.
I've had similar problem while using quickosm algorithms inside model. Adding "set layer encoding" after "string concatenation" fixed the problem.
Royas, Thanks but unfortunately I'm not at that level. I don't know what all that beautiful stuff is.
Best regards
Just save data layer encoded windows-1251. After save in layer properties set encoding UTF-8
I've tried and it's worse than before. Thank you anyway.
Thats resolve problem with encoding in last version QuickOSM:
-
Genarete request using QuickOSM
-
Result request
-
Save as usually result (Export layer-UTf8-save)
-
Solve problem. Save layer in 1251 encode. (Export layer-windows-1251-save)
-
Next in layer properties set UTF8
-
Result
Thats resolve problem with encoding in last version QuickOSM:
1. Genarete request using QuickOSM  2. Result request  3. Save as usually result (Export layer-UTf8-save)  4. Solve problem. Save layer in 1251 encode. (Export layer-windows-1251-save)  5. Next in layer properties set UTF8  6. Result 
I really appreciate your efforts to help me, but it doesn't work
Hello, I get the same problem on windows 11 but not on windows 10. I don't know if it's related but it looks like it depends on system environment. To get it work I choose Shapefile format to export data instead of geopackage (directly in QuickOSM UI in advanced) and then when I set to UTF-8 encoding in the layer properties of the layer it works. Be careful, use Shapefile will truncate fields name so you should take it into account on the rest of your workflow.
The bug is no more present in QGIS 3.24 Tisler!
Hello, I get the same problem on windows 11 but not on windows 10. I don't know if it's related but it looks like it depends on system environment. To get it work I choose Shapefile format to export data instead of geopackage (directly in QuickOSM UI in advanced) and then when I set to UTF-8 encoding in the layer properties of the layer it works. Be careful, use Shapefile will truncate fields name so you should take it into account on the rest of your workflow.
The bug is no more present in QGIS 3.24 Tisler!
Hello. Thanks for renponding. I did it always this way and problem persist. And I use 3.24.0 since it was launched. (Win 10)
This bug is still present in the last QGIS versions (3.24.0, 3.24.1, 3.24.2) and the latest QuickOSM.
I've researched the issue a little and found out that:
- issue happens on windows machines only;
- all the resulting osm-files always have the correct encoding - UTF-8 (at least in all my cases). But by an unknown reason QGIS interprets and opens some of them with ANSI encoding (and some of them with correct UTF-8, of course).
I really do not know if the developer of QuickOSM could force QGIS to open all the generated osm-files with UTF-8 encoding only. If no then it seems that we have to make a ticket for QGIS developers
Regards
This bug is still present in the last QGIS versions (3.24.0, 3.24.1, 3.24.2) and the latest QuickOSM.
I've researched the issue a little and found out that:
* issue happens on windows machines only; * all the resulting osm-files always have the correct encoding - UTF-8 (at least in all my cases). But by an unknown reason QGIS interprets and opens some of them with ANSI encoding (and some of them with correct UTF-8, of course).I really do not know if the developer of QuickOSM could force QGIS to open all the generated osm-files with UTF-8 encoding only. If no then it seems that we have to make a ticket for QGIS developers
Regards
Thanks for your comment and for pulling the request in Qgis.