GraphicsClusterer (FlareClusterer) and WKID 102100 problems

[christophernewbill]

I have a Graphics Layer which is populated in code. If I use a base layer that has a spatial reference of 4326, the clusterer works as intended. If the base layer being used is spatial reference 102100, then I get some weird behaviors with how items are clustered. For example, one graphic's location is listed as outside of Budapest, but it gets clustered in Africa, no amount of zooming in will "uncluster" the item so that it displays in its proper location.

I tried overriding the ClusterGraphicsAsync method to do some testing, but it became apparent that simply invoking the OnClusteringCompleted event isn't all that's really happening behind the scenes to make magic happen. My best guess is the default clustering algorithm isn't working how it should.

I even tried messing with the resolution parameter in the ClusterGraphicsAsync method, but that only gets me slightly closer to the actual location for the weird clusters.

Not all clusters are as completely off as some. I can't find a good point of reference to say X is definitely the problem.

If I do not use the Clusterer everything will always display exactly where it is supposed to, regardless of whether the spatial ref is 4326 or 102100 (since I convert if needed before it gets added to my data source).

Ideas before I just go off and try and implement my own Clusterer that doesn't try to grab items that are clearly not within my defined radius (10)?

[MichaelBranscomb]

Hi,

Do you have a simple reproducer application and data/service you could make available to test? (I'm keen to test with the imminent 10.1.1 release).

Either zip up and post here, or alternatively feel free to email it to mbranscomb@esri.com.

Cheers

Mike

[christophernewbill]

Thanks for the response, Mike.

Sample project is attached. Ran into more weirdness throwing together a sample app. If I set the GraphicsSource to my ObservableCollection of Graphic, the base layer remains blank (and no graphics are shown). No exceptions are thrown that I can see. It has something to do with the Projection.WebMercator call, as if I don't do the conversion it shows fine where it is (although everything is essentially in Africa). App continues to run. I added a button that can be pressed to set the clusterer and show the graphics that are loaded.

Interested in seeing what may be happening, even if it's me doing something I shouldn't be.

v/r,
-Chris Newbill

[MichaelBranscomb]

Hi,

Thanks for the excellent reproducer. This requires some more investigation so I have submitted an issue to track this. I'll post an update as soon as i have more information.

Cheers

Mike

[DominiqueBroux]

Hi Chris,

I've tested your nice sample and I found out that the issue was coming from points having a latitude equals to 90 or -90.
When converted to Web Mercator projection, we end up with a Y value equals to + or - infinity and that messes up the cluster process.

The workaround for now might be avoid such latitude. After changing your code to:

    // add the objects as Graphics to our graphics layer datasource
    foreach (var asset in assets)
    {
        asset.Lat = Math.Min(89.9, Math.Max(-89.9, asset.Lat));
        var graphic = new Graphic .......

all seem OK.

Thanks

[christophernewbill]

Thanks Dominique (and Mike),

For some reason I didn't get the alert, so, I'm just now seeing this. The work around works as advertised.

A bit of cross-threading here, but do you have an update for another post you were active in regarding WMS as a base layer and it being displayed blank?

http://forums.arcgis.com/threads/53766-Single-WMS-layer-in-map-not-displayed

Would be easier to debug these types of issue with source. Perhaps those with a service contract. 🙂

v/r,
-Chris Newbill

[DominiqueBroux]

Thanks Chris.

Good to know that the workaround is working well.

There will be a fix in the next version (post 10.1.1).

do you have an update for another post you were active in regarding WMS as a base layer and it being displayed blank?

The fix is in the version 10.1.1 that is now out.

Would be easier to debug these types of issue with source. Perhaps those with a service contract.

No need of a service contract :), the sources of the toolkit, which includes the WMS layer, are available on codeplex.

[christophernewbill]

Thanks,

Last question, I promise (I think, heh).

The SDK requires an EDN. We're using API 2.4, which didn't. Are there any plans to release the SDK, or a "less capable" version without the requirement of an EDN? I went over the licensing requirements for the SDK, our usage falls under the Basic (no cost) area. We have a service contract, just not an EDN (I think).

I downloaded the source from codeplex, but it's not the ESRI.ArcGis.Client namespace (Map, Geometry, etc), just the "toolkit".

[MichaelBranscomb]

Hi,

The SDK requires an EDN. We're using API 2.4, which didn't. Are there any plans to release the SDK, or a "less capable" version without the requirement of an EDN? I went over the licensing requirements for the SDK, our usage falls under the Basic (no cost) area. We have a service contract, just not an EDN (I think).

There are currently no plans to release a separate version of the ArcGIS Runtime SDK for WPF which can be licensed for development without an EDN subscription. However, I'm not familiar with the details of service contracts so I'd encourage you to talk to your esri account manager.

I downloaded the source from codeplex, but it's not the ESRI.ArcGis.Client namespace (Map, Geometry, etc), just the "toolkit".

Correct - it is just the toolkit - but the source for the WMSLayer is included in the ESRI.ArcGIS.Client.Toolkit.Datasources namespace.


Cheers

Mike