GoogleMapsOverlay with Scatterplot/GeoJson Circles

[MikeKeane]

I've been using deck.gl and the GoogleMapsOverlay to visualise data on my map.

The problem I'm facing is when using either the ScatterplotLayer or the GeoJsonLayer to draw circles to the map, when panning up and down (north and south) the circles appear to grow/shrink, quite considerably. It appears more apparent when the radius is quite large, for example, I have some that are 100000 meters and larger.

I had not noticed this at first but when going back to the Google Maps documentation (which is where I came across deck.gl), it appears their example does the same (https://developers.google.com/maps/documentation/javascript/examples/deckgl-points).

[Pessimistress]

This is due to the Mercator projection's distortion. Thesame meter size appears larger towards the poles.

If you want stable radius, use radiusUnits: 'pixels'.

Please only open issues using the provided templates. If you have a question, go to Discussions.

[MikeKeane]

@Pessimistress
I do not want a consistent radius at different zoom levels (I understand that can be achieved by simply changing the radiusUnits).

The problem is, that the radius changes when panning around the map, without zooming. So a circle drawn just above the equator, appears to grow/shrink as the user pans up and down the map.

I understand that the projection used distorts the actual size of countries, etc, that are near the poles but this is not what is happening. The link I provided to Google's documentation clearly shows the problem. If you pan around that map, you will see the circles growing and shrinking as you do. The radiusUnits property is set to "meters", so at any given zoom level, the size of the circle should not change by simply moving around the map.

You have closed this issue but I do not think you have addressed it.

[Pessimistress]

Right now, deck.gl projects meter sizes across the map using the meter/pixel ratio calculated from the latitude at the map center. This is less apparent when it’s used standalone, as the built-in controller prevents you from panning beyond the map bounds at low zoom levels.

If you are simply looking for visual stability when panning up and down, we can look into mitigating this in the google-maps integration.

If you are looking for ways to project the meter sizes more accurately at low zoom levels, or visual stability when zooming into the high latitude regions, then it’s more complicated. We will essentially have to do more computation in the vertex shader at low zoom, which may have a hit on performance.

[MikeKeane]

I think it requires some work. This resizing seems to occur, to some degree, at all zoom levels

As I am simply trying to visualise Geospatial data , the circle, based on a lat and lng positioning and a specified radius, which indicates it covers a certain area on the map, should not be varying in size depending where I am on the map.

If this can be mitigated in the GoogleMapsOverlay then I think that is a start, but for anyone trying to visualise Geospatial data, as I am, this just doesn't seem to be quite there yet.

The library is great, in honesty, but on noticing this I'm a little disheartened.

[Pessimistress]

Thank you for your feedback. I would like to provide some background here.

This library was originally created to make visualizations with a geospatial aspect, instead of rendering geospatial data - in other words, its initial focus was on analyzing data on top of a map, not rendering the map itself. Over time its functionalities have expanded for both geospatial and non-geospatial use cases. We think of deck.gl as a generic-purpose visualization tool, more like d3.js, not ArcGIS.

With that said, we have been constantly improving the library's compatibility with the Web Mercator projection. I recall this same issue being discussed before, and the concern was that to accurately represent the Mercator projection's distortion, we will break existing applications that map data values to meter sizes, and therefore relying on the current behavior for visual comparison. My suspicion is that these use cases are not uncommon.

@ibgreen I am happy to revive some of my old investigations on this. I think we only need to calculate latitude-based unitsPerMeter at zoom<12, and with some gymnastics it might not be too expensive. It will be a maybe significant breaking change for some, including kepler.gl. It will also be hard to get the old behavior once we flip the switch.

[MikeKeane]

Thanks for your reply. That makes sense, and I appreciate the library does a lot more than just integrating with Google Maps.

I agree that I don't think my use case will be very uncommon, as displaying large amounts of data via the Google Maps API can be under-performant, so I hope you can find a way to implement some changes to accommodate stable meter sizes for the Web Mercator Projection via the Google Maps Integration.