ArcGIS KML vs QGIS KML

المشرف العام

Administrator
طاقم الإدارة
The answer is going to be a bit longer than Twitter would allow for, so here we go.

I decided to take this to the most basic of tests. Let’s set a point at 0°,0°. I used the find XY tool in ArcGIS 10.3, then converted the graphic to a feature (shapefile). Next, I used the Layer to KML tool. It kicked out a KMZ which I’ll explain in a moment.

I then brought the shapefile into QGIS 2.8. Right-click the layer, Save As… format Keyhole Markup Language (KML).

KMZ is actually just a zip file containing kml along with any additional files. You can actually rename this ArcKML.kmz to ArcKML.zip. When you do that, simply unzip it, and you have the KML and all the additional files in their native format.

So now we just pop open their hoods and have a look.

For one point at origin, 10 lines from QGIS vs 90 lines from ArcGIS. Pretty substantial if you ask me.


I tried this again, only this time using Hardin County, OH as the feature with 19 ODOT attributes. Code results were 54 lines from QGIS vs 238 from ArcGIS!


So how do they actually perform?

Google Earth:

To be fair, I used the KMZ file that ArcGIS kicked out. It is how they want their product to package it. When doing the point, ArcGIS included a (fuzzy) graphic matching the symbol used in the map in the KMZ file. They’ve gone to a bit of effort to make this possible, but the symbol can be switch to something else easily. They’ve also held on to the original feature name: Converted Graphics. They’re trying to keep it as close to the original as they can, so we’ll give them that. I tried the unzipped KML as well and it performs equally.

With the polygon, there are no attached images; the vector properties are added in the markup. But also, in displaying the attributes in Google Earth, they’ve done a good job to make it readable.

The KML from QGIS as you might have guessed relies on the default symbology of the software. And displaying attributes are a admittedly rudimentary.

Fusion Tables:

The more I use Google Fusion Tables, the more I like it. And it was for the use of Fusion Tables I made the switch to using QGIS. However I did find one snag I’ll mention a bit later.

First, Fusion Tables does not support KMZ, so I converted to ZIP and extracted the KML for the ArcGIS output. The result looks like:

The infoboxes and cards take their formatting from the description (which is identical to the popup in Google Earth) and changes would need to be modified there, but filtering and symbolizing by attributes is completely out of the question; it’s just not possible without re-entering all the data manually.


Being able to customize infoboxes and cards are a huge factor. I won’t go into details how that’s done, but if you’re unfamiliar with it, here’s an awesome tutorial on it https://support.google.com/fusiontables/answer/1244603?hl=en

With QGIS, the import results in:

Clean attribute data which can be symbolized, filtered, and customized as God intended.*

As I mentioned, after a while I ran into a snag: If you have NULL values in the data, the next filled attribute gets put in it’s place.


Heartbreaking, I know.*

I could fill in the NULLs with some place holder and kick this out in KML, but I don’t find that practical. I would do this as a CSV with a KML field, but there isn’t the option to calculate the KML in QGIS (only WKT). I’m sorry, QGIS, but…


So I’ve moved on to doing this through PostGIS adding a ST_AsKML(geom) and exporting as CSV. I know it’s an extra hassle, but it works really well without the NULL hangups QGIS has.

So after finally writing up on this, yes, the underlying KML from QGIS is cleaner more flexible, and arguably better, but depending on your use, may not necessarily be friendlier.




أكثر...
 
أعلى