I'm trying to adapt this example http://prag.ma/code/d3-cartogram/ to show information about obesity in 2002, 2005 and 2010 around the world. This the visualization: http://datauy.github.io/obesity-cartogram with a link to the code in the same page.
The problem I'm trying to resolve is that the shapes are not being distorted like in the original example with the alberusa projection. The colors seems to be mapped just fine but for some reason I can't distort the map. I tried changing the scale and looking into the cartogram.js code but I don't see anything that could be the problem. If I change the data to have a larger difference then I see the color difference but nothing on shape.
Any clue what is happening? Thanks!
The problem is due to Fiji and Russia having project extents which cross the edge and return to the left border. When the cartogram.js calculations complete, the path has a negative value in it which is causing the problem. I'm trying to resolve it myself and will update asap.
Related
I am using Mapbox GL JS to overlay an image of satellite data over Texas. The image is big enough to cover Texas, but even when using 100% correct geo-coords, the image is not in the correct place. I have to split the image into 6 long (west-east) images like such, and stack them vertically in separate image overlays :
This produces the desired result :
When using the 6 stacked image overlays (each 2 degrees tall and very wide to cover the state's width, by the way), the placement of the clouds is exactly perfect with zero issues. It's perfect except that having to make 6 image overlays to build this is not at all ideal and it adding processing constraints.
If I merge all the images into one big picture and overlay it using the same coords - the effect is wrong. Even though the image is exactly the same. I have highlighted the coastline so you can see that when using one large image overlay for the whole state, it becomes inaccurate. For a storm chaser (my target audience) this would not be unacceptable. I have tried manually adjusting the images but it is no good and I have wasted days of my life tracking this issue down, and it is absolutely Mapbox. I have ruled out the other possibilities like bugs in the software I use to get the data.
Here is the bad result with one overlay as opposed to splitting it vertically :
Are there any ideas to what may be causing this, and a solution? I am completely lost.
I had solved this long ago but since others have the same problem, it deserves an answer here. The problem has to do with projection. Images can be sliced and diced exactly by coordinates but they must match the projection of the map they are being overlaid on. In the case of Mapbox, it uses web mercator and images must be reprojected to EPSG:3857.
A utility to convert images (such as geoTIF) to this projection is GDAL (https://gdal.org/). A command using GDAL tools to convert an image would be something like :
gdalwarp -t_srs EPSG:3857 input.tif input-projected.tif
Hopefully this clears things up. These issues are basic knowledge in the GIS community. If you want to work with data like this, I can say that I recommend doing what I did : learn basic GIS tools and how they work. It will save you.
I'm having an issue getting LineString features to show up consistently. Here's the gist, I draw several lines and zoom to fit this content. When the page first loads sometimes the lines will be displayed and sometimes they won't. I can't seem to find any real reason as to why they don't show sometimes. I did notice however, that if I zoom out far enough the will pop in, then I zoom right back to the same starting level and they remain visible. The odd thing is the data is always there as are the features, I can see them if I use the getFeatures() method. Does anyone know why this is happening or what I could try to address this? Thanks in advance.
I'm trying to display a large number of images on a d3 display using T-SNE. The x and y coordinates are pre-calculated, the location on the svg area is adjusted using using translate/zoom.
At the moment they all display using the precalculated coordinates.
and they remain in place as zooming/panning.
I'm looking to use collision detection (like this example) to adjust the images locations slightly so that they don't overlap, but as much as possible maintain the rough global structure.
Here's my attempt so far
https://gist.github.com/GerHarte/329af8ee5ffd8a1f87c5
With this it loads as in the image above, but as soon as I pan or zoom, all the points expand out hugely to a completely different location on the canvas and look like this, they don't seem to overlap, but they're extremely far apart.
Is there something wrong in my code or is there a better way to approach this?
Update:
I followed Lar's answer here, with the slight addition of setting the raw data points to where Lar's code settles since the points are translated when zooming or panning. The results look great (see below), but for a larger number of points (5000+) it seems to crash before converging on a final result.
Are there any suggestions to improve the efficiency with this approach? Going to try the Multi-Foci Forced Directed approach.
I am building a tiled map based on d3. So I found the corresponding d3 example and copy pasted its code to start my implementation. I need to add overlays to the map so went on and discovered they were misplaced and did not follow the map tiles when zooming. I spent a lot of time bisecting the difference between my adapted copy-paste and the original example and found out this was due to the fact that the example uses v2 of d3 and I am using v3.
My findings is that the main change between v2 and v3 is the behavior of the zoom and translation together. So I tested by zooming and printing the translation vector, and my findings are:
In v2, the projection.translate vector is kept unchanged if the mouse cursor is on the (lat,long) = 0,0) on the initial tile.
In v3, the projection.translate vector is kept unchanged if the mouse cursor is on the top left (most NW point) of the initial tile.
I've made a fiddle in which I copy-pasted the example code, added my debug dots that should cover the earth plus a dot on Paris to see if alignment with the tiles is correct.
You will note that Paris is not correctly placed, (but would be if you run this on d3 v2).
So I guess now there is just some Math to do on my side to update the initial example logic, probably where the tile_origin or tile translation computation.is made. I just started to try to fix them but this seem not trivial. So I am asking here if anybody has an idea of what to change in the example to have it working in v3 (i.e. having a red dot following Paris whatever the zoom level is).
I also could not find any related change in the v3 changelog, if any knows what exactly changed this could help me.
Ok so the best solution is to start from scratch from a v3 example, like http://bl.ocks.org/mbostock/4132797 (which I tried and succeeded with) or http://bl.ocks.org/mbostock/4150951 as Lars Kotthoff commented.
I have a webpage to show some sound values. But when I zoom out, values are added and red zone is bigger that it really is.
You can see an example here: https://developers.google.com/maps/documentation/javascript/heatmaplayer
down side has an example and if you make zoom out, you see the red part bigger.
Is it possible to modify this behaviour to make a median or something similar? It is quite strange that during night, if you zoom out, red zone is so big (meaning that there is too much noise)
The merge rule of Google heatmap is currently density-based. Unfortunately, it still cannot provide a custom merge rule due to its implementation:
Current implementation of heatmap is very perfomance and is computed at client side. The idea is to render each feature as a greyed blur circle. The issue is if two circles overlaps the intersection zone becomes dark greyed because values are added. Later when all features are rendered the class gets an images of the layer, as a grid of pixels, and substitute each grey value pixel (0..255) with a gradient color previously created. (Referenced from Google Forum)
So, maybe you can try the heatmap provided by Nokia. It seems they provide a value-based heatmap, whose merge rule is not defined by density but the value of points.