I have two questions; why is gazetteer.openstreetmap.org so slow at
20-50 seconds per request, and if anyone has code for faster variants
of name finders? Speed is essential..
--
/emj
___
dev mailing list
dev@openstreetmap.org
Erik Johansson wrote:
I have two questions; why is gazetteer.openstreetmap.org so slow at
20-50 seconds per request, and if anyone has code for faster variants
of name finders? Speed is essential..
Because it's a pile of PHP code that is hardcoded to use MySQL as the
backend and which uses
On Mon, Jan 12, 2009 at 10:57:24AM +0100, Erik Johansson wrote:
I have two questions; why is gazetteer.openstreetmap.org so slow at
20-50 seconds per request,
I remember David Earl mentioning a scheduled database rebuild. Perhaps
its currently running. Otherwise, I'd really like to know the
While what Tom says may help performance, I don't think it is why things
are running disparately slowly at the moment.
It is mainly extremely slow at present because it has got into a state
where daily updates are interfering with each other and I haven't had a
chance to look at why this is
Hi,
David Earl wrote:
suspect his vicious circle started because there was one day when there
was an exceptionally large update and this ran fro 24 hours, running
into the next.
It could also be the fact that there was no daily diff in the early
hours of 1st Jan because the server had
Hello!
I currently try to reconstruct ways from the history. Retrieving the
ways is no problem. Retrieving nodes from the history isn't too.
But how to put them together? Not every node has a entry for every
entry in a ways history.
Is figuring out by comparing the timestamps the right method or
David Earl wrote:
I am happy to try InnoDB, and will do this when I reload the database,
which I had hoped to do over Christmas, but didn't get to. But from the
I doubt it will make any significant difference. It would if there were
locking going on, but there isn't.
Currently 42 locked
On 12 Jan 2009, at 12:40, Frederik Ramm wrote:
Hi,
David Earl wrote:
suspect his vicious circle started because there was one day when
there
was an exceptionally large update and this ran fro 24 hours,
running
into the next.
It could also be the fact that there was no daily diff
Hi,
Nevel Gandish wrote:
I currently try to reconstruct ways from the history. Retrieving the
ways is no problem. Retrieving nodes from the history isn't too.
But how to put them together? Not every node has a entry for every
entry in a ways history.
Is figuring out by comparing the
David Earl wrote:
While what Tom says may help performance, I don't think it is why things
are running disparately slowly at the moment.
Oh yes it is...
It is mainly extremely slow at present because it has got into a state
where daily updates are interfering with each other and I haven't
On 12/01/2009 12:48, Grant Slater wrote:
David Earl wrote:
I am happy to try InnoDB, and will do this when I reload the database,
which I had hoped to do over Christmas, but didn't get to. But from
the I doubt it will make any significant difference. It would if there
were locking going
Hi all,
Excuse me if it's a silly question (I'm a newbie here), but what about using
a search engine component instead of SQL queries ?
I think about Apache Lucene (Java search engine) for example (
http://lucene.apache.org/) which seems to me a better solution about
indexing and searching than
Hi,
Nicolas Guillaumin wrote:
Excuse me if it's a silly question (I'm a newbie here), but what about using
a search engine component instead of SQL queries ?
I think about Apache Lucene (Java search engine) for example (
http://lucene.apache.org/) which seems to me a better solution about
On 12/01/2009 13:32, Frederik Ramm wrote:
Hi,
Nicolas Guillaumin wrote:
Excuse me if it's a silly question (I'm a newbie here), but what about using
a search engine component instead of SQL queries ?
I think about Apache Lucene (Java search engine) for example (
http://lucene.apache.org/)
I strongly suggest that you read the postgresql text search[1] chapter
in depth. You will find that a lot of textual and multilingual
confusions can be solved with that function set. the name text search
is by far too simple for what it covers...
Regards,
Milo
[1]
Milo van der Linden wrote:
I strongly suggest that you read the postgresql text search[1] chapter
in depth. You will find that a lot of textual and multilingual
confusions can be solved with that function set. the name text search
is by far too simple for what it covers...
I have read it,
On Mon, Jan 12, 2009 at 3:05 PM, David Earl da...@frankieandshadow.com wrote:
If we were only searching the names in the planet file or some other
plain text, life would be simple. But it is a great deal more
complicated than that to produce useful, contextual results. And I'd be
the first to
On 12/01/2009 14:21, Milo van der Linden wrote:
I strongly suggest that you read the postgresql text search[1] chapter
in depth. You will find that a lot of textual and multilingual
confusions can be solved with that function set. the name text search
is by far too simple for what it
David Earl wrote:
On 12/01/2009 13:05, Tom Hughes wrote:
David Earl wrote:
While what Tom says may help performance, I don't think it is why
things are running disparately slowly at the moment.
Oh yes it is...
Table locks would indeed cause a problem, as you say (I've never
disagreed).
David Earl wrote:
OK, I've got three possible ways forward:
(a) convert to InnoDB.
(b) do updates on different tables to queries and switch them over on
completion.
(c) both
The downside of (a) is that there is an overhead to row locking; of (b)
is that you do every update twice,
Tom Hughes wrote:
Milo van der Linden wrote:
I strongly suggest that you read the postgresql text search[1]
chapter in depth. You will find that a lot of textual and
multilingual confusions can be solved with that function set. the
name text search is by far too simple for what it
On 12/01/2009 15:54, Tom Hughes wrote:
David Earl wrote:
(b) do updates on different tables to queries and switch them over on
completion.
...
The main problem with b is that you need to make a complete copy of the
tables before you start the update - the logic presumably goes like this:
Hi, Alessandro!
I'm not sure if I fully understand your post.
I do think that a roundabout should be a circular way where the first
node is connected to the last one. There need not necessarily be another
road connected to the first node of such a loop.
Please give me an example so I can
Hi Marc!
well I think I did some overkill...
If this is common conensus I will drop this check, because it is
superseded by check intersections without junctions, which does
exactly what you describe.
Thank you!
Best Regards
Harald
There are several marks saying This way is tagged as
2009/1/12 Tobias Wendorff tobias.wendo...@uni-dortmund.de:
Rolf Bode-Meyer schrieb:
No you don't have to. The proj.4 sources already contain a jniwrap
around the proj.dll or proj.so or whatever. Although you'd still have
to provide native proj lib for all systems running JOSM.
Based on a
Hello,
We have just seen that a portion of the map I edited yesterday with
Potlatch is now really broken, is missing lots of points and has its
history broken.
http://openstreetmap.org/?lat=44.86196lon=24.89171zoom=16layers=B000FTTT
This is easily visible when comparing mapnik and osmarender
2009/1/13 Eddy Petrișor eddy.petri...@gmail.com
Hello,
We have just seen that a portion of the map I edited yesterday with
Potlatch is now really broken, is missing lots of points and has its
history broken.
http://openstreetmap.org/?lat=44.86196lon=24.89171zoom=16layers=B000FTTT
This
27 matches
Mail list logo
