[ForestryTools] database/ early design

Lee muellerl at gmail.com
Sun Jun 2 19:14:39 PDT 2013


Right. I'm imagining early on we can just ensure that there's a plot ID #
that's the same in both a vector and in a table. We can join the table as
necessary to compute the data, but not store it. As a minimum level of
functionality, I think that will work. It's enough to get something out the
door.

>From there, we could work a little bit more on building some interest and
community and begin incorporating additional features that meet our
individual interest, as well as the needs of others we may get involved.


--
All the best,
Lee
ISA Certified Arborist MI-4148A
Registered Forester #46043


On Sun, Jun 2, 2013 at 8:32 PM, TYLER MITCHELL <tylermitchell at shaw.ca>wrote:

> Agreed here - I'm comfortable either way.  Deciding on the column schema
> is important regardless.  When we get beyond data architecture, then app
> developers can build on their favourite platform - but in the meantime we
> need to decide what to store etc...
>
> On 2013-06-02, at 1:47 PM, "Jake Maier" <j.m at jmforestry.com> wrote:
>
> Lee****
>
> I understood your point, and I agree with it. It is not only that we want
> to have something presentable soon (that’s one good point) but also that
> when we use a database design some not so computer savvy people may be
> throwing the towel. So starting with a simple table design (csv) would be
> easier for some. And as we get more experience and more complex in the
> design than we still can easily switch to a database design. I think it
> would also be good to maintain a version with just excel files, (xlsx) in
> addition to database files because many don’t have and don’t know database
> software.****
>
> J****
>
> ** **
>
> *From:* Lee [mailto:muellerl at gmail.com <muellerl at gmail.com>]
> *Sent:* Sunday, June 02, 2013 4:07 PM
> *To:* Jake Maier
> *Cc:* ForestryTools List
> *Subject:* Re: [ForestryTools] database/ early design****
>
> ** **
>
> To clarify, my thoughts are not targetted towards the long-term
> use/feasibility of using tables/csv verses database. In the long term,
> databases will be necessary to handle more complex data for a variety of
> users. That said, I do think it is important we get something usable going
> as soon as possible to attract further interest. In this sense, I wondered
> if we'd be able to short-cut around some of the database design for the
> time being by using simple joins between table data and spatial data.****
>
> In this case, I'm in no way an expert. It just might be worth discussion.*
> ***
>
>
> ****
>
>
> --
> All the best,
> Lee
> ISA Certified Arborist MI-4148A
> Registered Forester #46043****
>
> ** **
>
> On Fri, May 31, 2013 at 7:02 PM, Jake Maier <j.m at jmforestry.com> wrote:***
> *
>
> Hi Lee and Abdoul.****
>
> I think a simple table is easier if it’s a simple relationship between the
> spatial and the tabular data. If the relationships are complex and changes
> often depending on the particular situation, then a database is quicker and
> easier.****
>
> Thanks for your good work.****
>
> My 2 ct****
>
> Jake ****
>
>  ****
>
> *From:* forestrytools-bounces at lists.osgeo.org [mailto:
> forestrytools-bounces at lists.osgeo.org] *On Behalf Of *Abdoul O. Dia
> *Sent:* Friday, May 31, 2013 3:03 PM
> *To:* forestrytools at lists.osgeo.org
> *Subject:* Re: [ForestryTools] database/ early design****
>
>  ****
>
> Hi Lee,
>
> This could be a way to start and test it. But we need to keep in mind that
> we'll need to handle external files (e.g. csv) and to manage spatial data
> (e.g.: vectors). The relationship between the external and spatial data
> should be kept some how so we can attribute to every single point or
> polygone in a shapefile its related data from the field. In this case I
> think using a database would be easier. What others think?
>
> Abdoul
>
>
> Le 2013-05-30 18:20, Lee a écrit :****
>
> To not flood the other string with a new topic, here's a new email:****
>
> I had a long drive the other day, which gave me a good chance to think
> things over regarding the database structure. Specifically, my current
> "narrative" I put on the forestry tools wiki calls for just loading
> external CSVs to do easy analysis, rather than porting into a database.***
> *
>
> How do you feel about establishing initial functionality with simple
> tables, opposed to database structure? Once we get an initial release out
> and develop some interest, we could add more complex database support.****
>
> I'm not sold either way, I just thought it might be worth discussion. I'm
> not sure what's simpler and more useful from a starting location.
>
> Thoughts?****
>
>
> --
> All the best,
> Lee
> ISA Certified Arborist MI-4148A
> Registered Forester #46043****
>
>
>
> ****
>
> _______________________________________________****
>
> Forestrytools mailing list****
>
> Forestrytools at lists.osgeo.org****
>
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/forestrytools****
>
>  ****
>
>
> _______________________________________________
> Forestrytools mailing list
> Forestrytools at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/forestrytools****
>
> ** **
>
> _______________________________________________
> Forestrytools mailing list
> Forestrytools at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/forestrytools
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/forestrytools/attachments/20130602/83335bdf/attachment.html>


More information about the Forestrytools mailing list