[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] grouping and merging problem

---

---

On 11/22/05, Sylvain Rouillard <RouillardSy@xxxxxxxx> wrote:
> Hi list!
>
> This is my first post in here and I'm really new to XSLT things, so I hope
my
> question will not sound too dumb. I've been googling around a lot and I
> cannot find anything similar enough to my problem, hence me comming here.
>
> I am using xslt 1.0 to transform an xml file into an svg image. Basically,
the
> xml file is a map of pixels (//row), with an @x, @y and @Altitude, and I
> render each pixel with a square (<rect>) positionned at (@x,@y) with an
> opacity proportionnal to the altitude. An exemple of my xml input and of
the
> xslt I use is given below.
>
> The next step for me is to trim the output size, by merging neighbour
pixels
> that have the same opacity (ie altitudes that are close enough from each
> other to be rendered by the same opacity on screen). To approach this
> problem, I decided that I would try and merge only the pixels on a same row
> (same @y), so that I don't have to be bi-directionnal. So, ideally, in the
> for-each loop, I should test if the next pixel in the loop has the same
> opacity as the current one. If not, then I can just output the same rect
with
> width=3 and height=3. If the next pixel has the same opacity, then I should
> test the one after and so forth (until the end of the row), and output a
rect
> with an appropriate width attribute. In this case, the subsequent pixels
> (//row) that have been covered in a previous enlarged rect should be
skipped.

Look at some of the grouping examples in the FAQ of this list.  You
should be able to modify this, although it will take a bit of elbow
grease.  Otherwise this would also fit well into a recursive template
(at least in my humble opinion).  Don't think of necessarily going
through the list item by item and then doing an action, think of it as
going through the sets you want a the list.  It's a subtle distinction
perhaps.  For every element that doesn't have the "similar enough"
opacity following it, do one thing.  For every group of elements with
similar enough opacity, do something else (average it or something
along those lines).


>
> I hope this makes sense, feel free to ask more details otherwise.

Yes, actually seems to be a pretty nice summary.  Just wish I had time
to work with it.  Best of luck.

---