Yes, your guess might be correct. As a hypercube has a limit specified in in the backend like the code below:
I would suggest you to use an other KML file which has only the polygons you are interested in analysing and use the background map image to display the omitted polygons like the image below.
Thanks and Regards,
Sangram, thanks for your reply!
I learned from a site which said Qlik sense only support 3333 polygons, while my KML file only has 31 state/province data, though some states have 100+ sub polygon. Yesterday, I tried to append polygon data one by one, state by state, and I did find some states with too many sub polygon will fail. So now I am wondering how can I merge these polygon areas to one polygon, you see, if it works, that means there is only total 31 polygon areas, which can supported by Qlik sense.
Do you think if it works or not? and how can I use GeoAggrGeometry function?
As you have recognised which sub areas have to be aggregated to form one polygon, I think you can achieve it using a for loop, Resident load with a where clause(Just loading the sub-polygon paths and using the GeoAggrGeometry(field_name)) and concatenate the results into one table.
As the polygon paths are not going to change hope fully . It would be better to find a KML file with the polygons you need.
Thanks and Regards,
Thanks to All who help me out!
Finally, I figured it out, here is the reason. from my experience, there is either one of following issues to trigger the mentioned map error:
1. too many polygon areas, use GeoAggrGeometry Function to merge when loading the data.
2. the precision of the polygon coordinates data, create a tool to edit the KML file to reduce the precision of the map data, for me, one digit decimal data is OK. or try to find other KML file, but normally it is very hard to find !
now my app keeps alive!
Really suggest Qlik provides more technical details for their product (error descriptions), otherwise the user would have to take much time to understand what happened and find the workarounds.....
"2. the precision of the polygon coordinates data, create a tool to edit the KML file to reduce the precision of the map data, for me, one digit decimal data is OK. or try to find other KML file, but normally it is very hard to find !"
I having the same issue as you. My UK map worked up until 2.1.1. Now it no longer works. I took days to get it working as it should. So can I ask how to do this
"reduce the precision of the map data, for me, one digit decimal data is OK."
Thanks for any help on this.
"Really suggest Qlik provides more technical details for their product (error descriptions), otherwise the user would have to take much time to understand what happened and find the workarounds....."
I sometimes wonder what goes on at Qlik. Why change something that works to something that doesn't without providing a full explanation. And a work around. It almost like they have a small destructive element within Qlik. Maps are so important so why make it so hard to set them up?
Normally, you will find this if you open the KML file using text editor
when I say "the precision of the polygon data", I mean the precision of longitude and latitude data is too high. what you need to do is to replace those data with a short, simple decimal data, eg, round them to 116.42,34.63
coz there are many lines of GPS data, so you can not handle it manually. You can ask somene to write a simple scripts to read the KML file line by line to do the rounding work automatically. You can also find an altanative KML file with low data precsion.
After that, you can load the edited KML to QS , remember to use GeoAggrGeometry Function to merge polygon areas.
hope it is helpful to you!
I eventually managed to solve this issue
I did a len [LEN (KML_Area)] of the KML addresses. Highland was over 1 million characters. So I simple excluded this area and it worked. Devon was 658,000 characters but was able to handle this area.
This site below had some interesting stuff on this issue
And I couldn't get GeoAggrGeometry to work. I'm working my way through "hidden gems in qlik sense geospatial functions" so hoepfully will eventually work this out as well.
Samuel Mota, work with GIS technologies for a long time
Considering that you are aware that KML is not the ultimate file format for geographic data and it does have a number of downsides on storage and even on processing .... here are some techniques:
- Use KMZ instead of KML - KMZ is a compressed (zip) format for KML;
- If not possible to use KMZ, strip all spaces and new lines from the KML (useless if you use a compressed format)
- Use Styles and BallonStyles to configure your map symbology and behavior;
- Edit the file to consolidate the <STYLE> tags. Usually the Google Earth app is not very smart on reusing the tags;
- Simplify the data to have less vertexes - there is a number of algorithms and tools out there. Take a look at for lines or the ready-to-use tool based on it: (or buy a tool like for polygons)
- Reduce the decimal places on coordinates (of course, it'll reduce the precision - analyze your use case)
I have never used this tool, but you may want to try it:
I eventually found this site for reducing the number of decimals
It's free and did the job very quickly. Highland reduced from around 3 million characters to 1.5 million based on 5 decimal places. (4 distorted the map slightly or a lot with 3 or less). I also used "optimize KML file size" (US$20). It reduced the number of characters slightly for Highland but not much. But using both worked OK. That is reduce the decimal's to 5 and then run optimize.
I tried Qlik's geogetboundingbox with 15 decimal places but it still didn't work.
Re getAggrGeomentry. I tried this and it increased the number of decimals back up to 15. So instead I just grouped greater London using the visualization grouping facility. Even though it still showed the boundaries (like GetReduceGeometry).