Subject: Marine Geospatial Ecology Tools (MGET) help
Text archives
From: | "Jason Roberts" <> |
---|---|
To: | "'Karl Zinglersen'" <> |
Cc: | <> |
Subject: | RE: [mget-help] MGET and GDAL and/or QGIS |
Date: | Wed, 25 Sep 2013 16:35:52 -0400 |
Karl,
Thanks for your interest in MGET. I understand and support your desire to
promote FOSS solutions to GIS problems.
The short answers to your questions are:
1. There is not a proper command line interface in current versions. But
MGET is a Python package and it is possible to utilize it from Python
scripts. The ArcGIS dependencies within it are compartmentalized such that
you do not need ArcGIS to be installed on your machine in order to install
MGET, and many MGET functions will work without ArcGIS. When ArcGIS is
needed, MGET will look for it and fail if it is not installed. We caution,
however, that we cannot offer a formal or stable API at this time, with a
guarantee that functions won't change in the future. Still, if you have
specific scenarios or tools you wish to access, I can advise you on a
script-based solution.
2. Yes, when we are able to obtain sufficient funding, we plan to expand
support from just ArcGIS as a GUI front end, to ArcGIS and QGIS. We are
specifically targeting QGIS as our second GUI platform due to it being FOSS
and also because its plugin framework is based on Python, making an MGET
QGIS plugin relatively easy (compared to GIS systems that do not use
Python).
The long answer is:
In the beginning, around 2007, MGET was pretty strongly tied to ArcGIS.
Since that time, as our experience with FOSS GIS libraries and applications
expanded, and as those libs and apps got better, we have trimmed MGET's
dependency on ArcGIS. Our goal is to eventually break our dependency on it
completely, and to allow MGET to be utilized from several GIS packages,
including ArcGIS. Our goal is to be flexible and responsive to the user
community. We perceive that adoption of FOSS GIS is increasing, and we want
to respond appropriately. This may be most important in locations of the
world where commercial solutions like ArcGIS may just be too expensive, yet
there are pressing needs to improve management and conservation of marine
resources.
In 2011, we took a significant step forward by reworking our internal vector
and raster access layers to be pluggable, and introducing GDAL as a primary
means for accessing vector and raster data. MGET includes a copy of GDAL
internally and uses it to read and write rasters, even when it is invoked
from ArcGIS, unless GDAL cannot read the format, in which case ArcGIS is
used.
This presentation talks some about that work:
http://code.env.duke.edu/projects/mget/export/1111/WikiFiles/Presentations/N
CGIS_2011_Jason_Roberts.pptx
One of the critical issues I did not discuss much in that presentation is
the difficulty finding suitable Python-oriented replacements to the many
geoprocessing tools provided by ArcGIS. Those tools represent a core value
of ArcGIS that is not fully duplicated elsewhere except perhaps by GRASS
(which is not easy to integrate with Python) and various commercial
packages. That was a problem in 2011 and still is a problem today. I started
a lengthy discussion of this on gdal-dev in 2010:
http://lists.osgeo.org/pipermail/gdal-dev/2010-January/023089.html
There has been some community progress since that time. For example, the
GDAL Python API now has layer operations
(http://trac.osgeo.org/gdal/wiki/rfc39_ogr_layer_algebra) and there are
various other libs out there to do this kind of thing (e.g.
https://pypi.python.org/pypi/Shapely).
Unfortunately, to date, we have not secured funding to continue to evolve
this aspect of MGET and fully break all dependencies on ArcGIS. If that
funding can be found, I hope to simultaneously relaunch MGET as a fully
community-based project, as a proper response to the number of people who
have inquired about contributing to MGET. I would also like to consider
expanding it to be a more general toolbox that is not branded as "marine".
There are many terrestrial applications and users. (For example, I recently
saw a poster of someone who used the predictive modeling tools to predict
locations of prehistoric human settlements in Europe, or something like
that.) And include a formal API.
But I digress and will leave off there, for now...
Best regards,
Jason
-----Original Message-----
From: Karl Zinglersen
[mailto:]
Sent: Tuesday, September 24, 2013 7:24 PM
To:
Subject: [mget-help] MGET and GDAL and/or QGIS
Hi,
I'll be installing the tool for ArcGIS to support my researchers at
Greenland Institute of Natural Resources and our partners abroad.
However, for many reasons, I am establishing a larger awareness of QGIS and
R over ArcGIS and SAS - also due to budget cuts. We are only few having an
ArcGIS license.
Would it be possible to run the tools outside ArcGIS in the command prompt
like gdal?
Are you considering a QGIS plugin?
Best regards,
Karl Zinglersen
Thanks for your interest in MGET. I understand and support your desire to
promote FOSS solutions to GIS problems.
The short answers to your questions are:
1. There is not a proper command line interface in current versions. But
MGET is a Python package and it is possible to utilize it from Python
scripts. The ArcGIS dependencies within it are compartmentalized such that
you do not need ArcGIS to be installed on your machine in order to install
MGET, and many MGET functions will work without ArcGIS. When ArcGIS is
needed, MGET will look for it and fail if it is not installed. We caution,
however, that we cannot offer a formal or stable API at this time, with a
guarantee that functions won't change in the future. Still, if you have
specific scenarios or tools you wish to access, I can advise you on a
script-based solution.
2. Yes, when we are able to obtain sufficient funding, we plan to expand
support from just ArcGIS as a GUI front end, to ArcGIS and QGIS. We are
specifically targeting QGIS as our second GUI platform due to it being FOSS
and also because its plugin framework is based on Python, making an MGET
QGIS plugin relatively easy (compared to GIS systems that do not use
Python).
The long answer is:
In the beginning, around 2007, MGET was pretty strongly tied to ArcGIS.
Since that time, as our experience with FOSS GIS libraries and applications
expanded, and as those libs and apps got better, we have trimmed MGET's
dependency on ArcGIS. Our goal is to eventually break our dependency on it
completely, and to allow MGET to be utilized from several GIS packages,
including ArcGIS. Our goal is to be flexible and responsive to the user
community. We perceive that adoption of FOSS GIS is increasing, and we want
to respond appropriately. This may be most important in locations of the
world where commercial solutions like ArcGIS may just be too expensive, yet
there are pressing needs to improve management and conservation of marine
resources.
In 2011, we took a significant step forward by reworking our internal vector
and raster access layers to be pluggable, and introducing GDAL as a primary
means for accessing vector and raster data. MGET includes a copy of GDAL
internally and uses it to read and write rasters, even when it is invoked
from ArcGIS, unless GDAL cannot read the format, in which case ArcGIS is
used.
This presentation talks some about that work:
http://code.env.duke.edu/projects/mget/export/1111/WikiFiles/Presentations/N
CGIS_2011_Jason_Roberts.pptx
One of the critical issues I did not discuss much in that presentation is
the difficulty finding suitable Python-oriented replacements to the many
geoprocessing tools provided by ArcGIS. Those tools represent a core value
of ArcGIS that is not fully duplicated elsewhere except perhaps by GRASS
(which is not easy to integrate with Python) and various commercial
packages. That was a problem in 2011 and still is a problem today. I started
a lengthy discussion of this on gdal-dev in 2010:
http://lists.osgeo.org/pipermail/gdal-dev/2010-January/023089.html
There has been some community progress since that time. For example, the
GDAL Python API now has layer operations
(http://trac.osgeo.org/gdal/wiki/rfc39_ogr_layer_algebra) and there are
various other libs out there to do this kind of thing (e.g.
https://pypi.python.org/pypi/Shapely).
Unfortunately, to date, we have not secured funding to continue to evolve
this aspect of MGET and fully break all dependencies on ArcGIS. If that
funding can be found, I hope to simultaneously relaunch MGET as a fully
community-based project, as a proper response to the number of people who
have inquired about contributing to MGET. I would also like to consider
expanding it to be a more general toolbox that is not branded as "marine".
There are many terrestrial applications and users. (For example, I recently
saw a poster of someone who used the predictive modeling tools to predict
locations of prehistoric human settlements in Europe, or something like
that.) And include a formal API.
But I digress and will leave off there, for now...
Best regards,
Jason
-----Original Message-----
From: Karl Zinglersen
[mailto:]
Sent: Tuesday, September 24, 2013 7:24 PM
To:
Subject: [mget-help] MGET and GDAL and/or QGIS
Hi,
I'll be installing the tool for ArcGIS to support my researchers at
Greenland Institute of Natural Resources and our partners abroad.
However, for many reasons, I am establishing a larger awareness of QGIS and
R over ArcGIS and SAS - also due to budget cuts. We are only few having an
ArcGIS license.
Would it be possible to run the tools outside ArcGIS in the command prompt
like gdal?
Are you considering a QGIS plugin?
Best regards,
Karl Zinglersen
Archives powered by MHonArc.