[GRASS-dev] On GSoC Proposal "New easy-to-use command line interface for GRASS GIS"

[Vaclav Petras]

On Wed, Feb 11, 2015 at 3:20 AM, Moritz Lennert <
mlennert at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20150211/179e3726/attachment.html>