Overriding the Default CSS for LayerSwitcher in OpenLayers

January 25th, 2010

So last week I was putting some new imagery online and was building a quick map interface in OpenLayers. However, I had more layers than would appear in the LayerSwitcher if it was contained within the map div. OpenLayers makes it easy enough to pull the LayerSwitcher out into its own div with

map.addControl(new OpenLayers.Control.LayerSwitcher({‘div’:OpenLayers.Util.getElement(‘layerswitcher’)}));

But this Leaves you with the LayerSwitcher hopelessly pinned in the upper right corner of the screen as far as I can tell. If someone knows a easy way to place the LayerSwitcher other than what I tried let me know.

In anycase whether or not any of the following is a good idea remains to be decided, but it got me where I wanted to go the other day. I wanted a solution that didn’t involve altering OpenLayers.js or it’s styelsheets.

First, I yanked the LayerSwitcher out of the map div and into it’s own with the id “layerswitcher” using the line of JavaScript above.

Next I Wrapped that “layerswitcher” div in a wrapper div and positioned it on the left hand side of the screen. The “layerswitcher” div inherits from the wrapper to force the position. The trick to making the style overrrides work is to add the !important tag to each style of the “layerswitcher” div, without this the default styles will persist.

<div id=”layerwrapper”  style=”position:absolute; top:82px; left:0px; width:208px;”>
<div id=”layerswitcher” style=”position:inherit !important; width:208px !important; “></div>

The last step was a little hacky, but seems to work (its been going fine for about 4 days now). Without this next bit the LayerSwitcher overflowed the div containing it, letting the background color spill out past where I would have liked. So to alter the style of the actual LayerSwitcher at load I found out that the actual layer list seems to be contained in a block with id OpenLayers.Control.LayerSwitcher_214_layersDiv”. Seems to be the same id every time so far; I tracked it down with FireBug in Firefox. The reason it overflowed was that it had a width set to 100% and 75px of right padding. So I put these two lines in my init() function that fires onload():

document.getElementById(“OpenLayers.Control.LayerSwitcher_214_layersDiv”).style.width = “198px”;
document.getElementById(“OpenLayers.Control.LayerSwitcher_214_layersDiv”).style.padding = “5px 0px 5px 10px”;

You can see how it looks in the screenshot here. As I said not sure if any of this is a good idea or good practice, but I got what I was going for. When I have more time I’ll make a nice external menu with GeoEXT, but for now this got the site online.


Getting Started with ESRI GeoProcessing Using Ruby

August 21st, 2009

So ESRI has chosen Python as their language of choice for GeoProcessing. Some of us however, prefer other languages to Python.  (Disclaimer: If you like Python that’s fine, I just prefer Ruby given my current circumstances).  So a quick look a the ESRI GeoProcessing documentation makes it clear that the GeoProcessing object is merely a COM object and should work in any COM compliant language. It just so happens Ruby can handle COM objects just fine in my experience. I have been using Ruby to do my GeoProcessing for some time now, but I have seen very little about this online and there is no section in ArcScripts for Ruby users.  So I decided to take it upon myself to start making some information and examples avaialble. I’ll try to continue to post examples and thoughts as I have time in the future. If there is anyone else out there using Ruby for GeoProcessing who has something to share please feel free to contact me. I’d be happy to post other peoples example/thoughts/experiences as well. In the meantime, here is part one, a brief intordution to using Ruby for GeoProcessing:


Ever find yourself with 100 KMZ files when you wanted KML files?

August 17th, 2009

So the other day someone sent me about 100 KMZ files that he had made by pinning points in Google Earth. He then said “Can you do….with these files?” The exact details don’t really matter, point is KML files are super easy to parse and work with compared to their zipped KMZ counterparts. Anyway, I didn’t feel like clicking on them all to unzip them and then rename them (Google Earth names the internal KML file doc.kml if you didn’t know that already). Since I had 7-zip installed I figured I’d write a quick script to unzip them and rename the doc.kml file based on the name of the KMZ file it came from. Ruby to the rescue; in just a matter of minutes I had my solution and it worked out really well. Anyway, if you ever find yourself in this boat here is the code I used: http://www.geooutlook.com/code/ruby/unzip_kmz_rb.html