Hello all,
We're having some success with the C++/apache implementation of the API - an
implementation of the map query up and running which returns appropriate
ways, nodes relations and their associated tags and members. It also seems
that the Cherokee/MonetDB version is at a similar stage.
So I
Alex Wilson schreef:
> Should have an example C++ api serving from an apache module online soon.
I guess it is a good thing that there is development going on for this
API thingie :) If you have a demo too, please make a wiki.
My demo can be found here:
http://wiki.openstreetmap.org/index.php/C
Am Freitag, den 30.05.2008, 13:37 +0200 schrieb Steven te Brinke:
> SELECT *
> FROM current_war_tags
> WHERE id IN (
> SELECT *
> FROM current_ways
> WHERE tile IN (...)
>AND latitude BETWEEN ... AND ...
>AND longitude BETWEEN ... AND ...
> )
> ORDER BY id;
>
> However,
In message <[EMAIL PROTECTED]>
Steven te Brinke <[EMAIL PROTECTED]> wrote:
> The second query uses a join only to select the correct values, not
> because you really want to join the tables. I think that you can achieve
> the same by a query like this:
>
> SELECT *
> FROM current_war_tag
Hi Steven,
Thanks for the suggestion. I think it would work nicely on a more
sophisticated db, but in my limited experience - MySQL is pretty dumb about
running subqueries and you can end up with O(n2) run time. So it's better to
stay with dumb joins unless OSM moves to something a little more
hea
The second query uses a join only to select the correct values, not
because you really want to join the tables. I think that you can achieve
the same by a query like this:
SELECT *
FROM current_war_tags
WHERE id IN (
SELECT *
FROM current_ways
WHERE tile IN (...)
AND latitude
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 <[EMAIL PROTECTED]>:
> In message <[EMAIL PROTECTED]>
> Alex Wilson <[EMAIL PROTECTED]> wrote:
>
> > Ah. good point - a
In message <[EMAIL PROTECTED]>
Alex Wilson <[EMAIL PROTECTED]> 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 - coul
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
In message <[EMAIL PROTECTED]>
Alex Wilson <[EMAIL PROTECTED]> wrote:
> I'm taking the printf method below - except streaming out using the apache
> module interface rather than stdout. I'm also streaming as much stuff from
> the db as possible (nodes, ways, . However I believe for the map
I'm taking the printf method below - except streaming out using the apache
module interface rather than stdout. I'm also streaming as much stuff from
the db as possible (nodes, ways, . However I believe for the map query
there's a trade-off between local process memory usage and minimising db
queri
Joachim Zobel wrote:
> Am Montag, den 26.05.2008, 15:07 +0100 schrieb Tom Hughes:
>> The reason is that we have to allow about 600Mb or so for each call
>> and that quickly mounts up as you try and add extra simultaneous
>> accesses.
>
> If _that_ amount of memory is needed this probably means the
On Wed, May 28, 2008 at 10:07 AM, Frederik Ramm <[EMAIL PROTECTED]> wrote:
> Hi,
>
>> The problem here is the remedial action taken by the user/editor:
>> they're going to try to work out the conflicts by downloading the
>> latest version of the region. If this comes off a replication server
>> tha
Hi,
> The problem here is the remedial action taken by the user/editor:
> they're going to try to work out the conflicts by downloading the
> latest version of the region. If this comes off a replication server
> that's a couple of minutes behind,
You could make it so that the intial map query is
2008/5/27 Karl Newman <[EMAIL PROTECTED]>:
> On Mon, May 26, 2008 at 8:33 AM, Tom Hughes <[EMAIL PROTECTED]> wrote:
>>
>> In message <[EMAIL PROTECTED]>
>> Ludwig <[EMAIL PROTECTED]> wrote:
>>
>> Map data for editing purposes will always have to come from the
>> master database anyway, or
A point of clarification: is it the map request that particularly requires
re-implementing? My friend and I are planning a hack-a-thon on Thursday
night and we're hoping to get something up and running - and we were
planning to implement that first.
Cheers,
Alex
2008/5/27 Karl Newman <[EMAIL PRO
Frederik Ramm schreef:
> Hi,
>
>> Um... no. Looking at the code would reveal that we do indeed create
>> a DOM tree and then flatten it out.
>
> Darn, there goes my credibility, should've looked at the code myself.
> Sorry Joachim!
I hope it is not a problem if this is not done in the 'high per
Hi,
> Um... no. Looking at the code would reveal that we do indeed create
> a DOM tree and then flatten it out.
Darn, there goes my credibility, should've looked at the code myself.
Sorry Joachim!
Bye
Frederik
--
Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33"
On Mon, May 26, 2008 at 8:33 AM, Tom Hughes <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>
> Ludwig <[EMAIL PROTECTED]> wrote:
>
> Map data for editing purposes will always have to come from the
> master database anyway, or you might get an old version which you
> are then
In message <[EMAIL PROTECTED]>
Frederik Ramm <[EMAIL PROTECTED]> wrote:
> > If _that_ amount of memory is needed this probably means the XML is
> > build in memory. This could be done the SAX way instead.
>
> Looking at the code, which is publicly available, would quickly have
> told yo
Hi,
> If _that_ amount of memory is needed this probably means the XML is
> build in memory. This could be done the SAX way instead.
Looking at the code, which is publicly available, would quickly have
told you that neither a DOM tree nor a SAX approach is used on output.
It's plain old DIY XML.
Am Montag, den 26.05.2008, 15:07 +0100 schrieb Tom Hughes:
> The reason is that we have to allow about 600Mb or so for each call
> and that quickly mounts up as you try and add extra simultaneous
> accesses.
If _that_ amount of memory is needed this probably means the XML is
build in memory. This
On Mon, 26 May 2008, Tom Hughes wrote:
> 2008/5/26 Stefan de Konink <[EMAIL PROTECTED]>:
>
> > How should one benchmark his solution? Just put the data in and fetch?
>
> Well that is certainly a good start - compare the time taken to fetch
> an area with the time taken by the current code on the s
2008/5/26 Stefan de Konink <[EMAIL PROTECTED]>:
> How should one benchmark his solution? Just put the data in and fetch?
Well that is certainly a good start - compare the time taken to fetch
an area with the time taken by the current code on the same machine.
It is also worth comparing the maximu
How should one benchmark his solution? Just put the data in and fetch?
Stefan
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
In message <[EMAIL PROTECTED]>
"Alex Wilson" <[EMAIL PROTECTED]> wrote:
> Re-implementing the API in C++ will hopefully give a constant-time speedup
> (x5?), serving the data from a cluster of machines offers a more scalable
> solution. To me both seem worthwhile. The former is (imho) a
Re-implementing the API in C++ will hopefully give a constant-time speedup
(x5?), serving the data from a cluster of machines offers a more scalable
solution. To me both seem worthwhile. The former is (imho) a fairly easy
task and will buy some time. The latter seems perhaps harder, but clearly if
My concern is that even if a reimplementation of the API in some other form
will not fundamentally solve the scalability problem if all data requests
will have to be served by a single machine.
Will not the introduction of the 0.6 API offer a solution in the sense that
will will with far greater r
In message <[EMAIL PROTECTED]>
Joachim Zobel <[EMAIL PROTECTED]> wrote:
> Am Donnerstag, den 22.05.2008, 00:06 +0100 schrieb Tom Hughes:
> > > Writing Apache modules in C is hard, and I don't think using mod_cpp
> > > will make it much easier. Doing Apache modules in Perl (mod_perl has
>
In message <[EMAIL PROTECTED]>
Ludwig <[EMAIL PROTECTED]> wrote:
> My concern is that even if a reimplementation of the API in some other form
> will not fundamentally solve the scalability problem if all data requests
> will have to be served by a single machine.
What makes you think t
In message <[EMAIL PROTECTED]>
Frederik Ramm <[EMAIL PROTECTED]> wrote:
> > Do we need an Apache server?
> > Why not writing (in c/c++) a small daemon listening on another port
> > (e.g. 8080) and having a pool of threads translating from GET requests
> > to mysql querries and from mysql
Frederik Ramm schreef:
> Hi,
>
>> Would it not be better to think about new services that could be offered
>> by OSM rather than putting a lot of effort into fixing something that is
>> not broken?
>
> While I agree that one should not over-engineer and try to be prepared
> for everything, if ONE
Hi,
> Would it not be better to think about new services that could be offered
> by OSM rather than putting a lot of effort into fixing something that is
> not broken?
While I agree that one should not over-engineer and try to be prepared
for everything, if ONE thing is sure then that is a steadi
2008/5/25 Ludwig <[EMAIL PROTECTED]>:
> Would it not be better to think about new services that could be offered by
> OSM rather than putting a lot of effort into fixing something that is not
> broken?
>
> Suggestions would be WMS, WFS, i18n, custom layer support, or some sort of
> support where th
Would it not be better to think about new services that could be offered by
OSM rather than putting a lot of effort into fixing something that is not
broken?
Suggestions would be WMS, WFS, i18n, custom layer support, or some sort of
support where the OSM DB can be integrated well with a GIS. Not a
On Sat, May 24, 2008 at 8:48 PM, Joachim Zobel <[EMAIL PROTECTED]> wrote:
> Am Donnerstag, den 22.05.2008, 00:06 +0100 schrieb Tom Hughes:
>> > Writing Apache modules in C is hard, and I don't think using mod_cpp
>> > will make it much easier. Doing Apache modules in Perl (mod_perl has
>> API
>> >
Am Donnerstag, den 22.05.2008, 00:06 +0100 schrieb Tom Hughes:
> > Writing Apache modules in C is hard, and I don't think using mod_cpp
> > will make it much easier. Doing Apache modules in Perl (mod_perl has
> API
> > access including filters) is a lot easier.
>
> Ye gads no. We want to keep the
On Fri, May 23, 2008 at 8:00 PM, Frederik Ramm <[EMAIL PROTECTED]> wrote:
> Hi,
>
>> Do we need an Apache server?
>> Why not writing (in c/c++) a small daemon listening on another port
>> (e.g. 8080) and having a pool of threads translating from GET requests
>> to mysql querries and from mysql resu
Frederik Ramm schreef:
> Hi,
>
>> Do we need an Apache server?
>> Why not writing (in c/c++) a small daemon listening on another port
>> (e.g. 8080) and having a pool of threads translating from GET requests
>> to mysql querries and from mysql results to xml?
>
> Famous last words: "Let's just wr
Hi,
> Do we need an Apache server?
> Why not writing (in c/c++) a small daemon listening on another port
> (e.g. 8080) and having a pool of threads translating from GET requests
> to mysql querries and from mysql results to xml?
Famous last words: "Let's just write a small HTTP daemon..." ;-)
Su
> I'm a frequent user of Perl and it has lots of merits, but I wouldn't
> want to base a high-performance module on it that reads data from Mysql
> and shifts it over to Apache. I haven't done the numbers on that but my
> gut feeling is that you'll be copying the data around a few times more
> in t
Hi,
> Writing Apache modules in C is hard
I don't think so.
> and I don't think using mod_cpp
> will make it much easier. Doing Apache modules in Perl (mod_perl has API
> access including filters) is a lot easier.
I don't know what the English would us in this situation but you might
be famil
All good answers. Thanks guys. My aim is to keep the memory footprint as low
as possible and stream the data out, so mod_apache it is.
Cheers,
Alex
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
In message <[EMAIL PROTECTED]>
Joachim Zobel <[EMAIL PROTECTED]> wrote:
> Am Mittwoch, den 21.05.2008, 11:14 +0100 schrieb Alex Wilson:
> > Further to earlier discussion on this list, I've been looking into
> > writing a C++ version of the OSM API server. When discussing this
> > before,
On Wed, 21 May 2008, Joachim Zobel wrote:
> Writing Apache modules in C is hard, and I don't think using mod_cpp
> will make it much easier. Doing Apache modules in Perl (mod_perl has API
> access including filters) is a lot easier. For modules using the C API
> read Nick Kews book (ISBN 978013240
Am Mittwoch, den 21.05.2008, 11:14 +0100 schrieb Alex Wilson:
> Further to earlier discussion on this list, I've been looking into
> writing a C++ version of the OSM API server. When discussing this
> before, it was suggested that an Apache module would be the best way
> to plug such an API into th
In message <[EMAIL PROTECTED]>
Alex Wilson <[EMAIL PROTECTED]> wrote:
> Further to earlier discussion on this list, I've been looking into writing a
> C++ version of the OSM API server. When discussing this before, it was
> suggested that an Apache module would be the best way to plug such
Hi,
Further to earlier discussion on this list, I've been looking into writing a
C++ version of the OSM API server. When discussing this before, it was
suggested that an Apache module would be the best way to plug such an API
into the OSM server. Just out of interest: what are the advantages of a
48 matches
Mail list logo