<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META content="text/html; charset=us-ascii" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.18828"></META>
<META name=SKYPE_FRAMEID content=HBROAMAKDT></META>
<META id=skype_v3_tb_marker_id name=SKYPE_PARSING_HAS_FINISHED
content=metacontent></META></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=135363814-31102009><FONT color=#0000ff
size=2 face=Arial>Nicklas and Paul,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=135363814-31102009><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=135363814-31102009><FONT color=#0000ff
size=2 face=Arial>Yap that's the main point. To add</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=135363814-31102009><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=135363814-31102009><FONT color=#0000ff
size=2 face=Arial>I'm not really in disagreement with Paul. I see his
point too. I'm just prodding him to think about all his use cases a little
more because I don't feel he has.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=135363814-31102009><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=135363814-31102009><FONT color=#0000ff
size=2 face=Arial>My feelings to sum up</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=135363814-31102009><FONT color=#0000ff
size=2 face=Arial>1) We have not thought about the complete ramifications of
this hack and I'm really concerned about the novice that transitions to an
expert rather than just getting them hooked on PostGIS. Perhaps I'm being
overly silly with that and even said, Paul's approach might be an easier to
transition solution. </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=135363814-31102009><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=135363814-31102009></SPAN><SPAN
class=135363814-31102009><FONT color=#0000ff size=2 face=Arial>2) My concern is
the penalty of putting it in and having to take it out later might be very great
(both from a code, testing, as well as a mindset perspective). I
just feel it needs more thought and testing and really if we want to make our
December deadline, I don't want it rushed in so lightly.
</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=135363814-31102009><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=135363814-31102009><FONT color=#0000ff
size=2 face=Arial>Unless of course Paul -- you want to wait till January or
February to release 1.5?</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=135363814-31102009><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=135363814-31102009><FONT color=#0000ff
size=2 face=Arial>Now the ST_Max_Distance is a separate issue. I would put
in the ST_ConvexHull hack in place. The reason being is that it just
improves performance any way I can think you slice it and an experienced user
would do exactly the same thing always and when you finally incorporate it
into the core function, there is no change in existing code just a speed
improvement. So to me its basically our ST_DWithin hack -- a very tried
and trued obvious answer. Its an implementation detail with no clear leaky
effects.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=135363814-31102009><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=135363814-31102009><FONT color=#0000ff
size=2 face=Arial>With that said, there are some clear functions in geometry
that are safe to put a geography cover over. Those ones where there is
clearly only one answer and don't involve transformation.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=135363814-31102009><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=135363814-31102009><FONT color=#0000ff
size=2 face=Arial>like ST_X, ST_Y etc. That don't require transformation
so no screw up in data. Also observe that even the geometry(geography ....
in these there is no penalty becuase the geometry/geography isn't changing so
the planner can cache the geometry to geography conversion. The
ST_Transformation ones however, the geometry/geography is changing slightly at
each step since ST_Tranformation is a lossy operation so you are not only
incurring overhead (because these answers can't be cached), but also adding in
extra errors .</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=135363814-31102009><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=135363814-31102009><FONT color=#0000ff
size=2 face=Arial>To me this is a bleeding abstraction and that is the main
reason I don't like it.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=135363814-31102009><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=135363814-31102009><FONT color=#0000ff
size=2 face=Arial>So getting back to you Paul,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=135363814-31102009><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=135363814-31102009><FONT color=#0000ff
size=2 face=Arial>What functions exactly are you planning to put a veil
over? ST_Buffer well that one is used so much and is not as exact anyway
that I suppose I can grudgingly accept that as okay.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=135363814-31102009><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=135363814-31102009><FONT color=#0000ff
size=2 face=Arial>Thanks,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=135363814-31102009><FONT color=#0000ff
size=2 face=Arial>Regina</FONT></SPAN></DIV>
<DIV dir=ltr align=left><FONT color=#0000ff size=2
face=Arial></FONT><BR> </DIV>
<DIV dir=ltr lang=en-us class=OutlookMessageHeader align=left>
<HR tabIndex=-1>
<FONT size=2 face=Tahoma><B>From:</B>
postgis-devel-bounces@postgis.refractions.net
[mailto:postgis-devel-bounces@postgis.refractions.net] <B>On Behalf Of
</B>nicklas.aven@jordogskog.no<BR><B>Sent:</B> Saturday, October 31, 2009 10:04
AM<BR><B>To:</B> PostGIS Development Discussion<BR><B>Subject:</B> Re:
[postgis-devel] Geog/Geom Hack<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV align=left>Hallo</DIV>
<DIV align=left> </DIV>
<DIV align=left>I can see the points from both of you. I think the most
important argument from you Regina is that it is not transparent enough. A
skillfull user trying postgis might be disapointed when realizing that the
nested functions caused an unnecessary big rounding-error.</DIV>
<DIV align=left>But if it is obvious that it is a "special" function at least
for the experienced user knowing about common function-names I don't think it is
a big problem and might work as an easy shortcut at least during the process of
learning.</DIV>
<DIV align=left> </DIV>
<DIV align=left>As I understand it this could be a solution for using many
functions against geography so, why not note it in the function name
like:</DIV>
<DIV align=left>ST_tBuffer for transformed buffer. Then when time is to
introduse a "real" variant of the function they can coexist and it will not
change the bahavior inside an application without someone consciously changes
the function name and remove the t.</DIV>
<DIV align=left> </DIV>
<DIV align=left>the t would be independent of geography-geometry in semantics
and just indicate that it is a lower-precision variant. I fit was commonly used
it would work as a warning to experienced users.</DIV>
<DIV align=left> </DIV>
<DIV align=left>I have a similar question about st_max_distance. The function
gets very much more effective when ran together with convexhull. I saw the trick
in <SPAN class=refentrytitle>ST_MinimumBoundingCircle and id makes a big
difference to do :</SPAN></DIV>
<DIV align=left><SPAN
class=refentrytitle>st_max_distance(st_convexhull(the_geom)) instead of just
<SPAN class=refentrytitle>st_max_distance(the_geom). </SPAN></SPAN></DIV>
<DIV align=left><SPAN class=refentrytitle><SPAN class=refentrytitle>The question
is: Should that be put in the sql-function?</SPAN></SPAN></DIV>
<DIV align=left><SPAN class=refentrytitle><SPAN class=refentrytitle>My opinion
now is that we just tell about it in the documentation and aims at doing that
trick internally in C in the future. Maybe together with moving the whole
convexhull to postgis-native from geos. It didn't look that impossible fromthe
JTS-code.</SPAN></SPAN></DIV>
<DIV align=left><SPAN class=refentrytitle><SPAN
class=refentrytitle></SPAN></SPAN> </DIV>
<DIV align=left><SPAN class=refentrytitle><SPAN
class=refentrytitle>/Nicklas</SPAN></SPAN></DIV>
<DIV align=left> </DIV>
<DIV align=left><BR>2009-10-31 Paul Ramsey wrote:<BR><BR>I still think I'm right
:) Honestly, I've got to a lot of trouble to<BR>>make this stuff for newbies,
and I don't think "learn how it works" is<BR>>the right answer for them. They
had that option before, but taking GIS<BR>>101 is not an option for these
people, they need something that "just<BR>>works". It's easier to teach the
experienced people the pitfalls than<BR>>the inexperienced people the
basics.<BR>><BR>>BTW, I just upgraded distance_sphere and
distance_spheroid to be as<BR>>powerful (handling point/line/polygon) as the
geography variants,<BR>>removing excuses for transforming geometries into
geographies for<BR>>processing purposes.<BR>><BR>>P.<BR>><BR>>On
Fri, Oct 30, 2009 at 9:15 PM, Paragon Corporation
<LR@PCORP.US></LR@PCORP.US>wrote:<BR>>> Paul,<BR>>> For what its
worth, here is another reason why I don't like this idea and I<BR>>> think
we should at least think about its ramifications more so should put
it<BR>>> off for consideration until 2.0.<BR>>><BR>>> In
geometry processing, its common practice to apply a lot of functions
in<BR>>> succession<BR>>><BR>>>
process1(process2(process3(geometry/geography)<BR>>><BR>>> With your
hackish approach -- the unsuspecting novice user will be incurring<BR>>> a
lot of transformation rounding errors with each process<BR>>><BR>>>
The advanced user, won't know if this is okay or not -- because they
can't<BR>>> tell by looking at the function call the hidden
transformations going on.<BR>>><BR>>> If these did not exist, they
would transform once before the processes and<BR>>> once after) and incurr
much less penalty<BR>>><BR>>> But if they both exist, they will
treat them as being on equal footing<BR>>><BR>>> ST_Buffer(geometry)
and ST_Buffer(geography)<BR>>><BR>>><BR>>> So your
approach while well-meaning gives a questionable benefit to novices<BR>>>
and is putting experienced users at a disadvantage.<BR>>><BR>>>
Thanks,<BR>>> Regina<BR>>><BR>>> -----Original
Message-----<BR>>> From:
postgis-devel-bounces@postgis.refractions.net<BR>>>
[mailto:postgis-devel-bounces@postgis.refractions.net] On Behalf Of
Paragon<BR>>> Corporation<BR>>> Sent: Friday, October 30, 2009 11:54
PM<BR>>> To: 'PostGIS Development Discussion'<BR>>> Cc: 'PostGIS
Users Discussion'<BR>>> Subject: Re: [postgis-devel] Geog/Geom
Hack<BR>>><BR>>> Paul,<BR>>> I suppose we can't just put this
decision off till 2.0. Isn't this a bit of<BR>>> scope creep?
I'm not absolutely sure which way is better, but I know the<BR>>>
cost of rolling back the change is more.<BR>>><BR>>> If you are
going to do this, how many functions are you planning to do this<BR>>>
for?<BR>>><BR>>> I'm cc'ing the postgis users group too to get more
of an opinion on this<BR>>> topic.<BR>>><BR>>> So the question
is it it a good idea to introduce a hack that transforms a<BR>>> geography
into what we call BestSRID to perform geometry operations on and<BR>>>
then transform back. My concern is that this is a silent operation
that<BR>>> gives the impression that these functions are natively done in
spheroid<BR>>> space just for the benefit of catering to less
technical users.<BR>>><BR>>>
http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.c#L541<BR>>><BR>>>
So you can't really tell by looking the penalty<BR>>><BR>>> Main
examples of this as shown for ST_Buffer<BR>>><BR>>> CREATE OR
REPLACE FUNCTION _ST_BestSRID(geography, geography)<BR>>> 530
RETURNS integer<BR>>> 531
AS 'MODULE_PATHNAME','geography_bestsrid'<BR>>> 532
LANGUAGE 'C' IMMUTABLE STRICT;<BR>>> 533<BR>>> 534 --
Availability: 1.5.0<BR>>> 535 CREATE OR REPLACE FUNCTION
_ST_BestSRID(geography)<BR>>> 536 RETURNS
integer<BR>>> 537 AS 'SELECT
_ST_BestSRID($1,$1)'<BR>>> 538 LANGUAGE 'SQL'
IMMUTABLE STRICT;<BR>>> 539<BR>>> 540 -- Availability:
1.5.0<BR>>> 541 CREATE OR REPLACE FUNCTION ST_Buffer(geography,
float8)<BR>>> 542 RETURNS
geography<BR>>> 543 AS 'SELECT<BR>>>
geography(ST_Transform(ST_Buffer(ST_Transform(geometry($1),<BR>>>
_ST_BestSRID($1)), $2), 4326))'<BR>>> 544
LANGUAGE 'SQL' IMMUTABLE STRICT;<BR>>>
545<BR>>><BR>>><BR>>><BR>>> Thanks,<BR>>>
Regina<BR>>><BR>>> -----Original Message-----<BR>>> From:
postgis-devel-bounces@postgis.refractions.net<BR>>>
[mailto:postgis-devel-bounces@postgis.refractions.net] On Behalf Of
Paul<BR>>> Ramsey<BR>>> Sent: Friday, October 30, 2009 11:07
PM<BR>>> To: PostGIS Development Discussion<BR>>> Subject: Re:
[postgis-devel] Geog/Geom Hack<BR>>><BR>>> We're going to have to
agree to disagree on this one, Regina. Catering to<BR>>> the less
technical users is what this exercise is all about, to my mind, and<BR>>>
that includes allowing easy flipping into geometry for calculations
that<BR>>> aren't supported in geography yet. Oracle does this
too.<BR>>><BR>>> What do other folks think?<BR>>><BR>>>
P.<BR>>><BR>>> On Fri, Oct 30, 2009 at 7:06 PM, Paragon Corporation
<LR@PCORP.US></LR@PCORP.US>wrote:<BR>>>> Paul,<BR>>>> Hmm when
I am comparing distance of two geometries in different<BR>>>> spatial
refs which I do a lot.<BR>>>><BR>>>> I still don't like the
hack even if you disregard the above or if you<BR>>>> must hack --
don't give it the same name as the non-hacked
functions.<BR>>>><BR>>>> the whole idea of picking BestSRID
for a person to cater to less<BR>>>> technical users I find extremely
annoying as I can think of 20<BR>>>> "BestSRID" depending on what I am
doing. If they get to that level of<BR>>>> sophistication, I
would rather have them think a little more and<BR>>>> understand
the implications of those decisions.<BR>>>><BR>>>> We must
learn to crawl before we can learn to walk,because walking<BR>>>>
without understanding will just get you into trouble in the long
run.<BR>>>><BR>>>><BR>>>>
Thanks,<BR>>>> Regina<BR>>>><BR>>>>
-----Original Message-----<BR>>>> From:
postgis-devel-bounces@postgis.refractions.net<BR>>>>
[mailto:postgis-devel-bounces@postgis.refractions.net] On Behalf
Of<BR>>>> Paul Ramsey<BR>>>> Sent: Friday, October 30, 2009
9:47 PM<BR>>>> To: PostGIS Development Discussion<BR>>>>
Subject: Re: [postgis-devel] Geog/Geom Hack<BR>>>><BR>>>> You
*can*, but I strongly doubt you *will*. Because there's nothing
in<BR>>>> geography that isn't already in geometry. So you as a primary
geometry<BR>>>> user are going to have no working need to cast things
to geography.<BR>>>><BR>>>> On the other hand, the very first
question from users of geography<BR>>>> will be "how can I access
<GEOMETRY function N></GEOMETRY>?" So having a<BR>>>> relatively full
set of functions already available in geography makes<BR>>>> sense to
me, even if they are hacked in with a planar
trick.<BR>>>><BR>>>> P.<BR>>>><BR>>>> On
Fri, Oct 30, 2009 at 5:46 PM, Paragon Corporation
<LR@PCORP.US></LR@PCORP.US>wrote:<BR>>>>> Paul,<BR>>>>>
I can put a functional geography index on can't I and take
advantage<BR>>>>> of geography index
bindings?<BR>>>>><BR>>>>> Lets say I have a large
network of tables broken out by region so I<BR>>>>> know a specific
table has one srid.<BR>>>>><BR>>>>> For many queries, I
may go to that table directly or if I'm doing<BR>>>>> single
geometry processing, really don't care what srid as long as<BR>>>>>
its in utm or whatever - so I can use the full power of
GEOS.<BR>>>>><BR>>>>> For my across the board distance
checks and so forth, I would want to<BR>>>>> use geography and I
could use a geography index if I put a functional<BR>>>>> geography
index on my geometry correct? Though that needs some more<BR>>>>
testing.<BR>>>>><BR>>>>><BR>>>>> So in short
if 90% of my workload involves geometry processing, I<BR>>>>> will
want to keep my data in geometry<BR>>>>><BR>>>>> But the
10% I would want to convert to geography on the
fly.<BR>>>>><BR>>>>> Thanks,<BR>>>>>
Regina<BR>>>>><BR>>>>> -----Original
Message-----<BR>>>>> From:
postgis-devel-bounces@postgis.refractions.net<BR>>>>>
[mailto:postgis-devel-bounces@postgis.refractions.net] On Behalf
Of<BR>>>>> Paul Ramsey<BR>>>>> Sent: Friday, October 30,
2009 8:34 PM<BR>>>>> To: PostGIS Development
Discussion<BR>>>>> Subject: Re: [postgis-devel] Geog/Geom
Hack<BR>>>>><BR>>>>> I'm not sure I understand why you
would ever convert a geometry to a<BR>>>>> geography as part of a
query on a geometry table. I fully expect<BR>>>>> geography to be
used as a storage type, because of the utility of<BR>>>>> having the
correct spherical indexes, which are not available when<BR>>>>>
you're just converting in via a cast. Since there's no
functions<BR>>>>> available on geography that are not already
available on geometry,<BR>>>>> why would you ever do a
geometry->geography cast unless you are (a)<BR>>>>> testing
geography or (b) bulk converting a table into geography for<BR>>>>
storage in that type.<BR>>>>><BR>>>>>
P.<BR>>>>><BR>>>>><BR>>>>><BR>>>>>
On Fri, Oct 30, 2009 at 5:24 PM, Paragon Corporation
<LR@PCORP.US></LR@PCORP.US>wrote:<BR>>>>>>
Paul,<BR>>>>>> I would rather you didn't for 2
reasons<BR>>>>>><BR>>>>>> 1) I'm lazy and for each
of these things we'd have to apply the text<BR>>>>>> additional
function proto hack to prevent from it breaking
geometry.<BR>>>>>> which we will probably end up taking out
anyway.<BR>>>>>><BR>>>>>> 2) I don't like the
hiddenness of it since it becomes especially<BR>>>>>> annoying if
you have your native in geometry and you are converting<BR>>>>>>
to geography for a special usecase, then you end up with a
slower<BR>>>>>>
implementation<BR>>>>>><BR>>>>>> as you would
really end up doing accidentally<BR>>>>>><BR>>>>>>
geometry -> geography -> geometry ->operation (and why do I want
my<BR>>>>>> calcs done in
UTM?)<BR>>>>>><BR>>>>>> Instead of the more
efficient<BR>>>>>><BR>>>>>> geometry ->
operation<BR>>>>>><BR>>>>>>
Thanks,<BR>>>>>>
Regina<BR>>>>>><BR>>>>>> -----Original
Message-----<BR>>>>>> From:
postgis-devel-bounces@postgis.refractions.net<BR>>>>>>
[mailto:postgis-devel-bounces@postgis.refractions.net] On Behalf
Of<BR>>>>>> Paul Ramsey<BR>>>>>> Sent: Friday,
October 30, 2009 8:16 PM<BR>>>>>> To: PostGIS Development
Discussion<BR>>>>>> Subject: [postgis-devel] Geog/Geom
Hack<BR>>>>>><BR>>>>>> I'm interested to know what
the general opinion is of the trick I've<BR>>>>>> used
on<BR>>>>>>
ST_Buffer(geography):<BR>>>>>><BR>>>>>>
http://trac.osgeo.org/postgis/browser/trunk/postgis/geography.sql.in.<BR>>>>>>
c<BR>>>>>> #L541<BR>>>>>><BR>>>>>>
I ask because I could apply the same idea to the larger suite of
OGC<BR>>>>>> SFSQL predicates before release. Is half-a-loaf
better than no loaf<BR>>>>>> in<BR>>>>> this
case?<BR>>>>>> (Note that there will be failure cases for really
large geometry,<BR>>>>>> like a polygon of "Asia" or "Russia"
that have polygons over the<BR>>>>>>
dateline.)<BR>>>>>><BR>>>>>>
P.<BR>>>>>>
_______________________________________________<BR>>>>>>
postgis-devel mailing list<BR>>>>>>
postgis-devel@postgis.refractions.net<BR>>>>>>
http://postgis.refractions.net/mailman/listinfo/postgis-devel<BR>>>>>><BR>>>>>><BR>>>>>><BR>>>>>>
_______________________________________________<BR>>>>>>
postgis-devel mailing list<BR>>>>>>
postgis-devel@postgis.refractions.net<BR>>>>>>
http://postgis.refractions.net/mailman/listinfo/postgis-devel<BR>>>>>><BR>>>>>
_______________________________________________<BR>>>>>
postgis-devel mailing list<BR>>>>>
postgis-devel@postgis.refractions.net<BR>>>>>
http://postgis.refractions.net/mailman/listinfo/postgis-devel<BR>>>>><BR>>>>><BR>>>>><BR>>>>>
_______________________________________________<BR>>>>>
postgis-devel mailing list<BR>>>>>
postgis-devel@postgis.refractions.net<BR>>>>>
http://postgis.refractions.net/mailman/listinfo/postgis-devel<BR>>>>><BR>>>>
_______________________________________________<BR>>>> postgis-devel
mailing list<BR>>>>
postgis-devel@postgis.refractions.net<BR>>>>
http://postgis.refractions.net/mailman/listinfo/postgis-devel<BR>>>><BR>>>><BR>>>>
_______________________________________________<BR>>>> postgis-devel
mailing list<BR>>>>
postgis-devel@postgis.refractions.net<BR>>>>
http://postgis.refractions.net/mailman/listinfo/postgis-devel<BR>>>><BR>>>
_______________________________________________<BR>>> postgis-devel
mailing list<BR>>> postgis-devel@postgis.refractions.net<BR>>>
http://postgis.refractions.net/mailman/listinfo/postgis-devel<BR>>><BR>>><BR>>>
_______________________________________________<BR>>> postgis-devel
mailing list<BR>>> postgis-devel@postgis.refractions.net<BR>>>
http://postgis.refractions.net/mailman/listinfo/postgis-devel<BR>>><BR>>><BR>>>
_______________________________________________<BR>>> postgis-devel
mailing list<BR>>> postgis-devel@postgis.refractions.net<BR>>>
http://postgis.refractions.net/mailman/listinfo/postgis-devel<BR>>><BR>>_______________________________________________<BR>>postgis-devel
mailing
list<BR>>postgis-devel@postgis.refractions.net<BR>>http://postgis.refractions.net/mailman/listinfo/postgis-devel<BR>><BR>></DIV></BODY></HTML>