Maps icon indicating copy to clipboard operation
Maps copied to clipboard

Coordinate precision issue

Open mwjames opened this issue 4 years ago • 3 comments

Setup and configuration

{
    "SMWSQLStore": {
        "mysql": "10.4.11-MariaDB"
    },
    "smw": "3.2.0-alpha",
    "mediawiki": "1.34.0",
    "php": "7.4.1"
}

Maps | 7.15.6

Issue

  1. Adding a wiki text annotation with [[Geographic coordinates::40.71449, -74.00713]] (with a discrete precision). For context, those data are imported and not something that can be changed.

  2. Data stored in the smw_di_coords table appears as:

s_id p_id o_serialized o_lat o_lon  
303179 303186 40.71449,-74.00713 40.71449 -74.00713
  1. Building a DataValue representation for the above item will return 40° 42' 52.16" N, 74° 0' 25.67" W in zero degree mark format.

  2. Now, when used as part of a query, {{#ask: [[Geographic coordinates::40° 42' 52.16" N, 74° 0' 25.67" W]] ...}} no results will return because those coordinates are transformed into o_lon = '-74.007130555556' and o_lat = '40.714488888889 which has a different precision than the data stored in (1).

So, the issue here is that [[Geographic coordinates::40.71449, -74.00713]] turns into [[Geographic coordinates::40° 42' 52.16" N, 74° 0' 25.67" W]] which when used as part of a query will have a different precision than the original stored data.

Part of the actual SQL query:

AS t12 ON t2.s_id=t12.s_id INNER JOINsmw_di_coordsAS t15 ON t2.s_id=t15.s_id) ON t0.smw_id=t2.s_id WHERE (t2.o_id='303185' AND (t4.p_id='303180') AND (t7.p_id='303186') AND (t9.p_id='303182') AND (t12.p_id='303180' AND t12.o_id='303179') AND ((t15.o_lat = '40.714488888889' AND t15.o_lon = '-74.007130555556') AND t15.p_id='303186')) AND t0.smw_iw!=':smw' AND t0.smw_iw!=':smw-delete' AND t0.smw_iw!=':smw-redi' LIMIT 251

mwjames avatar Mar 21 '20 03:03 mwjames

The SQL building done by Maps is at https://github.com/JeroenDeDauw/Maps/blob/master/src/SemanticMW/ValueDescriptions/CoordinateDescription.php#L37-L72. It uses the floats returned by the getters of SMWDIGeoCoord (in SMW).

I'm not sure where the relevant storage code in SMW is so currently do not know where the rounding is coming from.

The code in Maps does have a FIXME about misplacement of the query building code from an architecture point of view. The bug here is an illustration of the kind of issues you get if you spread the internal persistence knowledge across architectural boundaries. Ideally this code gets moved to SMW somehow.

JeroenDeDauw avatar Mar 21 '20 11:03 JeroenDeDauw

I'm not sure where the relevant storage code in SMW is so currently do not know where the rounding is coming from.

There isn't a rounding issue in SMW as demonstrated by the information provided above, the annotated data is stored as-is (see the table content) the problem as outlined is that when constructing a DV, it returns a zero degree mark format and when this is transformed into a DD (decimal degree) representation it becomes '40.714488888889' '-74.007130555556' which then of course doesn't match anything in the store.

mwjames avatar Mar 21 '20 11:03 mwjames

The default format maps uses to show coordinates is Degree Minutes Seconds (ie 40° 42' 52.16" N, 74° 0'). This can be changed with the egMapsCoordinateNotation setting, which also affects how coordinate values in SMW are displayed.

I'm not sure how to improve on things to get rid of the issue you are facing. Besides that rounding might fix it.

JeroenDeDauw avatar Mar 21 '20 12:03 JeroenDeDauw