[OSM-dev] Various OSM troubles
ce at christeck.de
Mon Jan 8 23:50:49 GMT 2007
thanks for sharing your thoughts.
About getting bigger areas:
> This is most likely an SQL query timeout and has always been present
> to some degree or other throughout the project to date. If we had
> tons more hardware my guess is the project could deliver more data
> for each query. Until then we must consider the workaround.
I'll use the planet dumps as suggested by Jörg. This will even save a
bit of server load, and for my SVG maps, I don't need the latest data
from the server.
> You can do the same via a direct call to the API using wget or
> similar. Details for obtaining "map" data from the REST page on the
Thanks for the hint. I already had tried to use wget, but it didn't
accept the login coded into the URL like
so I gave up. I will read the wiki, so thanks for the pointer.
[speed when downloading incomplete objects]
This problem disappeared, as it seems the Garmin map is *not* broken due
to incomplete ways but due to ways with misordered segments. Jochen
already has tried to fix huge portions of such ways, and if I had had
turned on the arrows in JOSM, we surely had less of them. Shit happens.
Sorry for the traffic, it was my own fault not being careful enough
when creating ways.
Jochen even told me that many problems in in the rendered results
disappeared since he fixed some ways.
> Currently the best way to search for a place is to click on the "city
> search" which is returned at the top of the page after the initial
> search results.
Not for my needs, but for visitors passing by: Was it possible to name
the first edit, maybe, search streets and place the second below it,
named search place? Just an idea, as a user may find it irritating that
there are two different searches and the second one appears on the 2nd
> The city search uses the geonames database rather
> than the results of metadata in the OSM database. When someone has
> some coding time to devote to improving the search capabilities I'm
> sure it will get much better. Currently it was only taken to a simple
> first implementation level.
Not really being a hacker, I guess a live search on our already very
busy server is a performance issue. But maybe it could create an index
table on a weekly basis, so recently added places will appear at least
after one week. Searching This table then should cause less server
> Of course most of these issues require more coding or hardware, both
> of which are in very short supply. You are probably the first person
> to sign up to the dev list in a very long time, so welcome. Anything
> you or others can do to contribute on the development side will be
> appreciated by all.
Sure. Unfortunately my hacking skills are limited to some hobbyist C++ ,
so even if I *could* write some code, it would be a nightmare to
maintain. There surely is enough to do for me except hacking.
More information about the dev