Dynamic loading of feature layers and editing

MapWinGIS
1

Hello community :wink:

I was wondering what the technical constraints are for not allowing feature editing when dynamic loading is enabled? Is this something which could be overcome?

Second related question: is dynamic loading currently working? When loading data from a MSSQL database, I often do not see my features on the map, despite the feature count (in the properties tab) correctly being set, and when debugging mapwingis it does seem to load the features in memory.

cheers,
Mathijs

2

Hello @Mathijs.Dumon

I’ll start by saying that I’ve not used Dynamic Loading before, so I would have to set up a test to debug it.

I see nothing in the StartEditing code that bails out if Dynamic Loading is enabled. As you may already know, here are the general rules regarding OGR Layer Editing.

Do you get any errors or does is just fail to save your edits?

As far as whether or not it is working - that you often do not see your features, do you consistently see the features if Dynamic Loading is disabled?

Regards.
Jerry.

3

Hi @jerryfaust

Thanks for the quick reply,

Just to clarify - I’m testing this using mapwindow 5 - when a layer is dynamically loaded I cannot toggle the editing state (using the pencil button). I get a message box stating ‘Editing of dynamically loaded OGR layers isn’t allowed.’ This is a check made by MapWindow5 (in LayerEditingService.cs) - you seem to suggest it is actually possible to edit dynamically loaded features?

As such I can not get errors (since I can’t start editing my shapes).

And yes, I can consistently see and edit my features when dynamic loading is disabled.

thanks for the help!

4

Hi @jerryfaust

I just tested this on PostGIS and dynamic loading works. It seems this is a SQLServer problem. Maybe GDAL driver related. Or perhaps because of the issues you reported relating to projection mismatch (Issues reprojecting OGR layers from SQL Server)?

cheers,
Mathijs

5

Hello there again!

I’ve been going through this step by step and found that if I change line 43 from OgrLayer.cpp from this:
get_Extents(&extents, VARIANT_FALSE, &vb);
to this:
get_Extents(&extents, VARIANT_TRUE, &vb);

dynamic loading works on SQLServer layers

I find it weird that dynamic loading still works for PostGIS, since that change should also affect it. Perhaps I’m missing something elsewhere.

In any case, it has to do something with the extent of the layer not loading properly.

6

After looking at the drivers for MSSQLSpatial and comparing with PostGIS I found the pg drivers override the GetExtents method of the GDAL OGRLayer class. In there, a version-specific extents query is made, regardless of the bForce flag.

The MSSQLSpatial driver does not override the GetExtents method. When bForce is true, the default implementation will load all features and then calculate the extents using the internal GDAL methods.

I think it’s better to pass VARIANT_TRUE to the get_Extents call mentioned in my previous post, since there might be other drivers as well that do not override the generic implementation. Since this is done only once, the performance hit is minimal IMO.

I’m working on an improvement for MSSQL spatial driver, but in the mean time: shall I make a pull request?

7

Yes, I think so. It is interesting that the GDAL call to OGRLayer GetExtent, which we are calling, will default the ‘bForce’ parameter to TRUE, so it seems appropriate that our default be the same, rather than overriding their default.

virtual OGRErr GetExtent(OGREnvelope *psExtent, int bForce = TRUE);

And it appears that InitOpenedLayer will be called once after loading/opening the layer, so there is not repeated overhead.