The following code works on Chromium :
var node = window.d3.selectAll('#L1 > *:nth-child(2)');
var bbox = node.node().getBBox();
console.log(bbox) // {height: 44, width: 44, y: -13, x: 144}
but not with nodejs + jsdom:
"TypeError: Object [ PATH ] has no method 'getBBox' "
M. Bostock pointed out that JSDOM doesn't support getBBox()
What D3js replacement to use to get the bounding box of #L1 > *:nth-child(2) ?
Past efforts lead me there : getBBox() based fiddle
Path's bounding box
Digging straight into the element's path data d="..." should work. An svg line is basically a set of x,y points. Assuming absolute coordinates without translation nor big bezier curves, which is the case of my D3js-generated svg lines, I'am finding in this data the min and max values for both x and y.
To do so, I get the d="..." svg line or multilines code. For simplicity sake, I rudely removes possible relative jumps such h30 or v20 since I never saw any in my D3js output, then clean out letters (aka svg commands : M,L,H,V,C,S,Q,T,A,Z), simplify the spaces and line jumps, then split by the remaining spaces. I get a clean arrays of coordinates.
Important to note, my selector directly target a single non-translated path.
var getBBox = function(selector){
var xmin, xmax, ymin, ymax,p;
// clean up path
var t = d3.select(selector).attr("d"); // get svg line's code
console.log(t)
t = t.replace(/[a-z].*/g," ") // remove relative coords, could rather tag it for later processing to absolute!
.replace(/[\sA-Z]+/gi," ").trim().split(" "); // remove letters and simplify spaces.
console.log(t)
for(var i in t){ // set valid initial values
if(t[i].length>1){
p = t[i].split(",");
xmin = xmax = p[0]; ymin = ymax = p[1]; }
}
for(var i in t){ // update xmin,xmax,ymin,ymax
p = t[i].split(",");
if(!p[1]){ p[0]=xmin; p[1] = ymin;} // ignore relative jumps such h20 v-10
xmin = Math.min(xmin, p[0]);
xmax = Math.max(xmax, p[0]);
ymin = Math.min(ymin, p[1]);
ymax = Math.max(ymax, p[1]);
} return [[xmin,ymax],[xmax,ymin]]; // [[left, bottom], [right, top]] as for https://github.com/mbostock/d3/wiki/Geo-Paths#bounds
}
var bb = getBBox("path");
JSfiddle DEMO
Groups bounding boxes
For groups of multiple paths, you may want to traverse the svg DOM to loop upon each single path of the group in order to update xmin, ymin, xmax, ymax.
Translated elements
To handle translated elements, adapt further.
Alternatives
Other better approaches may exist. Remember to check if getBBox() and getBoundingClientRect() are available in your context, since they are native and very convenient.
The reason why getBBox/getBoundingClientRect/getClientRect does not work in NodeJS+JSDOM is that calculating these values of an SVG (or HTML) element involves massive amounts of computation.
First, all CSS code in <style> elements must be parsed (which is already not trivial). Then the CSS selectors, cascading and inheritance rules must be applied to know what size, position or line width an element has. And even after you know all style property values, you need to do some non-trivial maths to calculate the bounding boxes: definition of different SVG transform functions, compositions of these, bounding boxes of SVG primitives and Bezier curves. Browsers support all of these (they have to, in order to draw the element), but JSDOM is simply not meant for all of these.
But fortunately, canvg is a JavaScript implementation of most of SVG, which uses a <canvas> element to draw the image. It does support most of the above, and although it does not have an interface for giving you those data, fortunately it has very nice (and MIT licensed) code, so hopefully you can copy and reuse parts of it. As of now, the code is written in a single file, and it has CSS parsing, applying cascading rules, path data parsing, definitions of SVG transforms, applying transformations, and bezier curve bounding box calculation. That is, almost everything you need to calculate bounding boxes :) It does not, however, support CSS selectors, but it can reuse another library. But unfortunately, as far as I can tell, canvg is not ready for running in NodeJS, you probably need some tweaks.
There is, however canvgc, an SVG to JS compiler, which contains an older version of canvg, and it is capable of running in NodeJS. So it is easier to start with that.
I have written a code which plots multiple 3d points as spheres. I want to add some text near each sphere in 3D to mention some info about each point. But I have vtkPoints to store points positions which doesn't have GetOutputPort which I need in labelMApper (and also used glyph3d to make spheres)
vtkSmartPointer<vtkLabeledDataMapper> labelMapper = vtkSmartPointer<vtkLabeledDataMapper>::New();
labelMapper->SetInputConnection( vtkpoints->GetOutputPort() ); // No GetOutputPort()
vtkSmartPointer<vtkActor2D> labelActor = vtkSmartPointer<vtkActor2D>::New();
labelActor->SetMapper(labelMapper);
renderer->AddActor(labelActor);
You should construct a vtkPolyData from the points and set it as Input to the label mapper.
Something like this:
vtkNew<vtkPolyData> labelPolyData;
labelPolyData->SetPoints(labelPoints);
labelMapper->SetInput(labelPolyData); // Note: If you're using VTK from master (6.x), this is SetInputData(...)
renderer->AddActor2D(labelActor);
I have a KML file with placemarkers, each of which has polygon coordinates. I'd like to change the fill color of the polygons on the fly, depending on values I read in from a json file. My understanding is that Google caches kml files, so you can't easily change the fill color of polygons on the fly.
So I'm trying to convert my kml polygons into svg paths so that I can use Raphael to place my polygons on my Google map. Then I can change fill colors with javascript.
But how do I convert polygon coordinates to svg paths, does anyone know?
A sample set of coordinates would be:
<Polygon><outerBoundaryIs><LinearRing><coordinates>-80.098181,40.42127 -80.096479,40.421262 -80.096464,40.421409 -80.096448,40.421551 -80.096444,40.421583 -80.096434,40.421666 -80.096406,40.421931 -80.096389,40.422087 -80.096353,40.422423 -80.09583,40.426101 -80.095525,40.428234 -80.095315,40.429714 -80.095276,40.429989 -80.092585,40.428593 -80.092273,40.428431 -80.09069,40.430519 -80.090384,40.430924 -80.08989,40.430618 -80.089699,40.4305 -80.089499,40.430359 -80.088738,40.429886 -80.088418,40.429688 -80.088254,40.429585 -80.087931,40.429384 -80.087086,40.428859 -80.086867,40.428722 -80.086658,40.428592 -80.086493,40.42849 -80.08617,40.428282 -80.086177,40.428265 -80.08621,40.428188 -80.0864,40.427742 -80.086397,40.42749 -80.086394,40.427125 -80.08631,40.426427 -80.086335,40.425887 -80.086235,40.425409 -80.085776,40.425327 -80.085442,40.42527 -80.084993,40.424585 -80.085076,40.42448 -80.085542,40.423842 -80.085679,40.423125 -80.085659,40.423011 -80.085626,40.422827 -80.085191,40.421758 -80.08467,40.420859 -80.084258,40.420336 -80.083828,40.4201 -80.083078,40.420005 -80.082504,40.420072 -80.081444,40.420196 -80.080888,40.420181 -80.080775,40.420178 -80.080604,40.420173 -80.080122,40.420161 -80.079753,40.420151 -80.07947,40.420144 -80.079287,40.420139 -80.078239,40.420296 -80.077661,40.420418 -80.076213,40.420726 -80.075673,40.420766 -80.075298,40.420719 -80.075127,40.420625 -80.074909,40.420307 -80.075028,40.419779 -80.07539,40.419028 -80.07583,40.41836 -80.076065,40.418108 -80.076528,40.417616 -80.077217,40.417124 -80.077503,40.417002 -80.077725,40.416907 -80.078391,40.416622 -80.078614,40.416528 -80.078657,40.41651 -80.078693,40.416491 -80.078755,40.416457 -80.079174,40.416233 -80.079205,40.416217 -80.079292,40.416128 -80.079439,40.415977 -80.079456,40.41596 -80.079614,40.415473 -80.079604,40.415377 -80.079584,40.415179 -80.07958,40.415168 -80.079539,40.415042 -80.079499,40.414915 -80.079407,40.414785 -80.079742,40.414965 -80.08086,40.415568 -80.081458,40.415889 -80.081535,40.41593 -80.082292,40.416343 -80.08238,40.416392 -80.082597,40.41651 -80.082624,40.416525 -80.082787,40.416614 -80.083508,40.417007 -80.083934,40.417239 -80.084422,40.417505 -80.084622,40.417432 -80.084852,40.417348 -80.085329,40.417179 -80.085419,40.417141 -80.085948,40.41695 -80.086252,40.417184 -80.088463,40.418885 -80.088964,40.418631 -80.089036,40.418595 -80.089145,40.418539 -80.089173,40.418525 -80.089346,40.418438 -80.089376,40.418457 -80.089398,40.418471 -80.089964,40.418827 -80.090299,40.419055 -80.091306,40.419739 -80.091642,40.419967 -80.091803,40.420088 -80.091966,40.420043 -80.092445,40.419915 -80.092561,40.419885 -80.096792,40.418748 -80.098853,40.41815 -80.098868,40.418242 -80.09943,40.421273 -80.098181,40.42127</coordinates></LinearRing></outerBoundaryIs></Polygon>
Disclaimer: I'm a bit rusty on geodetics, but think your #1 problem here is the coordinate system - lat, lng are projection-dependent data points, whereas your screen is a flat pixel one. What you need to do is convert these to northing and easting points first.
There is a projection conversion library out there called proj.4 - use this to convert your coordinates. If needed, there is a javascript port of it that you can easily adapt for your use at https://trac.osgeo.org/proj/
Generic conversion process would go like this (LAT, LNG are actual coordinates.)
var source = new Proj4js.Proj('WGS84');
var dest = new Proj4js.Proj('GOOGLE');
var p = new Proj4js.Point( LATITUDE, LONGITUDE ); // replace with actual coords!
var pdest = Proj4js.transform(source, dest, p);
At this point, pdest.x and pdest.y will contain your SVG-compatible coordinates.
After your coordinates are converted to pixel units, simply plot them - and mind the range and units. Northing and easting coordinates will be in 800,000 range, so you will likely be applying some transformations, such as translation and scaling.
End result should look like this (being rusty, I may have messed up and flipped lat/lng around, etc.)
Here's a working jsfiddle with a conversion and plot: http://jsfiddle.net/LPzKV/1/
I am using Raphael to draw some paths. Each path has an associated rectangle [container] the size and position of the bounding box. I am using the container for dragging both shapes.
In the move callback, I update the both positions so they both move together.
This all works great until I serialize. I am only serializing the path, then creating the container on the fly after deserialization.
Immediately after converting to json and back, things look fine. I can print out the current transform of the path and it looks correct. Doing any transform on the path after this results in the path being reset and moved to 0,0.
Here is a fiddle that shows the problem.
If you move the rect, you can see both objects move together.
If you click 'Save/Load', things look fine, and the path prints the same.
If you now drag, the path gets reset to 0,0. Printing shows the transform has been reset from 0,0.
I am trying to find out how to make the path move as it did before serialization. Is something getting lost in the process? Or is there an internal state that needs to be updated?
Raphael.JSON serialises data stored in the elements. It does not preserve temporary data stored in the paper object so something does indeed get lost in the process when calling R.clear(). For example drag events bound to elements are not preserved.
However the main issue here is with your drag function, notice how dragging the square a second time applies the transformation from the top left of the paper. I suggest using Raphael.FreeTransform (which you already included in the Fiddle) to handle this.
I wrote both Raphael.JSON and Raphael.FreeTransform plugins and have struggled with the same issues. I'm currently working on an application that lets you save save and restore the state of the paper (similar to what you're doing) and it works fine. If you need any help feel free to open an issue on Github.
You need to capture the initial transform offsets of your elements when the drag starts and use those as the basis for your drag-move transforms. Consider the following:
var start_x, start_y;
cont.drag(function(x, y, e)
{
p.transform('t' + ( start_x + x ) + ',' + ( start_y + y ) );
cont.transform('t' + ( start_x + x ) + ',' + ( start_y + y ) );
},
function( x, y )
{
var start_bbox = p.getBBox();
start_x = start_bbox.x;
start_y = start_bbox.y;
console.log("Drag start at %s,%s", start_x, start_y );
} );
I've staged this in a fiddle located here.
Unfortunately, there is still an issue with the path -- it's offset is being incremented by the difference between it's bounding box y value and the y axis (a difference of 12, to be precise) each time drag is used. I'm not sure where that's coming from exactly.