Our web app includes simple mapping capabilities (currently just markers and KML overlays on an embedded Google Map). This works pretty well; the only real limitation we face is KML overlays that go beyond Google's size & complexity restrictions for KML.

We're considering standing up our own server (e.g. GeoServer or ArcGIS Server); but that seems like a huge step just to serve up (for example) 15 MB of KML when Google's limit is 10 MB.

I need a sanity check: Is there some middle ground between Google's free and easy API for KML overlays, and setting up my own tile server?

  • 5
    break your one KML into 2 smaller KML files - optional switch on and off data you do not require. – Mapperz May 18 '11 at 19:43
  • 1
    optional use fusion tables (100k row limit or 100mb in data) - gmaps-samples.googlecode.com/svn/trunk/fusiontables/… see groups.google.com/group/fusion-tables-users-group/browse_thread/… – Mapperz May 19 '11 at 3:24
  • @mapperz You can only upload 100MB of data at one time, but you can then import further rows to the same table up to 250MB of storage. – geographika Jun 23 '11 at 12:30
  • Although I see you knew that already.. gis.stackexchange.com/questions/6615/… – geographika Jun 23 '11 at 12:32
  • Fusion Tables service is shutting down December 3, 2019, so the option I see is to make the kml files smaller with software - QGIS desktop. there is also qgis python library. I used QGIS desktop with the Simplify geometry option using 0.0005. Then I export the created layer as kml. You can do this as batch job as well from the same menu. Then you can open all created layers in separate project and using the Console inside the QGIS desktop to convert all the .shp files to .kml – makkasi Nov 29 at 10:38

Since you have already invested in Google Maps development, I would highly suggest pushing all of the data into Google Fusion Tables, which can then be parsed onto the map in a similar way as KML with incredible performance (see WNYC Fusion Tables app). Consider it an upgrade to KML without having to drastically modify the front-end.

  • I think this is a great idea if your data does not on a > 24 hour update schedule. This is what google just told us (if kml is slowing down the browser use fusion tables) to do so I would say this is the best answer. – Steve May 18 '11 at 21:16
  • 1
    Thanks for pointing out Fusion Tables - somehow this had totally escaped my attention, very cool. Unfortunately this would be a bit clumsy to work with for data that changed frequently; and the overall storage limitations (250MB per user) wouldn't allow us to scale. – Herb Caudill May 19 '11 at 14:50
  • 2
    Note that the experimental Fusion Tables service is shutting down December 3, 2019. – Jonas Mar 28 at 9:41

You can break down your KML in to multiple KML's with a Parent KML referencing the smaller kmls. At least this will bring your file sizes down to a respectable level and allow you to reference much larger datasets as KML's.

Honestly KML is really only good for small datasets with few features and associated attributes. I wouldn't go near it as a file data source. If you're looking at these files getting bigger, I'd look at another data type, or definitely head down the GeoServer/MapServer route for distributed datasets.

  • 2
    But Network KML (with Superoverlays are design for large datasets) but requires a web server and rendering software Geoserver does a good job with this type of KMZ - works best with Google Earth as Google Maps API has restricted KML usage. – Mapperz May 18 '11 at 20:32
  • I never had much luck with superoverlays, except's with Google Earth Enterprise Client. Though I didn't spend a lot of time with on this. Definitely an option to explore, +1 @Mapperz – OptimizePrime May 18 '11 at 20:50
  • 1
    Use GeoServer with Oracle and works very well rendering KMZ (superoverlay) - live (constantly updated) data pulled very useful to users - had to tweak geoserver to get the speed up on refresh. – Mapperz May 18 '11 at 20:50

If you haven't invested too much time in your Google Maps API you could switch to OpenLayers which has a client side KML parser that can read your own KML files - see example below:


However for a 15MB file this would likely grind the browser to a halt. It is probably quite slow through the Google servers too when you get near the file size limit.

Is there really a need for the 15MB level of detail or could you simplify the KML without losing too much information?

Do you need to access the vector/geometry on the client-side? Could this data be served as images?

If neither of these is possible you will have to look at some map serving type of software. Along with GeoServer of ArcGIS Server you could consider MapServer to serve out the KML, or as a WFS. The benefit of using a mapserver is that the requests will only return the data within the map - reducing network traffic and decreasing load times.

  • After trying out Google Fusion tables Guddie's approach is by far the easiest to implement. You can only upload 100MB of KML at a time, but each user has a 250MB storage option (at time of writing). – geographika Jun 23 '11 at 12:25

If you're using version 3, you could strip out all attribute information except for a unique identifier and request the information via ajax calls to a web service whenever a user clicks a feature. If you have over 10 MB worth of points, it's probably a good idea to do some kind of clustering instead of displaying all those points at once. Also you might separate out your ground overlays into separate KML files.


Have you tried Google Fusion Tables. http://www.google.com/fusiontables/public/tour/index.html

You can load up to 100mb of data for free.


MapLarge has an interesting solution - they can replicate your data on their servers and then do the heavy lifting of generating tiles on the fly using their proprietary software. They offer Javascript APIs that can then overlay these on base maps from Google Maps, OpenLayers, etc.

Check out some of their examples - the speed is impressive:

It's not free, but it could be a good option for someone who didn't want the trouble & expense of standing up a separate server to generate these layers.

Not the answer you're looking for? Browse other questions tagged or ask your own question.