Category: Software

  • Using TileCache with Google Maps, Virtual Earth

    In order to use TileCache to cache tiles for use in the Google Maps API, you need three things:

    • A WMS server which supports the spherical mercator projection
    • A properly configured TileCache pointing to it
    • A small snippet of code to add a custom TileLayerOverlay to your Google Map
    • A small snippet of code to add a custom TileSource to your Virtual Earth Map

    WMS Server

    My experience is with MapServer, so that’s what I’m going with here.

    MapServer uses proj.4 for its reprojection support. In order to enable reprojection to Spherical Mercator in MapServer, you must add the definition for the projection to your proj.4 data directories.

    On Linux systems, edit the /usr/share/proj/epsg file. At the bottom of that file, add the line:

    <900913> +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 
                   +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs
    

    After you do this, you must add the projection to your wms_srs metdadata in your map file:

    map
      web
        metadata
          wms_srs "EPSG:4326 EPSG:900913"
        end
      end
      # Layers go here
    end
    

    This will allow you to request tiles from your MapServer WMS server in the Spherical Mercator projection.

    Configuring TileCache

    Your TileCache configuration will need to point to your WMS installation, using the parameters suggested for Spherical Mercator in the default tilecache.cfg.

    [google-tiles]
    type=WMS
    url=http://labs.metacarta.com/wms/vmap0
    layers=basic
    extension=png
    bbox=-20037508.3427892,-20037508.3427892,20037508.3427892,20037508.3427892
    maxResolution=156543.0339
    srs=EPSG:900913
    

    Here, you can see that I’ve used the MetaCarta Labs vmap0 WMS. If you’re using a standard MapServer WMS, you might have a url more like:

    url=http://example.com/cgi-bin/mapserv?map=/mapdata/mapfiles/vmap0.map

    Setting up Google Maps

    Finally, you must make a GTileLayerOverlay for your tiles.

     
        var myTileLayer = new GTileLayerOverlay(new GTileLayer(null,null,null,{ 
          tileUrlTemplate: 'http://example.com/tilecache/1.0.0/google-tiles/{Z}/{X}/{Y}.png?type=google', 
          isPng:true})); 
        var map = new GMap2(document.getElementById("map_canvas"));
        map.setCenter(new GLatLng(0,0), 0);
        map.addControl(new GSmallMapControl());
        map.addOverlay(myTileLayer);
    

    The ‘type=google’ flag on the end of the URL tells TileCache to use the “Google-style” 0,0 in the upper left corner.

    Once you’ve done this, you should have a TileCache layer on top of your Google Maps base layer. You can see an example of this setup, just for proof that I’m not putting you on. 🙂

    Virtual Earth Javascript

    “But I don’t like Google!” you say. “I want VE!” Well then, why aren’t you using OpenLayers already? I mean, that’s what it’s for, right? 🙂

    More seriously, VE isn’t much more difficult:

        vemap = new VEMap('myMap');
        vemap.LoadMap(new VELatLong(0, 0), 0 );
        //Add layer
        var tileSourceSpec = new VETileSourceSpecification("mclabs", null, 1, 
           [new VELatLongRectangle(new VELatLong(-86,-180),new VELatLong(86,180))], 
           1, 16, function (tileContext)
    {
       if(tileContext != null && tileContext != "undefined")
       {
          var key = tileContext.ZoomLevel+ "/" + tileContext.XPos + "/" + tileContext.YPos + ".png?type=google";
          var path = "http://example.com/tiles/1.0.0/google-tiles/" + key;
          return path;
       }
    }, 0.8, 100 );
         vemap.AddTileSource(tileSourceSpec);
        
         var tileLayer = new VELayerSpecification(VELayerType.VETileSource,"mclabs","mclabs");
         vemap.AddLayer(tileLayer);
    

    And, for your viewing pleasure: an example of the same tileset in use.

  • TileCache in Debian

    I took the last week of the year off from work, and I spent most of the time doing a push to get some of the software that I help develop into Debian.

    Debian is a Linux distribution that is built and maintained almost entirely by volunteers: it is the basis of the very popular Ubuntu operating system used on desktops, and is also used heavily for both desktops and servers at MetaCarta. Getting a package into Debian’s main repository is an indication that it meets the projects (relatively stringent) guidelines for inclusion into the repository.

    The first package that I did this for was TileCache. TileCache is a relatively simple to install utility, but it has significant benefits from being installed directly on the system — such as the ability to place the configuration file into the main configuration files locations, etc. In addition, TileCache is a relatively widely used piece of software — meaning it could have benefits for a number of users.

    New packages are typically packaged by a user, then a ‘sponsor’ is searched for. A sponsor is a Debian Developer — someone with the rights to upload packages to Debian — who will take on the review of the packaging materials to ensure that the meet Debian’s guidelines.

    Thanks to a thorough and patient review by Paul Wise, from the DebianGIS list, TileCache was able to be put into Debian in less than a week’s time, and is now available to users of Debian “Sid”/unstable. Barring any problems with TileCache showing up, in 10 days, TileCache will be migrated to “Lenny”/testing. Additionally, I believe that this means that TileCache may be included in the next Ubuntu release. (I’m not sure on that — I don’t know the exact way that Ubuntu pulls its packages in.) You can see information on the TileCache package on the TileCache Debian package info page.

    As a result of this, I’ve also packed the python-memcache library, maintained by tummy.com, ltd, which will make it easier for TileCache users to use the Memcached cache class.

    All in all, my initial experiences with Debian have been very positive, and I’m looking forward to continuing to work on building more of the software I build into Debian packages for wider distribution. Indeed, cleaning up things for Debian has resulted in a lot of other improvements to the code as well: meeting guidelines for documentation, packaging, etc. has resulted in adding documentation that didn’t otherwise exist, and cleaning up what did exist.

    You can track some of what I’m now maintaining or working to get into Debian via my maintainer page, as well.

  • early commits

    First commit in 2008:
    * FeatureServer: r412
    * TileCache: r242
    * OpenLayers: r5614

    All just updates to copyright dates, but hey, they make me fee special.

  • TileCache: Two announcements

    TileCache 2.0 has been released. From the announcement:

    TileCache 2.0 is a major change in that way that the code works internally: rather than one large module each for layers, services, and caches, these are now split up into individual files.

    The benefit that this offers is large: it allows for much easier customization of TileCache layer classes, with support for dropping your own custom modules into your TileCache config for either Layers or Caches. Additionally, it makes support for new services simpler.

    One of the new layer types is an ArcXML layer, and one of the new Service types is support for MGMaps, a mobile mapping client available on many different mobile phones. One of the things that’s *not* mentioned in the relase is that TileCache now has limited support for KML SuperOverlays, allowing you to use browse your worldwide dataset in Google Earth. (A handy thing to have, if you ask me.)

    Second announcement: TileCache in SVN now has support for storing tiles in Amazon Web Services S3 — simply tweak your tilecache.cfg, and enter:

    [cache]
    type=AWSS3
    access_key=your_access_key
    secret_access_key=your_secret_access_key
    

    save the file, and you’ll be caching in S3.

    (Also, in development, I have accrued a total of 4 cents of cost — but all of those are rounded up numbers, I’m nowhere near actually having to pay any ‘real’ money yet on any of their four metrics.)

    Included as part of the Cache layer is a handy set of management tools for your S3 cache:

    Usage: AWSS3.py [options] action    
        action is one of: 
          list_locks
          count_tiles
          show_tiles
          delete <object_key> or <list>,<of>,<keys>
          delete_tiles
    
    Options:
      -h, --help  show this help message and exit
      -z ZOOM     zoom level for count_tiles (requires layer name)
      -l LAYER    layer name for count_tiles
      -k KEY      access key for S3
      -s SECRET   secret access key for S3
    

    There’s probably a lot more that should be done with regard to the S3 cache layer, but for users for whom outsourcing data management is an acceptable cost, you now have the ability to use S3 more easily.

    Enjoy!

  • TileCache Talk

    Schuyler gave a great overview of TileCache, how to use it, and what it does earlier today. It was good that I didn’t have to give it. 🙂 Came together really nicely. From the talks, sounds like a few people are interested in it, and more than a few people are already using it.

    TileCache is a weird piece of software, because it’s very good at what it does — per user, it seems like I get significantly fewer questions for TileCache than OpenLayers or something else. This is good, but means that my insight into the number of TileCache users is way lower than into OpenLayers.

    Still, good to see the high interest in TileCache, and a great presentation by Schuyler which is great for people getting into it.

  • Broader OSGeo Contributor

    In the last couple weeks I’ve contributed to two other OSGeo projects, besides OpenLayers:

    Even though they are minor changes, it feels nice to participate outside the OpenLayers/MetaCarta bubble.Site for optical communication

  • MapServer AGG Rendering: Now With Fonts

    Today, I finally made the switch from the 7 month-running Mapnik based homepage map on the boston freemap to a MapServer 5.0-based AGG rendering.

    The new map has had more cartography put into than any existing Boston Freemap to date. Maps like:

    Cambridgeport
    The state of Massachusetts
    Downtown Boston

    All demonstrate some of the qualities offered by the new MapServer.

    Among other things, the new maps:

    • Have had the labels lowercased, to fit more text in (Python OGR script I wrote, help from #gdal)
    • Have had sortshp run over them, to order them so that you don’t get weird overlaps (help from danmo)
    • Have had additional cartography work done in order to create a better fit for labels
    • Benefit from the excellent AGG rendering work I’ve been describing here, by tbonfort.

    In my opinion, the look and feel of these maps really does approach the level of quality that the commercial services have set, as far as rendering goes. MapServer’s leaps and bounds in the past couple weeks in rendering have changed the game from being a “Work on the rendering” game back to a “Work on the cartography” game.

    I want to send a special thanks to tbonfort and all the work he’s done recently to make this happen! The rendering is simply incredible in comparison — truly night and day. I’m so happy to be back in MapServer land where the hard work I’ve done on this cartography hasn’t gone to waste. He and the other MapServer developers have really brought me back into the fold with the latest work, and I’m happy to be there.

    The font work really doesn’t show up well in a small screenshot — it’s a total affect that makes a difference. Comparing AGG to GD is probably pretty informative though.

  • MapServer AGG Rendering: Symbols now AGG

    A MapServer developer (Thomas Bonfort) pinged me this morning, using my Boston Freemap as remote testing of a patch for MapServer’s agg rendering. (It was a very minor difference: little rounding errors were causing small black pixels in some places on the map.) In the process of testing a patch for him, he also pointed out that the newest SVN has added AGG symbol support.

    The end result is that my comparison from the other day has now gotten even better:

    MS 4.10:

    SVN Rev 6432 + minor patch:

    Now the only thing that’s left is to fix those labels… Wonder if I can learn enough C++ in the next week or two to help get that in. 😉

    Nicely done work on the symbols! Better every day.

  • MapServer AGG Rendering: No Longer Disappointed

    Click for larger image
    With Steve Lime’s help on my previous post on the topic, I’ve been able to turn my previously somewhat dissappointing map into something that is definitely coming out way ahead of where it was. (Click the image to see a bigger version of the same area).

    First trick: Removing ‘antialias true’/’transparency alpha’ lines from my mapfile, as Zac and Steve both mentioned on the previous post. This actually did most of the work. Looking back, had I actually removed them all, that would have done all of the work, but I missed one, so my polygon fills were still not working. Thankfully, Steve is a great man, and committed fixes for that to trunk, so now I’ve got real pretty images serving up out of the Boston Freemap. With these changes, the label problems aren’t nearly as pronounced as I’d seen them be on other maps.

    I definitely feel like this is a huge step in the right direction.

    Old:

    New:

    Pay extra attention to the T lines, which are one of the more obvious failings of the GD rendering.

    Many many thanks to Steve for his help in turning the rather disappointing map into something that I’m really very happy with. I’m glad to be proven wrong — in exactly the way I hoped I would be — on the problems with MapServer’s AGG rendering. I’m looking forward to converting more maps in the near future.

  • MapServer 5.0 Agg Support: Disappointing

    The MapServer 5.0 beta is out. For a while, people had been mentioning the AGG support, and I even saw a pretty great demo put together by DM Solutions that demonstrated the functionality, and I had been impressed.

    I was disappointed to learn recently that the fonts are still going to continue to be rendered by GD for the 5.0 release: really, the biggest case where I care about smooth lines is in fonts, because it makes the difference between the ability to use an 8px font, and the corresponding increase in number of labels, and being forced to use a 10px/11px font. (Small fonts become less and less readable at smaller sizes without sub-pixel rendering.) However, I was hoping that the rest of the support would be sufficient that I would be happy with switching the Boston Freemap over to using AGG instead of GD as the renderer.

    This morning, I grabbed MapServer, and figured out how to build it after some stumbling. MapServer’s default of “Don’t include anything” is probably a great idea for most people, but for me, it definitely was at stumbling block. Just an example: I was trying to set up –with-agg. I knew I had installed it, and files were in /usr/include/agg2 and /usr/lib/libagg.a. But there’s only one directory! So I tried just pointing to /usr/lib, and got:

    error: “could not find agg_rendering_buffer.h or libagg.a in /usr/lib.”

    Well, obviously agg_rendering_buffer.h wasn’t there, but libagg.a was! I got there eventually by reading the configure script. It actually wants you to point to /usr, which would have been clearer if it asked for ‘AGG *prefix*’ instead of just ‘AGG directory’. I’m sure this stuff is obvious to people who roll their own, but I love my debian, damnit! 😉

    I then ran into an error in building mapagg.cpp, #2188, which I was able to fix by commenting out the offending lines, and an error in building php_mapscript, which I solved by removing that from the build.

    I eventually got it built, and bumped into what I eventually filed as a bug: #2187: WMS Request for DRIVER AGG/PNG claims ‘invalid output format’. FrankW was kind enough to help me fix mapwms.c so I could continue to play.

    I now have an agg demo of the Boston Freemap. However, I find it very disappointing. The lines actually look *more* jagged in some cases, and for fonts without an outlinecolor, the text is almost unreadable. Additionally, it seems that the blue of my water has changed to be a weird grey color. You can compare against 5.0’s GD rendering and 4.10’s GD rendering — the two differ only by what likely amounts to rounding errors.

    The agg rendering is simply not up to snuff. I’ll admit I’ve put more than my fair share of work into getting the Boston Freemap to look good with previous versions of MapServer, but this definitely seems like a step backwards.

    I’d love to be told that I’m missing some obvious “Make Output Pretty” option, but if there is one, the AGG RFC doesn’t mention it.

    I’d hoped to have a brilliant demo of the power of MapServer. Instead, I’ve got disappointment and pain. It’s a shame that it has to end this way… 😉

    The mapfile for the Boston Freemap is, of course, available, if someone feels like trying to understand better why the problems exist. The data is also available, though it’s likely easier to just get it direct from MassGIS.