Native vs OGR db drivers (Re: A MapServer 5.0 Branch?) (Re: RFC 17: Dynamic Arr

[Steve Lime]

I wonder if one could render, query, etc... directly off the OGR internal structures thus saving
a translation to a shapeObj. Man, that would be disruptive (and a lot of work) but could move 
a ton of code out to OGR and perhaps help with performance.

Had OGR been around when MapServer was initially written that might have been the case. There's
a reason shapeObj's look similar to the structs originally found in shapelib.

Steve

>>> Steve Lime <Steve.Lime at DNR.STATE.MN.US> 5/17/2006 11:55:19 AM >>>
In my opinion it all comes down to performance. If maintaining native 
drivers provides a significant boost in speed then it seems to me to be
worth the effort since speed is one of MapServer's calling cards.

Has the overhead of OGR been quantified relative to something like
native access in MapServer?

Steve

>>> Howard Butler <hobu at IASTATE.EDU> 5/16/2006 2:51 PM >>>
At 02:15 PM 5/16/2006, Attila wrote:
>On Monday 15 May 2006 16:44, Sean Gillies wrote:
> > advantage of the opportunity to ditch some unsupported or outdated
> > aspects of MapServer: non-OGR mysql, image maps, flash, cartoline.
>
>Note that the functions from non-ogr mysql are used for the mysql joins, and
>from the feedback I'm getting, that is one of the major usages of this
>otherwise admittedly rarely used data source. I'm not sure, maybe this
>functionality is now available through different means, but keep this in
>mind, too.

I don't know off the top of my head for sure if OGR supports JOINs in 
a similar fashion as the MyGIS driver or Shapefiles.  I would agree 
that the spatial side of MySQL is probably covered pretty well by 
OGR, but not something like JOINs that cross LAYERs (you could write 
a pure MySQL sql statement that joined some tables together to get 
results with OGR's MySQL support or use some OVF).

A downside of MySQL with OGR on MapServer is taking on the overhead 
of OGR.  But again, "if you want performance -- use shapefiles" has 
seemed to be our mantra in that regard.

A somewhat related issue is whether we want start to move "native" 
drivers down to OGR, implement single-pass querying, and start to get 
MapServer out of the data reading business (keeping shapefiles, of 
course :).  As the SDE maintainer, there are some things that 
mapsde.c does right now that OGR doesn't (but could be made to).  I 
would rather bother with maintaining one set of code (and providing 
much leverage for lots of folks) than having two sets of SDE reading 
code with different feature sets etc.  Also, user confusion about 
using the OGR or native drivers (and it can make a big difference 
because of how things are implemented) seems to be an issue.  Native 
drivers aren't plugins at this time, and this means trouble for folks 
wishing to not compile their own (mostly SDE and Oracle in this 
regard).  And the purist in me feels that two different drivers is redundant.

All four of the native MapServer db drivers (Oracle, PostGIS, MyGIS, 
and SDE) have tweaks and features specific to MapServer.  It's 
possible that it isn't realistic to do this either.  What do people think?

>That MyGIS is fairly obsolete in itself and is in need of a rewrite 
>to use the
>spatial features (although OGR might be capable of doing what this would be
>good for) or a shrink from a complete backend to a join provider. I would
>really like to do the rewrite, my C at the time of writing the module was
>sloppy at best - I feel I have improved much since then, but unfortunately
>the time to do this properly this time around is what I don't have :(