[postgis-devel] Docbook ID's and <a name> links

[Obe, Regina]

I didn't see this email when I wrote one of my others.

I still like combining

   OpenGIS Functions -> Geometry Relationship Functions
   PostGIS Functions -> Measurement Functions


to 

Geometry Relationship and Measurement Functions

I don't know about others, but I tend to think of 
Relationships and Measurement Functions in the same vein except
Relationship return true/false and Measurement functions return a
measurement.

Spatial Predicates sounds too -  hmm logicy mathy? 
Its not an immediate concept you can visualize and for space,
visualization is important.

 

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
Kevin Neufeld
Sent: Monday, July 14, 2008 6:50 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Docbook ID's and <a name> links

Obe, Regina wrote:
> Okay that's good so we can have meaningful names.  So what goes in 
> Chapter  6?  I can start moving my changes into chapter 7 and putting
in 
> the refentry replacement when you are ready.
>  
> So would we just delete whatever we have in chapter 6 once we move it
to 
> chapter 7?
>  
> Thanks,
> Regina

That would be great.  Yes, I propose we delete the function entry(s) 
from chapter 6 as we make a new refentry in chapter 7.  Eventually ch6 
would disappear entirely.  I foresee this taking some time, but with 
couple of people working on this, it's not too bad.  Functions sometimes

occur several times in the docs in different sections.

IE. ST_Distance() is in:
   OpenGIS Functions -> Geometry Relationship Functions
   PostGIS Functions -> Measurement Functions
   SQL-MM Functions
each time with a different definition, which I think could get cleaned 
up.  Other functions are in appropriate headings, like ST_LineMerge 
which is in the Editors heading when its really a constructor like 
ST_Polygonize.

I think first thing we would need to come up with though, is an outline 
that will reduce the number of duplicate entries.  As you may recall, it

was discussed that the "OpenGIS Functions" and "PostGIS Extensions" 
could merge together 
(http://postgis.refractions.net/pipermail/postgis-devel/2008-June/003134
.html). 
   Should we include SQL-MM and ArcSDE functions as well?

What about something like...

6.1  Management Functions
6.2  Geometry Constructors
6.3  Geometry Accessors
6.4  Geometry Editors
6.5  Geometry Outputs
6.6  Operators
6.7  Spatial Predicates
6.8  Linear Referencing
6.9  Long Transactions Support
6.10 Misc

Alternatives?

-- Kevin
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel
-----------------------------------------
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.