Delphi MapWinGis OGR Issues

MapWinGIS
1

Hello,
I am using Delphi RAD 10.1 Berlin

I can load shape layers… normally
I can load Images …normally
but…
Loading OGR layers something is going wrong:
The following sql statement:
sql := ‘select * from “db_db”.“public”.“layera”’;
with
Lay := Map1.AddLayerFromDatabase(ConnSt,sql,true) ;
or
layer := OGR.RunQuery(sql);
Lay := Map1.AddLayer(layer, true);

loads the records but they do not show in map, actual limits are set to 0 0 0 0

But if I use:
sql := ‘select st_buffer(geom, 0.0001), * FROM “db_db”.“public”.“layera”’;
loads and displays the data, with any of the methods described
…but I do not want buffers of the vectors, but the actual vectors to be able to edit etc.

Does anybody have a clue …??
Tanks
Alex

2

I do not know but forcing the data 2D worked fine…

sql := ‘select ST_Force2D(geom), * FROM “db_db”.“public”.“layera”’;

I need to keep my data 3D :thinking:

3

Hello @AlexBV

We need to divide and conquer, to figure out if the issue is with the OGR datasource, the data itself, Delphi (unlikely), or the OCX. We recently discovered a bug in the OCX related to 3D data, although that applied to disk-based Shapefiles. By the way, what is the OGR datasource?

One thing to try would be to load the layer into memory (do not yet add it to the Map) and then get the Shapefile version of the layer (using GetBuffer). Then try adding the resulting Shapefile to the map to see if it behaves any differently.

Then try saving the Shapefile to disk (using SaveAs). You can try loading it from disk, understanding that there may be issues related to load due to the bug. If you don’t mind posting the Shapefile, please do so, and I can try loading it to see what the result may be (I am currently running a version of the OCX with the bug fix, but I have not yet posted it).

Let’s start with these things and then decide where to go from there.

Kind regards,
Jerry.

5

Hello Jerry,
On first instance I could not load? or actually display any data to MapwinGIS Map… The nature of the data is 3D, which I believe is the main issue here.
So… the only way to do it was via the function like Buffer (which was 2d) or really force the load to be 2D.

So I believe that the ocx can not load any 3d data as it is (from OGR data source or data base source via OGR). This is not happening on 3d shape files…(as far as I tried), but I am not sure that their 3d integrity remains … since I’ve not been working long enough with the ocx (but I will extensively)

Alex

6

Jerry,
Reading your text…
I also tried loading the data, got the shapefile version… have same results !!

Alex

7

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

8

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:

  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,
Jerry.

9

Jerry,

  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

10

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

11

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.

12

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

Image1
Image1941×711 121 KB
Image2
Image2941×711 118 KB
Image3
Image3941×605 18.2 KB

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

Image4
Image4759×631 84.1 KB

I am sending you more data:

I hope these instructions can help you

Alex

13

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

14

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.

15

Yes, I believe the are single part…

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

Cheers !!

16

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.

image
image806×535 119 KB

17

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.

18

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

19

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

20

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.

21

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