Open issues pnorman's version

[roelderickx]

• [x] pnorman/ogr2osm#56 Duplicate of pnorman/ogr2osm#47
• [x] pnorman/ogr2osm#47 Resolved in the latest master branch, will be included in versions later than 1.0.0
• [x] pnorman/ogr2osm#46 Possible duplicate of pnorman/ogr2osm#24 and pnorman/ogr2osm#9, won't fix without further information
• [x] pnorman/ogr2osm#45 See README.md for more information
• [x] pnorman/ogr2osm#44 Added better description for both parameters
• [x] pnorman/ogr2osm#42 --add-bounds parameter added
• [x] pnorman/ogr2osm#40
• [x] pnorman/ogr2osm#31 See merge_tags translation method.
• [x] pnorman/ogr2osm#36 Likely out of memory, files must be splitted up. Possible duplicate of pnorman/ogr2osm#19
• [x] pnorman/ogr2osm#28 Because of the complexity a new issue has been created. See #7
• [x] pnorman/ogr2osm#24 Duplicate of pnorman/ogr2osm#9
• [x] pnorman/ogr2osm#22
• [x] pnorman/ogr2osm#19
• [x] pnorman/ogr2osm#18 Not applicable as it is related to a python version not supported in this fork
• [x] pnorman/ogr2osm#15 A valid use case has been reported in issue #8
• [ ] pnorman/ogr2osm#14
• [x] pnorman/ogr2osm#9 Returning None in filter_tags will drop the object

[roelderickx]

pnorman#56

@mr-greenjeans +1 for the completeness of your bug report and the investigation you have done already. Thanks! You correctly identified a bug and it will be fixed in the next version, which will be in this fork since maintenance has ceased on pnorman's version. I will think about a good way to implement the fix, your patch is technically correct but it is not the most elegant solution.

[roelderickx]

pnorman#47

@joaokho After closer inspection this turns out to be the same issue as above. Thanks for reporting!

[roelderickx]

pnorman#22

I am not sure if the encoding can be detected for any ogr datasource, if it is not UTF-8 it must be specified by the encoding parameter. Ogr2osm will then try to interpret the file with the given encoding, it is up to the user to know or guess how the source file is encoded. Even though the standard for shapefiles is Latin-1 it is possible to create such a file with any other encoding. However, for KML files this is not possible, the driver included in GDAL can only handle UTF-8 no matter how the encoding is defined on the first line. Because human-readable source files are preferable over binary shapefiles and KML is not an option, the encoding testcases have been replaced by geojson files, for which GDAL accepts any encoding.

[grischard]

Hey, I'd given up hope on some of these. Many thanks, @roelderickx! This will be very helpful.