Andrea Rosso has posted some amazing details about further SVG development on ArcWeb Services. Due to their REST API, ArcWeb Services already offer some basic SVG output.
Apparently ESRI is just about to enhance ArcWeb’s SVG capabilities and release sort of a SVG ArcWeb Explorer, similar to ArcWeb Explorer based on Flash. Unlike the existing Flash version, you’ll be able to download the whole viewer including all sources and customize it in order to fit your needs. Since JavaScript plays an important role when it comes to interactivity and SVG, he points out that it’ll be quite similarly to a JavaScript API. So it should be fairly straightforward to embed ArcWeb SVG into your applications or create your own mashups.
Another highly welcome detail is that he mentions Firefox’s built-in SVG support in his post. As well the screenshot on his site shows Firefox demonstrating ArcWeb SVG Viewer. If ArcWeb SVG works well in Firefox I assume that it will be truly platform independent, something one could hardly achieve while Adobe’s SVG Viewer was the only serious viewer for SVG (cf. DOM implementations on Win/Mac/Linux browsers for instance).
If you got interested by now in what’s going on with ArcWeb and SVG you should keep your eyes open for ArcWeb Labs (to be opened soon). According to Andrea ArcWeb Labs should give some insights and information on unreleased applications.
ArcWeb Services providing an advanced and easy to use SVG interface means a significant progress for the acceptance of SVG as webmapping technology. You may look forward how this will work out.
Update #1:
Head over to Kerry Coffin’s post to get some more information about ArcWeb’s SVG Viewer (e.g. available widgets, perfomance in Firefox vs. Adobe SVG Plugin) and see a few very promising screenshots!
Brian Timothy pointed in his comment on my “Flash vs. SVG”-post to the website of the US Department of Agriculture (USDA) containing maps done completely in SVG. Apart from the “political matter” he mentioned I would like to stress the potential of SVG for mapping statistics.
The USDA maps let the user change and apply various styles immediately without reloading the whole map. Following the same method you could allow users to change thresholds too for instance. Since every single attribute is stored within or linked to the according map object it’s easy to modify the map presentation by JavaScript and XML/SVG/DOM on the client side. As you can read in this short review by Jeff Thurston the application appears fast and with a snappy user interface.
If you’re interested in webmapping using SVG you’ll find below a few well done examples:
In addition you can find my first SVG mapping experiment here. I stopped development 2 years ago. Neither will it work in Firefox 1.5 (compelled to optimize it for Adobes plugin then, *the* showstopper for SVG) nor is it fully functional because as backend I used a PostgreSQL/PostGIS database which I don’t have available online.
Some years ago SVG was considered as the next generation of rich media and animation in the internet, as a sort of Flash killer. Nothing happened. Flash technology enhanced and is still widely spread. SVG enhanced too and even went mobile but it’s still a good kept secret.
Now, ESRI & Yahoo! are implementing their webmapping services based on Flash technology. Last week Google silently enabled SVG in their latest API update (API v2.37) for Google Local.
Honestly, it’s quite a time since I did my last Flash development but back then (it was version 5 I guess) I never would have choosen Flash as a tool to be used in a webmapping application. Actually the decision for a vector graphics based webmapping application was then in favour of SVG. Flash’s object handling and ActionScript was too unfunctional for my purpose: I wanted to load geographic objects on demand (e.g. on changing view extents) out of a PostgreSQL/PostGIS database and map them in a web browser, without continuously reloading the whole map of course. SVG was the easiest way to go. As a XML based vector graphic format it allows you to edit, put attributes and styles as you want to every single object within your map. On the other hand vector graphics as SVG required more potential clients compared to raster pictures delievered by mapservers. All objects were handled – requesting & rendering – on the client side (JavaScript was used to access and parse XML, something like “pre AJAX”, to name a buzzword) while the user was interacting with the map. However, after this work I became a big fan of SVG, especially when it comes to webmapping. If there wasn’t this plugin-dependency, which resulted in every single discussion to be the main showstopper for SVG. With native SVG support in a popular browser like Firefox hopefully things start to change.
Back to Google Local: in SVG compatible browsers (such as Firefox 1.5) one can now use SVG rather than PNGs to draw polylines if following parameters are set:
_mSvgEnabled = true/false … to enable/disable SVG in SVG compatible browsers
_mSvgForced = true/false … to force the use of SVG in every browser (even if not capable of displaying SVG correctly) or limit SVG to compatible browsers.
If SVG is not “forced” Internet Explorer 5.5+ will still render polylines with VML (something like a rudimentary SVG…).
This simple comparsion gives an idea what can be done at what perfomance with SVG.
“It draws a random polyline with 100 segments. You can change the
number. There are “Redraw with SVG” and “Redraw without svg” buttons.”
SVG is a well elaborated standard. Maybe Google Local is the push that this technology needs.
Another interesting point on the Flash vs. SVG discussion is the take-over of Macromedia by Adobe. Now we have both technologies under one umbrella. Why not merging them together? Or at least bundle them to one single plugin. Since XML support is already built into Flash, why not extend it to SVG?
Thanks to Google’s Summer of Code an Open Source project is bringing up the best SVG editor I’ve seen so far – Inkscape. Since I’m not doing very artistic work in SVG I can’t comment those features. We are drawing maps and trying to make them usable online with the help of SVG (c.f. my ArcGIS SVG export macro). It’s a rather technical approach and for that reason I really appreciate the possibility to see the graphics (well, of course the visual work is vital as well) and browse/edit the XML tree at once.
As you can read in their FAQ Inkscape is not supposed to be a replacement for any big commercial vector graphics editor like Adobe Illustrator or Macromedia (Adobe) Freehand. But when it comes to SVG Inkscape is playing in the same league along with them.
Keep up the great work!
Mozilla Deer Park Alpha 1
SVG Support
SVG is W3C specification providing resolution-independent scalable vector graphics, along with a DOM. A technology preview of native SVG support is included in this release. Currently a subset of SVG 1.1 Full, missing functionality includes filters, declarative animation, and SVG defined fonts.
Time to check if our SVG mapping tools work outside the Adobe SVG Viewer as well.
Because I was not entirely satisfied with the built-in SVG export option of ArcMap I wrote this short macro to do it my own way. The essential feature, compared to ArcMap’s built-in SVG export, is that I can define an (known) ID for every SVG element out of the attribute table. Thus I’m able to access my SVG elements later via JavaScript.
What the macro does:
- Exports all layers and features of your map document (mxd) to SVG
- Every layer will be preserved as SVG group
- Adds the values of the field “SVG_ID” of your attribute table to every SVG element as ID
- Units and extent are taken from the layer properties of ArcMap
- Produces clean SVG 1.1 code
What the macro does not:
- no formating – no colours, stroke-widths, etc. – everything will be visible as black in black (I just needed a clean SVG skeleton, graphic attributes I add later via interactivity)
- no HTML embedding, you get just the SVG code
If you think this can be useful for your purpose, just copy & paste the code of the text file into the Visual Basic Editor of ArcMap (Project/ArcMap Objects/ThisDocument) and hit run.
SVG-Export
PostGIS 0.9.0 released
Beside various new features (e.g. GEOS 2.0) PostGIS now comes along with Klaus Försters AsSVG() functionality, which allows to deliver SVG elements directly out of PostGIS.
ESRI & PostGIS
ESRI released their ArcGIS Data Interoperability Extension, which finally offers a slightly integration of PostGIS into their products. A first review and user experience you can find here.
Windows & PostGIS
For testing PostgreSQL/PostGIS on windows without cygwin I recommend to check out those installers:
PostgreSQL Win32-Installer
PostGIS Win32-Installer
PostgreSQL/PostGIS Win32-Installer
PostgreSQL/PostGIS on Windows Tutorial
Während der Beschreibung der Funktionen des praktischen Beispiels kamen mir einige Ideen wie einzelne Features eventuell verbessert werden könnten. Ein paar Tests in diese Richtung gaben mir recht und das Beispiel wurde weitgehend adaptiert.
So, nach 2400 Zeilen Sourcecode ist der stabile Punkt, wo ich das Beispiel ruhen lassen kann, endgültig erreicht und mein eigener Ehrgeiz, eine funktionelle kartographische Applikation zu entwickeln, gestillt.
Highlights
- Automatisierte und maßstabsabhängige Generalisierung der Straßen und Bezirke
- Suche und Anzeige von Detailinformationen einzelner Kartenelemente (z.B. Nachbarschaftsfunktion bei Bezirken, Überlappungen bei Bezirken und Straßen)
- Plattformunabhängig und (theoretisch) skalierbar auf jede Bildschirmgröße durch ausschließlicher Verwendung der ASV-Script-Engine und ASV-DOM
- Bei Verwendung von PostgreSQL/PostGIS als Backend in GIS-Systemen könnte diese Anwendung das Web-Frontend bilden, die laufend und ohne zusätzliche Arbeitsschritte die aktuellen Daten visualisiert.
Eine Demonstration des Beispiels ist hier zu finden. Jedoch ist die Datenbank nicht online und daher sind einige Funktionen deaktiviert.
Im Herbst 2004 kam ein Update des von mir eingesetzten Datenbankservers PostgreSQL auf die Version 7.4 sowie des PostGIS-Moduls auf die Version 0.8.0 (inzwischen 0.8.1) heraus.
Die Aktualisierungen waren etwas trickreich, erweiterten jedoch mein Beispiel um essentielle Funktionen. Mit Hilfe von GEOS werden nun alle räumlichen Funktionen der OpenGIS “Simple Features for SQL” Spezifikation unterstützt.Als Beispiel möchte ich an dieser Stelle nur die Methode simplify erwähnen, die auf Basis des Douglas-Peuker Algorythmus eine automatisierte Generalisierung der Geodaten durchführt. Simplify führte in meinem Beispiel zu einer wesentlichen Steigerung der Darstellungsgeschwindigkeit bei gleichzeitiger Erhaltung der originalen Geo(GIS)daten, was eines meiner Ziele bei der Entwicklung des Beispiels war.
Die automatisierte Generalisierung von Geodaten ist im Allgemeinen ein sehr heikles Anwendungsgebiet. In meinem Beispiel ist jedoch die Ausgabegenauigkeit (“slivering polygons”) durchaus ausreichend und v.a. in Verbindung mit dem Perfomancegewinn als deutliche Verbesserung zu sehen.
Vollständige Migration der Scripts auf MySQL 4.1
Erarbeitung des schriftlichen Teils
Abgabe des Rohentwurfes Ende August 2003