Colors lost during KMZ import

thomaschristian's Avatar

thomaschristian

21 Apr, 2020 09:48 PM

I'm importing a KMZ that classifies terrain according to the Avalanche Terrain Exposure Scale (ATES).

Colors are very important in ATES and anyone familiar with the rating system can understand terrain complexity at a glance thanks to its color-coding. ATES ratings are very important to our AvSAR team and may inform a go / no-go decision.

Unfortunately colors are lost in SAR Topo during the KMZ import and all polygons are rendered in semi-transparent red.

I have inspected the KML file and as far as I'm aware the colors are defined according to the spec. Colors work fine in both Google Earth and Touch GIS. My test file is attached.

Are colors supported in SAR Topo KMZ imports?

  1. Support Staff 1 Posted by rmarcucci on 22 Apr, 2020 02:22 AM

    rmarcucci's Avatar

    Thomas,

    How are you generating the KMZ? Is there a possibility you could get that file as a geoJSON file type? GeoJSON preserves the style upon import to CalTopo, whereas KMZ doesn't preserve the color. You could also use an online converter if you don't have access to the file in geoJSON. Please let me know if you're able to get it worked out. I'll add color support to our suggested development list.

    All the best,
    Rom

  2. rmarcucci closed this discussion on 22 Apr, 2020 02:22 AM.

  3. rmarcucci re-opened this discussion on 22 Apr, 2020 02:22 AM

  4. 2 Posted by thomaschristian on 22 Apr, 2020 05:36 AM

    thomaschristian's Avatar

    Thanks for your input. I can ask the data provider about alternate formats but I don't think it will be an option. Their website (https://www.avalanche.ca/news/maps-of-ates-rated-regions-available-for-download) is currently preventing use of the Trip Planner, where ATES downloads are available, to discourage outdoor activity so I cannot be sure until I ask. However that page specifically mentions KMZ as if it's the only option.

    I converted the KMZ to GeoJSON first with ogr2ogr (GDAL 2.4.2, latest official release on Ubuntu) and then using https://mygeodata.cloud/converter/kmz-to-json but neither of the outputs contained any style information so the polygon again defaulted to semi-transparent red.

    Our backup plan is to pre-generate a static raster layer of the ATES areas with colour but it's definitely not our preferred option as we will lose the ability to enable / disable individual features and hover / click interaction.

  5. 3 Posted by thomaschristian on 22 Apr, 2020 05:41 AM

    thomaschristian's Avatar

    Are you sure GeoJSON supports color / styling? I haven't worked much with the format, but I can't find the words 'color' or 'style' anywhere in the specification https://tools.ietf.org/html/rfc7946

  6. Support Staff 4 Posted by Ben Lantow on 22 Apr, 2020 01:19 PM

    Ben Lantow's Avatar

    Hi there,
    KMZ is a massive scope and format. We do support styled individual elements. However this file is using StyleURLs to apply common styles from the top of the file to each element, which is not part of the format we support. If you generate this file, directly apply the styling you want to the object in that object definition and it will import totally fine with styling as expected.

    With regard to geoJSON, if you generate a geoJSON from within CalTopo it preserves all elements of the objects on the map (essentially creates an exact backup). Just like KML this is a massive format that allows for a huge number of things, converting online, especially from a KMZ file like this one (with styling applied via link within the file) will probably not preserve the styling.

    The easiest solution would be to talk to the person generating the KMZ file and have them alter the way they create the file if possible.

    Best,
    Ben

  7. Ben Lantow closed this discussion on 22 Apr, 2020 01:19 PM.

  8. thomaschristian re-opened this discussion on 22 Apr, 2020 05:54 PM

  9. 5 Posted by thomaschristian on 22 Apr, 2020 05:54 PM

    thomaschristian's Avatar

    Thanks for the response, however this is a little disappointing. If the product claims to support KML/Z then it should carry qualification to indicate that support is only partial.

    The data comes from Canada's national avalanche forecasting service, it conforms to the KML spec, and it imports correctly into multiple other applications. I anticipate some difficulty in convincing the data provider to change the format to suit a particular product.

  10. 6 Posted by thomaschristian on 23 Apr, 2020 12:01 AM

    thomaschristian's Avatar

    Following up on this - I'm experimenting with geoJSON format and I think I've hit another snag. I converted three layers from the KMZ to geoJSON and one of the layers fails to import with the error "Sorry, no importable features were found."

    The only difference I can see between the two layers that do import and the one layer that doesn't is Polygon vs. MultiPolygon. The problem layer's only feature is a MultiPolygon.

    Does SAR Topo support geoJSON import of MultiPolygon?

  11. Support Staff 7 Posted by matt on 23 Apr, 2020 11:56 PM

    matt's Avatar

    I know this doesn't help you any, but even Google's browser-based Google Earth version (earth.google.com) only supports a subset of the KML spec, although obviously it's more comprehensive than what CalTopo supports. In this case it looks like the file routes all the styles through a stylemap to provide separate normal vs highlighted styles, which is not something we've invested time in handling.

    As you've probably figured out, while GeoJSON doesn't support styles directly, we (mostly) implement the simplestyle spec for geojson.

    Can you send me your GeoJSON file? We probably need to make a change to accommodate multipolygons by splitting them into separate un-linked polygon objects (multi polygons/linestrings are not supported within CalTopo) but I'll look into it.

  12. Support Staff 8 Posted by matt on 24 Apr, 2020 04:08 PM

    matt's Avatar

    I was able to modify the import code to handle your example KMZ file (one of the zones is carved out inside of another one, so they're shown as overlapping since we don't support polygon inner rings). No guarantees on handling all future files that might use stylemaps and multigeometries.

Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:

»

Already uploaded files

  • CraterLake.kmz 96.1 KB

Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac