Re: [GRASS-dev] [GRASS-SVN] r72686 - grass/trunk/raster/r.mode/testsuite

[Luca Delucchi]

On 5 May 2018 at 05:57, Anna Petrášová  wrote:
> Hi,
>

Hi,

> I just wanted to point out, that some of the newly added tests were
> actually not testing anything (see below) or failing because of
> whitespace, please be more careful what you commit.
>

sorry, but I  usually test them, maybe I skip some.
However some tests are failing because in the basic_north_carolina
doesn't contain some useful maps like landsat for i.* commands.

what do you think to use the full North Casolina dataset as default
one? If there consensus I could try to fix the failing tests


> Thank you,
>
> Anna
>

-- 
ciao
Luca

www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC introduction Roberta Fagandini

[Veronica Andreo]

Hey Robi,

I just found this review [0]. It is for Landsat, but maybe some insights
could be also useful for you (?)

Cheers :),
Vero

[0]
https://www.researchgate.net/publication/324975294_Cloud_and_Cloud_Shadow_Detection_for_Landsat_Images_The_Fundamental_Basis_for_Analyzing_Landsat_Time_Series

El jue., 3 may. 2018 a las 22:06, Roberto Marzocchi (<
roberto.marzoc...@gmail.com>) escribió:

> Nice! The last step of the script you have written in python works as you
> expected.
>
> Now it is important to draw a diagram (or schema ) as a summary for you (you
> have worked a lot in the last few months) and to share it with Moritz and
> Markus.
>
> After that, test, test and test ;-) for validation/calibration of the
> automatic procedure.
>
> R
>
> 2018-05-03 18:48 GMT+02:00 Roberta Fagandini :
>
>>
>> 2018-05-03 14:03 GMT+02:00 Moritz Lennert :
>>
>>> Hi Roberta,
>>>
>>
>> Hi Moritz and Roberto!
>>
>>
>>>
>>> On 25/04/18 18:03, Roberta Fagandini wrote:
>>>


 2018-04-25 16:03 GMT+02:00 Moritz Lennert >:
 Looking at your bash scripts, I think the first thing to do during
 this bonding period is, as you planned yourself, to get familiar
 with the writing of GRASS modules in Python. You can have a look at
 existing scripts [1, 2] to get feeling for this works and how to
 structure addon code in order to make it directly installable with
 g.extension.

 You can find the actual function definitions and documentation of
 the GRASS Python scripting library at [3]. The functions in that
 library should be more than enough to translate your scripts into a
 (or several) modules.

 Be aware that GRASS modules create their own GUI. So, unless you
 need some interactive features in your modules, you will not have to
 program your own GUI.


 Thank you for your precious suggestions! I'll start studying how to
 write a GRASS module in Python in the next days and at the same time I will
 keep on testing the procedures so as to show you some results and fix some
 open points.


 Something else you should probably do during this bonding time is to
 elaborate a schema of your algorithm, so that it is easier to
 understand what it does at each step.


 Yes, this could be very useful also for me in order to better organize
 and put in order everything!


>>> Have you advanced on any of this ? Do you have any questions ? Please
>>> don't hesitate to ask on the mailing list.
>>>
>>
>> Yes, I started working with GRASS Python scripting library. I'm following
>> the link [0] you suggested, I'm also looking at other existing GRASS
>> scripts [1,2] and moreover, Roberto gave me one of his scripts as an
>> example. I have just committed the first version of the python script I'm
>> working on, it works and I'm quite satisfied ;-)
>> Tomorrow I want to elaborate the schema of the algorithm and at the same
>> time, I have to keep testing the procedure. As I wrote in the bash file,
>> shadows detection seems to be strongly land cover dependent therefore I
>> think it is necessary to test the procedure using several images sensed in
>> different seasons, latitude, etc.
>>
>> Anyway, I'll commit some results tomorrow so as to show you something
>> more concrete!
>>
>>>
>>> Best wishes,
>>> Moritz
>>>
>>
>> Best regards,
>> Roberta
>>
>> [0] https://grass.osgeo.org/grass75/manuals/libpython/script_intro.html
>> [1] https://trac.osgeo.org/grass/browser/grass/trunk/scripts
>> [2] https://trac.osgeo.org/grass/browser/grass-addons/grass7
>>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Different CRS matching in 7.2 and trunk

[Markus Metz]

On Sun, Nov 19, 2017 at 10:33 PM, Markus Metz 
wrote:
>
>
>
> On Sun, Nov 12, 2017 at 12:21 AM, Markus Metz <
markus.metz.gisw...@gmail.com> wrote:
> >
> >
> >
> > On Sat, Nov 11, 2017 at 8:05 PM, Helena Mitasova 
wrote:
> > >
> > >
> > > On Nov 10, 2017, at 7:20 PM, Markus Metz <
markus.metz.gisw...@gmail.com> wrote:
> > >
> > >
> > >
> > > On Sat, Nov 11, 2017 at 12:22 AM, Helena Mitasova 
wrote:
> > > >
> > > > Please note, that  in spite of the fact that the datum.table shows
same transformation parameters,
> > > > different nad83 datums are different (it is not just a different
name for the same datum) and there are different EPSG codes associated
> > > > with the relevant CRS.
> > > > You can find more about it here (or just google it)
> > > > https://confluence.qps.nl/pages/viewpage.action?pageId=29855153
> > > >
> > > > Supposedly, the shift from NAD83(86) to NAD83(HARN) can be done
with the NGS NADCON program (I have not checked it out)
> > > > (http://www.ngs.noaa.gov/TOOLS/Nadcon/Nadcon.shtml).
> > >
> > > There are 12 (!) different definitions for NAD83. What to do about
this? Regard these 12 definitions as different datums? In this case I would
need to reinstate the datum check and we need to add more entries to
datum.table.
> > >
> > >
> > > Markus, we absolutely need to have a datum check
> >
> > This datum check has been first added in Oct 2003 and has been quickly
removed again in Jan 2004. As long as we do not have proj-style definitions
reflecting the differences in the various nad83 datums, it does not make
sense to differentiate between say nad83 and nad83harn.
>
> Apparently there is a way to construct different proj-style definitions
for different nad83 datums:
>
> - proj provides the hdatum grids nad83_2002.ct2 and nad83_2010.ct2
> - for nad83harn (High Accuracy Reference Networks), see
http://proj4.org/grids.html#harn on instructions to get an appropriate
nadgrid
> - for fine grade conversions between various NAD83 epochs and WGS84, see
http://proj4.org/htpd.html#htpd
>
> This looks like users might need to modify proj-style definitions
manually, after the appropriate grids have been manually obtained/created.

With PROJ 5, you can now define custom projection pipelines [0] in r.proj
(trunk r72598) and v.proj (trunk r72599). I hope this solves issues with
different NAD83 datum definitions.

Markus M

[0] https://proj4.org/usage/transformation.html#transformation

>
> Markus M
>
> >
> > > - although the differences between different NAD83 datums are less
than a meter, differences between NAD27 and NAD83 are over hundred meters
in some areas. Anything that has a different EPSG should be treated as
different CRS exactly for the reasons you mentioned in your answer to Vasek.
> >
> > GRASS does not use EPSG to construct proj-style definitions.
> >
> > Markus M
> >
> > >
> > > Helena
> > >
> > >
> > > Markus M
> > >
> > > >
> > > > Helena
> > > >
> > > > On Nov 10, 2017, at 5:30 PM, Markus Metz <
markus.metz.gisw...@gmail.com> wrote:
> > > >
> > > >
> > > >
> > > > On Fri, Nov 10, 2017 at 8:46 PM, Vaclav Petras 
wrote:
> > > > >
> > > > > On Fri, Nov 10, 2017 at 2:21 PM, Markus Metz <
markus.metz.gisw...@gmail.com> wrote:
> > > > > >
> > > > > > > >
> > > > > > > > 7.2 considers this OK while trunk considers this different.
I'm not sure which one is correct.
> > > > > > >
> > > > > > > In this case, 7.2 is correct, but 7.2 does not compare
datums, i.e. projections would be regarded as matching even with e.g. nad27
and nad83.
> > > > > > > The comparison of datums is new in 7.3 and needs some
refinement.
> > > > > > >
> > > > > > > I will fix the comparison of swapped lat_1 and lat_2.
> > > > > >
> > > > > > Fixed in trunk r71656.
> > > > > >
> > > > > > The test for different datum names has been disabled again in
trunk r71657. There are several different datum names in
lib/gis/datum.table that apparently mean the same: same ellipsoid and same
transformation parameters. Apparently, GRASS does not provide a datum name
when converting projection information from GRASS to proj4 for reprojecting
data.
> > > > >
> > > > >
> > > > > Thank you so much, Markus. This saves me a lot of trouble.
> > > >
> > > > About avoiding trouble, the motivation of the stricter CRS
comparison is to avoid subsequent geolocation errors. If data have been
imported and differences in the CRS were not detected, it can become very
difficult later on in the processing to figure out the reason for
geolocation errors (different data not matching each other spatially). I'm
not sure what to do about different datum names. The current check relies
on the test for differences in ellipsoids.
> > > >
> > > > Markus M
> > > >
> > > > >
> > > > > (I'm working on a Jupyter Notebook where I need trunk.)
> > > > >
https://github.com/wenzeslaus/Notebook-for-processing-point-clouds-in-GRASS-GIS
> > > > >
> > > > > >
> > > > > >
> > > > > >