Open issues pnorman's version

[roelderickx]

• ogr2osm misses some multipolygons in US National Park boundary shapefile pnorman/ogr2osm#56
  Duplicate of Multipolygon without inner do not assign tags pnorman/ogr2osm#47
• Multipolygon without inner do not assign tags pnorman/ogr2osm#47
  Resolved in the latest master branch, will be included in versions later than 1.0.0
• Not returning osm file in Mac pnorman/ogr2osm#46
  Possible duplicate of Error when trying to skip an object in translation pnorman/ogr2osm#24 and filterTags not returning pnorman/ogr2osm#9, won't fix without further information
• Making main flow importable pnorman/ogr2osm#45
  See README.md for more information
• Clarify the difference between rounding digits and significant digits pnorman/ogr2osm#44
  Added better description for both parameters
• add bounding box information pnorman/ogr2osm#42
  --add-bounds parameter added
• Inconsistent or missing use of addparent. pnorman/ogr2osm#40
• Request for duplicated points pnorman/ogr2osm#31
  See merge_tags translation method.
• python killed pnorman/ogr2osm#36
  Likely out of memory, files must be splitted up. Possible duplicate of Memory error pnorman/ogr2osm#19
• Shared borders represented as duplicated ways. pnorman/ogr2osm#28
  Because of the complexity a new issue has been created. See JOSM validation: merge duplicate geometries #7
• Error when trying to skip an object in translation pnorman/ogr2osm#24
  Duplicate of filterTags not returning pnorman/ogr2osm#9
• Switch encoding testcases to KML pnorman/ogr2osm#22
• Memory error pnorman/ogr2osm#19
• syntax error pnorman/ogr2osm#18
  Not applicable as it is related to a python version not supported in this fork
• utf-8 encoding xml output pnorman/ogr2osm#15
  A valid use case has been reported in issue Issues with encoding in windows batch #8
• Pass options to translation modules pnorman/ogr2osm#14
• filterTags not returning 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.