# GeoHistogram with GeoRange fails with WeightedData

positions = {GeoPosition[{30.446, -97.6482}],
GeoPosition[{30.446, -97.6482}], GeoPosition[{30.3898, -97.8822}],
GeoPosition[{30.3898, -97.8828}], GeoPosition[{30.286, -97.7639}],
GeoPosition[{30.1128, -97.7853}], GeoPosition[{30.3346, -97.9689}],
GeoPosition[{30.4366, -97.6139}],
GeoPosition[{30.2571, -97.6118}],
GeoPosition[{30.3876, -97.9066}]};
weights = {1/32632, 1/32632, 1/36224, 1/36224, 1/129325, 1/14217,
1/48702, 1/28012, 1/20287, 1/35752};
weightedPositions = WeightedData[positions, weights];


This works

GeoHistogram[positions, GeoRange -> Quantity[3, "Miles"]]


This works

GeoHistogram[weightedPositions]


This fails

GeoHistogram[weightedPositions, GeoRange -> Quantity[3, "Miles"]]


with the error message

MapThread::mptc: Incompatible dimensions of objects at positions {2, 1} and {2, 2} of MapThread[Append,{{{-97.7639,31.8036}},{1/32632,1/32632,1/36224,1/36224,1/129325,1/14217,1/48702,1/28012,1/20287,1/35752}}]; dimensions are 1 and 10.

This seems like a bug. Any ideas on how to work around it?

Update

Reported to WRI, CASE:4220082.

Update 2

WRI has confirmed that this is a bug in 11.3.

• I can confirm that I've seen this behaviour as well, I think it's a bug too. Notice how it functions if you give a GeoRange of, say, 100 miles. Similar issue in GeoSmoothHistogram. – Carl Lange Feb 2 '19 at 7:38
• This bug is still unfixed in 12.0 (I just checked). – Carl Lange Apr 12 '19 at 8:45
• @CarlLange Thanks for checking. That is disappointing. I have been following some of the threads on the chat regarding open source and WRI focussing on new shiny stuff while significant bugs in many areas e.g. graphs have not been fixed for a long time. I hope WRI does a 'bug fix only' release in the near future. – Rohit Namjoshi Apr 12 '19 at 22:43
• I have just updated my answer with a significantly better workaround - just use Show. – Carl Lange Apr 12 '19 at 22:50
• @CarlLange That is a great workaround. Thanks! – Rohit Namjoshi Apr 12 '19 at 23:54

I agree that this is a bug. Please report it to WRI.

A strong workaround is just to do

Show[GeoHistogram[weightedPositions], GeoRange -> Quantity[3, "Miles"]]


This functions in at least 11.3 and 12.0.

(The following is my old, much poorer answer)

A workaround is to filter the data for only what's going to be displayed. However, this has some issues, since the data displayed will only be on a local scale (within 3 miles, for instance) rather than a global scale (ie, all your data). If you're going to use this workaround, please don't rely on it for $$\#Science$$.

First, we get the centre point of your data:

centre = GeoPosition[Mean /@ GeoBounds@positions];


Then, we create a GeoWithinQ function to determine whether or not to include the data, with the same GeoRange specification we care about:

within = GeoWithinQ[GeoDisk[centre, Quantity[3, "Miles"]]];


We're going to pass an association rather than weighted data - it works the same way but it's easier to filter an association:

data = AssociationThread[positions, weights];


Finally, in our call to GeoHistogram, we pre-select the data to be used with KeySelect[data, within]:

GeoHistogram[KeySelect[data, within], GeoCenter -> centre,
GeoRange -> Quantity[3, "Miles"]]


It's really not great, but at least this evaluates.

• Carl, Thanks for the workaround, but as you cautioned, it does not preserve the global scale. For now, I am going with DynamicGeoGraphics[GeoHistogram[weightedPositions]] so I can manually pan and zoom. – Rohit Namjoshi Feb 3 '19 at 0:44
• @RohitNamjoshi Yes, that's a nice workaround. It seems like there were many changes to the Geo functions in version 12, so hopefully this will be fixed in the near future. – Carl Lange Feb 3 '19 at 5:52