So this is probably going to be a stupid question and I am missing something obvious, but I've hit a bit of confusion and I'm hoping someone can tell me where I am going wrong.
According to the d3 docs:
Important: the inside of a polygon is all points that the polygon winds around in a clockwise order. If your GeoJSON input has polygons in the wrong winding order, you must reverse them.
Ok, simple enough. However, for every GeoJSON file I've been trying from my project, which lint (via https://geojsonlint.com/) fine, are coming out inverted when trying to display them using d3's geopaths.
So I go to the d3indepth example, which has a nice small GeoJSON example included in it. The example works, and the example data works in my own code. But when I take that example data and run it through the linter, it fails with 'Polygons and MultiPolygons should follow the right-hand rule', and my own 'make sure this is correct' code identifies the polygons as counterclockwise.
Now, the example does seem to match what is listed in RFC7946
A linear ring MUST follow the right-hand rule with respect to the
area it bounds, i.e., exterior rings are counterclockwise, and
holes are clockwise.
So that matches the behavior I see in d3, but not the documentation, and seems at odd with GeoJSONLint.
In trying to figure this out I ran into this earlier question:
d3 v4 geo draws boundary inverted, which provided an even simpler test case. And again, the version that worked in d3 was counterclockwise and failed geojsonlint, while the broken version was clockwise, was inverted in d3, but passed the lint test.
So I guess the basic questions are:
What is correct?
Is the GeoJSONLint website wrong?
Related
I am working on a system to procedurally build meshes for "mines", right now I don't want to achieve visual perfection I am more focused on the basic.
I got the point in which I am able to generate the shape of the mines and from that generating the 2 meshes, one for the ground and one for the "walls" of the mine.
Now I am working on getting the UV mapping right but my problem is that the ground is really hard to map to UV coordinates properly and I am currently not able to get it right.
For the tessellation I am using a constrained version of the delaunay triangulation to which I added a sub-tessellation what simply splits the triangles at least once and keeps splitting them if the area of the triangle is greater than X.
Here a 2D rendering of the tessellation that highlight the contours, the triangles and the edges
Here the result of the 3D rendering (using three.js and webgl) with my current UV mapping applied (a displacement map as well, please ignore it for now).
I am taking a naive approach to the UV mapping, each vertex of a triangle in the grid is translated to values between 0 and 1 and that's it.
I think that, in theory should be right, but the issue is with the order of the vertexes that is creating a problem but if that would be the case the texture should be shown rotated or oddly not just oddly AND stretched like that.
Once I will get the UV mapping right, the next step would be to correctly implement the
I am currently writing this in javascript but any hint or solution in any language would be alright, I don't mind converting and/or re-engineering it to make it work.
My goal is to be able to procedurally build the mesh, send it to multiple clients and achieve the same visual rendering. I need to add quite a few bits and pieces after this other step is implemented so I can't rely on shaders on the client side because otherwise being able to place tracks, carts or something else on the ground would just be impossible for the server.
Once I will get these things sorted out, I will switch to Unity 3D for the rendering on the client side, webgl and three.js are currently being used just to have a quick and easy way to view what's being produced without the need of a client/server whole infrastructure.
Any suggestion?
Thanks!
I sorted out the issue in my code, it was pretty stupid though: by mistake I was adding 3 UV mappings per triangle and not 1 per point causing an huge visual mess. Sorted out that, I was able to achieve what I needed!
https://www.youtube.com/watch?v=DHF4YWYG7FM
Still a lot of work to do but starts to look decent!
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'm hitting a wall in some work I'm doing; I've searched on here for many, many threads regarding numerical interpolation and have found them either to contain too much math for me to interpret them, or that their coding solutions have been too specific to be generalized to the task I'm working on.
I have sets of coordinates (currently float x, y distances around an 0,0 origin point) which I am, via Javascript, transposing to latitude, longitude coordinates. (The transposition is easy, so don't worry about that — I'm just telling you that to make the application more clear.)
For the rest, refer to the below graphic:
The dots are the coordinates. (They are generated algorithmically.) The blue line shows a simple, linear interpolation between the points. What I want is something more like the red line. It's not quite an ellipse — you can see that around the first coordinates, it forms arcs that are almost like a perfect circle.
Note that some of the points are negative in various places. Note that the lines between them must be draw sequentially — an algorithm that generates the points out of sequence will make things much harder for this application.
What I'd like is to have a Javascript function that would let me do the following: specify two sequential points from this series (x1,y1; x2,y2), specify a number of interpolated steps in between (say, 5 to 10), and then output an array of coordinates that would, when linked linearly (that is, when a straight line is drawn between them), look something like the red line above (with the degree of curviness obviously constrained by the number of steps).
Of all of the many spline functions out there, which of these satisfies these requirements? The mathematical precision of the spline function is less important to me than the simplicity of adapting it to this purpose, and to its aesthetic output. I would be fine with manually setting the eccentricity/circle-ness of each individual set of coordinates, too (so the first ones really should be very circle-like, but the latter should not be).
Put another way, I am looking for a simple function for getting the interior coordinates of an arc between any two sets of coordinates. EDIT to clarify that I'm fine with there being a third variable that sets the inclination of the arc (positive or negative) and its eccentricity or whatever. The function doesn't necessarily have to know where it is on the diagram above, as I will know that. I'm just looking for something that can help me interpolate the arc points.
I think I understand the parameters of the problem; what I'm bad at is geometry and turning mathematical answers into usable Javascript. (Because I don't really understand the math.)
I have already looked at Midpoint circle algorithm and found it difficult to adapt to this purpose (because of the need for sequentiality and non-integer coordinates); I've also looked at a variety of spline interpolation methods and found them way too complicated for my dummy-self to make sense of.
Any pointers, help, and code would be appreciated!
I want to understand how I would draw a line between two shapes that are nested in other groups/layers. Here is a jsfiddle example which illustrates what I mean. As you can tell, when the coordinates in use are in the same layer, it is trivial to draw line. When the coordinates are nested inside other groups/layers, then the outcome is not as expected. Try moving the right box around to see the less than desirable results.
Could someone please show me how I translate coordinates from one layer into that of another.
You had some Xs where Ys should be, here's a fixed fiddle: http://jsfiddle.net/6UhNp/8/.
This works as far as you have specified, so you were using it right, but it does not work when you zoom in and out.
I have seen that zoom function you're using floating around recently, and I don't feel it's a correct solution. I haven't sat down to work it out yet, though.
I have an exercise in problem solving for those who like that kind of thing. I'm working on a mapping application that uses Google Maps. A user first enters a series of coordinates and a "radius". The user then requests either a line or an area be plotted. The plots are taking place on Google Maps using polygons. In other words, given the blue line (or area) defined by the blue points and a distance, calculate the red points and draw the red polygon where the edges are of the given distance away from the user-provided edges:
I have managed to get this to work in "most" situations by calculate forward and reverse bearings, then finding the points with a bearing 90 degrees off these in the appropriate direction. For the arcs I just calculated the location points along that arc at 5 degree intervals. In the case of the inside of an acute angle, I determine where the two lines intersect and use that point, but this fails miserably sometimes when the cross-track distance at that point is greater than the radius that was provided.
I'm hoping someone knows of an easier way? Maybe one that works all the time regardless of the ratio of the cross-track to radius distances? Or maybe a library already exists to do this?
I hope what I'm trying to do makes sense... It's hard to put in words. Maybe if I had the words a search would have been helpful even.
Well, the answer turned out to be simpler than I thought. It took me back to a lesson I was taught during CompSci 101 almost 15 years ago:
"Use existing libraries whenever possible."
Once I found out (via googling), that what I'm looking for isn't called an "offset" or a "scale" but is actually called a "buffer" in GIS computing, it was simple. There are some great libraries like Clipper by Angus Johnson that can do it, but I wanted something JavaScript specific.
That brought me to arcGIS's GeometryService. They even have a Google Maps version but it's only API v2. Luckily, there's an official, unsupported version I found via the arcGIS forums that works with GMaps API v3.
So, my solution was to use that, called arcgislink, and it's buffer function works perfectly with Google Maps LatLng points, Google Maps Polygons/Polylines, and any of the standard arcGIS types. Anyone else needing to do this with Google Maps, I highly recommend looking at their libraries.
In the general setting, this problem is quite difficult because it is a global one (you cannot just solve locally, at each polygon vertex but just handling the two incoming edges). And also uneasy because it involves circular arcs.
There is a solution which is quite unefficient but safe: assume you have a general polygon union algorithm (like http://gvu.gatech.edu/~jarek/graphics/papers/04PolygonBooleansMargalit.pdf); you will add inflated versions of every edge one by one (every time a rectangle and two half-disks approximated by polygons), together with the original polygon for closed shapes.
For the sake of efficiency, you can design a "sweepline" algorithm that works by slicing the plane with horizontal lines at every "event point", i.e. segment/arc endpoints and arc apexes, so that the configuration in every slice is simpler. Do you see what I mean ?
BTW, what do you call the "cross-track distance" ?