[OSM-dev] Various OSM troubles

Christoph Eckert ce at christeck.de
Mon Jan 8 23:50:49 GMT 2007


Hi Andy,

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
> wiki.

Thanks for the hint. I already had tried to use wget, but it didn't 
accept the login coded into the URL like
http://username:passphrase@URL
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 
page only.

> 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 
load.

> 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.

ce





More information about the dev mailing list