<!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=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>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=955584715-02112006><FONT face=Arial 
color=#0000ff size=2>FGF is&nbsp;based on OGC WKB specification&nbsp;from Simple 
Feature specification and is designed to be lightweight and as efficient as 
possible.&nbsp;&nbsp; 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>&nbsp;</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&nbsp;would be&nbsp;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&nbsp;keep it&nbsp;lightweigth we 
would have to&nbsp;create a common based for&nbsp;coordinate system (a 
coordinate system catalog).&nbsp; As you could see, FDO doesn't have coord 
system capability although there was discussion to&nbsp;add an API around it few 
years ago.&nbsp;&nbsp;</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=955584715-02112006><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</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&nbsp;it is&nbsp;not a requirement for FDO Providers&nbsp;to have the 
capability of doing projection. The data must be passed&nbsp;in the correct 
projection&nbsp;so it can&nbsp;be consumed by the target connection. Projection 
of FGF is done by client apps and not by the provider itself.&nbsp;&nbsp;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>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=955584715-02112006><FONT face=Arial 
color=#0000ff size=2>Using SQLCommand,&nbsp;you bypass a lot of the FDO 
infrastructure and while doing so, you loose some of the metadata that would be 
available otherwise.&nbsp;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>&nbsp;</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&nbsp;after we&nbsp;added&nbsp;the association 
between geometry property and spatial context.&nbsp;&nbsp; We think this is a 
better concept because it enable pro&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</DIV>
<DIV><SPAN class=046063811-02112006><FONT face=Arial size=2>Regardless of Active 
Spatial Context&nbsp;that I think it would be benefit if in FGF could hold 
spatial context association in it ( perhaps to add a kind of id&nbsp;for spatial 
context&nbsp; which would&nbsp;be provider specific ) .</FONT></SPAN></DIV>
<DIV><SPAN class=046063811-02112006><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</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&nbsp;extending a FGF format I would&nbsp;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>&nbsp;</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>&nbsp;</DIV>
<DIV><SPAN class=046063811-02112006><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV></BODY></HTML>