Longitude greater than 90 crashes the broker

[fgalan]

To reproduce the bug: clean database (using MongoDB 2.4.9), start the broker, and sends the following request:

(curl localhost:1026/NGSI10/queryContext -s -S --header 'Content-Type: application/json' --header 'Accept: application/json' -d @- | python -mjson.tool) <<EOF
{
  "entities": [
  {
    "type": "Point",
    "isPattern": "true",
    "id": ".*"
  }
  ],
  "restriction": {
    "scopes": [
    {
      "type" : "FIWARE_Location",
      "value" : {
        "polygon": {
          "vertices": [
                        {"latitude":2.811371193331,"longitude":130.078061},
                        {"latitude":13.031027211328,"longitude":130.078061},
                        {"latitude":13.031027211328,"longitude":140.24472766667},
                        {"latitude":2.811371193331,"longitude":140.24472766667}
          ]
        }
      }
    }
    ]
  }
}
EOF

The result is that the broker crashes.

Why? Looking to the mongo logs:

Wed Jul 23 09:24:14.655 [conn27] assertion 16535 can't parse query (2dsphere): { $geoWithin: { $geometry: { type: "Polygon", coordinates: [ [ [ 2.811371193331, 130.078061 ], [ 13.031027211328, 130.078061 ], [ 13.031027211328, 140.24472766667 ], [ 2.811371193331, 140.24472766667 ], [ 2.811371193331, 130.078061 ] ] ] } } } ns:orion.entities query:{ query: { $or: [ { _id.id: /.*/, _id.type: "Point" } ], _id.servicePath: { $exists: false }, location.coords: { $geoWithin: { $geometry: { type: "Polygon", coordinates: [ [ [ 2.811371193331, 130.078061 ], [ 13.031027211328, 130.078061 ], [ 13.031027211328, 140.24472766667 ], [ 2.811371193331, 140.24472766667 ], [ 2.811371193331, 130.078061 ] ] ] } } } }, orderby: { creDate: 1 } }

This parsing error is caused because we are breaking the rules for latitude and longitude (remember from school that longitude range is -180 to 180 and latitude ranges is from -90 to 90, see https://answers.yahoo.com/question/index?qid=20071121075230AATuvo3), considering that the format for the coordinates in the query at MongoDb is: (from http://docs.mongodb.org/manual/tutorial/query-a-2dsphere-index/):

 db.<collection>.find( { <location field> :
                         { $near :
                           { $geometry :
                              { type : "Point" ,
                                coordinates : [ <longitude> , <latitude> ] } ,
                             $maxDistance : <distance in meters>
                      } } } )

Thus, we are wrongly "swapping" the place of longitude and latitude.

In order to fix this with minor impact in existing implementations, we should:

• A test harness based on the above test that causes CB crashing (I'd recommend to do this first, in a kind of TDD philosophy).
• Check that latidudes and longitudes are within ranges in the following places:
  • In updateContext, when processing the "value" string
  • In polygon vertex coordinates processing
• Storing coordinates in locations.coords in the opposite order upon updateContext processing at mongoDackend
• Modify the building query logic for polygons, interchanging the current order in the BSON building
• Provide a MongoDB script to interchange the position of the coordinates in locations.coords to be used by users with existing geo-positioned entities in their Orion databases.

Note that considering the above solution, the REST API is not changed, so we minimize the impact in existing users.

[fgalan]

In addition, probably we should review the circle logic, as probably the coordinates to specify the center in the circle should be also swapped in the BSON.

[kzangeli]

Yes, the circle is swapped as well

[fgalan]

A litte note about what ordering convenion we follow in API and documentation should be added in the User Manual, recognizing the existence of other but citing the references of the one we follow, e.g. Google Eartch, Google Maps (to confirm), etc.

[fgalan]

Before closing this issue, provide an answer to question http://stackoverflow.com/questions/24789244/orion-geo-located-query-returns-internal-server-error-when-use-positive-values-t

[fgalan]

Fixed in PR #462