On Wed, Feb 11, 2015 at 3:20 AM, Moritz Lennert <
mlennert@club.worldonline.be> wrote:
Vaclav,
I don't want to mess with the wiki page, so I'm sending my remarks here.
If you (and others) think that this kind of discussion should go directly
onto the page then I can do that.
Mailing list is the right place to discuss it but otherwise, feel free to
edit the ideas.
I've looked at your proposal for GSoC and I think I understand the reasons
for it. However, I do have a few remarks:
- "The GRASS GIS Database, Location and Mapset should be created on the
fly and deleted afterwards (the .grassrc wouldn't be used)."
How is this different from what QGIS Processing already does now ?
It is not. The difference is that GRASS GIS part of QGIS Processing would
not have to deal with it because GRASS GIS itself would solve it. However,
the main point is that this does not apply only to QGIS Processing.
- "There are different workarounds for calling GRASS modules without
starting GRASS explicitly, or running GRASS in a batch mode. However, none
of these allows one to skip the database setup phase. This leads to the
need for constant reimplementing of setup, import and export steps in
various environments including user scripts (Bash, Python, R), QGIS
Processing, gvSIG/SEXTANTE, uDig/JGrassTools and all the web/server/cloud
tools which use GRASS GIS as a processing backend."
Idem: if you create GISDBASE, etc on the fly, what is it you are proposing
to change through this project ?
It will work the same. The change is in API approach and place where the on
the fly creation, import and export is done. I propose that it should be
done in GRASS GIS in a best way possible, once and for all, i.e. all the
other projects and users who wants to use "GRASS without starting it
explicitly" will be provided with API which solves this for them.
What I'm afraid of is if this is convenient enough and if it will actually
work for all, e.g. because of performance issues, interface complexity
(getting files from it) and complicated data sources such as PostGIS.
- "The input maps could be linked (external) rather than imported (except
for the cases when projection differs) which should be faster than import."
Please don't forget issues of topology that can arise when you use
v.external. E.g. compare the result of
v.overlay ain=boundary_municp atyp=area bin=zipcodes_wake btype=area
op=and out=muni_and_zipcodes
using both imported and externally linked maps...
Yes, I forgot to discuss sentence from #2579: "But obviously we could be
hitting issues with projection and topology here, so it is a bit tricky."
which is quite an issue.
When the external map is raster, it is not an issue, when it is a PostGIS
vector, it can be linked with topology (it it exists). Shapefile should be
imported and perhaps cleaned (expensive) but output might be just linked.
These are the complexities which should be solved inside GRASS GIS, so that
caller does not have to know all the GRASS tricks.
In general, IIUC, what you are looking for is actually a form of special
script that:
- creates a location based on the input data (question: how to handle
input data that is not in the same projection ?)
- links (or imports) the data into that location
- executes the command and saves the output via r/v.external.out
This seems like a very short project to put in place.
That's basically it and was also afraid of this being too simple. However,
I asked myself, if it is so simple, why we don't have it already? So,
probably there is a lot of issues of different formats (ranging from
potentially large but simple GeoTIFF, through messy Shapefile, to complex
PostGIS with topology), special (relatively unique) GRASS data types
(spatio-temporal data), projections (no projections, different projections
for different files, broken projections) and determining what should be
imported and exported (without the need to specify file - grass map pairs
manually, this might be really challenging for r.mapcalc).
I don't see more issues now but I'm afraid there are some more (this is a
call for ideas).
I think that the interface implemented in patch for #2579 is great
improvement in convenience and I'm going to commit it but it does not
address the import/export part (and reimplementing this over and over
again). Does this seems reasonable to you?
Vaclav
http://trac.osgeo.org/grass/ticket/2579
Or is there something I'm missing ?
Moritz