You can do that in three lines of perl or sed using a regular expressions (and one of those was just to add extra spaces after the commas). If this is the sort of thing you are doing then you should ensure your well familiar with them cos it makes manipulation like this so easy.
$in = '<path d="M 258.59905,189.69191 80.812204,365.45845 264.65997,692.74788 220.21325,510.92042 519.21841,434.14883 385.87827,246.26045 z" />';
$out = $in;
$out =~ s/<path d="M /LINESTRING (/;
$out =~ s/ z" \/>/)/;
$out =~ s/,/, /g;
print "Before: $in\n";
print "After : $out\n";
# Before: <path d="M 258.59905,189.69191 80.812204,365.45845 264.65997,692.74788 220.21325,510.92042 519.21841,434.14883 385.87827,246.26045 z" />
# After : LINESTRING (258.59905, 189.69191 80.812204, 365.45845 264.65997, 692.74788 220.21325, 510.92042 519.21841, 434.14883 385.87827, 246.26045)
That might work in this very specific case, but not for SVG Path Data in general. Like I said, SVG is flexible and allows a lot of different ways of expressing things. Dealing with all those different ways is the hard part. You can express numbers as integers, decimals, or in scientific notiation, you can use commas or spaces as separators, commands and numbers don't need to be separated, but can be, commands can be omitted in which case you repeat the previous one with the next set of parameters, unless it was a moveto command in which case you treat the repetitions as lineto commands. Closed paths are handled differently between the two requiring that you keep track of the first point of any subpath, and just about every command has a relative form requiring you keep track of the most recent point as well.
And that's not even getting into the problem of all the curved path sections like bezier curves and elliptic arcs.
That said, I am using Regexps, it just takes a fair bit beyond regexps. Also, I wanted to be able to load directly into JTS; the WKT export is just corollary of sorts since JTS already has WKT export. Ultimately I'd be aiming to use the Centroidal Voronoi algorithm from the start of the thread on shapes loaded from an SVG file.
PPS: The topological issues with turning closed SVG paths into JTS Polygons or Multipolygons is going to be a lot of work too. SVG allows subpaths to intersect themselves and each other, and doesn't make topological distinctions between them. The The OGC Simple Features data model used by JTS doesn't allow intersecting rings, and does make a distinction between a polygons with an enclave, and a multipolygon with an exclave.
Lordy, I remember just barely touching on some things similar to these issues way back when in earlier software, and all the headaches it caused.
Good luck, and you have my sympathies!
Ok - who woke me up!!!! Lol.
Inspired by This post I've done a bit more work on this using the Wang Tile + Progressive Poisson Disc technique rather than Weighted Centroidal Voronoi.
It still needs some work, and there are some bugs I'm feeling completely lost on, but It's producing something somewhat reasonable now, and it's FAR faster.
OK, much smoother now that I've got the re-ranking step done. It dies on the seam finding step at random, so there's something wrong there. I'll be saving the generated tiles and simply load them in future, but it still would be nice to not have to run the generator several times to get a tile set out of it.
Running a greyscale photo through it.
Stipple-icious indeed :). Most of this goes a bit over my head, I fear ... but if it was easy to use, I would definitely use it! :)
I'll probably try to wrap some kind of interface around it when I've got it cleaned up and tested. For now though, here's a test of a stippled coastline effect.
Originally Posted by Lukc
By using a function of distance inside the polygon for the density, making a simple arc shape as a stipple, and rotating it to face the nearest edge, I managed a fairly good looking forest symbol. It's not perfect, but I can probably improve it a bit.