[Xapian-tickets] [Xapian] #481: Merge geospatial branch

Xapian nobody at xapian.org
Mon Jun 7 14:02:25 BST 2010


#481: Merge geospatial branch
-------------------------+--------------------------------------------------
 Reporter:  richard      |       Owner:  richard  
     Type:  enhancement  |      Status:  assigned 
 Priority:  normal       |   Milestone:  1.2.1    
Component:  Library API  |     Version:  SVN trunk
 Severity:  normal       |    Keywords:           
Blockedby:               |    Platform:  All      
 Blocking:               |  
-------------------------+--------------------------------------------------

Comment(by richard):

 Users of the C++ API aren't actually forced to use LatLongCoords
 explicitly:

  - when serialising, to store values, a serialised LatLongCoord has the
 same representation as a serialised LatLongCoords object containing the
 same single coordinate, so a LatLongCoord can be serialised and stored
 directly.  (This is noted in the documentation, too.)

  - when creating a PostingSource, Metric or KeyMaker, a LatLongCoord can
 be passed in place of the LatLongCoords reference required, and the non-
 explicit {{{LatLongCoords(const LatLongCoord & coord)}}} constructor will
 be used to convert the parameter automatically.

 However, the automatic conversion won't work in other languages; so, for
 example, python users will be forced to do the wrapping explicitly.  We
 could provide a wrapper in such languages, of course.

 I'm not sure what a cleaner approach would be, whilst retaining the
 ability to calculate distances based on sets of points.

 Regarding exposing of STL iterators, it would be quite easy to write a
 simple iterator for iterating the contents of a LatLongCoords; I'll take a
 go at that in a bit.  Doing so should make the SWIG wrappers better, so
 it's probably worth it just for that.

-- 
Ticket URL: <http://trac.xapian.org/ticket/481#comment:8>
Xapian <http://xapian.org/>
Xapian



More information about the Xapian-tickets mailing list