Revised RFC-28 - Add X, Y, Z and M Expression Functions

[Robert Fortin]

Some javascript/style in this post has been disabled (why?)

Hi All!

 

I have updated the RFC-28 based on our discussion.  Please review and provide comments.

 

http://trac.osgeo.org/fdo/wiki/FDORfc28

 

Thanks for your inputs!

 

RF

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Robert Fortin]

Some javascript/style in this post has been disabled (why?)

Since there was no feedback since the last update and review request for RFC-28, I’m calling for a vote by the FDO PSC members.

 

http://trac.osgeo.org/fdo/wiki/FDORfc28

 

RF

 

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Frank Warmerdam]

Robert Fortin wrote:
> Since there was no feedback since the last update and review request for
> RFC-28, I’m calling for a vote by the FDO PSC members.
>
>  
>
> http://trac.osgeo.org/fdo/wiki/FDORfc28

Robert,

Apparently I missed the part of the discussion where it was decided that
adding additional accessors was outside the scope of this RFC.  I had
expected the StartPoint, EndPoint, NumPoints and PointN accessors to be
added.  Is adding them at the same time difficult?  It seems this would
give us a respectible set of accessors (possibly along with something to
access component geometries within a collection).

I'd add it quite bothers me that this sort of functionality is strictly
per-provider and that there isn't generic machinery to provide it to all
the non-RDBMS based providers in a convenient way.

I'm "-0" on the RFC as proposed because I feel a more comprehensive solution
to geometry accessors is desirable at this time rather than just adding things
in dribs-and-drabs.

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

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Jason Birch]

Some javascript/style in this post has been disabled (why?)

+1 Jason

 

Technically, I think that someone from the PSC is supposed to start/sponsor the vote, but with the current status (with Mateusz gone and Bob MIA) maybe we should suspend this until we meet to discuss the PSC composition going forward?

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Robert Fortin
Sent: Wednesday, November 12, 2008 09:09
To: FDO Internals Mail List
Subject: [fdo-internals] RFC-28 - Add X, Y, Z and M Expression Functions

 

Since there was no feedback since the last update and review request for RFC-28, I’m calling for a vote by the FDO PSC members.

 

http://trac.osgeo.org/fdo/wiki/FDORfc28

 

RF

 

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Robert Fortin]

Frank,

The scope limitation is due to resource and time constraints.  It's not ideal but I think the nice part about the discussion around this RFC was that we agreed to follow some standard going forward. Addition of other function can be done following those standard.

The implementation will add the functions and a generic implementation to the expression engine and therefore could be used by any provider. The new functions won't be part of the Standard functions list returned by the expression engine.  Each provider will need to add them to their supported list of function.  If we were adding them to the standard list, then we would have to change all the provider that would not support it.  At the moment, the intent is to expose them for SDF only.

So all other non-RDBMS provider would have to do is

- Register the functions as custom functions to the ExpressionEngine used by the provider.
- Add them to the list of supported functions returned by ExpressionCapabilities::GetFunctions()

I hope that raise your vote from -0 to a +0...

RF

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Frank Warmerdam (External)
Sent: Wednesday, November 12, 2008 12:19 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] RFC-28 - Add X, Y, Z and M Expression Functions

Robert Fortin wrote:
> Since there was no feedback since the last update and review request for
> RFC-28, I'm calling for a vote by the FDO PSC members.
>
>
>
> http://trac.osgeo.org/fdo/wiki/FDORfc28

Robert,

Apparently I missed the part of the discussion where it was decided that
adding additional accessors was outside the scope of this RFC.  I had
expected the StartPoint, EndPoint, NumPoints and PointN accessors to be
added.  Is adding them at the same time difficult?  It seems this would
give us a respectible set of accessors (possibly along with something to
access component geometries within a collection).

I'd add it quite bothers me that this sort of functionality is strictly
per-provider and that there isn't generic machinery to provide it to all
the non-RDBMS based providers in a convenient way.

I'm "-0" on the RFC as proposed because I feel a more comprehensive solution
to geometry accessors is desirable at this time rather than just adding things
in dribs-and-drabs.

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

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Greg Boone]

+1
Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Robert Fortin
Sent: Wednesday, November 12, 2008 12:36 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC-28 - Add X, Y, Z and M Expression Functions

Frank,

The scope limitation is due to resource and time constraints.  It's not ideal but I think the nice part about the discussion around this RFC was that we agreed to follow some standard going forward. Addition of other function can be done following those standard.

The implementation will add the functions and a generic implementation to the expression engine and therefore could be used by any provider. The new functions won't be part of the Standard functions list returned by the expression engine.  Each provider will need to add them to their supported list of function.  If we were adding them to the standard list, then we would have to change all the provider that would not support it.  At the moment, the intent is to expose them for SDF only.

So all other non-RDBMS provider would have to do is

- Register the functions as custom functions to the ExpressionEngine used by the provider.
- Add them to the list of supported functions returned by ExpressionCapabilities::GetFunctions()

I hope that raise your vote from -0 to a +0...

RF

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Frank Warmerdam (External)
Sent: Wednesday, November 12, 2008 12:19 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] RFC-28 - Add X, Y, Z and M Expression Functions

Robert Fortin wrote:
> Since there was no feedback since the last update and review request for
> RFC-28, I'm calling for a vote by the FDO PSC members.
>
>
>
> http://trac.osgeo.org/fdo/wiki/FDORfc28

Robert,

Apparently I missed the part of the discussion where it was decided that
adding additional accessors was outside the scope of this RFC.  I had
expected the StartPoint, EndPoint, NumPoints and PointN accessors to be
added.  Is adding them at the same time difficult?  It seems this would
give us a respectible set of accessors (possibly along with something to
access component geometries within a collection).

I'd add it quite bothers me that this sort of functionality is strictly
per-provider and that there isn't generic machinery to provide it to all
the non-RDBMS based providers in a convenient way.

I'm "-0" on the RFC as proposed because I feel a more comprehensive solution
to geometry accessors is desirable at this time rather than just adding things
in dribs-and-drabs.

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

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Frank Warmerdam]

Robert Fortin wrote:

> Frank,
>
> The scope limitation is due to resource and time constraints.  It's not
> ideal but I think the nice part about the discussion around this RFC was
> that we agreed to follow some standard going forward. Addition of other
> function can be done following those standard.
>
> The implementation will add the functions and a generic implementation to
> the expression engine and therefore could be used by any provider. The new
> functions won't be part of the Standard functions list returned by the
> expression engine.  Each provider will need to add them to their supported
> list of function.  If we were adding them to the standard list, then we
> would have to change all the provider that would not support it.  At the
> moment, the intent is to expose them for SDF only.
>
> So all other non-RDBMS provider would have to do is
>
> - Register the functions as custom functions to the ExpressionEngine used by
> the provider. - Add them to the list of supported functions returned by
> ExpressionCapabilities::GetFunctions()
>
> I hope that raise your vote from -0 to a +0...

Robert,

Well, how about I will convert from -0 to "0", leaning neither for nor
against.  I am very happy with the approach and following OGC's approach.
It just seems crazy to do it in such little steps.

I'm pleased to hear it is easy to turn on the capability for non-RDBMS
providers.  Wouldn't you like to prove it by doing it for the OGR and
Shape providers?   :-)

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

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Robert Fortin]

I'd like to do them all and expand the list of function but...

I looked at shp and it is pretty similar to SDF (code + unit test). So it's probably feasible.
OGR I'm not familiar with at all. I'd have to dig into it.
Thanks fot the upgraded vote!

RF

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Frank Warmerdam (External)
Sent: Wednesday, November 12, 2008 10:00 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] RFC-28 - Add X, Y, Z and M Expression Functions

Robert Fortin wrote:

> Frank,
>
> The scope limitation is due to resource and time constraints.  It's not
> ideal but I think the nice part about the discussion around this RFC was
> that we agreed to follow some standard going forward. Addition of other
> function can be done following those standard.
>
> The implementation will add the functions and a generic implementation to
> the expression engine and therefore could be used by any provider. The new
> functions won't be part of the Standard functions list returned by the
> expression engine.  Each provider will need to add them to their supported
> list of function.  If we were adding them to the standard list, then we
> would have to change all the provider that would not support it.  At the
> moment, the intent is to expose them for SDF only.
>
> So all other non-RDBMS provider would have to do is
>
> - Register the functions as custom functions to the ExpressionEngine used by
> the provider. - Add them to the list of supported functions returned by
> ExpressionCapabilities::GetFunctions()
>
> I hope that raise your vote from -0 to a +0...

Robert,

Well, how about I will convert from -0 to "0", leaning neither for nor
against.  I am very happy with the approach and following OGC's approach.
It just seems crazy to do it in such little steps.

I'm pleased to hear it is easy to turn on the capability for non-RDBMS
providers.  Wouldn't you like to prove it by doing it for the OGR and
Shape providers?   :-)

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

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Orest Halustchak]

+1
Orest.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Greg Boone
Sent: Wednesday, November 12, 2008 6:05 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC-28 - Add X, Y, Z and M Expression Functions

+1
Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Robert Fortin
Sent: Wednesday, November 12, 2008 12:36 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC-28 - Add X, Y, Z and M Expression Functions

Frank,

The scope limitation is due to resource and time constraints.  It's not ideal but I think the nice part about the discussion around this RFC was that we agreed to follow some standard going forward. Addition of other function can be done following those standard.

The implementation will add the functions and a generic implementation to the expression engine and therefore could be used by any provider. The new functions won't be part of the Standard functions list returned by the expression engine.  Each provider will need to add them to their supported list of function.  If we were adding them to the standard list, then we would have to change all the provider that would not support it.  At the moment, the intent is to expose them for SDF only.

So all other non-RDBMS provider would have to do is

- Register the functions as custom functions to the ExpressionEngine used by the provider.
- Add them to the list of supported functions returned by ExpressionCapabilities::GetFunctions()

I hope that raise your vote from -0 to a +0...

RF

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Frank Warmerdam (External)
Sent: Wednesday, November 12, 2008 12:19 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] RFC-28 - Add X, Y, Z and M Expression Functions

Robert Fortin wrote:
> Since there was no feedback since the last update and review request for
> RFC-28, I'm calling for a vote by the FDO PSC members.
>
>
>
> http://trac.osgeo.org/fdo/wiki/FDORfc28

Robert,

Apparently I missed the part of the discussion where it was decided that
adding additional accessors was outside the scope of this RFC.  I had
expected the StartPoint, EndPoint, NumPoints and PointN accessors to be
added.  Is adding them at the same time difficult?  It seems this would
give us a respectible set of accessors (possibly along with something to
access component geometries within a collection).

I'd add it quite bothers me that this sort of functionality is strictly
per-provider and that there isn't generic machinery to provide it to all
the non-RDBMS based providers in a convenient way.

I'm "-0" on the RFC as proposed because I feel a more comprehensive solution
to geometry accessors is desirable at this time rather than just adding things
in dribs-and-drabs.

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

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Greg Boone]

Put the SHP implementation on my list. Looks very straightforward.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Robert Fortin
Sent: Thursday, November 13, 2008 9:51 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC-28 - Add X, Y, Z and M Expression Functions

I'd like to do them all and expand the list of function but...

I looked at shp and it is pretty similar to SDF (code + unit test). So it's probably feasible.
OGR I'm not familiar with at all. I'd have to dig into it.
Thanks fot the upgraded vote!

RF

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Frank Warmerdam (External)
Sent: Wednesday, November 12, 2008 10:00 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] RFC-28 - Add X, Y, Z and M Expression Functions

Robert Fortin wrote:

> Frank,
>
> The scope limitation is due to resource and time constraints.  It's not
> ideal but I think the nice part about the discussion around this RFC was
> that we agreed to follow some standard going forward. Addition of other
> function can be done following those standard.
>
> The implementation will add the functions and a generic implementation to
> the expression engine and therefore could be used by any provider. The new
> functions won't be part of the Standard functions list returned by the
> expression engine.  Each provider will need to add them to their supported
> list of function.  If we were adding them to the standard list, then we
> would have to change all the provider that would not support it.  At the
> moment, the intent is to expose them for SDF only.
>
> So all other non-RDBMS provider would have to do is
>
> - Register the functions as custom functions to the ExpressionEngine used by
> the provider. - Add them to the list of supported functions returned by
> ExpressionCapabilities::GetFunctions()
>
> I hope that raise your vote from -0 to a +0...

Robert,

Well, how about I will convert from -0 to "0", leaning neither for nor
against.  I am very happy with the approach and following OGC's approach.
It just seems crazy to do it in such little steps.

I'm pleased to hear it is easy to turn on the capability for non-RDBMS
providers.  Wouldn't you like to prove it by doing it for the OGR and
Shape providers?   :-)

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

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

[Greg Boone]

OK. I think we can call the voting closed. The motion is passed.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Orest Halustchak
Sent: Thursday, November 13, 2008 10:03 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC-28 - Add X, Y, Z and M Expression Functions

+1
Orest.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Greg Boone
Sent: Wednesday, November 12, 2008 6:05 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC-28 - Add X, Y, Z and M Expression Functions

+1
Greg

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Robert Fortin
Sent: Wednesday, November 12, 2008 12:36 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC-28 - Add X, Y, Z and M Expression Functions

Frank,

The scope limitation is due to resource and time constraints.  It's not ideal but I think the nice part about the discussion around this RFC was that we agreed to follow some standard going forward. Addition of other function can be done following those standard.

The implementation will add the functions and a generic implementation to the expression engine and therefore could be used by any provider. The new functions won't be part of the Standard functions list returned by the expression engine.  Each provider will need to add them to their supported list of function.  If we were adding them to the standard list, then we would have to change all the provider that would not support it.  At the moment, the intent is to expose them for SDF only.

So all other non-RDBMS provider would have to do is

- Register the functions as custom functions to the ExpressionEngine used by the provider.
- Add them to the list of supported functions returned by ExpressionCapabilities::GetFunctions()

I hope that raise your vote from -0 to a +0...

RF

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Frank Warmerdam (External)
Sent: Wednesday, November 12, 2008 12:19 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] RFC-28 - Add X, Y, Z and M Expression Functions

Robert Fortin wrote:
> Since there was no feedback since the last update and review request for
> RFC-28, I'm calling for a vote by the FDO PSC members.
>
>
>
> http://trac.osgeo.org/fdo/wiki/FDORfc28

Robert,

Apparently I missed the part of the discussion where it was decided that
adding additional accessors was outside the scope of this RFC.  I had
expected the StartPoint, EndPoint, NumPoints and PointN accessors to be
added.  Is adding them at the same time difficult?  It seems this would
give us a respectible set of accessors (possibly along with something to
access component geometries within a collection).

I'd add it quite bothers me that this sort of functionality is strictly
per-provider and that there isn't generic machinery to provide it to all
the non-RDBMS based providers in a convenient way.

I'm "-0" on the RFC as proposed because I feel a more comprehensive solution
to geometry accessors is desirable at this time rather than just adding things
in dribs-and-drabs.

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

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals