Delphi MapWinGis OGR Issues

AlexBV · February 13, 2020, 4:03pm

Jerry,

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)…

Alex

jerryfaust · February 13, 2020, 6:40pm

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.

Notes:

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.
Can you tell me how PostGIS classifies the geometry types you are trying to load? (for example, PolylineZ, MultiPolygonZ)?
The MapWindow5 program uses this OCX, so any issues with the OCX will also be present there.
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.
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,
Jerry.

AlexBV · February 13, 2020, 8:45pm

Jerry,

My geometries are:
MultilineZM (Imported by the Postgis2.0 shape importer)
MultipolygonZM (Also Imported with the importer)
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

AlexBV · February 13, 2020, 9:12pm

public_11_cerca.zip (11.6 KB)

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

100cerca.zip (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)

Greetings…

Alex

jerryfaust · February 15, 2020, 7:44pm

Hello @AlexBV

I’m setting up PostGIS on my computer. One of the files you uploaded (public_11_cerca.zip) 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?

Thanks.

AlexBV · February 17, 2020, 2:28pm

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

AlexBV · February 17, 2020, 2:26pm

Camino.zip (602.5 KB) Andador.zip (1.1 MB)

jerryfaust · February 19, 2020, 6:42am

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?

Regards.

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

AlexBV · February 19, 2020, 11:18pm

Yes, I believe the are single part…

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

Cheers !!

jerryfaust · February 20, 2020, 4:45am

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.

?sf.Shape(0)
{MapWinGIS.ShapeClass}
    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

?sf.Shape(0).Point(0)
{MapWinGIS.PointClass}
    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.

jerryfaust · February 20, 2020, 4:49am

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.

AlexBV · February 20, 2020, 4:04pm

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 !!

Alex

jerryfaust · February 24, 2020, 12:19am

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

jerryfaust · March 17, 2020, 5:11am

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.

Regards,
Jerry.

AlexBV · March 20, 2020, 4:17pm

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

jerryfaust · March 21, 2020, 6:11am

Hello.

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

Jerry.

pmeems · July 31, 2020, 8:12am

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

AlexBV · July 31, 2020, 12:26pm

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

pmeems · July 31, 2020, 1:03pm

You’re right ECW support is still lacking. We’re waiting for https://github.com/gisinternals/buildsystem/issues/154 to be solved.

pmeems · September 29, 2020, 1:03pm

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