W3C home > Mailing lists > Public > www-svg@w3.org > August 1999

SVG suggestions (geoinformation)

From: Michael Gould <mgould@lander.es>
Date: Fri, 6 Aug 1999 17:07:20 +0200
Message-ID: <003801bee01e$6f29be80$9e304cc3@act.uji.es>
To: <www-svg@w3.org>

Dear SVG spec developers;

Below are some geoinformation-related comments we've been compiling over the
past weeks (some problems may have been solved in the latest version, which
we haven't viewed entirely: anything ever come of the requests for
downloadable files?).

Things we liked about the penultimate version:

1. Groups. They will make our SVG output much smaller. If I have 300
building polygons (on a town map), I only define once filling, stroking,
etc, and for each building just write the points, no other properties.

2. Relative coords will also help on smaller code.

3. Clipping is also helpful, so server can output complete features.
Although it may be also done via CSS, your's is better for certain jobs.

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.

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.

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

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

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

4.1. Set layer filling, stroking, behavior (only certain layers should
launch certain events), z-index, etc.

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

4.3. Set layer image. Returning to the 4.2 examples, all restaurants must
show an image
Also too many bytes here.

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

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

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

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.

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

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.

That's all for now: we hope to receive replies to some or all of these.

Keep up the good work,


Michael Gould
Univ. Jaume I
Castellón, Spain


Antonio Ribalaygua
XYZ Sistemas Industriales, S.A.
email: arb@imapper.com
Received on Friday, 6 August 1999 11:16:50 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:29:08 UTC