W3C home > Mailing lists > Public > www-svg@w3.org > November 2009

Re: Again with the getIntersectionList()

From: Andreas Neumann <a.neumann@carto.net>
Date: Fri, 20 Nov 2009 10:53:16 +0100 (CET)
Message-ID: <30599.>
To: "Jonathan Watt" <jwatt@jwatt.org>
Cc: "Jeff Schiller" <codedread@gmail.com>, "www-svg" <www-svg@w3.org>

so - as I understand it. It is not a question of "if" these methods get
properly specified and implemented, but more like "how" - is that true?

I hope the fact that most other interactive technologies like Java, Flash,
Silverlight, qt, etc. offer similar methods is good enough to convince SVG
implementers that it is worth wile specifying and implementing
intersections tests in SVG as well.

I agree that it would be useful not only to test rects against shapes but
also path-elements or other shapes against shapes. I wouldn't go as far as
taking stroking and other decoration like markers, etc. into account. For
my use cases, raw geometry would be fine.

I wonder if the people who voted for those two methods in the first place
are still around and explain a bit more about their reasoning back then. I
am sure they also had use-cases in mind.

As to implementation and speed: I am only a script programmer, but I know
that in GIS a lot of Open-Source code exists for doing
intersections-stuff. Also, every decent drawing package, like Inkscape or
others needs to have such methods implemented. I know that one cannot just
take code from other projects, but the algorithms/ideas/concepts might be
useful to share.

I know that in GIS, databases and applications build spatial indexes. They
start with bounding box approximations (r-tree or quad-tree like
structures) for the first run and later test the geometry of the elements
where the bounding box intersected. If you want, I can try to dig up more
information on how those index-structures are implemented in GIS.

More comments below:

On Fri, November 20, 2009 2:18 am, Jonathan Watt wrote:
> On 2009-11-19 9:58 PM, Andreas Neumann wrote:
>> Most decent drawing tools also allow to customize the selection mode:
>> * select all elements that are completely inside a selection rectangle
>> (.getEnclosureList())
>> * select all elements that intersect with a selection rectangle
>> (.getIntersectionList())
>> You would need it for:
>> * Full-blown drawing tools/editors
>> * GIS: e.g. select all polygons where you want to sum up areas,
>> population; calculate different things based on the selection, etc.
> A good example, but an API that only allows for selection based on a
> rectangle
> seems inadequate for this case, no? You probably want any arbitrary path,
> and it
> seems to me that some API to ask "is this point inside the given path"
> would be
> most appropriate. (So in something like the Flash demo you gave below, you
> could
> take the center of each area of interest and check if it was "inside".)

I agree that it would be desirable to have arbitrary geometry intersection
tests, but as Jeff said, it would already help a lot to have simpler tests
widely available, such as the rectangle based tests.

>> * Games
> What in particular are you thinking of here? Simple collision detection
> with the
> edges of a viewport? I think if SVG is to provide API to help with
> collision
> detection we'd be better off designing something completely new.

I am not much of a gamer and also not a game developer, so I can't provide
details here. I just had the idea that intersection tests may be important
in gaming as well.

>> * multimedia-apps: think about a photo light-room board where you have a
>> couple of photos floating around - you want to grab some photos and
>> apply some effects on them, or tag them, or remove them ...
> The demos I've seen most commonly involve drawing a path around the photos
> you
> want to select. I guess being able to draw a rect would provide a
> poor-man's
> select tool. Anyway, good concrete use case, thanks.

right - but drawing a rectangle is also easier for users than drawing a
polygon. I guess most users would use the rectangle tool (and then do
another rectangular selection with ctrl/shift) and would use freeshape
selections only in cases where the rectangular case would be too
complicated. I may be wrong though. Again - both selection methods would
be useful I think.

>> * Technical Drawings: select elements and get a part-list
> I may misunderstand, but I'm not so convinced by this one, either as a use
> case
> for the current API or as a use case for similar-but-different API. I'm
> assuming
> you're suggesting that you can select a sub-part of a drawing, and then
> work out
> a list of all the component parts that make up that sub-part. The current
> doesn't return container element's though, it returns all the leaf
> graphics
> elements (which isn't even a parts list...*unless* each part is only
> represented
> by a *single* graphical element). Maybe one way you could use it is to say
> "this
> sub-part is selected if all its graphical leaves are selected" though.
> Hmm... A
> center-points-inside-path query (or something along those lines) may be a
> better
> bet for this too.

right - for this it wouldn't be enough to only get leaf nodes. You'd want
the group nodes as well, or maybe be able to stop at a certain hierarchy
and don't go into details.

So having not only leave-nodes bot also group-nodes would be something to
consider for an enhanced version of the getIntersectionList() and
getEnclosureList() functions.

>> * flow charts and mind maps where you want to drag around groups of
>> elements
> Again, this is interesting because you ultimately want to tell if one of
> the
> nodes in the flow chart/mind map is in the selection or not, not whether
> all
> it's component graphics objects are in the selection. I'm wondering about
> some
> sort of mechanism to say on a container: when finding selections, I'm in
> if X is
> true about some shape that I'll give you - don't bother looking at my
> descendants.

Such a mechanism would be useful if we specify it in a way that is not too

There may also be use-cases where you'd want only group nodes returned,
but no leave nodes. But as Jeff said, developers can still filter the
resulting list for special cases.

>> I think the resulting node list should be in the order the elements
>> appear in the DOM. The question is then if you only get shapes or also
>> group/container nodes? Did you discuss that?
> The spec says "graphics elements". I.e. only elements that themselves
> paint, so
> not container elements.

hm - see discussion above

>>>  * Would you really want 'pointer-events' to be taken into account?
>> I think there should be a parameter in the two methods that specify the
>> behavior. I think there use-cases for both modes - taking them into
>> account or not.
> Can you give specific examples for when you'd want to pay attention to
> pointer-events?

I think pointer-events is an easy way to make a visible group of elements
(or single elements) non-selectable. If I'd do a drawing app and I want to
implement layer functionality, I'd use pointer-events="none" for inactive
but visible layers. Those inactive layers shouldn't be responsive to
selections. In other cases maybe they should be included.

>>>  * Would you want 'visibility' or 'display' to be taken into account?
>> display should be taken into account - definitely. If you switch of a
>> layer in a drawing app or GIS, you don't want invisible elements to get
>> selected. Besides, display means "not part of the rendering tree",
>> anyway?
> It does yes. Still wondering about visibility myself.

I don't use visibility a lot. I mainly use display.


Andreas Neumann
Received on Friday, 20 November 2009 09:54:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:24 UTC