Template talk:BC Basemap

Re: this forum thread

Making that map was mostly trial and error. There are 6 important things:

1. min latitude
2. min longitude
3. max latitude
4. max latitude
5. width
6. height

lat/lng coordinates (aka the bounding box) are decimal degrees, width and height are pixels. It is possible to create maps where the x-scale <> y-scale. I did it by mistake one time, and it looks quite weird, so you have to make sure the aspect ratio for the bounding box matches the image dimensions you are asking it to create. It shouldn't be too hard to automatically create maps with a wiki template - one of the dimensions (e.g. width) could be taken from a template variable, and the other calculated to match the bounding box.

How I actually created that map was:

1. use bivouac basemap tool to generate 3km radius map of Mt Garibaldi
2. adjust bounding box keeping aspect ratio the same (by adding/subtracting the same amount from both the co-ordinates of both sides), until map showed south end of the neve traverse
3. subtract southern latitude from northern latitude, to get total latitude range of map.
4. multiply that by 3, add to southern latitude to get new northern latitude
5. increase height of map in px to 3000

I guess that's a starting point - I'll give some thought to how this template could work on the wiki. Suggestions welcome. --Matthew 21:55, 19 February 2008 (PST)

If we make this work, it would be cool to have a way to generate maps for myself without having to make a wiki page... ie. an alternate interface. Basically something for friendly than bivouac or trail.brijn.nu. The gov't web interfaces are ok, but it is hard to make a big map with them. Scott Webster 22:05, 19 February 2008 (PST)

I should be able to whip up a form to do that fairly quickly - probably more easily than the wiki template. Actually, I'd like that for myself, so it has a high likelihood of getting done. --Matthew 22:19, 19 February 2008 (PST)

I whipped together something that takes the center lat/long, a lat width, a long width and a scale as parameters. I think that's easier for the user than specifying a bounding box, height and width. It also keeps the vertical and horizontal scales the same. Right now it assumes you are at 50 degrees lattitude to do the lat/long distance ratio. Ideally we could use the cosine of the lattitude to calculate this but I haven't figured out how to do that yet. Scott Nelson 10:02, 20 February 2008 (PST)

Nice work Scott. I also whipped together something - a form for easily creating maps. I still need to add the ability to control the scale, but it does all the calculations properly using the WGS84 ellipsoid, which is rather neat - I found a function to do that. tool | source. Also, if calculations are difficult to do on the wiki, we could always make the template point to an external page that redirects to the correct map, in a similar way to the utm2latlng thing I put together for Template:Coord --Matthew 10:54, 20 February 2008 (PST)

While I think it is good to figure out your own thing, you might want to check out trail.brijn.nu as is does this same thing already with more options and stuff. I think you have to create an account (free) if you want to make large maps. Anyway, it might be worth a look to see if you can get any hints from what they do. Scott Webster 11:29, 20 February 2008 (PST)

Cosine Function

So it looks like there is a cosine function for mediawiki, but I don't know how to activate the MathStatFunctions extension. Any hints? Scott Nelson 08:38, 26 February 2008 (PST)

Looks like it's another extension that I should install. I've got to run right now, but I'll take care of this later today. Chris Michalak 09:36, 26 February 2008 (PST)

Ok, I ended up upgrading all of mediawiki while I was at it since the MathStat extension claimed it needed 1.8.x or better. So, let's see, cos(pi/2) = -3.4914813388431E-15. Bah... close enough (I hope there aren't any mathematicians watching this program). Chris Michalak 20:37, 26 February 2008 (PST)

Ouch. [1] --Matthew 00:12, 27 February 2008 (PST)

That's close enough for me Scott Nelson 00:25, 27 February 2008 (PST)

Embedding directly into articles

Embedding images directly into articles with an <img> tag is possible: [2], or possibly more appropriate would be to enable it for the BC basemap as an exception: [3]. If Chris changes that in the settings, we can have BC basemaps embedded into articles - possibly even a default x km around the waypoint given in the hutbox template, if no alternative map parameters are given. That would be quite neat. --Matthew 10:57, 27 February 2008 (PST)

It might also be nice to allow external images from elsewhere on the VOC website, especially from the gallery. Scott Nelson 11:05, 27 February 2008 (PST)

On closer inspection, it looks like wgAllowExternalImages makes the mediawiki parser convert the url of an image into an image tag, rather than letting you specify the <img src="... - this might be tricky since the BC basemap URLs don't actually look like images. I expect it's possible to work around with a redirect if necessary. --Matthew 11:45, 27 February 2008 (PST)

Yeah, I actually played with that earlier today! But it doesn't work for the basemap URLs because Mediawiki only parses the URL as an image if it has an image like ending (.jpg, .png, etc). The basemap url doesn't fit that format. But yeah, should be possible to hack something together but not sure if I'll work up the motivation... Chris Michalak 12:53, 27 February 2008 (PST)

So is wgAllowExternalImages activated? It doesn't look like it. If you switch it on I'll try to hack something... it should be a fairly simple mod-rewrite line, or maybe a few lines of php depending on exactly what mediawiki accepts as a valid image url. Would require the ability to load external images from carroll.org.uk - I promise not to hotlink Veenstra's famous photo onto the home page ;) --Matthew 14:54, 27 February 2008 (PST)

Wouldn't it me better to put any php hacks or stuff like that on the VOC website instead of your personal website? I mean, just in case you were to get deported to Syria or something. Scott Nelson 15:41, 27 February 2008 (PST)

Yes, hacks are better off on the VOC website, but development is easier on my own site. That also goes for the utm-lat/lng conversion hack used in Template:Coord although that is perhaps harder to move than this hack because it relies on calling external software (cs2cs) which it may not be available here.

OK, here we go: this URL takes 4 parameters in a pseudo-directory format to look like a regular image url - BBOX/WIDTH/HEIGHT/LAYERS/map.png and rewrites that to the correct location on the bc basemap, e.g. [4] If you want to run that locally, Chris, the mod_rewrite line is (all one line):

RewriteRule ^(.*)/(.*)/(.*)/(.*)/map.png$ http://libcwms.gov.bc.ca/wmsconnector/com.esri.wsit.WMSServlet/ogc_layer_service?VERSION=1.1.0&request=GetMap&SRS=EPSG:4326&BBOX=$1&WIDTH=$2&HEIGHT=$3&LAYERS=$4&STYLES=&FORMAT=PNG [R,QSA]

I think the commas in the bbox and layers should be ok, but if mediawiki decides not to parse that as an image url, we can split up the bbox into separate parameters and hard-code the list of layers --Matthew 15:56, 27 February 2008 (PST)

In part because I'm not too excited about allowing external images in general, and in part to make a nice clean wiki interface to inlining bc maps, I've whipped up a mediawiki extension to do the inline map. See the VOCWiki:Sandbox for an example. Basically usage is <bcmap>lat=50|long=123</bcmap>. It takes the same parameters/defaults as the template. Only downside is that you'll have to go through me to modify the layers and/or anything else that needs optimizing... Let me know if you can think of any improvements. In particular, I think we could make the image clickable and link to a higher resolution map of the same area. We could simply add an extra "linkscale" parameter. What do you think? Chris Michalak 14:10, 28 February 2008 (PST)

That's awesome Chris. I really like the idea of the "click to change the scale feature". I was just thinking if we wanted to control the layers more closely from the wiki side, we could allow the user to manually specify the layers field, but have it default to what it's using right now if the layers are not specified. This would also allow the call to the extension to be wrapped with a wiki template that had it's own alternate set of default layers. Scott Nelson 16:38, 28 February 2008 (PST)