rmarcucci on 22 Apr, 2020 02:22 AM
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.
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.
Ben Lantow on 22 Apr, 2020 01:19 PM
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.
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.
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?
matt on 23 Apr, 2020 11:56 PM
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.
matt on 24 Apr, 2020 04:08 PM
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.