[OSM-dev] Trial clickable POI layer

Jon Burgess jburgess777 at googlemail.com
Fri Sep 21 21:39:11 BST 2007

On Fri, 2007-09-21 at 21:12 +0100, David Earl wrote:
> On 21/09/2007 20:49, Jon Burgess wrote:
> > On Fri, 2007-09-21 at 20:48 +0200, Martijn van Oosterhout wrote:
> >> On 9/21/07, David Earl <david at frankieandshadow.com> wrote:
> >>> But I really think it does need saving: there must be more than 60,000
> >>> POIs - unless you are only thinking about specific types, maybe. But
> >>> given the HTML is very compact, I think all POIs per tile could be done.
> >> To be honest, lets cross that bridge when we come to it. Until I get
> >> images for other things that raise the number of POIs it's not worth
> >> optimising something that only takes a fraction of a second anyway.
> >>
> >> Besides, I wouldn't have a clue how to get openlayers to read HTML
> >> into tile. That's not currently supported. What is supported is icons
> >> with configurable HTML when you click on them...
> >>
> > 
> > IMO it would be much better to use an XML format which you can pump
> > through XMLHttpRequest & XML JS DOM tree (or any other XML parse). This
> > leaves the door open for other scripts to interpret the data (both JS
> > and non-JS).
> > 
> > For example, I can see a simple PDA or Phone application which could
> > list the nearest pub/cafe/hotel etc by doing a POI request based on its
> > current location. It could display the results as a text list with phone
> > numbers etc without even displaying the map tile. 
> > 
> > I understand OSMXAPI can do this sort of thing too.
> Name finder already provides exactly this interface 
> ("search.xml?find=pubs+near+<lat>,<lon>")
> The point here is that HTML can be a drawing format equivalent to an 
> image tile, so I thought it would slot in well to the openlayers 
> methodology. Apparently though I was wrong there, though, but the 
> principle is still sound. 

One of the problems with HTML is that it mixes content and
layout/rendering information. For example, instead of returning
something like:

<Name>The Ivy</Name>

in HTML we might get:

<IMG href="images/restaurant.png" />
<A href="http://www.the-ivy.co.uk">The Ivy</A>

The latter may be simpler for PC browsers to display, but we'd have to
'scrape' the IMG tag to get the fact that this is a restaurant. In
addition icon specified by the HTML might not be suitable to display on
the screen of the device making the request.

Even for the PC browser cases, knowing the list of POIs being returned
with no HTML parsing is great for displaying a list of enable/disable
tick boxes to selectively display the POIs etc.

> XML would require a layer of JS to be invoked 
> client side to convert to HTML (DOM) for display (which requires an 
> appropriate hook), or at server side on request. The load on the server 
> is quite high for rendering maps, so the less it has to do on a tile 
> request the better.

As far as rendering tiles in concerned almost all of the CPU is used by
the bitmap rendering algorithms, the database queries and sending the
data is quite relatively cheap.

> The HTML is a simple conversion of the XML you get from the database 
> (which would then be cached). So if you want XML, why not just go to the 
> database to get it, just as this application does?

I guess I don't see what advantage you get from serving HTML instead of

> David

More information about the dev mailing list