Delphi MapWinGis OGR Issues


I am now trying to load the data using the Desktop MapWindow V5 and seems to have same problem with the 3d data…comming from Postgres (Postgis)…


Hello Alex. Thanks for your response.

I would very much like to get to the bottom of this. The OCX “should” handle the 3D (2.5D) data, so if there is a breakdown somewhere, I would like to get it resolved.


  1. We rely on the GDAL driver for PostGIS for data retrieval and conversion. I believe that should be a robust driver, so I don’t expect any issues there.
  2. Can you tell me how PostGIS classifies the geometry types you are trying to load? (for example, PolylineZ, MultiPolygonZ)?
  3. The MapWindow5 program uses this OCX, so any issues with the OCX will also be present there.
  4. The Shapefile created by the GetBuffer command should not drop the Z values - they should still be present. Would you mind posting the Shapefile to this site? That would help me to analyze the problem. You should be able to just drag/drop it onto this post.
  5. Although I don’t use PostGIS, I use MS SQL Server quite a bit, and I should be able to set up a test

Thank you,


  1. My geometries are:
    MultilineZM (Imported by the Postgis2.0 shape importer)
    MultipolygonZM (Also Imported with the importer)

  2. I can not import the OGR layer as 3d. Actually … If I ask sf.NumShapes gives correct Nr of shapes, but sf.Extents are (0.0 0.0 0.0 0.0)
    If I export sf.SaveAs (‘d:\0export\export2.shp’, cB); it exports an empty shape file.

If I load the OGR as 2d with 'select ST_Force2D(geom), * FROM …etc then I get the shapefile correct (in 2d), so If I export it , I get a shapefile with Polylines only.

Probably what you need is a 3d shapefile, and import it to Postgis using the importer as I did to create a small Postgres db …and make tests from there…

Alex (11.6 KB)

These are 100 records of the 3d table… I do not know if you can import it somehow… (11.9 KB)

This is the shapefile…3d

If you import it as shape file it will import it fine… (the problem is the ogr import)



Hello @AlexBV

I’m setting up PostGIS on my computer. One of the files you uploaded ( does not unzip (invalid). Is that the one I will want to import into PGis? Or will it be easy enough to import the Shapefile?

Follow-up: I found the PostGIS Shapefile Importer, but it is failing to import 100cerca.shp. Any special settings or something I should know?


Hi Jerry

I had those problems before, jaja !!

First you have to create a database using the manager or via sql:
createdb createdb2 createdb3
Important thing is encoding UTF8

Then you have to load the postgis extension via the manager or sql

Then you load the Importer, select the files to import and run. Important thing here is to put the SRID 32614 (UTM Z14 N)

I am sending you more data:

I hope these instructions can help you

Alex (602.5 KB) (1.1 MB)

Hello again.

Ok, so I can duplicate the error. I tried both the 100cerca and the camino tables in PostGIS (imported from shapefiles). When I open them as OgrLayers in MapWinGIS, I get a ShapeType of SHP_NULLSHAPE. So next I will have to debug into the code to determine if the breakdown is in GDAL or in MapWinGIS.

I’ll let you know what I find.

My feeling is that it is not a problem with 3D, but with the MultiLineString type. Are the geometies acually multipart-linestrings, or are they all actually single-part polylines? Could they be converted to single-part polylines?


EDIT: I also tried importing with the Option “Generate simple geometries instead of MULTI geometries” and the problem still exists.

Yes, I believe the are single part…

Remember that Importing with query forcing 2d works fine…(I do believe is the 3D)

Cheers !!

Hello @AlexBV

The OCX is prepared for well-known Shape Types such as wkbLineString, and wkbLineString25D (which would contain Z-values), but it is not coded to accept wkbLineStringZM, which is what is being returned by PostGIS (and likely returned by many other OGR Data sources).

So as a test, when the code was checking for shape type wkbLineString25D, I added a check also for wkbLineStringZM, and it successfully loaded the Shapefile as a POLYGONZ shape type.

Here’s a quick look in the immediate window of the Shape(0), and Point(0) of Shape(0). You can see that we have a POLYGONZ layer that includes Z-values.

    Area: 0
    Center: {MapWinGIS.PointClass}
    Centroid: Nothing
    Extents: {MapWinGIS.ExtentsClass}
    GlobalCallback: Nothing
    InteriorPoint: {MapWinGIS.PointClass}
    IsEmpty: False
    IsValid: True
    IsValidReason: ""
    [Key]: ""
    LastErrorCode: 29
    Length: 2.6834364485418587
    NumParts: 1
    Perimeter: 0
    ShapeType: SHP_POLYLINEZ {13}
    ShapeType2D: SHP_POLYLINE {3}
    numPoints: 2

    GlobalCallback: Nothing
    [Key]: ""
    LastErrorCode: 0
    M: 0
    Z: 2251.7454182142378
    x: 479553.23742459458
    y: 2190808.2159989206

And here’s a screenshot of my little test app, zoomed in a couple clicks.

So, my current interpretation is that the OCX has not kept up with the various Shape types that can be returned from an OGR datasource. That may or may not be true.

Moving forward from here, I think we need to review the various Shape types that may be returned and make sure that we properly interpret and unpack them. It may well be that some of them cannot currently be supported, but I suspect that some of them can - we just have to code for them.

LinestringZM is a really old data structure … as far as I remember

I do not know why the importer converts elements to ZM. Originally the elements where linestring25D as you mentioned. Anyway, in the mean time it would be good thing to publish the ocx that handles this check.

On the other hand (subject form other conversation) I hope the issue of the ecw images get solved as well.

Thank you for you patience !!


Just FYI, I’ve created a ticket on Atlassian, MWGIS-218, representing the update that will take place.

Hello again.

I have submitted Jira ticket MWGIS-218, which I consider the first phase implementation of compliance with ISO SQL/MM Part 3 geometry types (inasmuch as can be complied within a Shapefile).

If you are able to get the latest ‘develop’ branch and build, please do so. If you are not able to, let us know and I will see if we can make an interim build available.


Unfortunatelly I am using the ocx. Can you build new ocx for us ?


I’m going to check in a fix for an unrelated bug, and I’ll do a new ‘dev’ build this weekend.


Did you try with the latest OCX?
Is it solved now?

ecw images not supported jet… I will test for other issues… Thanks !!

You’re right ECW support is still lacking. We’re waiting for to be solved.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.