Re: Intersection without Rects

I understand that part of the difficulty in implementing intersections is
that different results are obtained at different zoom levels; using a
1-pixel margin of error, 2 elements that are only 1 pixel apart when at
normal zoom, seem to intersect when zoomed out (even to the renderer). This
makes a high degree of precision extremely difficult for many purposes (say,
in a GIS system that wants to find out if two roads cross, at a far
resolution). I would argue that in this case, perfect is the enemy of good.
For most purposes, this degree of precision would not be mission-critical;
virtual intersection would often be good enough, detecting intersection at
the current zoom level. For more precision, you could always weed out the
false positives at higher zooms; I could see this as being implemented in
script, or included in the viewer, perhaps as a ranging factor that would
test returns at increasing levels of zoom in a multipass fashion. It might
be slow, but it would be much better than not having it at all.

Perhaps this zoom-level-sensitive detection could be discussed in the Spec,
to allow UAs to have varying degrees of compliance to this very useful
aspect of SVG, rather than present an unworkable challenge for them.

Thanks-
-Doug



----- Original Message ----- 
From: "Gavin Kistner" <gavin@refinery.com>
To: <www-svg@w3.org>
Sent: Wednesday, October 01, 2003 4:39 PM
Subject: Intersection without Rects


>
> Rather than
> SVGSVGElement.checkIntersection(element, rect)
> and
> SVGSVGElement.getIntersectionList(rect, referenceElement)
> (which I would only find moderately useful in any UA that supported
> them) I would really like to see
>
> ==================================
> SVGLocatable.intersects(element)
> element - A SVGLocatable element to check against the current element
> returns - true if the source element intersects the parameter element,
> false otherwise
> ==================================
> SVGLocatable.intersectsElements(parentElement)
> parentElement - the SVGLocatable container element to which the search
> should be constrained.
> If null, the entire document is searched.
> returns - a dom::NodeList of all elements which intersect the calling
> element
> ==================================
>
> Restricting the intersection check to simply a SVGRect may make it a
> little easier for the UA developers, but fails to address a large
> number of programming needs necessary for SVG to be a rich interface to
> programming.
>
> I have never written an SVG UA before, but I (naively?) imagine that
> implementing these arbitrary intersection checks would be only a trifle
> more difficult for the UA developers. I would think that they would
> already have such algorithms written for the optimization of drawing,
> anyhow. (Having them overlap on the screen, to screen-px precision,
> would likely be sufficient for the majority of applications.)
>
> If backwards compatibility is important enough, the spec could persist
> in its current not-very-oop design of calling these methods off of the
> SVGSVGElement, and simply expand the type for the current 'rect'
> parameter to be SVGLocatableElement.
>
> (Aside: should the 'element' and 'referenceElement' parameters above
> really be SVGElement, as the ECMAScript binding currently specifies, or
> should they be SVGLocatable (or even SVGTransformable)?)
> --
> Gavin Kistner @ Refinery, Inc.
> gavin@refinery.com
> work: +1.303.444.1777
> cell: +1.303.641.1521
>
>

Received on Monday, 6 October 2003 17:37:20 UTC