[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