[fdo-dev] FGF and spatial context

[Haris Kurtagic]

Robert,
 
It is based on but not exactly same, please correct me if I am wrong.
Yes with each, but in definition of FGF already there is a lot of
overhead, I think (my remark bellow).
 
a)  Doesn't need to be wkt could be something meaningful to provider
(one int per feature)
b) I don't think so, provider will now what to do whit this, no need to
FDO stores something, provider will do that - if needs to
 
Yes, no need for provider to do projections but some data stores
requires these information to be able to store geometry at all, like
Oracle Spatial.
Generally yes and now, if you have data store like Oracle in which you
have ability to work with different coordinate systems at once.
 
It is not about bypassing FDO interface FdoISqlCommand is part of it,
but also in Select command we could come across selecting against
different coordinate systems and
we need to send correct geometry parameters. So if select is coming for
two tables with different coordinate systems, we are in trouble.
 
Haris

________________________________

From: Robert Fortin [mailto:robert.fortin at autodesk.com] 
Sent: Thursday, November 02, 2006 6:02 PM
To: dev at fdo.osgeo.org
Subject: RE: [fdo-dev] FGF and spatial context


Haris,
 
FGF is based on OGC WKB specification from Simple Feature specification
and is designed to be lightweight and as efficient as possible.   WKB
doesn't store the coord system info with the geometry binary so FGF
doesn't either. If we were to keep the info on the related SC with each
FGF: 
 
a) It would make it much heavier (I assume the correct info to preserve
would be the WKT so it can be shared between providers).
b) If we wanted it to keep it lightweigth we would have to create a
common based for coordinate system (a coordinate system catalog).  As
you could see, FDO doesn't have coord system capability although there
was discussion to add an API around it few years ago.  
 
Another reason for not storing the SC with each FGF is because it is not
a requirement for FDO Providers to have the capability of doing
projection. The data must be passed in the correct projection so it can
be consumed by the target connection. Projection of FGF is done by
client apps and not by the provider itself.  The apps generally know
where the data came from and where it is going.
 
Using SQLCommand, you bypass a lot of the FDO infrastructure and while
doing so, you loose some of the metadata that would be available
otherwise. But I guess you have a good reason for using SQLcommand
instead of SelectCommand. 
 
As for ActiveSpatialContext, this was a legacy from other eras that was
made obsolete after we added the association between geometry property
and spatial context.   We think this is a better concept because it
enable pro Nobody relies on that anymore.
 
RF

________________________________

From: Haris Kurtagic [mailto:haris at sl-king.com] 
Sent: Thursday, November 02, 2006 6:52 AM
To: dev at fdo.osgeo.org
Subject: [fdo-dev] FGF and spatial context


Hi,
 
I came across issue converting a FGF format to provider specific (
Oracle ).
To convert it properly provider needs to know Spatial Context, and when
I am doing it for feature class queries it is ok in a sense that I can
get spatial context (and SRID) from geometry property.
 
But, I came across problem, when I wanted to use FGF as parameter in
FdoISQLCommnad, then from FGF itself I can't get spatial context.
I can imagine that concept of ActiveSpatialContext can help, but once I
asked here about it I got replied that this concept of Active Spatial
Context is going out.
 
Regardless of Active Spatial Context that I think it would be benefit if
in FGF could hold spatial context association in it ( perhaps to add a
kind of id for spatial context  which would be provider specific ) .
 
BTW:
If there is a chance of extending a FGF format I would like to point on
issue of repeating of data in that format, for example: for every point
in multipoint there is again gtype saying it is a point and
dimensionality .
 
Haris
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20061102/67a8eb2b/attachment.html