One of the the things that has gotten a major overhaul in 3.8 is the way of how point maps are drawn. Before 3.8 it was a bit chaotic. You had multiple options there to drawn point maps with very different sets of attributes. For example, the “graph” drawing and the “true-type” drawing. For 3.8 I simplified the whole system and basically there is now only one way to draw points. As a consequence this means that there is only one set of attributes to change and that will work for all points of all types.
The basis of it all is the “symbol”. The symbol is the representation of a single point that is described in a “svg”-like text file located under resources\symbols in the installation folder. I say “svg’-like because the syntax of the description of the symbols is a derivative of a small subset of svg (see http://en.wikipedia.org/wiki/Scalable_Vector_Graphics). Svg is big and I selected what i felt I needed from it to define my own symbols and skipped the rest. The I added a few things that were needed to respond to attributes that the user could set. The result is a fairly small set of commands that can be used to define a symbol. Each symbol has its own file (with an .ivg extension) and ILWIS reads them when the first pointmap needs to be drawn.
Before showing a bit what is possible with it, let me first a bit explain about the geometry of points in the map window. Every point symbol has default the same size. 1/200 th of the size of the zoomed in map window. This means that at every scale the point has the same size. The default size is multiplied by the “scale” of the point ( default 1.0) to enlarge/shrink it if needed. So there are no “point” sizes for symbols as there were previously. Each point symbol is centered around, eehm, its center 🙂 and scales it within the default size. ILWIS shifts each defintion of a symbol to the center of the bounding coordinate box that defines the lines, arcs and other drawing commands of the symbol. So it doesnt matter which units or relative position you use when defining the symbol, ILWIS makes sure it fits. If no sizes are defined (some simple drawing commands can do this, see below) ILWIS will default (size) to the default symbol size.
Though the default size is 1/200, ILWIS ,may adapt this default size if there are a lot(100+) of points to something smaller. Else the points would overcrowd the mapwindow. You can always overrule this by changing the scale as this default is only calculated when opening the map.
So back to the Ivg defintions. Lets look at a simple example. The definition of a simple right standing cross
<ivg scale="1.0" version="1.1"> <line x1="0" y1="-50" x2="0" y2="50" style="stroke-width:1;stroke:black"/> <line x1="-50" y1="0" x2="50" y2="0" style="stroke-width:1;stroke:black"/> </ivg>
This is straighforward SVG. The cross consists of two crossing lines defined by x1,y1 and x2,y2 coordinates and a style definition. The style follows is a subset of the normal style definitions in SVG. I don’t support gradients (at least not yet) and some of the other more complex color definitions, just simple flat colors. A special color is ‘user-defined’, this is a color set from the Representation of ILWIS. I support the line, polygon, circle, rectangle and path. In the beta-2, the path didnt work correctly yet but that is solved now.
For more examples how to make your own symbol just look into the other ivg files in the symbols folder.
Apart from that ILWIS defines two special operations on the points : stretching and rotating on attribute values. Stretching stretches the scaling of a point based on its postion relative in the value range. Rotation does the same but then with the orientation of the symbol.
For the moment the the whole “mini-graph’ part is gone. I might reintroduce the pie-chart idea but for the others I don’t see much use to warant the time investement.
Barend Köbben says
He Martin,
First, since SVG is XML I suppose IVG is too…? And does that mean there is a DTD or Schema definition against which you validate the IVG instances? That schema could be useful for people to find out the possibilities or to validate their own IVG symbols.
Secondly, I’d advise to support at least hex-colors (#fffff = white, etc), since named colors are very limited and badly standardised across OS-es and apps…
yours,
Barend
(trying the BLog comment instead of going next-door 😉
MartinSchouwenburg says
Yes it is. The schema definition is still a bit in flux as I am sometimes adding a capability, but at the release it will be stable (well for that release at least).
Your probably right about the coloring; I map them of course to a hex number before applying them so directly getting a hex number wouldnt be a problem.