Issues reprojecting OGR layers from SQL Server

MapWinGIS
1

Hello All.

I am using the SQL Server driver to load OGR layers into MapWinGIS. The layers required reprojection, and I encountered a number of issues during this process. I will list the issues here, and create Atlassian/JIRA tickets to document the fixes. My intent is to fix each of these issues. Thank you.

  1. When not reprojecting-in-place, shapes and attributes are copied from the source Shapefile to the destination Shapefile. This process allows for the bypassing of Shapes that could not be reprojected, in which case the source row index will get out-of-sync with the target row index. This was properly coded for the Shapes, but when copying the Shapefile attributes, the source row index was being used for the target row, resulting in an out-of-range exception for the target row.
  2. Within ReprojectCore, while iterating the Shapes, a VARIANT_BOOL is used to capture the result of individual library calls (for example, EditInsertShape and EditCellValue). However, the value of the VARIANT_BOOL is never observed during the iteration, so it may be toggling both TRUE and FALSE, and whatever value it has at the end of the iteration is (inappropriately) used to determine the success or failure of the function. This method will be slightly restructured to properly capture success or failure.
  3. Shapefile.ReprojectInPlace calls ReprojectCore, handing in a nullptr for the Shapefile** parameter, and setting the reprojectInPlace flag = true. Every time the Shapefile** is referenced, it should be conditional, based on the value of reprojectInPlace being false. However, there is one call, ClearShapefileModifiedFlag, which is not called conditionally, and the library throws a Null Reference exception in this case.
  4. Shapefile.Reproject is called from MapView.ReprojectLayer. Following the call to ReprojectLayer, a comparison is made to see if the number of Shapes reprojected is equal to the number of Shapes in the original layer. If the number differs, the Reprojection is failed, and the function returns FALSE. So even though the Reproject method allows for failure of individual Shape conversions, the calling routine will reject the entire layer if there is even one bad record. I believe that we should allow a layer to be added to the map even if not all Shapes could be reprojected. Since this would be a change to the current map behavior, I would recommend a new Global Setting so that, at the programmers discretion, we allow layers to be added for which not all Shapes could be reprojected.
  5. The OgrLayer.ReloadFromSource call does not work properly on reprojected layers. Following the reload of the layer, the layer must again be reprojected. Otherwise its coordinates are no longer in the proper range, and it is no longer visible on the map.
2

Relating to bullet points 1, 2, and 3. These are resolved in MWGIS-147, Issues related to reprojection in Shapefile.ReprojectCore

3

Relating to bullet point 5. This has been resolved in MWGIS-148, Reloading a reprojected OGR layer from source causes layer to disappear

4

Relating to bullet point 4. This has been resolved in MWGIS-149, Allow adding layers to map that could not be completely reprojected

5

Since all bullets have been resolved I’m closing this issue.

@jerryfaust Thanks for taking the time to implement them.