I often work with large relations (like this). Currently, the preview maps at osm.org/browse/relation/[number] or at osm.org/?relation=[number] load painfully slowly. Can this be solved somehow? Is it possible to cache these so they would load instantly?

asked 16 Nov '11, 07:45

Kozuch's gravatar image

Kozuch
1.6k567282
accept rate: 8%

edited 16 Nov '11, 09:44


The preview maps use the editing API to download all objects referenced by the relation. There are several problems with that:

  • The API is meant for editing not browsing; the preview maps were a nice feature when they were introduced but being ever more heavily used they start to put undue strain on the servers. The relation/full call required will often time out for complex relations.
  • Because the API is for editing, it returns much more information than strictly needed for drawing a preview map (for example, all tags and metadata like last edit date for all nodes and ways that form the relation). All this information has to be fetched from the database, put into XML form, sent over the wire, decoded by the browser, and prepared for display in OpenLayers.
  • Even the largest relations are transmitted in full resolution, which may mean tens of thousands of coordinate pairs. This is of course overkill for a small preview map.

There are many ways how this could be fixed. A simple caching of the XML response would ease the strain on the database but not solve the issue of a ton of unnecessary data being transmitted to the browser. An ideal solution would probably store the relation as a pure string of coordinates, with simplified geometry, and hand that out to the browser in KML form or so. The challenge for any caching solution would be to find out when to invalidate the cache.

All this could easily be implemented by a third party relying on diff updates loaded from the OSM server - a kind of "fast relation viewer" service.

I'm sure people would appreciate if someone built such a system they could then use. As is often the case in OSM, there's no lack of good ideas, just a lack of good people to put them into practice.

permanent link

answered 16 Nov '11, 08:22

Frederik%20Ramm's gravatar image

Frederik Ramm ♦
71.3k846451113
accept rate: 24%

Thanx for a complex answer. Do you think XAPI would be faster than API?

(16 Nov '11, 09:52) Kozuch
2

From reading Frederik's reply, XAPI may be a little quicker for retrieving the information, but for the best performance you wouldn't want any of the tags or version information returning - just the member nodes of any ways in the relation, and for those nodes only their longitude and latitude. Which in an optimised custom database structure is the "pure string of coordinates" Frederik also mentions above, though he goes the one step further and simplifies the geometry; eg you probably don't need full details of the Mississippi riverbank if you are zoomed out far enough to see the whole river.

(16 Nov '11, 10:40) EdLoach ♦

Well, I think full details would still be nice - I mean to show all nodes of a relation in case you zoom in... It sounds like the biggest load does all the extra data fetched, so let us cut this only.

(16 Nov '11, 10:55) Kozuch
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×190
×19

question asked: 16 Nov '11, 07:45

question was seen: 2,825 times

last updated: 16 Nov '11, 10:55

powered by OSQA