[OSM-dev] C++ implementation of the API

Alex Wilson alex_wilson at pobox.com
Fri May 30 09:54:21 BST 2008


Thanks Tom. I'll have a play with the various alternatives - and keep the
code flexible enough to allow them to be swapped without much fuss.

Alex

2008/5/30 Tom Hughes <tom at compton.nu>:

> In message <44d06e000805300136g56758eefq1063ec0077f5a3c3 at mail.gmail.com>
>         Alex Wilson <alex_wilson at pobox.com> wrote:
>
> > Ah. good point - a sensible third way. Apologies for missing it, I'm a
> > relative SQL novice. However, if you fetch the tags along with the ways
> > using a join, given that there are potentially many tags per way -
> couldn't
> > you end up with considerable duplication of the way data in the query
> > result? I suppose one would have to profile both the join method and my
> > local storage method to see which had better memory and time performance.
>
> You will get some duplication, yes. How much that matters will be
> down to profiling as you say.
>
> The other option is to run two queries in parallel:
>
>  SELECT *
>  FROM current_ways
>  WHERE tile IN (...)
>    AND latitude BETWEEN ... AND ...
>    AND longitude BETWEEN ... AND ...
>  ORDER BY id;
>
> and:
>
>  SELECT cwt.*
>  FROM current_way_tags cwt
>  INNER JOIN current_ways cw ON cwt.id = cw.id
>  WHERE cw.tile IN (...)
>    AND cw.latitude BETWEEN ... AND ...
>    AND cw.longitude BETWEEN ... AND ...
>  ORDER BY cwt.id
>
> then read both result sets at the same time and match them up.
>
> Tom
>
> --
> Tom Hughes (tom at compton.nu)
> http://www.compton.nu/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20080530/6f29730d/attachment.html>


More information about the dev mailing list