[OSM-talk] Map tag in Wikipedia

[Ævar Arnfjörð Bjarmason]

On Sat, Apr 4, 2009 at 10:05 AM, Frederik Ramm <frederik at remote.org> wrote:
> Hi,
>
> Ævar Arnfjörð Bjarmason wrote:
>>
>> Evidently yes, I went there after all and this is a blog posting about
>> some of the progress we've been making:
>>
>> http://openstreetmap.org/user/%C3%86var%20Arnfj%C3%B6r%C3%B0%20Bjarmason/diary/5800
>
> Comments on that blog entry:
>
> 1. MapOf is T at H only but could trivially be changed.

I just read its source, and yes,it looks easy to change this:

#-----------------------------------------------------------------------------
# Location of map tiles
#-----------------------------------------------------------------------------
function tileURLB($X,$Y,$Z){
  return(sprintf("http://tah.openstreetmap.org/Tiles/tile/%d/%d/%d.png",
$Z, $X, $Y));
}

So if we go the route of stitching together existing tiles that's
something we might want to use.

> 2. Depending on the reason why you want stitched images: If you want to
> freeze the current map display then of course you need a stitched image and
> save that. If your only reason is avoiding JavaScript dependency, then it
> might be possible to achieve a proper map display by statically combining
> tiles and using CSS to adjust the viewport. Results would then be identical
> to a stitched image where CSS is supported, and on non-CSS viewers the map
> would be up to 510 pixels (worst case) larger in each direction because
> viewport adjustment doesn't work.

Someone suggested that we might want to do that. I'm not familiar with
the problems with that but it was mentioned that mobile devices would
handle such hacks badly. I think optimally we'd like to do something
like:

* Display a static image pre-generated for an extension request
generated by something like:

   <map lat="51.485" lon="-0.15" z="11" w="300" h="200" format="png" />

* If the browser supports JavaScript we'd like to replace that with a
OpenLayers iframe, or maybe if the user clicks on the image a
OpenLayers map browser will open and if the user's browser supports JS
nothing will happpen, the user will just get the static map.

> 3. Slippymap technology and Mapnik would allow reducing the tile size to,
> say, 64x64 pixel if desired. Resulting in a much higher amount of HTTP
> requests, but being able to adjust the map size in 64-pixel steps only would
> perhaps be acceptable so you could work with full tiles throughout, never
> stitching or cutting a tile.

I think stitching these server-side is so easy that we wouldn't want
to trade that in for say having a static map consisting of multiple
pre-rendered tiles displayed in a HTML <table> or some hackery like
that.

> 4. Bigmap has two aspects, one is combining tiles into a map display using
> HTML tables (no JS), the other is a Perl script that downloads tiles and
> combines them into a large PNG. It could trivially be converted to a CGI but
> what you want would probably be something that runs on the machine with the
> local tile storage rather than accessing tiles via the web, essentially what

I like what MapOf does after reading its source. Bigmap looks more
like the sort of more complex thing we don't want.

> 5. Custom on-demand rendering will work if there's a good caching layer in
> front of it.

A good front-end cache is what we're aiming for from day one.
Basically the process we want is:

1. A user edits an article and embeds a map
2. The map is dynamically rendered either from scratch or from
pre-rendered map tiles
3. The generated data is saved in a form which can be given to the
caches to worry about, i.e. static .png