[ForestryTools] database/ early design

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[ForestryTools] database/ early design

Lee-3
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
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/forestrytools
Reply | Threaded
Open this post in threaded view
|

Re: [ForestryTools] database/ early design

dia.abdoul
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
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/forestrytools


_______________________________________________
Forestrytools mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/forestrytools
j.m
Reply | Threaded
Open this post in threaded view
|

Re: [ForestryTools] database/ early design

j.m

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: [hidden email] [mailto:[hidden email]] On Behalf Of Abdoul O. Dia
Sent: Friday, May 31, 2013 3:03 PM
To: [hidden email]
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
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/forestrytools

 


_______________________________________________
Forestrytools mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/forestrytools
Reply | Threaded
Open this post in threaded view
|

Re: [ForestryTools] database/ early design

Lee-3
In reply to this post by dia.abdoul
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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Abdoul O. Dia
Sent: Friday, May 31, 2013 3:03 PM
To: [hidden email]
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
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/forestrytools

 


_______________________________________________
Forestrytools mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/forestrytools



_______________________________________________
Forestrytools mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/forestrytools
j.m
Reply | Threaded
Open this post in threaded view
|

Re: [ForestryTools] database/ early design

j.m

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:[hidden email]]
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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Abdoul O. Dia
Sent: Friday, May 31, 2013 3:03 PM
To: [hidden email]
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
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/forestrytools

 


_______________________________________________
Forestrytools mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/forestrytools

 


_______________________________________________
Forestrytools mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/forestrytools
Reply | Threaded
Open this post in threaded view
|

Re: [ForestryTools] database/ early design

Tyler Mitchell-5
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" <[hidden email]> 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 [[hidden email]]
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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Abdoul O. Dia
Sent: Friday, May 31, 2013 3:03 PM
To: [hidden email]
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
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/forestrytools

 


_______________________________________________
Forestrytools mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/forestrytools

 

_______________________________________________
Forestrytools mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/forestrytools

_______________________________________________
Forestrytools mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/forestrytools
Reply | Threaded
Open this post in threaded view
|

Re: [ForestryTools] database/ early design

Lee-3
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 <[hidden email]> 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" <[hidden email]> 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 [[hidden email]]

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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Abdoul O. Dia
Sent: Friday, May 31, 2013 3:03 PM
To: [hidden email]
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
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/forestrytools

 


_______________________________________________
Forestrytools mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/forestrytools

 

_______________________________________________
Forestrytools mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/forestrytools


_______________________________________________
Forestrytools mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/forestrytools