[postgis] PostGIS relationship to SFSQL Specification

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[postgis] PostGIS relationship to SFSQL Specification

Frank Warmerdam
Guys,

I am reviewing the OGC SFSQL specification and I am wondering about how
closely you are interested in following it.  In my dreams, PostGIS would
implmeent a useful subset of the SFSQL "Types and Functions" specification
in a manner that would make it relatively easy to port applications between
this environment and other environments claiming to implement SFSQL (SDE?
Oracle?).

If this is a reasonable goal, could we start following the spec now as
new features are introduced?  For instance, the progress report on Saturday
mentioned that the new wkb_ndr() and wkb_xdr() functions are being added.
A cursory review of the SFSQL spec suggests the equivelent function from it
is called AsBinary() and that there is no control of the byte order.  I
would suggest using this, and adding an optional argument to control XDR/NDR
byte order defaulting to what ever is most convenient when that argument isn't
given.

I haven't reviewed the other features of PostGIS for their relatinship with
SFSQL, but it seems that there are other possibly unnecessary differences as
well.  For instance, are the geometry tests done in a syntactically
equivelent way for the amount that PostGIS wishes to implement?  

Looking through postgis.txt I do see a few more examples.  For instance, the
SFSQL geometry types can be operated on by a Length() operator, which is
presumably the same as the PostGIS length2d() operator.  The PostGIS npoints()
operator is similar to the NumPoints() operator in SFSQL.

So, can we strive towards SFSQL compliance, even if we don't intend to
implement everything?

Best regards,

---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

To unsubscribe from this group, send an email to:
[hidden email]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 



Reply | Threaded
Open this post in threaded view
|

Re: [postgis] PostGIS relationship to SFSQL Specification

Paul Ramsey-2
This is a really good idea. I'll haul out our SFSQL binder for Dave...

Frank Warmerdam wrote:

>
> Guys,
>
> I am reviewing the OGC SFSQL specification and I am wondering about how
> closely you are interested in following it.  In my dreams, PostGIS would
> implmeent a useful subset of the SFSQL "Types and Functions" specification
> in a manner that would make it relatively easy to port applications between
> this environment and other environments claiming to implement SFSQL (SDE?
> Oracle?).
>
> If this is a reasonable goal, could we start following the spec now as
> new features are introduced?  For instance, the progress report on Saturday
> mentioned that the new wkb_ndr() and wkb_xdr() functions are being added.
> A cursory review of the SFSQL spec suggests the equivelent function from it
> is called AsBinary() and that there is no control of the byte order.  I
> would suggest using this, and adding an optional argument to control XDR/NDR
> byte order defaulting to what ever is most convenient when that argument isn't
> given.
>
> I haven't reviewed the other features of PostGIS for their relatinship with
> SFSQL, but it seems that there are other possibly unnecessary differences as
> well.  For instance, are the geometry tests done in a syntactically
> equivelent way for the amount that PostGIS wishes to implement?
>
> Looking through postgis.txt I do see a few more examples.  For instance, the
> SFSQL geometry types can be operated on by a Length() operator, which is
> presumably the same as the PostGIS length2d() operator.  The PostGIS npoints()
> operator is similar to the NumPoints() operator in SFSQL.
>
> So, can we strive towards SFSQL compliance, even if we don't intend to
> implement everything?
>
> Best regards,
>
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent
>
> To unsubscribe from this group, send an email to:
> [hidden email]
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

--
      __
     /
     | Paul Ramsey
     | Refractions Research
     | Email: [hidden email]
     | Phone: (250) 885-0632
     \_

To unsubscribe from this group, send an email to:
[hidden email]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/