Real Time Rendering in the Browser - Ideas how it can be done


I really love the openstreetmap project. I have an idea how it could be extremely improved: Not images are downloaded from the server, but the vector data itself. Then a script renders it into an image.
Data Structure:

  • for it to work the vector data must be structured so that only the streets that correspond to the current zoom level are downloaded. So If I view whole USA, only the biggest roads are loaded

This has a number of advantages:

  • much less data has to be downloaded, since only vector data and not images are downloaded
  • the OSM Browser window would be completely interactive, meaning, if I click on a road a window can pop up with all the information about that street (very much like Portland2), only any zoom level. Every POI would be available with all the infos without extra layers.
    Everything would be completely interactive.
  • Routing on a smartphone: A mobile navigation system would request a route over openrouteservice. Only this route (just some vector points) is downloaded and the phone can route, with minimal download.
  • Smooth zoom: The vector data can be zoomed without any download. And the extra downloaded data can be smoothly faded into the already zoomed map. So zooming into a city gets completely smooth.
  • Filtering: If I want to see only supermarkets on the map, that can be easily done.
  • Any sort of manipulation: Bigger supermarkets, different rendering, filtering, animation, etc. can be done without any downloads. → Much faster.
  • A stand alone application could use OpenGL to render the images even faster and display it in 2D and 3D

Problems ans solutions:

  • I have no idea how the data structure of the vector data is stored. But it probably would have to be rearranged, so that everything could be filtered fast by the level of detail.

I think it would be THE next big step to success.
What do you think?

PS: Next Step to overtaking the world: - A p2p distributed version of the vector database.

Hello data1, and welcome to the OpenStreetMap forums!

I fully agree that client-side real-time rendering will play a large part the future of OSM maps, and you have already provided a comprehensive list of the benefits.

To be fair, however, some additional challenges should be mentioned:

  • Browser compatibility. Image tiles work everywhere, whereas the ability to render maps in real time is not available in all browsers.
  • Speed. Rendering an image takes some time, which can slow down map browsing.
  • Cartographic quality. Currently, only traditional renderers can perform visual optimizations (e.g. related to generalization and label placement).
  • Routing and rendering need very different information, you can probably not efficiently use the same data organization for both.
    Many of the problems are mostly related to browsers, so I expect native applications (including mobile apps) to adopt real-time rendering first.

There are already some people working on ingredients for real-time rendering:

  • KothicJS is a JavaScript renderer - which proves that the idea can work, even though it also highlights some of the drawbacks
  • MapCSS is a stylesheet language for maps, and is currently used mostly in real-time rendering applications (which includes editors)
  • one user (Alv) is currently working on generating mergeable data tiles.

Maybe you want to support one of the efforts?

I looked into a few renderers and all have much overdraw. For example, how do they draw an eight pixels wide black colored road with two pixel yellow borders?
-draw thick yellow line/curve with line thickness set to 12
-draw thick black line/curve with line thickness set to 8 on top of the yellow line/curve. This is vast overdraw.

What should really happen is the renderer should calculate the exact 2D vertices and triangles for the long strips of left yellow border, the black road itself, and the right yellow border. Then draw each of the three long strips in sequence, which is zero overdraw.

Are you aware of any renderer that does this already?

How about the ones you listed?

Do you mean:
Given that the routing for large data set such as a country must be converted to a SQL like database, to render a 1km x 1km tile in real time, a database query ‘give me geometry data for all objects in this 1km x 1km tile’ would be too slow. Thus it is much faster if you use your own file format?

@data1: As your edits are in Germany, I think I can point you to two threads in the German Forum, where this also has been discussed and where you can find some more links: (you’ve probably already seen this one following the last link above)

thanks for all your answers and links!

And it’s great to know that people are already thinking about it / working on it.

What about rendering with SVG? Not all vectors should be put into SVG, some should be bitmaped, but with SVG you could have mouseover events for roads and such.

There is a new example of HTML5 map rendering from the company GIS Cloud, see their blog entry: “GIS Cloud Starts HTML5 Mapping Revolution!”.

The rendering engine is based on Leaflet (like Kothik JS), but is closed source. One example is based on OSM data.

Wow, I guess svg isn’t necessary for mouseovers…

A post on the OpenLayers mailing list explains how it is done.