Open NicoledeGreef opened 6 years ago
Is KML re-projection working on upload?
KML file styles are overridden. Also if you upload, but don't turn on clustering, points don't seem to draw. In fact, I could only get the attached file to work once. Saw a few upload errors, then it worked. Re-creating the app fails to enable clustering/drawing.
The points draw, but the initial stroke width of 1 renders them very, very small (width of 10 is reasonable for point features).
I managed to get the file uploaded by 'replacing' the initial data source. First time I added got an attachment error in the SMK interface when it tried to upload attachments.
Still need to have an option to honor the KML styles on upload as part of the MVP.
I've noticed that sometimes I can't get the clustering to display unless I also choose the heat map option. Noticed I can't identify points with clustering/heat map enabled. Intermittent upload file errors.
There's a bug we detected with a late change on the last release that's causing problems identifying with clustering (basically, pixel tolerance on click). Heatmaps currently don't allow identify at all (they don't have a point we can query). The upload file error is in the Admin UI side. I'll be working on a fix for that asap.
Note as well, I'll be making an update in the service side converter to bring it up to the KML 2.2 spec. With that, we'll be adding inclusion of KML "ExtendedData" tags, which will be used for attributes in a KML placemark.
While handling these updates, I'll also bring in support for parsing and using the KML style where possible and using that as the default layer setting. Users will still be able to override and upload markers via the admin ui.
Example of the KML api for attributes:
<Placemark>
<name>Easy trail</name>
<ExtendedData>
<SchemaData schemaUrl="#TrailHeadTypeId">
<SimpleData name="TrailHeadName">Pi in the sky</SimpleData>
<SimpleData name="TrailLength">3.14159</SimpleData>
<SimpleData name="ElevationGain">10</SimpleData>
</SchemaData>
</ExtendedData>
<Point>
<coordinates>-122.000,37.002</coordinates>
</Point>
</Placemark>
<Placemark>
<name>Difficult trail</name>
<ExtendedData>
<SchemaData schemaUrl="#TrailHeadTypeId">
<SimpleData name="TrailHeadName">Mount Everest</SimpleData>
<SimpleData name="TrailLength">347.45</SimpleData>
<SimpleData name="ElevationGain">10000</SimpleData>
</SchemaData>
</ExtendedData>
<Point>
<coordinates>-122.000,37.002</coordinates>
</Point>
</Placemark>
KML 2.2 with Extended data has been implemented and will be deployed to dev with our next release.
Additionally, we've update the loader/parser for KML files to attempt to pull out styling if possible. There are a number of caveats with this.
1.) Leaflet doesn't play well with mixed content, so our layers are working under the assumption of single data types. If you mix lines points and polys, and mix in renderers for them, the converter will likely mix values. 2.) If you include a marker URL, it will be automatically added as an attachment and downloaded. You don't need to add it twice. 3.) Style pre-parsing only occurs on the Admin UI client, not in the service. This means that it doesn't work if you manually add the attachment, and it won't work for KMZ files (yet, we just need to add the logic to the service as well, if it's desired there)
Extended Data 2.2 specification:
We've implmented the Simple extended data spec. KML will support data in the following format:
<ExtendedData>
<Data name="someAttribute">
<displayName>Some Attribute</displayName>
<value>123 Attribute!</value>
</Data>
</ExtendedData>
Display name is optional, and you can always modify the names in the layer definition directly via the Admin UI.
(side note, attributes are now applied automatically for WMS layers too, if they allow WFS requests)
Did some testing with the above posted Parks 2018 KML:
Loads up, with KML popup intact. Additionally, no fudging required to get the attributes loaded up as well, as they all come from ExtendedData tags.
Plus, a search query, for good measure:
Excellent. Still trying to reproduce. As discussed, control of the size of the pop-up would be important for authors, to tune the window and avoid scrollbars as per your screen shot. Not sure of the item ref #.
Will continue UAT testing June 4th
Continued testing blocked by a bug impacting upload of any data files:
Change made to KML to GeoJSON processing to handle potential problems with encoding
Author uses KML to source content.