Discussion Board

Results 1 to 3 of 3
  1. #1
    Registered User
    Join Date
    Jul 2013

    Question KML size and KMZ support


    I have large KML files that are generated by my software that are result of Drive Testing. The files are compressed to KMZ files, resulting in a much smaller size. (Example: A 74MB KML is compressed to a 2.18MB KMZ).

    Since HERE Maps does not currently support KMZ packages (and I also ask, when will this be available), what is the maximum supported size for a KML file or amount of placemarks?

    Best regards,

  2. #2
    Regular Contributor
    Join Date
    Aug 2011

    Re: KML size and KMZ support

    If you look at the Advanced Earthquake example, you will be able to see that the library is able to handle a KML file of at least 1.1MB. I haven't tried larger files mind you.

    Supporting KMZ is not considered a high priority at the moment, the main blocking point for rendering very large files is the browser itself (which is obviously not something under the control of the API.) As it is the 1.1MB file is OK on Chrome, sluggish on Firefox and painfully slow on IE. My assumption is that the architectural decision has been made not to include unzip support for KMZ directly since it would add to the size of the library and increased footprint whilst only being relevant for a small number of use cases

    For adding unzip support, there are existing libraries which are able to do that - see this blog for example. You could load and inflate the file using a third party library, and then call
    nokia.maps.kml.Manager.parse() on the XML document itself.

    For processing *really* large files you could even pre-process your data server side and retrieve only a subset of the data based on the view port.

    The problem is of course that KML is based on XML and by its very nature it is relatively verbose.
    Last edited by jasfox; 2013-07-26 at 16:22.

  3. #3
    Registered User
    Join Date
    Jul 2013

    Re: KML size and KMZ support

    Thank you for your feedback. I've come to realize that the server processing is a necessary step in the workflow, as it will increase the user experience by not pushing the entire data to the browser and gives the flexibility to load a lot of placemarks without having an impact on performance right away as I'll be possibly be dealing with over 1M placemarks. It also gives the flexibility of manipulating these nodes and not having to iterate them (from my experience with google maps).
    Last edited by danimt; 2013-07-26 at 16:41.

Similar Threads

  1. Replies: 2
    Last Post: 2010-07-13, 17:42
  2. NDEF message/record size and phone buffer size
    By npr.novo in forum Near Field Communication
    Replies: 3
    Last Post: 2009-10-12, 12:56
  3. PIXEL Size support
    By amitkamboj in forum Symbian Tools & SDKs
    Replies: 5
    Last Post: 2009-01-10, 11:42
  4. Support for Certificate Authority Root Certificates with key size 4096bits
    By dhanas_r in forum Mobile Java Networking & Messaging & Security
    Replies: 1
    Last Post: 2008-08-20, 22:40
  5. Replies: 1
    Last Post: 2006-12-07, 03:44

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts