Wicket
Wicket copied to clipboard
arthur-e
Add extension for D3.js SVG path creation from WKT
@arthur-e how are you planning to do this? I'm pretty comfortable using d3 geo.mercator to bring coordinates to pixels inside an imageOverlay object in google maps api, but I guess you're planning in covering leaflet and arcgis too.
@amenadiel I haven't given it the least bit of though! (=D) It's a wish-list, item. I was not thinking of integration with Google Maps, Leaflet, or ArcGIS, however--just adding a method to Wkt.Wkt() instances that takes, as an argument, a projection (and width, height?) and returns SVG path data.
That would be good only as a snapshot of the current viewport, because as soon as you pan or zoom, the SVG path would no longer match the underlying coordinates. I'm currently using d3 to calculate proper transform (in terms of scale and offset) to compensate for that. At least it's cheaper to transform one container than reprojecting all paths over and over again.
@amenadiel In the case of SVG overlaid on a "slippy" map (e.g. Leaflet), yes, you're right. However, with "pure" SVG this is not a problem. As you mentioned, it is possible to pan/zoom SVG elements using scale and offset transformations in a "slippy" way (e.g. by applying them to a wrapping SVG element such as a
So the scope of this feature would be to grab the static SVG representation of a polygon (or other feature) that's in my current viewport.
In attempting to better explain the conception of this issue, I've revisited some previous work in D3.js and realized my mistake. I had conflated the path data (the "d" attribute), which comes from the projection, with the vector data (the "path data" in the GIS sense). Sorry for the confusion. Upon this reflection, it would seem that this issue is irrelevant. I tend to use GitHub "Issues" as a place to quickly (casually) write down half-baked ideas to look into later. Thanks for your persistence, @amenadiel ! (=3)