[Qgis-developer] Ogr database access design and plans
frdcn at hotmail.com
Fri Dec 7 12:11:01 EST 2007
Thank you for checking the design. I also want to reuse the classes
for some plugins like SPIT and placing them in app will make difficult
to reuse them, but at this first stage I think the classes could change a
lot so is a good idea to keep them in app until they are more mature.
> Date: Fri, 7 Dec 2007 11:50:19 -0200
> From: tim at linfiniti.com
> To: wonder.sk at gmail.com
> Subject: Re: [Qgis-developer] Ogr database access design and plans
> CC: frdcn at hotmail.com; qgis-developer at lists.qgis.org
> Hi Godofredo
> I also had a look through your design documents during the week and
> generally liked the proposal. I think Martin makes some good points
> below. My only concern of putting it in 'app' is that this
> functionality wont be available to 3rd party apps using QGIS libs -
> which would be a pity because I suspect in many cases it would be very
> 2007/12/7, Martin Dobias <wonder.sk at gmail.com>:
> > Hi,
> > first of all sorry for my late reply.
> > I've been thinking quite a lot about the current design and future of
> > vector providers, database connections etc. The things as you've
> > designed them can be used well with the current status of QGIS - in
> > case you will put the new classes to 'app' sources and not to the
> > libraries.
> > My vision is that after 1.0 we should improve our architecture for
> > providers - and make it more similar to the one used in OGR.
> > - OGR uses 'data source' for a compound of layers, this can be e.g. a
> > database or a directory in file system. With data sources you open or
> > create layers
> > - QGIS uses 'providers' for accessing directly layers, but there's no
> > abstraction on the level of data sources as in OGR. With addition of
> > data sources (which are currently equivalent to database connections
> > in your design) we will add much more functionality which is not
> > supported currently by QGIS like some generic way to
> > list/create/remove/rename etc. layers). This is I guess important part
> > for our future common Load layer / data manager dialog.
> > The future redesign is the reason why I think that the new classes
> > you're working on should not go to core library. Once your new
> > features land to trunk, we will be able to reuse the code when
> > introducing 'data sources' term to QGIS slang. So go ahead with the
> > coding, we're all looking forward to see the new features in action
> > :-)
> > Regards
> > Martin
> > On Nov 30, 2007 9:16 PM, godofredo contreras <frdcn at hotmail.com> wrote:
> > >
> > > Hi Martin:
> > >
> > > I have being working with the ogr database access document and modelling
> > > the classes and interaction needed to enable ogr database access in qgis.
> > > Attached are a doc document describing the changes planned, the classes
> > > and dialogs that will be affected and a jpeg image of the model with your
> > > suggestions
> > > applied. Could you please give me your comments and suggestions.
> > >
> > > Regards
> > >
> > > Godofredo Contreras
> > >
> > > ________________________________
> > > Get the power of Windows + Web with the new Windows Live. Power up!
> > _______________________________________________
> > Qgis-developer mailing list
> > Qgis-developer at lists.qgis.org
> > http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
> Tim Sutton
> QGIS Project Steering Committee Member - Release Manager
> Visit http://qgis.org for a great open source GIS
> openModeller Desktop Developer
> Visit http://openModeller.sf.net for a great open source ecological
> niche modelling tool
> Home Page: http://tim.linfiniti.com
> Skype: timlinux
> Irc: timlinux on #qgis at freenode.net
You keep typing, we keep giving. Download Messenger and join the i’m Initiative now.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Qgis-developer