[ZMapServer-Developers] Fwd: SVG/GML matchup

[Sean G. <sgi...@fr...>]

Forwarded on behalf of Yves Moisan who is the victim of overzealous (I 
hope) or incompetent network administrators :)

Begin forwarded message:

> From: "Moisan Yves" <ym...@gr...>
> Date: February 7, 2005 10:07:31 AM MST
> To: <sgi...@fr...>
> Subject: SVG/GML matchup
>
> Hi Sean,
>
> I'm getting more and more acquainted with PCL/ZCO and I now have a
> better feeling for the origin of the class design of PCL looking at the
> pointer you make to OGC's GeoAPI.  Good thing we can get rid of
> getters/setters in Python indeed!
>
> I think a lot of the things I would ultimately want can be done by
> Python scripts on the filesystem (e.g. your examples of DataStore and
> Styles). BTW, I find this a pretty clever idea to allow such user
> extensions via the filesystem!  Since I'm rather obsessed with 
> standards
> (I know I'll have to calm down a bit at least in the first iterations
> ...), I was trying to find URL's pointing to standard symbol sets on 
> the
> internet in a bid to provide a filesystem based wrapper style object
> providing the necessary Python interface (and eventually having a local
> application to synchronize with the third-party symbol list).  I 
> haven't
> found any yet but I was thinking it could be interesting to start
> building "open standardized" symbols.  I found some standardization of
> geological symbols at the FDGC, but it does not seem to be very active
> (proposed document in 2000 ...).
>
> One interesting avenue could be to use SVG for symbol definitions.
> There is plenty of resources on carto.net to help one build symbol
> definitions in SVG and I also found this URL which demonstrates the
> combined use of GML and SVG :
> http://www.svgopen.org/2004/papers/VisualizingEditingGISdatawithSVG/
>
> Quote : " As GML is not for data display, SVG is an ideal vector 
> graphic
> for displaying geographic data. GML sets at the backend to store and
> transport data and on the other side SVG sets on front end to render 
> and
> display geographic data. They not only can visualize geographic data on
> the web, but also give the possibility to edit geographic data online."
>
> I think using GML as a transport layer only could be good enough if the
> data store is in ZODB.  There could be the equivalent of 
> AsGML()/AsSVG()
> for Zope objects, in which case it could be relatively easy to combine
> data stored in the ZODB with data stored in PostGIS, for example, and
> the backend would be abstracted from the GML (i.e. it wouldn't have to
> store data as GML per se).  Imagine a Zope-based WFS service : we'd ask
> for data, Zope would get data from any number of DataStores and
> everything would come out as GML.  For client Zope applications
> (displaying maps), data could be requested to DataStores AsSVG().  I
> don't know where AsGML()/AsSVG() functions would belong in your class
> diagrams for now but my feeling is that those would be very useful
> utilities.  Or else ZCO could be responsible for AsGML() only and leave
> the SVG transformation to an external XSLT engine like mod_transform
> (which uses libxml2 AFAIK) ??  I guess that boils down to what 
> GeoClient
> offers : SVG rendering of a WFS.
>
> What do you think ?
>
> Yves
>