Archive for the 'Software' Category

Using TileCache with Google Maps, Virtual Earth

Posted in Google Maps, Locality and Space, TileCache, Virtual Earth on April 18th, 2008 at 06:15:00

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

Posted in Debian, Locality and Space, TileCache on January 6th, 2008 at 13:07:51

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

Posted in FeatureServer, Locality and Space, OpenLayers, TileCache on January 1st, 2008 at 03:51:35

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

Posted in Amazon Web Services, Locality and Space, TileCache on December 22nd, 2007 at 17:57:51

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

Posted in FOSS4G 2007, Locality and Space, TileCache on September 26th, 2007 at 13:09:51

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

Posted in GDAL/OGR, Locality and Space, Mapserver on September 1st, 2007 at 08:36:41

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

Posted in Locality and Space, Mapserver, OpenLayers on August 8th, 2007 at 11:55:41

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

Posted in Locality and Space, Mapserver on August 1st, 2007 at 08:02:55

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

Posted in Locality and Space, Mapserver on July 31st, 2007 at 01:46:46

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

Posted in Locality and Space, Mapserver on July 28th, 2007 at 10:04:59

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.