[OSM-dev] Map rendering code... API or database direct?

[immanuel.scholz at gmx.de]

Hi,

On Thursday 30 March 2006 09:14, nick at hogweed.org wrote:
> OK, I plan to start hacking on the freemap code so that it's in a state
> suitable for rendering by OSM itself.

I am currently hacking on a tiled map cache for JOSM which will be suitable 
for OSM too (later). The API of the cache would be just another boring 
standard WMS server, but its data requested to the other end are always in 
specific tiles (with non-changing URL's ;-).

As an additional outcome (which I get for free) there will be an API like 
"give me the tile picture that this lat/lon is in with this zoom level". 
Maybe this can be usefull for freemap?


> The main issue at the moment is that ways that span several slippy map tiles 
> disappear as they pass through tiles which do not contain any nodes of that 
> way. 

There are two solutions to this: Either search through ALL line segments in 
the data base and look whether they cross any of your 4 borders of the tile 
to be rendered. This is slow but works everytime.

The other is to restrict the maximum length one line segment can have (or just 
assume and hope they are restricted) and grab all data from your tile plus 
the line segment offset widened. Then draw just all line segments and clip 
your tile accordingly out of the bigger picture.

Of course, you can combine both methods ;-)


> Would like to get some feedback on one point though. Should it interact
> with the database via the API (as a remote client would do) or direct with
> the database?

Depends on how much work you will have in the future ;-). The database schema 
is likely to change as it grows and single-tables containing history and 
actual data cannot be handled anymore. Also it is likely that the tag's 
currently inlined into segment and node table move outside.

Next is, that you cannot easily deploy freemap without the database, if you 
use it directly.

I suggest you use the API. :)


> direct interaction with the database might be faster?

I am not so sure about this. Where are the real bottlenecks? I doubt they are 
in launching up ruby and executing some lines of code.

However, in the past it turned out that the ruby XML implementation used was 
indeed a bottleneck. So profiling could give an answer here ;)


Ciao, Imi.