SVG 2D Graphics Research
GIS Architecture

GIS

GIS Architecture and Integration

When you look at it, SVG code can be a bit daunting, but you just need to know what to look for. Our AnalyseSvg program (Windows only) is good at setting out the main structure of any SVG document, and is a great help in clarifying what is going on. You should try it (It's free). Version 1.0.a.1 5 April 2005. Latest Version. It does not do SvgZ files, by the way. Please unzip them first.

There are really two distinct ways to use SVG. The first way is the best.

1. Start in 'paper'* coordinates and axes, using {scale, at, turn, xmirror/ymirror} to move into 'real-world' coordinates (about the thing you are graphically representing). This is the simplest way to do it, and makes integrating with other SVG output easy. It allows you to do both of the things you need to do in a drawing: a) to work in real-world distances, and b) to draw symbols in terms of how big you want them in terms of 'paper' distances.
2. Start in 'real-world' coordinates, and find a way to scale things such as symbols and text so they end up looking right. This is much the harder way to do it. Some people slip into this way, because they see the SVG viewBox and they think that it allows them to define the boundaries of their map in real-world coodinates and then move on from there. (It does... with a big but...) But SVG viewBox works from the top downwards, with left-handed axes (y axis) down the page. Which is not really how map coordinates work. Plus it makes drawing map symbols hard, because when you want to draw symbols, you have to scale them from real-world coordinates: that means you are defining the size of a symbol (eg church) in terms of real-world distance (how many metres it would be on the ground – which is plain ridiculous!) .

*'Paper' coordinates. That's just a term that we use as a shorthand notion. Computer graphics may be on paper, but they equally may be on a 1280 by 1024 pixel 17"monitor, a 3840 by 2400 pixel 42" projector screen, a 320 by 220 pixel PDA 2" display, or even a 160 by 130 pixel mobile phone screen. The thing is, you have to know beforehand what the output is going to be on: what its resolution and dimensions are. That is critical. You can not simply send VGA output to a mobile phone or vice versa. The amount of text that is right for a large output device is totally different for small one. Likewise on a high-res device you can pack more in than on low-res. To cut through, and make things simple, PenDraw works in terms of defining the size of the surface you are going to output onto, so you can think in terms of real size. Resolution gets better all the time, so resolution is usually less important than physical size. We call it 'paper', because we have found that most people are comfortable with thinking about their drawing as if it is on a piece of paper. It's natural. It's intuitive. It works.

1. Find the outermost (first) <svg ... > tag.
2. Within that <svg ... > tag, that is before its closing >, find width and height: they will probably be specified in terms of pixels eg width="700px" height="400px". If no units are given, the default is px, or pixels, eg height="400". Width and height define how big the map is to be on the final device. Sometimes they are in percent: width="100%" means "use all of the device width", or it can mean "use all of the width of the assigned area" if the svg is being fitted into a part of a document.
3. Still within the <svg tag, find the viewBox. This defines the coordinates you want to natively work in. PenDraw's default is millimetres: if you are imagining that you are drawing on a piece of A4 paper, landscape, your code would be viewBox="0 0 297 210", which means that the bottom left is at (0,0) and the top right is at (297,210). It is only notional, after all, because the user can put you whole drawing into a small rectangle in some other document, or output it on a surface that is bigger than A4 paper. Thus the best course of action is to make it something that simplifies your own thinking about your own graphics.
4. At this point you have all the key data. So now you think through how you are going to integrate the GIS SVG with PenDraw's (or other) SVG output. The simplest way is to define the PenDraw output to use exactly the same width and height and viewBox. Then you can put PenDraw's SVG into the GIS SVG. You can do that through PHP or Perl, or whatever, on a server, or you could even cut-and-paste. When you do it, you will need to find the first <g ... > tag after the outermost <svg ... > tag, and then find its matching </g> tag : that is the chunk of PenDraw's XML-SVG that you need to put into the GIS SVG file. Where should you put it? Well, a good place is after the last <g ... > to </g> block of SVG code in the GIS SVG file: after its closing </g> tag, and before the closing </svg> tag.

The simplest SVG has an <svg ... > tag to </svg> tag 'block' of SVG code, and inside it are nested <g ... > to </g> tag pairs. If it is structured like that, you simply need the 'outermost' <g ... > to </g> tag pair. (That is how PenDraw creates SVG.)

However, it is also possible that there may be several <g ... > to </g> tag pairs between the <svg ... > tag and the </svg> tag. If there are, you need them all.

If the GIS constructor has used viewBox unwisely (to our way of thinking), it will look something like this: viewBox="-501067 -14142 12000 9000". That is a sure sign that s/he is using the viewBox to try to stick with real-world coordinates. It is very difficult to work with and to integrate any other graphics. About the only way is to integrate it into Pendraw SVG. You will need to position and scale the GIS SVG <g ... > block: the simplest way would be to put another <g ... > to </g> block around it with the right transform definition in the <g ... > tag. But rather than trying to adapt it, try to persuade them not to do it that way. There are lots of GIS systems/software out there, so if they really can't or won't change, it may be worth getting a different GIS.

Whichever SVG code comes later draws 'on top of' the earlier SVG. So if you want to annotate a map with symbols, you want the symbols last in the final SVG file. Plus, don't put a background colour on the drawing that your symbols are on, or that background will be drawn all over the map, with the effect that you won't see the map at all!

Some GIS want to hide scale from outsiders. They hide the details of the scales they use and so forth, byt putting them in javascript functions. It is probably well intentioned, to try to react to the size of monitor, or the screen resolution, and so forth. However, it is impossible to integrate their SVG without finding out the basic facts, so you will just have to ask them.

Some GIS like to hide SVG code from outsiders (they probably do it to protect their interests so that the SVG can not be copied.) You know you can right-click on SVG and you get a menu that shows "Show Source"? Well, they disable that part of the menu, so you can not see anything of the code at all. Hence you can not analyse it. You will just have to talk to them about it and persuade them to help you.