Issues with SHP_POLYGONZ shapefile type

MapWinGIS
1

Hello,

I have 4 points in UTM coordinate system (UTM Zone 33, Northern Hemisphere).These four (the first and the last one are the same):
549340.837580, 5155906.01505, 12.1631324421
549352.704610, 5155906.62361, 5.94776381969
549348.444651, 5155914.53497, 0.0
549340.837580, 5155906.01505, 12.1631324421

I create a closed polygon (triangle) from those 4 points. The shapefile has only this one polygon.
Then reproject the shapefile to WGS84, and save it.
Attached is here: shapefile_polygonZ.zip (925 Bytes)

Shapefile type is MapWinGIS.ShpfileType.SHP_POLYGONZ.

Then I try to open this shapefile. I reproject it to UTM (UTM Zone 33, Northern Hemisphere), and start reading it. I get the following points of the shape:

549340.837580 5155906.01505 12.1631324421
549352.704610 5155906.62361 5.94776381969
549348.444651 5155914.53497 0.0
549340.837580 5155906.01505 0.0

The Z coordinate of the last point is incorrect - it is 0, instead of “12.1631324421”.

I tried testing this on polygons with more than 4 points, and noticed that this problem always appears. It’s either the Z coordinate of the first point that is not correct (equals 0) or the last point in the shape.

Is this a bug?

I tested on MapWinGIS “MapWinGIS-only-v5.1.1-x64-VS2015” and “MapWinGIS-only-v4.9.5.0-x64” versions and got the same problem.

The code is ironpython, so I am not sure how much of a help would it be.

I would be grateful for any kind of help or comment.

2

Hello @george

Here’s my initial answer, but I’ll have to dig a little deeper.

  1. It looks like the Shapefile::Reproject transforms the X and Y only, and simply leaves the Z alone, which should mean that the Z is retained through transformations. But this would also mean that your Z coordinate would have been inappropriate when in the WGS coordinate system (still being meter values).
  2. It looks like using the Utils::ReprojectShapefile would have dropped the Z’s altogether in the new shapefile, so they would have all become zero.

I’ll have to consider why we don’t transform the Z also, and also why you are losing only the last Z.

I’ll get back to you,
Jerry.

@pmeems, Do you know why we are only transforming the X and Y. Should we make a change to transform the Z as well?

3

Hi @jerryfaust,

Thank you for the quick reply.
For the reprojection I am using Shapefile.Reproject as per your recent reply.

4

I believe that I’ve found the problem.

There is a bug in the OCX when reading a Shapefile from disk. When reprojected in memory, the data was fine. But after saving to disk and reloading, the last Z coordinate is bypassed, and left at zero.

I will write up a ticket and submit a change. Do you build your OCX from source code, or are you using the most recent development build?

5

Thank you for the quick finding of the issue Jerry!
I download the latest development build from github.

6

Thank you for reporting the issue.

We sometimes put out interim builds to make certain fixes available without having to wait for the next formal build. I think we can do that in this case. I’ll let you know when it’s available.

It may be a couple days.

Regards,
Jerry.

1 Like
7

Hi @jerryfaust,
I hope this message finds you in good health in these troublesome times.

I was just wondering: has this bug with MapWinGIS.ShpfileType.SHP_POLYGONZ ever been fixed?

8

Hello George.

Yes, it has been fixed

[MWGIS-217] - Loading POLYGONZ Shapes from disk-based Shapefile drops final Z’s

and is in the current release v5.2.4

Regards,
Jerry.

[And yes, my family and I are well, Thank you.]

1 Like
9

Hi Jerry,
Thank you very much for this!!
Glad to hear you and your family are fine.