Re: SVG suggestions (geoinformation)

Michael,
I'll take a stab at responding to your comments:

At 05:07 PM 8/6/99 +0200, Michael Gould wrote:
>Some suggestions/questions interesting for the GI (geographical
>information) community:
>
>1. Holes. Do you support an element with holes inside it? It is very common
>in GI to deal with this kind of element. You could add H/h in the path
>definition (analog to M/m) which would mean "Move to hole".
>
>Maths for holes are very similar to regular polygons. If the number of
>times a line from point A to an external one crosses the path itself and
>all the holes is odd, A is an inside point. Otherwise A is outside or
>inside a hole.

I believe we have this. A <path> can consist of multiple sub-paths, where
each sub-path starts with a Moveto command. Whether a given point is within
a "hole" or not is determined by the properties "fill-rule" and "clip-rule"
(depending on whether you are performing a fill or clip operation).

Check out the 'clip-rule' property in section 5.3 and and the 'fill-rule'
property in section 8.2 in the July 30 draft spec
(http://www.w3.org/1999/07/30/WD-SVG-19990730/). (You'll see that we are
missing descriptions of these properties, but you might get some comfort
because "evenodd" is one of the options.)

>2. Coordinates are important for us. May be that coordinates and projection
>management should be server's (or GIS app's) job, which should output just
>pixels (or any other browser coordinates system). The pity is that
>valuable information (the real-world location) is lost.

The SVG client should be able to do many transformations for you.
Definitely, you don't need to restrict yourself to pixels! Look at Chapter
7: Coordinate Systems, Transformations and Units.

>
>If you find real location would be nice to keep, there are many things
>to consider: different coordinates systems, projection systems, decimals in
>coordinates, reference points (so the path coordinates are refered to it
>and do not extend too much), etc. Many things ...
>
>[One thing the GI community could contribute, if sufficient interest exists,
>is a hierarchical triangle-based coordinate system for the entire globe:
>saves space and eliminates lots of projection and datum problems. Uses a
>quadtree and stores not only position but also resolution.]

This sounds very interesting! How can the SVG team learn more about this?
Pardon my personal ignorance. Is there a textbook or a URL that you can
provide which describes this coordinate system?

>
>
>3. It would be nice if paths could have "Area" and "Length" read-only
>properties.

Does "Area" mean "bounding box"? That is, the extent in X and Y for the
geometry of the path? Exclusive of stroke width?

What do you mean by "Length"? Distance along the path in the current user
coordinate system?

We intend to provide DOM utility functions for providing the bounding box
of an object and various distance along a path utility functions.

>
>4. Layers. Antonio mentioned before that groups can be used to draw a
>complete layer, as all its elements must be displayed the same way. But a
>specific layer management would be very useful for us. For example, we want
>to:
>
>4.1. Set layer filling, stroking, behavior (only certain layers should
>launch certain events), z-index, etc.

You can get all of this (except z-index) by putting the contents of a layer
inside of a <g>.

The SVG working group decided that z-index management would put a huge
burden on SVG processors and greatly complicate streaming. Most of z-index
management can be accomplished by DOM manipulation calls which move <g>
elements around in the SVG document hierarchy. Thus, we decided to *NOT*
support z-index. We would be interested in feedback on this feature from
the mapping community.

>
>4.2. Set layer Link. For example, I want the restaurant with id="CasaMaria"
>to link (onclick) to
>"http://www.santander.com/tourist/restaurants?id=CasaMaria, and so on with
>all the other restaurants. If the server writes to the SVG the complete
>URL, they are a lot of bytes. Instead of that it would be great to set the
>layer link mask to "http://www.santander.com/tourist/restaurants?id=%Id%,
>so it just replaces %Id% for the real Id otf the current restaurant.
>[I think this link naming is now in there, no?]

SVG 1.0 won't have any ability to do parameter substitution. We might look
at parameter substitution in a future version of SVG.

The only way to accomplish this now would be via an "onclick" event handler
which would do the appropriate parameter substitution before invoking a
command to hyperlink to the given computed URL. For convenience, the
"onclick" event handler could be assigned to the <g> element instead of
putting it on each element within the <g>.

>
>4.3. Set layer image. Returning to the 4.2 examples, all restaurants must
>show an image

What exactly do you mean by "show an image"? Do you want the same graphics
to appear multiple times? If so, you can employ SVG's <use> element. See
section 3.6 in the July 30 draft spec.

>
>4.4. Show/Hide a layer or a family of layers

You can set visibility: { hidden | visible } on a <g> element.

>
>4.5. Display a standard legend with all of them with checkboxes to
>show/hide. Or is that client-specific?

Hmmm. Details on the <use> element are still being worked out. We
definitely want the ability to override attributes/properties inside child
elements of a template object. This might or might not make it into SVG
1.0. Certainly, hearing that someone from the mapping community wants this
feature will carry weight.

>5. we support Andrew Wooldridge's suggestion: "Instead of
>caching just SVG images as a whole, it might be interesting to cache
>sub-components which get re-used throughout the site.".

Sounds like a good idea. This is really an implementation issue, not an SVG
spec issue, although the SVG spec could encourage implementations to follow
Andrew's suggestion.

>
>6. Explicit coincidence. This is common in datasets like cadastral maps,
>where a single line may represent part of a street right-of-way, a parcel
>boundary and a municipal district boundary (let's say). We don't want to
>replicate the line(s), but in which layer would a single representation be?
>In the datasets it's normally stored once but we visualise it 3 times as we
>turn on the three layers mentioned. These problems crop up in lots of
>real-world vector map applications.

SVG does have a <use> element, which might solve the need here.

>
>7. What about mouseover behavior of individual items? We saw it in the
>Granada SVG demo by Adobe folks, but not sure if it's in the SVG or the
>Javascript...

The latest draft of the SVG spec says that:
* all container elements (e.g., <g>) and all graphics elements (e.g.,
<path>)  have onmouseover, onclick, etc. event handlers
* the default scripting language is ECMAScript (i.e., JavaScript)
* conforming viewers need to support ECMAScript

Therefore, JavaScript event handling will work (unless the user turns off
JavaScript).

The other alternative is leveraging the animation features. You can cause
the document to change based on user events without getting JavaScript
involved. Look at the <animate> element and the "beginEvent" attribute in
particular in section 15.2.1 in the July 30 draft spec. There is an awful
lot of flexibility in the animation package. It can be used for things
other than spinning logos and cartoons.

>
>8. Also nice would be fixed-size bitmaps, for small icons which we do not
>wish to change as window size (or zoom) increases. An absolute point or
>align/valign could be specified.

This can be done via clever construction of the document and its various
<g> elements and the order of transform= attributes. Also, there will be on
onzoom and resize event handlers which can be used to invoke custom
JavaScript.

>
>
>That's all for now: we hope to receive replies to some or all of these.
>
>Keep up the good work,

And please keep sending in feedback!

Jon Ferraiolo
SVG Editor
Adobe Systems Incorporated

Received on Sunday, 8 August 1999 15:33:44 UTC