[ZMapServer-Developers] Fwd: SVG/GML matchup
Status: Alpha
Brought to you by:
sgillies
|
From: Sean G. <sgi...@fr...> - 2005-02-08 21:04:30
|
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 > |