Re: Again with the getIntersectionList()

Hi all,

Yes, editing and selecting elements would be the main use case for both. 
But I think that this is the case for many applications, not just full 
blown editors.

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.
* Games
* 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 ...
* Technical Drawings: select elements and get a part-list
* flow charts and mind maps where you want to drag around groups of elements

Here is a nice flash-based mapping-app: 
http://www.emc3dev.com/usa_demo/carto.php?lang=en - in the toolbar on 
the top you may find two different selection tools: polygonal and 
circular selection. After the selection you get a list with all the 
counties and associated data of elements that intersected.

----------------

More comments inline:
> I'm curious what use cases people see for functionality along the lines of
> getIntersectionList/getEnclosureList. In any use case you may have:
>
>  * Would you want to get elements that are "below" a given element
>    in rendering order, or would you rather want elements that
>    are descendants of a given element.
>   
I think it would be very useful if the user can specify the parent node 
in the DOM where the search algorithm should start with and traverse 
down the DOM tree. In some cases it could be a group node (representing 
a layer in a drawing app or GIS app), or it could be the root node (the 
whole document).

I think the author of a drawing or GIS app would want to start the 
search at a given group/parent node (such as the drawing canvas or the 
map root)

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?

>  * If you want the elements that are "below", should 'z-index' be
>    taken into account in deciding what's "below" an element, or
>    do you really just want "comes before in document order"?
>   
hm - not so sure if I need the "what's" below. Would you use that mode, 
Jeff?

>  * 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.

>  * 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?

>  * How about opacity, markers, masking or filters?
>   
not so sure. I would say no. I am mostly interested in the "raw" 
geometry, not the decorations.

>  * Would you want elements that are fully inside the rectangle
>    that you specify?
>   
yes - with getEnclosureList()

>  * Would you want elements that have overlap with the rectangle
>    that you specify?
>   
yes - with getIntersectionList()

>  * Would you only want elements that intersect with the *edges*
>    of the rectangle that you specify (i.e. not elements that are
>    fully inside)?
>   
For getIntersectionList() I would want both: elements that are inside 
the selection rectangle and elements that intersect. Both cases are 
actually intersection. Inside is also an intersection of the two areas 
(the shapes and the selection rectangle)

>  * Would bbox intersection checking be sufficient?
>   
Not for all cases. I think there should be a parameter: bounding box 
checks (faster) and checks on full geometries (slower, but more accurate)

I hope that the use cases above are strong enough to be properly 
specified by the SVG WG and picked up by the implementors.

Thank you for discussing and working on this! I think there would be a 
lot of applications that would benefit from proper and compatible 
.getIntersectionList() and .getEnclosureList()


Andreas

Received on Thursday, 19 November 2009 20:59:06 UTC