[mapguide-internals] RE: GDAL stability in MGOS 2.1

[Jason Birch]

AFAIK, the PSC does not have funds at its discretion suitable for addressing
this issue at the level that you're suggesting.

As long as this is the case, I believe that this should be addressed as an
unaligned initiative (a bunch of users pay someone to have this fixed), or
as a targeted initiative (a bunch of users indicate that they have funds to
address this, donate tagged funds to the project, the project manages).  The
benefits of the former are that all funds go directly to the work and that
the PSC does not have to be involved in soliciting bids from qualified
developers, etc.

In either case, this needs to be a user-funded effort (unless we have
had significant donations I'm unaware of), so perhaps this discussion is
better off remaining on the -users list until a source of funds is
identified.

Jason

2009/12/29 Trevor Wekel

> Hi everyone,
>
> I am forwarding this email chain to the -internals list for further
> discussion.  It seems as though we still have stability problems with some
> raster file formats under MapGuide/GDAL.  Haris has indicated that he feels
> that is more probably an MG problem than a GDAL problem.  I agree with him
> in that any analysis we perform must include both the server and the
> provider.  As far as I know, other Fdo providers do not exhibit instability
> so the combination of the server and GDAL is problematic.
>
> So where do we go from here?  Based on my experience with MapGuide and
> raster in general, this could be a lengthy and multi-faceted problem to
> solve.  I expect that will find more than one issue to resolve when a deeper
> analysis is undertaken.
>
> I also believe we should fix the core problems instead of simply
> band-aiding them.  In other words, putting a big fat mutex over all raster
> processing would likely fix the issues our user base is seeing but it will
> also throw any kind of scalability out the window.  Getting MapGuide/GDAL
> thread safe with appropriately scalable mutexing will be more difficult and
> take longer.
>
> Once we come to agreement on what we are trying to achieve, we should then
> figure out who should do the work and how we go about funding it.  Based on
> past experience, this project could take a while.
>
> I believe Haris and I are both qualified to do this work.
>
> For myself, I do have enough hardware, software, and data "in-house" to
> accomplish this task - at least for TIFF, ECW and SID.  I also have some
> unallocated time available to work on this.  If the code changes become very
> involved, collaboration with people at Autodesk may be easier for me.  I can
> commute to the Calgary office and maybe someone will be nice enough to let
> me in.
>
> If I am given the nod to perform this work, I would start with an initial 1
> week time block.  One week should be enough to set up an appropriate test
> environment, reproduce the problem(s), and begin the analysis.  For longer
> term projects like this, my weekly rate is $3800 CAD including GST.
>
> Thanks,
> Trevor
>
>