Projection recognition between MapInfo and QGIS
Opened this issue · 0 comments
Issue raised
The problem is the following : MapInfo uses a trick to distinguish between various Lambert 93 projections using different bounds.
The issue is to find out if an elegant solution can be found to solve this problem, and implement a general solution, or if we resort to implementing the mapinfo trick.
Hereafter is a detailed use case for this bug. It is linked to #1, #2 and #3.
Use case
Here is an example of using the bounds patch, and explanations leading to this bug entry.
We first set the MITAB_BOUNDS_FILE to a file containing the projection description using bounds.
In this use case, and the original need, the projections used are either the initial MapInfo projection without bounds, or the projection with european bounds. All data use the Lambert 93 projection (no Lambert I/II/III)
In the Mapinfo projection files given by Pytney Bowes for MapInfo V11.0, the following projections definitions are given :
"--- Systèmes de coordonnées français ---" "Lambert-93 français", 3, 33, 7, 3, 46.5, 44, 49, 700000, 6600000 "Bounded French Lambert-93", 2003, 33, 7, 3, 46.5, 44, 49, 700000, 6600000, 75000, 6000000, 1275000, 7200000
We can find a bit later in that file the following definitions, probably added by PBBI France :
"--- Systèmes français RGF93 - Méridien de Greenwich (non borné) ---" "France Lambert-93 (non borné)\p2154", 3, 33, 7, 3, 46.5, 44, 49, 700000, 6600000 "--- Systèmes français RGF93 - Méridien de Greenwich (Borne Europe) ---" "France Lambert-93 (Borne Europe)\p2154", 2003, 33, 7, 3, 46.5, 44,49.00000000001, 700000, 6600000, -792421, 5278231,3520778, 9741029 "--- Systèmes français RGF93 - Méridien de Greenwich (Borne France) ---" "France Lambert-93 (Borne France)\p2154", 2003, 33, 7, 3, 46.5, 44,49.00000000002, 700000, 6600000, 75000, 6000000, 1275000, 7200000
As we can see in the last two definitions, the last number of one of the projection parameter differs ( 1 in the first definition, 2 in the second).
Note that MapInfo uses the file from top to bottom, therefore the EPSG2154 projection is associated to the first entry : 'Systèmes français RGF93 - Méridien de Greenwich (non borné)'
If we look at the MapInfow.prj used by the french environment ministry, the projections definitions are the following :
"--- Systèmes français RGF93 - Méridien de Greenwich (Borne France) ---" "France Lambert-93 (Borne France)", 2003, 33, 7, 3, 46.5, 44, 49.00000000002, 700000, 6600000, 75000, 6000000, 1275000, 7200000 "--- Systèmes français RGF93 - Méridien de Greenwich (Borne Europe) ---" "France Lambert-93 (Borne Europe) -recommandé \p2154", 2003, 33, 7, 3, 46.5, 44, 49.00000000001, 700000, 6600000, -792421, 5278231,3520778, 9741029 "--- Systèmes français RGF93 - Méridien de Greenwich (Non Borné) ---" "France Lambert-93 (Non Borné)", 3, 33, 7, 3, 46.5, 44, 49, 700000, 6600000
In this case the EPSG2154 code is associated to the 'France Lambert-93 (Borne Europe) -recommandé' projection.
Note that when using non-bounded projection, the precision is 10cm and 1mm when using Europe bounds.
Example 1 : exporting a L93 point in non-bounded projection
We focus on a specific point : (200 000, 6800 000)
Mapinfo cannot create this point, and replace it with (1999 999.9, 6 800 000.0). This is coherent with the maximum precision that MapInfo is able to use with a non-bounded projection. The X coordinate (200 000) cannot be represented.
The following bounds are used in that case by MapInfo :
After applying patches #1 and #2 to MiTAB/OGR/QGIS, we load the POINTL93NB.TAB file.
The correct projection recognised by QGIS is EPSG:2154 - RGF93/Lambert 93.
The point coordinates in QGIS are (199 999.9, 6 800 000)
We then save the table as SHP, keeping the projection, and re-open it in QGIS.
We create a point at (200 000, 6 800 000).
The MITAB_BOUNDS_FILE environment variable is not set.
We save this table as TAB format, with Lambert 93 projection.
We open it with MapInfo
The correct projection is recognised, and the bounds are :
These bounds are OGR/MiTAB default for Lambert 93.
Zooming in with MapInfo shows different locations for the points :
Coordinates of the points as shown in Mapinfo :
- initial Mapinfo point converted by QGIS : (199 999.9002, 6 800 000.000)
- Initial Mapinfo point : (199 999.9, 6 800 000.0)
- point created with QGIS : (199 999.9996, 6 800 000.000)
We now activate the bounds option on QGIS, setting the environment variable MITAB_BOUNDS_FILE, and set the bounds to the values used by MapInfo for non-bounded projection.
When opening the data, the 3 points are at the exact same location.
Example 1 conclusion : exporting in non-bounded L93 with QGIS, activating the custom bounds and using MapInfo values for those bounds when using QGIS keeps all settings coherent and use MapInfo initial precision.
Example 2 : exporting a point to L93 with Europe bounds
We use L93 with Europe bounds, therefore having a precision of 1mm for the coordinates.
We create a point at (199 999.999, 6 799 999.999)
The bounds are :
We then save the file, and open it with QGIS, then saving it using the bounds corresponding to Mapinfo's Europe bounds given above.
In that case, the projection is not recognised by QGIS, because MapInfo uses the last decimal trick of the projection parameter to distinguish among the different projection variants.
First, we save a file with original SCR. When opening the file with Mapinfo, the projection is not recognised. The first entry in the mapinfow.prj file is chosen by Mapinfo, with the following bounds :
Then we try with the file saved from QGIS with L93 projection. In that case, the projection identified by MapInfo is non-bounded L93. However the bounds in the Mapinfo table are the Europe bounds, and the point is at the same location than the original point.
Example 2 summary : Exporting from QGIS in L93 with Europe bounds, activating «Europe bounds» in QGIS, respects the initial MapInfo precision. When exporting from QGIS, it is however necessary for the user to indicate L93 as a projection, and Mapinfo recognizes it only as non-bounded projection.
Further thoughts
The process described can be disturbing for the user, as he opens a table in Mapinfo in L93, which will be identified as non-bounded whereas the bounds are actually Europe bounds.
Most user do not know how to use the bound manager in Mapinfo, and it would be a real improvement to be able to correctly detect the Mapinfo projection.