<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2963" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=421460517-02112006><FONT face=Arial
color=#0000ff size=2>Robert,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=421460517-02112006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=421460517-02112006><FONT face=Arial
color=#0000ff size=2>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).</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=421460517-02112006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=421460517-02112006><FONT face=Arial
color=#0000ff size=2>a) Doesn't need to be wkt could be something
meaningful to provider (one int per feature)</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=421460517-02112006><FONT face=Arial
color=#0000ff size=2>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</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=421460517-02112006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=421460517-02112006><FONT face=Arial
color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=421460517-02112006><FONT face=Arial
color=#0000ff size=2>Generally yes and now, if you have data store like Oracle
in which you have ability to work with different coordinate systems at
once.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=421460517-02112006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=421460517-02112006><FONT face=Arial
color=#0000ff size=2>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</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=421460517-02112006><FONT face=Arial
color=#0000ff size=2>we need to send correct geometry parameters. So if select
is coming for two tables with different coordinate systems, we are in
trouble.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=421460517-02112006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=421460517-02112006><FONT face=Arial
color=#0000ff size=2>Haris</FONT></SPAN></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Robert Fortin
[mailto:robert.fortin@autodesk.com] <BR><B>Sent:</B> Thursday, November 02, 2006
6:02 PM<BR><B>To:</B> dev@fdo.osgeo.org<BR><B>Subject:</B> RE: [fdo-dev] FGF and
spatial context<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV dir=ltr align=left><SPAN class=955584715-02112006><FONT face=Arial
color=#0000ff size=2>Haris,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=955584715-02112006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=955584715-02112006><FONT face=Arial
color=#0000ff size=2>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: </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=955584715-02112006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=955584715-02112006><FONT face=Arial
color=#0000ff size=2>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).</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=955584715-02112006><FONT face=Arial
color=#0000ff size=2>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. </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=955584715-02112006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=955584715-02112006><FONT face=Arial
color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=955584715-02112006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=955584715-02112006><FONT face=Arial
color=#0000ff size=2>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. </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=955584715-02112006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN><SPAN class=955584715-02112006><FONT
face=Arial color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=955584715-02112006><FONT face=Arial
color=#0000ff size=2>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 </FONT></SPAN><SPAN
class=955584715-02112006><FONT face=Arial color=#0000ff size=2>Nobody relies on
that anymore.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=955584715-02112006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=955584715-02112006><FONT face=Arial
color=#0000ff size=2>RF</FONT></SPAN></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Haris Kurtagic [mailto:haris@sl-king.com]
<BR><B>Sent:</B> Thursday, November 02, 2006 6:52 AM<BR><B>To:</B>
dev@fdo.osgeo.org<BR><B>Subject:</B> [fdo-dev] FGF and spatial
context<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><SPAN class=046063811-02112006><FONT face=Arial
size=2>Hi,</FONT></SPAN></DIV>
<DIV><SPAN class=046063811-02112006><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=046063811-02112006><FONT face=Arial size=2>I came across issue
converting a FGF format to provider specific ( Oracle ).</FONT></SPAN></DIV>
<DIV><SPAN class=046063811-02112006><FONT face=Arial size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=046063811-02112006><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=046063811-02112006><FONT face=Arial size=2>But, I came across
problem, </FONT></SPAN><SPAN class=046063811-02112006><FONT face=Arial
size=2>when I wanted to use FGF as parameter in FdoISQLCommnad, then from FGF
itself I can't get spatial context.</FONT></SPAN></DIV>
<DIV><SPAN class=046063811-02112006><FONT face=Arial size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=046063811-02112006><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=046063811-02112006><FONT face=Arial size=2>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 ) .</FONT></SPAN></DIV>
<DIV><SPAN class=046063811-02112006><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=046063811-02112006><FONT face=Arial
size=2>BTW:</FONT></SPAN></DIV>
<DIV><SPAN class=046063811-02112006><FONT face=Arial size=2>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 .</FONT></SPAN></DIV>
<DIV><SPAN class=046063811-02112006><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=046063811-02112006><FONT face=Arial
size=2>Haris</FONT></SPAN></DIV>
<DIV><SPAN class=046063811-02112006><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=046063811-02112006><FONT face=Arial
size=2></FONT></SPAN> </DIV></BODY></HTML>