[postgis-devel] Nice diagrams
robe.dnd at cityofboston.gov
Fri Jul 18 12:26:59 PDT 2008
I second that - the drop shadows add a nice gah gah touch, but we
already have color which is better than most of the other spatial db
I supose we should worry about the colors how they would render on
non-color printers too.
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Dane
Sent: Friday, July 18, 2008 3:23 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Nice diagrams
+1 on your graphics an a excellent start. I agree with Mark that it
would be very useful to think through a standardized approach to
generating/automating the graphics.
On Jul 16, 2008, at 9:27 AM, Kevin Neufeld wrote:
> Ah yes, that's a good point. The images were taken using OpenJUMP's
> screenshot feature and modified using PhotoShop. I suppose I could
> save the features as small shapefiles, jml, or gml, but it would be
> nice to save the styling as well (which doesn't work yet in JUMP).
What if we created a set of ultra simple sample data of each geometry
type. These could sit in svn and we could pull from them and add
styling for the graphics and source them as raw data samples for the
code examples (where appropriate).
> (Personally, I like the drop shadows, which obviously JUMP can't do
> as well).
I agree that drop shadows would be nice but I'd personally like to see
just crisp svg or png graphics with nice, consistent colors as a first
> Does anyone have any suggestions how we could standardize this?
> Perhaps a GIS editor I'm unware of that can perform nice rendering
> so all we have to do is load a project file and take some screen
It would be ideal if the graphics could either be autogenerated ( if
they are turned into png, gif etc) during the build process or
generated dynamically within the HTML documentation.
Options in my mind are:
1) write a simple perl, python, or other script that could read in the
features from the svn repo dir and (re)generate the graphics and pngs/
gifs. This could be done with mapserver, mapnik, or a variety of
graphics toolkits, but I would think that the simplest, least
dependencies possible approach would be best and I'm not sure what
that would be yet.
2) used Openlayers to read/parse the features from the relative dir
and render them dynamically as svg wherever graphics are needed.
The OL idea very well may be shooting for the moon, but it would have
the advantage of not needing any build dependencies and new graphics
could be added anywhere in the page simply by pointing a generic OL
map to a WKT, GML, or GeoJSON file. However, I'm unclear on the
may wreak havoc or preclude graphics inclusion within the PDF output.
> Or, alternatively, we just agree on a color theme, image size, etc.
> and save the features as WKT in an images_src directory. (Is there
> an opensource picture editor out there that can do drop shadows?)
WKT can't hold any styling information the way that GML or GeoJson
can, afaik. But I really like this train of thinking. The GUI
application Inkscape is the only editor I know of for creating drop
shadows with svg.
I'll do some digging to try to answer some of my own gaps in knowledge
> Mark Cave-Ayland wrote:
>> Seconded. Well done on all the work you've put into this Kevin. My
>> only query was that I can't see the source files for the graphics
>> in SVN, i.e. particularly for st_crosses*.gif. I'm just thinking
>> about if we decide to alter the graphics at a later date (or add
>> new ones), then it becomes so much easier to match the existing
>> style with the vector sources available.
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
postgis-devel mailing list
postgis-devel at postgis.refractions.net
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.
More information about the postgis-devel