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