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

[David William Bitner]

Man, it'd be nice if the OpenGIS Simple Features implementation for
SQL and the SQL/MM standards were addressable through html rather than
just as click through pdf so we could just link right to those.

On Tue, Jul 15, 2008 at 6:20 AM, Obe, Regina <robe.dnd at cityofboston.gov> wrote:
> 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.
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>



-- 
************************************
David William Bitner