KML Display Issue
KML layers I upload do not draw properly. It seems like they are not being georeferenced properly. The map pans over to some unknown area and the scale bar show NaN. The KML displays properly in Google Earth.
Wondering if there is some confusion in my map with layers having different coordinate systems perhaps, or...
Thanks,
David
-
David.
We're having the same problem - did you find a solution?
On or internal environments, we get an Alert "Upload Data Error" with "An unknown error has occurred".
The HTML5 Viewer log shows a message that suggests traffic to the schema URL is being blocked:
"[error]" Exception has been thrown by the target of an invocation. The request was aborted: Could not create SSL/TLS secure channel.
On our external facing test environment, we don't get this error, but the KML is rendered as a horizontal line against a blank background and we see NaN as you described, suggesting it's incorrectly positioned. The KML displays correctly in applications such as Global Mapper.
0 -
Hi Graham,
Yes still an issue at 4.14.1. Support suggested a workaround to convert the kml to a shapefile or use another application. I haven't seen anything in latest release notes addressing this either unfortunately.
David
0 -
Still seems an issue in 4.14.2 It used to work in our 4.10 then something suddenly changed?
0 -
Same issue for us on 4.14.2. Rather annoying as we have a few clients that rely on uploading KML files into the maps for display purposes. Using the Shapefile workaround for now.
0 -
I'm seeing the same behaviour in Version 4.14.2.4.
1 -
Seems like they are just not going to fix this, focusing on their newer web viewer instead I guess.
0 -
Jared Spurdza is that the latest version? or did you mean to write 4.14.4?
0 -
we are currently running 4.14.2
0 -
Ah okay. I'm seeing the issue on 4.14.2. I believe it's fixed at 4.14.3 or 4.14.4. I haven't gotten around to testing it though.
0 -
Hi Everyone,
We fixed an issue in 4.14.3 where some uploaded KML files would display as a single horizontal line or in an incorrect location/extent, which appears to cover some of the cases that were mentioned here. Can you please try upgrading an see if this resolves your issue?Thanks, Stefan
1 -
Great, thanks. Upgrading to 4.14.4 fixed the issue.
David
0 -
All,
We upgraded to 4.14.3 (4.14.4 wasn't available as ArcFM Web) but it didn't fix the problem.
However, I’ve found a workaround to the KML upload problem.
I believe we had two separate problems.
The first is that although many applications (including Google Earth) open KML in either the compressed or uncompressed forms, trial and error showed that the Geocortex Essentials Upload tool requires KML in uncompressed UTF-8 Unicode variable-width character encoding format. If we convert any KML not with that encoding to UTF-8 using 3rd party software (e.g. Global Mapper), the KML opens successfully. Attempting to open a compressed KML shows the following error:
Exception has been thrown by the target of an invocation. Error occurred while parsing the KML: 400 - Internal kml parser error.\nDetails: System.Object[]
The second problem relates to TLS 1.2.
Our prototype environment had more up-to-date set of Windows patches, including for the .NET Framework. When we tried opening the same KML (that worked on our prototype environment) on our DEV environment, it worked okay, but it failed on our UAT and PROD environments with the following error:
Exception has been thrown by the target of an invocation. The request was aborted: Could not create SSL/TLS secure channel.
Our DEV environment has a primary spatial reference of WGS-84 (SRID 3857) which is able to process the KML’s geographic co-ordinates without reprojection. The spatial reference on our UAT and PROD environments is GCS_GDA_1994 (SRID 4283). So I think what was happening is the Geocortex Upload tool tried to call the Geometry service set in the Geocortex Manager Services tab (https://pwdgcess05.pwc.local/arcgis/rest/services/Utilities/Geometry/GeometryServer) but because ArcGIS Server services now force TLS 1.2 (since 2019), that call was being blocked. We think the .NET Framework on the Essentials server wasn’t set to use TLS 1.2 when requesting web resources.
The fix for us was to create two new registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319\SchUseStrongCrypto
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SchUseStrongCrypto
and set their values to 1 and restart the server. This allows the traffic to the geometry service to pass to ArcGIS Server so the geographic co-ordinates in the KML can be reprojected to the primary spatial reference on the Geocortex site.
It’s a similar problem to calling external services requiring TLS 1.2 as described in this article at myArcFM.
Hope this helps anyone else with the KML problem.
Graham
0
Du måste logga in om du vill lämna en kommentar.
Kommentarer
12 kommentarer