- From: Michael Gould <mgould@lander.es>
- Date: Fri, 6 Aug 1999 17:07:20 +0200
- 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 properties. 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. 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 "http://www.GreatBitMaps.com/symbols/business/public/restaurant023.gif. 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 Javascript... 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 http://www.lander.es/~mgould and Antonio Ribalaygua XYZ Sistemas Industriales, S.A. email: arb@imapper.com http://www.imapper.com
Received on Friday, 6 August 1999 11:16:50 UTC