Issues with SHP_POLYGONZ shapefile type


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: (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.

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,

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

Hi @jerryfaust,

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

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?

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

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.


1 Like

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?

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


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

1 Like

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