Fix issue in sentinel 2 metadata where 0 z coordinates are listed.

[lossyrob]

There are some product metadata files that contain 0 z coordinate values in the product metadata that is used to construct STAC Item geometries. This causes the Item geometry to be invalid. This change modifies the parsing logic to filter out '0' string values in the coordinates to avoid this issue.

[codecov-commenter]

Codecov Report

Merging #122 (6ebd129) into master (e1fcbff) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #122   +/-   ##
=======================================
  Coverage   85.26%   85.26%           
=======================================
  Files          82       82           
  Lines        2463     2463           
=======================================
  Hits         2100     2100           
  Misses        363      363           

Impacted Files	Coverage Δ
..._sentinel2/stactools/sentinel2/product_metadata.py	91.01% <ø> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e1fcbff...6ebd129. Read the comment docs.

[gadomski]

Looks good as is, I have three questions mostly for my own education:

• Is there chance of a boundary granule footprint that includes 0 as a x or y value that could get caught by the added check?
• Are 3D geometries useful? Could this be solved by only supporting 2D?
• Does one of the test files include the bogus z value?

[lossyrob]

Is there chance of a boundary granule footprint that includes 0 as a x or y value that could get caught by the added check?

Looking at the precision of the other x/y values, I don't believe so, but could not guarantee it. I found it difficult to find documentation on this part of the sentinel product metadata, so there's some assumptions made here.

Are 3D geometries useful? Could this be solved by only supporting 2D?

The example I found had all 0 values for z, which is common in a bug I've seen elsewhere where the default z values are printed out unintentionally. I have a hunch that a similar issue happened here with some scenes printing the default. I couldn't find documentation of meaningful Z footprint values.

Does one of the test files include the bogus z value?

The added test case reads an example product metadata file that was found to have the bogus Z values.

[gadomski]

Roger, that all sounds good to me. Once CI passes I can merge. Thanks!