[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