<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 11, 2015 at 3:20 AM, Moritz Lennert <span dir="ltr"><<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.worldonline.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Vaclav,<br>
<br>
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.<br>
<br></blockquote><div>Mailing list is the right place to discuss it but otherwise, feel free to edit the ideas.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I've looked at your proposal for GSoC and I think I understand the reasons for it. However, I do have a few remarks:<br>
<br>
- "The GRASS GIS Database, Location and Mapset should be created on the fly and deleted afterwards (the .grassrc wouldn't be used)."<br>
<br>
How is this different from what QGIS Processing already does now ?<br>
<br></blockquote><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- "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."<br>
<br>
Idem: if you create GISDBASE, etc on the fly, what is it you are proposing to change through this project ?<br></blockquote><div><br></div><div>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.<br><br></div><div>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.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
- "The input maps could be linked (external) rather than imported (except for the cases when projection differs) which should be faster than import."<br>
<br>
Please don't forget issues of topology that can arise when you use v.external. E.g. compare the result of<br>
<br>
v.overlay ain=boundary_municp atyp=area bin=zipcodes_wake btype=area op=and out=muni_and_zipcodes<br>
<br>
using both imported and externally linked maps...<br>
<br></blockquote><div>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.<br><br>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In general, IIUC, what you are looking for is actually a form of special script that:<br>
<br>
- creates a location based on the input data (question: how to handle input data that is not in the same projection ?)<br>
<br>
- links (or imports) the data into that location<br>
<br>
- executes the command and saves the output via r/v.external.out<br>
<br>
This seems like a very short project to put in place.<br>
<br></blockquote><div>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).<br><br>I don't see more issues now but I'm afraid there are some more (this is a call for ideas).<br><br></div><div>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?<br></div><div><br></div><div>Vaclav<br></div><div><br><a href="http://trac.osgeo.org/grass/ticket/2579">http://trac.osgeo.org/grass/ticket/2579</a><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Or is there something I'm missing ?<span class=""><font color="#888888"><br>
<br>
Moritz<br>
</font></span></blockquote></div><br></div></div>