Fix the range of latitude/longitude

[Plopix]

We need to be worldwide ;-)

[Plopix]

In the indexation class, the longitude is first https://github.com/ezsystems/ezfind/blob/master/classes/ezfsolrdocumentfieldgmaplocation.php#L46

[bdunogier]

I guess that it was wrong all along ?

[andrerom]

+1, review ping @pspanja @paulborgermans

[Plopix]

@bdunogier Only the ezfind extendedattribute filter was wrong. For me the fact that the ezfsolrdocumentfieldgmaplocation indexes long/lat is not an issue if the extended filter works correctly with.

Additionnaly, I think it could be a bad idea to change the order (lon,lat) in the ezfsolrdocumentfieldgmaplocation because it could be an issue for existing project. (they will have to re-index)

Then this fix should be enough but it's just my opinion ;)

Thx!

[Plopix]

To my understanding I find out that the sort was also wrong, the geodist function need to know the field/origin.

According to the documentation: https://cwiki.apache.org/confluence/display/solr/Spatial+Search

geodist is a distance function that takes three optional parameters: (sfield,latitude,longitude). You can use the geodist function to sort results by distance or score return results.

I'm not a Solr expert and the feedback of @paulborgermans or @pspanja would be great.

But without the 3 arguments, the results was not correctly sorted.

Thx!

[paulborgermans]

In general, geographical support in ez find is lagging behind Lucene/Solr capabilities and the whole datatype handling should be refactored ...

That said, my opinion on this pull request:

• the indexing indeed makes the wrong order, so the error should be fixed there, not repeating the "error" here, even though that means the need for re-indexing
• either the use of the query parameters sfield, pt are to be used or as arguments to geodist() but not both
• using the filter is actually also a workaround for a missing parameter in schema.xml