Re: [GRASS-user] question on i.nightlights.intercalibration code

[Nikos Alexandris]

* Gabriel Cotlier  [2018-06-21 18:24:38 -0300]:


Hello Veronica,

Thanks a lot it worked!!


Dear Gabriel,

Thanks for posting details and great it works. Don't worry about the
last image, there are no coefficients for F18 and 2013. We are forced
to skip this image in any analysis.


Details

Veronica is right, and I am ignorant for so many things when it comes to 
Windows.

In Linux, one may use the syntax `some_command` or
$(some_command). It's a smart way to feed-in longer list of items, such
as map names in GRASS GIS. Note, the former is old-style, so best to use the $()
notation (if of interest, see
https://unix.stackexchange.com/a/5782/13011).

You might want to re-check the extent you have set, so as to
get rid of the "360 degree EW extent is exceeded by 0.999827 cells"
messages (?). Depending on how you have set your region, maybe the `-a`
option for `g.region` would help (?).

The last failing image is not a computational error. The error
message
--%<---

ValueError: The selected model does not know about this
combination of Satellite + Year!

--->%--
means that there are no coefficients for satellite "F18" and for the
year 2013. You may read this in
https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_coefficients.py#L99
and the referenced papers, of course.

For various reasons, I did not improve the script in
handling this situations. I just let it emit an error message. I hardly
remember having modified this message to say something like "There are
given coefficients for satellite F?? and Year ". But I can't trace
anything in my local repository.

(
Note, there are many newer algorithms. It would be obviously great to
integrate some of them in the existing module. If a new model bases upon
a similar math formula, then it's only necessary to add:

1. a new set of coefficients in 
https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_coefficients.py#L38

2. a new equation in 
https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_equations.py#L15

3. a new subclass, for the new model, in 
https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.nightlights.intercalibration/intercalibration_models.py

Maybe more work if there is a substantially different math logic.
)

Thanks, Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] 7.5svn repos question

[Rich Shepard]

On Thu, 21 Jun 2018, Helmut Kudrnovsky wrote:


as already mentioned in another mail, the easiest thing to stay updated
about svn activities is to look at:
https://lists.osgeo.org/pipermail/grass-commit/


Helmut,

  This morning I checked out the trunk, configured and built it. This told
me the revision number is 72869. I assume that's the most current revision
as it's the at the bottom of that web page dated Thu Jun 21 13:57:47 PDT
2018.


for svn related command options, the easiest thing is to consult the svn
manual.


  As a non-developer who does not commit changes I use either co or up.
Usually the latter. The other commands are not appropriate for me.

  Neither of these explain why 'svn up' returns the result that I'm at the
latest revision when no new code has been downloaded.

Regards,

Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] 7.5svn repos question

[Helmut Kudrnovsky]

Rich Shepard wrote
> On Thu, 21 Jun 2018, Markus Neteler wrote:
> 
>> As of now, i.e. date -u
>> Thu Jun 21 20:49:37 UTC 2018
>>
>> ... the SVN trunk revision is 72867.
> 
> Markus,
> 
>Then I wonder what changed here:
> 
> $ date -u
> Thu Jun 21 21:23:28 UTC 2018
> 
> $ svn up
> Updating '.':
> At revision 72869.
> 
>Any thoughts?
> 
> Best regards,
> 
> Rich
> ___
> grass-user mailing list

> grass-user@.osgeo

> https://lists.osgeo.org/mailman/listinfo/grass-user

as already mentioned in another mail, the easiest thing to stay updated
about svn activities is to look at:

https://lists.osgeo.org/pipermail/grass-commit/

for svn related command options, the easiest thing is to consult the svn
manual.



-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] 7.5svn repos question

[Rich Shepard]

On Thu, 21 Jun 2018, Markus Neteler wrote:


As of now, i.e. date -u
Thu Jun 21 20:49:37 UTC 2018

... the SVN trunk revision is 72867.


Markus,

  Then I wonder what changed here:

$ date -u
Thu Jun 21 21:23:28 UTC 2018

$ svn up
Updating '.':
At revision 72869.

  Any thoughts?

Best regards,

Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] question on i.nightlights.intercalibration code

[Gabriel Cotlier]

Hello Veronica,

Thanks a lot it worked!!

following the line you wrote:

i.nightlights.intercalibration image=img1,img2,img3 suffix=c elvidge2014


and got the error:

(Thu Jun 21 17:36:56
2018)
i.nightlights.intercalibration
image=F101992,F101993,F101994,F121994,F121995,F121996,F121997,F121998,F121999,F141997,F141998,F141999,F142000,F142001,F142002,F142003,F152000,F152001,F152002,F152003,F152004,F152005,F152006,F152007,F162004,F162005,F162006,F162007,F162008,F162009,F182010,F182011,F182012,F182013
suffix=c model=elvidge2014
|i Inter-satellite calibration of DMSP-OLS Nighttime Stable Lights
WARNING: Operating on current region

|> Calibrating average visible Digital Number values
Regression coefficients: (-2.057, 1.5903, -0.009) | Associated R^2: 0.9075
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
ERROR:
|* Timestamp is missing! Please add one to the input map if further times
series analysis is important. If you don't need it, you may use the -t flag.
(Thu Jun 21 17:37:47 2018) Command finished (51
sec)
(Thu Jun 21 17:39:49 2018)

So aggregating the flag -t, because an error that appeared, as follows:

i.nightlights.intercalibration
image=F101992,F101993,F101994,F121994,F121995,F121996,F121997,F121998,F121999,F141997,F141998,F141999,F142000,F142001,F142002,F142003,F152000,F152001,F152002,F152003,F152004,F152005,F152006,F152007,F162004,F162005,F162006,F162007,F162008,F162009,F182010,F182011,F182012,F182013
suffix=c model=elvidge2014 -t

And it finally worked!!

But as you can see bellow all inter-calibrated layers were created but
F182013 was not generate (F182013.c)

if you see at the end of this email it shows an error for the last layer
F182013 of the data set...

Why could this be happening?
Thanks a lot again.
Gabriel

|i Inter-satellite calibration of DMSP-OLS Nighttime Stable Lights
WARNING: Operating on current region

|> Calibrating average visible Digital Number values
Regression coefficients: (-2.057, 1.5903, -0.009) | Associated R^2: 0.9075
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attem,pted.
WARNING: Operating on current region

|> Calibrating average visible Digital Number values
Regression coefficients: (-1.0582, 1.5983, -0.0093) | Associated R^2: 0.936
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

|> Calibrating average visible Digital Number values
Regression coefficients: (-0.3458, 1.4864, -0.0079) | Associated R^2: 0.9243
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

|> Calibrating average visible Digital Number values
Regression coefficients: (-0.689, 1.177, -0.0025) | Associated R^2: 0.9071
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

|> Calibrating average visible Digital Number values
Regression coefficients: (-0.0515, 1.2293, -0.0038) | Associated R^2: 0.9178
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

|> Calibrating average visible Digital Number values
Regression coefficients: (-0.0959, 1.2727, -0.004) | Associated R^2: 0.9319
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

|> Calibrating average visible Digital Number values
Regression coefficients: (-0.3321, 1.1782, -0.0026) | Associated R^2: 0.9245
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

|> Calibrating average visible Digital Number values
Regression coefficients: (-0.0608, 1.0648, -0.0013) | Associated R^2: 0.9536
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

|> Calibrating average visible Digital Number values
Regression coefficients: (0.0, 1.0, 0.0) | Associated R^2: 1.0
360 degree EW extent is exceeded by 0.999827 cells
360 degree EW extent is exceeded by 0.999827 cells
WARNING: As requested, timestamp transferring not attempted.
WARNING: Operating on current region

|> Calibrating average visible Digital Number values
Regression coefficients: (-1.1323, 1.7696, -0.0122) | Associated 

Re: [GRASS-user] Spatial data exchange formats

[Rich Shepard]

On Thu, 21 Jun 2018, Markus Metz wrote:


you need to patch together all bare earth coverages from all years in
order to get a more complete coverage


Markus,

  I missed this point when I read the descriptive data. It certainly
explains why there's 2009_OLC_Hood-to-Coast, 2013_OLC_Clackamol, and
2014_OLC_Metro subdirectories.

  Now I'm on the right track. My thanks to all of you.

Regards,

Rich

___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Spatial data exchange formats

[Rich Shepard]

On Thu, 21 Jun 2018, Daniel Victoria wrote:

Daniel,


What I've seen is that most of you data has values -3.4028e+38 which
appears to be the NODATA value. So, are you sure this part of the data is
not a corner of the mapped area? Because there is valid data for the upper
and left borders. Also, this data is not a 1 x 1 degree rectangle, as you
said it should be. So this makes me believe that we are looking at just
one corner of the data, where it happens to have a lot of NODATA cells.


  Yes, Markus pointed this out to me. I'll import all three years' worth of
data and patch them together.

  I did not recognize this from reading the descriptive data that
accompanied the spatial data.

Thanks again,

Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Spatial data exchange formats

[Rich Shepard]

On Thu, 21 Jun 2018, Markus Metz wrote:


No, they should not. They cover a part of that rectangle. You need to
patch coverages from different years together in order to get a more
complete coverage.


Markus,

  Ah, I didn't realize this. That explains the why there are three files
with different names for three years.


The -o flag of r.in.gdal overrides the source's projection for the map
instead of using it.


  Mea culpa! I had that backwards.

Thanks very much,

Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] 7.5svn repos question

[Markus Neteler]

Rich,

On Wed, Jun 20, 2018 at 11:41 PM, Rich Shepard  wrote:
>   Something must have changed in the subversion repository and I want to
> confirm that this is a deliberate change.

... nothing was changed. The server operates as before.

>   At least once a week when I'm working with grass I start by checking for
> upgrades using 'svn up'. The past month or two the server's response is that
> I'm already at the current revision, just now that's at revision 72862. I'm
> having trouble understanding how upgrades are being pushed to me without my
> knowledge or active requests.

As of now, i.e. date -u
Thu Jun 21 20:49:37 UTC 2018

... the SVN trunk revision is 72867.

HTH
Markus
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Spatial data exchange formats

[Markus Metz]

Trying to help those trying to help Rich:

the tiling scheme is available in a web viewer here:

https://gis.dogami.oregon.gov/maps/lidarviewer/

the archive containing the data in question is available here:

http://www.oregongeology.org/pubs/ldq/LDQ-45122C3.zip (1.8 GB)

you need to patch together all bare earth coverages from all years in order
to get a more complete coverage

Markus M


On Thu, Jun 21, 2018 at 8:27 PM, Daniel Victoria 
wrote:

> Rich,
>
> I was able to open your GRID in QGis. And if it works in QGis, it should
> work in GRASS too.
>
> What I've seen is that most of you data has values -3.4028e+38 which
> appears to be the NODATA value. So, are you sure this part of the data is
> not a corner of the mapped area? Because there is valid data for the upper
> and left borders. Also, this data is not a 1 x 1 degree rectangle, as you
> said it should be. So this makes me believe that we are looking at just one
> corner of the data, where it happens to have a lot of NODATA cells.
>
> Cheers
> Daniel
>
>
> On Thu, Jun 21, 2018 at 3:17 PM Markus Metz 
> wrote:
>
>>
>>
>> On Thu, Jun 21, 2018 at 7:24 PM, Rich Shepard 
>> wrote:
>> >
>> >   My problems are that pointing r.in.gdal to the hdr.adf files display
>> only
>> > the strange wedge/rectangle I attached to messages earlier in this
>> thread.
>> > They should be retangles for a full 1 degree x 1 degree topographic
>> quad map
>> > with colors varying by elevation.
>>
>> No, they should not. They cover a part of that rectangle. You need to
>> patch coverages from different years together in order to get a more
>> complete coverage.
>>
>> >
>> >   My need is to learn why I'm not getting clean imports of either
>> bare_earth
>> > or highest_hits for any of the three years of data. This is why this
>> thread
>> > has continued so long. The only option to r.in.gdal I've used is '-o' to
>> > use the source's projection for the map.
>>
>> The -o flag of r.in.gdal overrides the source's projection for the map
>> instead of using it.
>>
>> Markus M
>>
>> >
>> > Thanks,
>> >
>> >
>> > Rich
>> >
>> >
>> > ___
>> > grass-user mailing list
>> > grass-user@lists.osgeo.org
>> > https://lists.osgeo.org/mailman/listinfo/grass-user
>>
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-user
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Spatial data exchange formats

[Daniel Victoria]

Rich,

I was able to open your GRID in QGis. And if it works in QGis, it should
work in GRASS too.

What I've seen is that most of you data has values -3.4028e+38 which
appears to be the NODATA value. So, are you sure this part of the data is
not a corner of the mapped area? Because there is valid data for the upper
and left borders. Also, this data is not a 1 x 1 degree rectangle, as you
said it should be. So this makes me believe that we are looking at just one
corner of the data, where it happens to have a lot of NODATA cells.

Cheers
Daniel


On Thu, Jun 21, 2018 at 3:17 PM Markus Metz 
wrote:

>
>
> On Thu, Jun 21, 2018 at 7:24 PM, Rich Shepard 
> wrote:
> >
> >   My problems are that pointing r.in.gdal to the hdr.adf files display
> only
> > the strange wedge/rectangle I attached to messages earlier in this
> thread.
> > They should be retangles for a full 1 degree x 1 degree topographic quad
> map
> > with colors varying by elevation.
>
> No, they should not. They cover a part of that rectangle. You need to
> patch coverages from different years together in order to get a more
> complete coverage.
>
> >
> >   My need is to learn why I'm not getting clean imports of either
> bare_earth
> > or highest_hits for any of the three years of data. This is why this
> thread
> > has continued so long. The only option to r.in.gdal I've used is '-o' to
> > use the source's projection for the map.
>
> The -o flag of r.in.gdal overrides the source's projection for the map
> instead of using it.
>
> Markus M
>
> >
> > Thanks,
> >
> >
> > Rich
> >
> >
> > ___
> > grass-user mailing list
> > grass-user@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-user
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Spatial data exchange formats

[Markus Metz]

On Thu, Jun 21, 2018 at 7:24 PM, Rich Shepard 
wrote:
>
>   My problems are that pointing r.in.gdal to the hdr.adf files display
only
> the strange wedge/rectangle I attached to messages earlier in this thread.
> They should be retangles for a full 1 degree x 1 degree topographic quad
map
> with colors varying by elevation.

No, they should not. They cover a part of that rectangle. You need to patch
coverages from different years together in order to get a more complete
coverage.

>
>   My need is to learn why I'm not getting clean imports of either
bare_earth
> or highest_hits for any of the three years of data. This is why this
thread
> has continued so long. The only option to r.in.gdal I've used is '-o' to
> use the source's projection for the map.

The -o flag of r.in.gdal overrides the source's projection for the map
instead of using it.

Markus M

>
> Thanks,
>
>
> Rich
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Spatial data exchange formats

[Rich Shepard]

On Thu, 21 Jun 2018, Rich Shepard wrote:


to replacing this ancient 32-bit system with a more capable 74-bit system.


  Er, ... that should be 64-bit system.

Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Spatial data exchange formats

[Rich Shepard]

On Thu, 21 Jun 2018, Daniel Victoria wrote:


I tried to download the data you placed on file dropper (other email
tread). But both links you sent gave me corrupt files.


Daniel,

  There was something funky going on with file dropper. But, I just
successfully uploaded bare_earth.tar.xz there:



File size is 7.6M (uncompressed: 669M).

  I just downloaded it using that URL and the file size is the same as that
of the uploaded file. It will remain there for 3 days.


Have you tried opening in some other software, like QGis?


  No. I have qgis-2.18.18 installed but have not used it. I'm getting closer
to replacing this ancient 32-bit system with a more capable 74-bit system.
The new system will accommodate the latest qgis and I'll spend time learning
it then for map publication.

Thanks,

Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] help with m.nviz.image - no output

[Carlos Henrique Grohmann de Carvalho]

Hello all

I'm trying to create some images with m.nviz.image, but all I get as output
is a 11 byte ppm...

Some of the options are quite puzzling in terms of mixing units:

position=x,y
Viewpoint position (x,y model coordinates)

height=value
Viewpoint height (in map units)

focus=x,y,z
Focus to point on surface (from SW corner in map units)

So I have to convert my position coordinates from map units (say meters in
UTM) to 0-1, I can use height in meters, and also need to do some math to
get the position of the focus point in meters from the SW corner...

Also, regardless of the output size, all I get is an unreadable ppm with 11
bytes. With format=tif, I get an error creating the file
(TIFFScanlineSize64: Computed scanline size is zero.).

Opening the ppm file into a text editor, I see that all that was written
was the header, and that the image size was 0,0:

P6
0 0
255

navigating trough the code, I see that m.nviz.image calls GS_write_ppm to
write the file, which is in lib/ogsf/gsd_img_ppm.c:


int GS_write_ppm(const char *name)
{
unsigned int x;
int y;
unsigned int xsize, ysize;
FILE *fp;
unsigned char *pixbuf;

gsd_getimage(, , );

if (NULL == (fp = fopen(name, "w"))) {
G_warning(_("Unable to open file <%s> for writing"), name);
return (1);
}

fprintf(fp, "P6\n%d %d\n255\n", xsize, ysize);

for (y = ysize - 1; y >= 0; y--) {
for (x = 0; x < xsize; x++) {
   unsigned char r = pixbuf[(y * xsize + x) * 4 + 0];
   unsigned char g = pixbuf[(y * xsize + x) * 4 + 1];
   unsigned char b = pixbuf[(y * xsize + x) * 4 + 2];

   fputc((int)r, fp);
   fputc((int)g, fp);
   fputc((int)b, fp);
}

}
G_free(pixbuf);
fclose(fp);

return (0);
}


GS_write_ppm calls gsd_getimage to get the actual image data and size.

So it seems to me that gsd_getimage is not getting the image?




The goal is to reproduce a nadir-looking aerial view (airplane, UAV).

Is this even possible?

thanks





-- 
Prof. Carlos Henrique Grohmann
Institute of Energy and Environment - Univ. of São Paulo, Brazil
- Digital Terrain Analysis | GIS | Remote Sensing -

http://carlosgrohmann.com
http://orcid.org/-0001-5073-5572

Can’t stop the signal.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Spatial data exchange formats

[Daniel Victoria]

OK.

I tried to download the data you placed on file dropper (other email
tread). But both links you sent gave me corrupt files.

If you can manage to place the files in some shared folder or point to the
original data source, I can take a look.

Have you tried opening in some other software, like QGis?

Cheers
Daniel

On Thu, Jun 21, 2018 at 2:24 PM Rich Shepard 
wrote:

> On Thu, 21 Jun 2018, Daniel Victoria wrote:
>
> > ESRI ArcINFO used two formats that spreded files into a directory with
> the
> > layer name and another directory called INFO. In the directory with the
> > layer name, the files had the .ADF extension you mentioned in the first
> > email. But their content is different.
>
> Daniel,
>
>In the late 1980s I used Arc/INFO on a Prime and pc-arc/info on a pc.
> Info
> was the attribute database.
>
> > From the list you sent, you have a file named hdr.adf, which is a
> giveaway
> > that we are dealing with an ESRI GRID (raster format). The presence of a
> > .OVR file also indicates that it's a grid, OVR being the raster pyramid
> > overviews.
>
>Thought so.
>
> > So, if you have a Raster product, it means that the person providing the
> > data took care of the processing to generate both the bare earth model
> and
> > the highest hit.
> >
> > Anyway, you can use r.in.gdal to import those GRIDS into GRASS. Just
> point
> > to the hdr.adf file and all should be OK.
>
>My problems are that pointing r.in.gdal to the hdr.adf files display
> only
> the strange wedge/rectangle I attached to messages earlier in this thread.
> They should be retangles for a full 1 degree x 1 degree topographic quad
> map
> with colors varying by elevation.
>
>My need is to learn why I'm not getting clean imports of either
> bare_earth
> or highest_hits for any of the three years of data. This is why this thread
> has continued so long. The only option to r.in.gdal I've used is '-o' to
> use the source's projection for the map.
>
> Thanks,
>
> Rich
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Spatial data exchange formats

[Rich Shepard]

On Thu, 21 Jun 2018, Daniel Victoria wrote:


ESRI ArcINFO used two formats that spreded files into a directory with the
layer name and another directory called INFO. In the directory with the
layer name, the files had the .ADF extension you mentioned in the first
email. But their content is different.


Daniel,

  In the late 1980s I used Arc/INFO on a Prime and pc-arc/info on a pc. Info
was the attribute database.


From the list you sent, you have a file named hdr.adf, which is a giveaway
that we are dealing with an ESRI GRID (raster format). The presence of a
.OVR file also indicates that it's a grid, OVR being the raster pyramid
overviews.


  Thought so.


So, if you have a Raster product, it means that the person providing the
data took care of the processing to generate both the bare earth model and
the highest hit.

Anyway, you can use r.in.gdal to import those GRIDS into GRASS. Just point
to the hdr.adf file and all should be OK.


  My problems are that pointing r.in.gdal to the hdr.adf files display only
the strange wedge/rectangle I attached to messages earlier in this thread.
They should be retangles for a full 1 degree x 1 degree topographic quad map
with colors varying by elevation.

  My need is to learn why I'm not getting clean imports of either bare_earth
or highest_hits for any of the three years of data. This is why this thread
has continued so long. The only option to r.in.gdal I've used is '-o' to
use the source's projection for the map.

Thanks,

Rich


___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Spatial data exchange formats

[Daniel Victoria]

Hi Rich,

Looks like I confused things a bit.

ESRI ArcINFO used two formats that spreded files into a directory with the
layer name and another directory called INFO. In the directory with the
layer name, the files had the .ADF extension you mentioned in the first
email. But their content is different.

>From the list you sent, you have a file named hdr.adf, which is a giveaway
that we are dealing with an ESRI GRID (raster format). The presence of a
.OVR file also indicates that it's a grid, OVR being the raster pyramid
overviews.

So, if you have a Raster product, it means that the person providing the
data took care of the processing to generate both the bare earth model and
the highest hit.

Anyway, you can use r.in.gdal to import those GRIDS into GRASS. Just point
to the hdr.adf file and all should be OK.

Cheers and sorry for the confusion.
Daniel

PS - Some references explaining both ESRI formats
http://desktop.arcgis.com/en/arcmap/10.3/manage-data/raster-and-images/esri-grid-format.htm

http://desktop.arcgis.com/en/arcmap/10.3/manage-data/coverages/contents-of-a-coverage-workspace.htm




On Thu, Jun 21, 2018 at 11:50 AM Rich Shepard 
wrote:

> On Mon, 18 Jun 2018, Daniel Victoria wrote:
>
> > You are correct about GRID being a raster format in ESRI world. But from
> > your description, I believe what you have is a coverage, which is ESRI
> > vector format for ArcINFO (shapefile being another vector format).
>
> Daniel,
>
>What information can I provide that clarifies the format in which these
> data were delivered so I know how to import them?
>
>A couple of years ago I downloaded LiDAR data from the same state agency
> and that was provided in .gdb format. When I imported the files I had
> clouds
> of data points for bare earth and highest hits. Why the newer data are in a
> different format I've no idea. The agency tells me they'll sell the point
> cloud data, but my project budget has no provision for buying data.
>
>Attached is a list of directories and files for the 2014 LiDAR data
> flights. I need to learn how to import these and use them to create bare
> earth and highest hit DEMs useful for hydrological modeling. Help from
> those of you who focus on spatial analyses with grass is needed. If I can
> provide more information, such as specific files, tell me and I'll provide
> them. (The entire directory compressed using xz is about 165M.)
>
> Regards,
>
> Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] question on i.nightlights.intercalibration code

[Veronica Andreo]

It is a bit difficult to read, can you post the command you used? It seems
you typed image twice, suffic instead of suffix and you are using $() to
pass the list of map names which is not necesary, AFAIU. Try the following:

i.nightlights.intercalibration image=img1,img2,img3 suffix=c model=liu2012

if that does not work, then, Nikos will know ;)

best,
Vero

El jue., 21 jun. 2018 a las 18:34, Gabriel Cotlier ()
escribió:

> Hello Vero,
> Thanks a lot for your response.
> I have tried that with no results, with the error in the image bellow:
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Jun 21, 2018 at 12:12 PM, Veronica Andreo 
> wrote:
>
>> Hi Gabriel,
>>
>> Are you using Windows? I think you cannot use g.list inside a command as
>> we do in Linux. Solution would be to first get the list of comma separated
>> map names and then paste it in the i.nightlights command.
>>
>> HTH,
>> Vero
>>
>> El jue., 21 jun. 2018 11:05, Gabriel Cotlier 
>> escribió:
>>
>>> I have tried to run i.i.nightlights.intercalibration on the command line
>>> and got the following error:
>>> What could be happening?
>>> Thanks a lot
>>>
>>>
>>> ___
>>> grass-user mailing list
>>> grass-user@lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/grass-user
>>
>>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] question on i.nightlights.intercalibration code

[Gabriel Cotlier]

Hello Vero,
Thanks a lot for your response.
I have tried that with no results, with the error in the image bellow:













On Thu, Jun 21, 2018 at 12:12 PM, Veronica Andreo 
wrote:

> Hi Gabriel,
>
> Are you using Windows? I think you cannot use g.list inside a command as
> we do in Linux. Solution would be to first get the list of comma separated
> map names and then paste it in the i.nightlights command.
>
> HTH,
> Vero
>
> El jue., 21 jun. 2018 11:05, Gabriel Cotlier 
> escribió:
>
>> I have tried to run i.i.nightlights.intercalibration on the command line
>> and got the following error:
>> What could be happening?
>> Thanks a lot
>>
>>
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-user
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] question on i.nightlights.intercalibration code

[Veronica Andreo]

Hi Gabriel,

Are you using Windows? I think you cannot use g.list inside a command as we
do in Linux. Solution would be to first get the list of comma separated map
names and then paste it in the i.nightlights command.

HTH,
Vero

El jue., 21 jun. 2018 11:05, Gabriel Cotlier  escribió:

> I have tried to run i.i.nightlights.intercalibration on the command line
> and got the following error:
> What could be happening?
> Thanks a lot
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] G_malloc errors in i.segment

[Moritz Lennert]

Hi Paul,

On 21/06/18 16:54, Paul Shapley wrote:

Hi Marcus,

Thanks again for your patience with this issue. It seems that whatever i 
set in the memory of 'i.segment' to it throws up the same 'G_malloc' 
error with the same 3 gb shortfall. I had another idea which is to make 
a smaller subset image (but if i do this) will the new subset of 'id' 
segments be applicable if applied to the entire image. For example if a 
value of '5134' represents 'peat' could i use 'r.mapcalc' to query the 
entire image for those values of '5134'. Supervised and Unsupervised 
Classification would not yield the differences in the landscape i'm 
looking for which 'i.segment' succeeds.


i.segment does not classify (i.e. label segments with a semantic 
meaning). It only creates segments. Across an image you will have many 
(without your size of image probably millions of segments which will 
correspond to the same class, but each segment will have its own id. In 
addition these ids are somewhat random, so you cannot deduct any meaning 
from them.


In order to classify your map you will have to either use classification 
rules or go for supervised classification of your segments. Currently 
GRASS GIS offers the addons i.segment.stats and v.class.mlR to do this. 
Check this article [1] and the related Jupyter notebook [2] for a more 
detailled explanation.


Another tip linked to your large image: you can cut the image into small 
tiles and segment each tile separately. You might have some border 
effects, but by using i.cutlines to define the tiles you can reduce 
those (or by using overlaps in a rectangular tiling scheme). You can 
parallelize the segmentation process in order to speed it up. We use 
i.segment.uspo for that here (at the same time optimizing the threshold 
segmentation parameter separately for each tile), but you can also use 
i.segment.hierarchical or simply create a little python script using 
GridModule (which creates rectangular tiles), i.e. something like this:


from grass.pygrass.modules.grid.grid import GridModule
import grass.script as gscript

# Create dictionary with the parameter arguments for i.segment
kwargs = {'group' : 'YourGroup',
'output' : 'YourOutputMap',
'threshold' : YourDesiredThreshold,
'minsize' : YourDesiredMinsize,
etc...
'quiet' : True}

# Define your desired gridding, overlap between grids and number of 
processes

grd = GridModule('i.segment',
width=width,
height=height,
overlap=overlap,
processes=processes,
split=False,
**kwargs)

# Run the module on each of the grid cells
grd.run()

Moritz

[1] http://www.mdpi.com/2072-4292/9/4/358
[2] https://github.com/tgrippa/Opensource_OBIA_processing_chain





Thanks,

Paul Shapley

On 21 June 2018 at 08:52, Markus Metz > wrote:


[please keep it in the list]

On Thu, Jun 21, 2018 at 9:12 AM, Paul Shapley mailto:p.shap...@gmail.com>> wrote:
 >
 > Thank you Markus...here are the results of g.region -p and r.info

 >
 > g.region -p
 > projection: 99 (OSGB 1936 / British National Grid)
 > zone:       0
 > datum:      osgb36
 > ellipsoid:  airy
 > north:      242815
 > south:      200862.25
 > west:       263134.25
 > east:       298833.75
 > nsres:      0.25
 > ewres:      0.25
 > rows:       167811
 > cols:       142798
 > cells:      23963075178
 > (Thu Jun 21 08:03:51 2018) Command finished (0 sec)
 >
 > (Thu Jun 21 08:08:02 2018)
 > r.info  map=APGB_aerial_1.1@PERMANENT
 >
  
++
 >  | Map:      APGB_aerial_1.1@PERMANENT      Date: Tue May 29
09:11:31 2018    |
 >  | Mapset:   PERMANENT                      Login of Creator:
administrator   |
 >  | Location: TempLocation
             |
 >  | DataBase: C:\
              |
 >  | Title:    APGB_aerial_1.1
              |
 >  | Timestamp: none  
              |

 >
  
||
 >  |  
              |
 >  |   Type of Map:  raster               Number of Categories: 0  
             |
 >  |   Data Type:    CELL  
             |
 >  |   Rows:         167811
             |
 >  |   Columns:      142798
             |
 >  |   Total Cells:  23963075178  
              |
 >  |        Projection: OSGB 1936 / British 

Re: [GRASS-user] G_malloc errors in i.segment

[Paul Shapley]

Hi Marcus,

Thanks again for your patience with this issue. It seems that whatever i
set in the memory of 'i.segment' to it throws up the same 'G_malloc' error
with the same 3 gb shortfall. I had another idea which is to make a smaller
subset image (but if i do this) will the new subset of 'id' segments be
applicable if applied to the entire image. For example if a value of '5134'
represents 'peat' could i use 'r.mapcalc' to query the entire image for
those values of '5134'. Supervised and Unsupervised Classification would
not yield the differences in the landscape i'm looking for which
'i.segment' succeeds.

Thanks,

Paul Shapley

On 21 June 2018 at 08:52, Markus Metz  wrote:

> [please keep it in the list]
>
> On Thu, Jun 21, 2018 at 9:12 AM, Paul Shapley  wrote:
> >
> > Thank you Markus...here are the results of g.region -p and r.info
> >
> > g.region -p
>
> > projection: 99 (OSGB 1936 / British National Grid)
> > zone:   0
> > datum:  osgb36
> > ellipsoid:  airy
> > north:  242815
> > south:  200862.25
> > west:   263134.25
> > east:   298833.75
> > nsres:  0.25
> > ewres:  0.25
> > rows:   167811
> > cols:   142798
> > cells:  23963075178
> > (Thu Jun 21 08:03:51 2018) Command finished (0 sec)
> >
> > (Thu Jun 21 08:08:02 2018)
>
> > r.info map=APGB_aerial_1.1@PERMANENT
>
> >  +--
> --+
> >  | Map:  APGB_aerial_1.1@PERMANENT  Date: Tue May 29 09:11:31
> 2018|
> >  | Mapset:   PERMANENT  Login of Creator:
> administrator   |
> >  | Location: TempLocation
>   |
> >  | DataBase: C:\
>  |
> >  | Title:APGB_aerial_1.1
>  |
> >  | Timestamp: none
>  |
> >  |--
> --|
> >  |
>  |
> >  |   Type of Map:  raster   Number of Categories: 0
>   |
> >  |   Data Type:CELL
>   |
> >  |   Rows: 167811
>   |
> >  |   Columns:  142798
>   |
> >  |   Total Cells:  23963075178
>  |
> >  |Projection: OSGB 1936 / British National Grid
>   |
> >  |N: 242815S:  200862.25   Res:  0.25
>   |
> >  |E:  298833.75W:  263134.25   Res:  0.25
>   |
> >  |   Range of data:min = 0  max = 255
>   |
> >  |
>  |
> >  |   Data Description:
>  |
> >  |generated by r.in.gdal
>  |
> >  |
>  |
> >  |   Comments:
>  |
> >  |r.in.gdal -o -k input="J:\Spatial Data\Aerial\APGB_received_20180416\
>   |
> >  |\source\RGB_25cm\output\test\JPEG.png" output="APGB_aerial_1"
> memory\   |
> >  |=300 offset=0 num_digits=0
>  |
> >  |
>  |
> >  +--
> --+
> > (Thu Jun 21 08:08:02 2018) Command finished (0 sec)
>
> OK, so you really have a group of rasters with 24 billion cells. Still, do
> you really need to run i.segment on the full extents with such a high
> resolution? If yes, try i.segment with memory=25000. Even if the system has
> more RAM, the operating system and any other programs also need some RAM,
> therefore it is safer to not use all free memory. Be aware that i.segment
> will take a long time (several days) to process such a large region.
>
> >
> > Should the output image from 'r.in.gdal' have had more memory allocated
> than the 300mb?
>
> The memory option of r.in.gdal applies to the input image, not the output
> image. Sometimes more memory can help, sometimes it does not have any
> effect. However, it does not affect subsequent processing steps.
>
> Markus M
>
> >
> > Thanks again Markus...I appreciate your help.
> >
> > Paul Shapley
> >
> >
> >
> >
> > On 20 June 2018 at 16:15, Markus Metz 
> wrote:
> >>
> >>
> >>
> >> On Wed, Jun 20, 2018 at 1:30 PM, Paul Shapley 
> wrote:
> >> >
> >> > Hi Users,
> >> >
> >> > Apologies if i'm posting this error again but i need to get pass the
> memory allocation issue of trying to allocate 3gb memory. The Grass version
> is (using file r.contour). Processor has 32 gb ram and i've allocated 3
> mb under memory option of 'i.segment'.
> >> >
> >> > System Info
>
> >> > GRASS version: 7.4.1
>
> >> > GRASS SVN revision: r72807
>
> >> > Build date: 2018-06-13
>
> >> > Build platform: i386-w64-mingw32
>
> >> > GDAL: 2.2.4
>
> >> > PROJ.4: 4.9.3
>
> >> > GEOS: 3.5.0
>
> >> > SQLite: 3.17.0
>
> >> > Python: 2.7.4
>
> >> > wxPython: 2.8.12.1
>
> >> > Platform: Windows-2008ServerR2-6.1.7601-SP1 (OSGeo4W)
>
> >> >
>
> >> >
> >> > ERROR: G_malloc: unable to allocate 2995426350 bytes of memory at
> imagery/i.segment/flag.c:25
> >>
> >> this error appears because all other memory has already been allocated,
> there is less than 3 GB free RAM left.
> >>
> >> It seems that the current region has more than 20 billion grid cells.
> Does this match the input to i.segment? You might want to check the current
> region settings and compare them with extents 

[GRASS-user] question on i.nightlights.intercalibration code

[Gabriel Cotlier]

 I have tried to run i.i.nightlights.intercalibration on the command line
and got the following error:
What could be happening?
Thanks a lot
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] question on i.nightlights.intercalibration code

[Gabriel Cotlier]

 I have tried to run i.i.nightlights.intercalibration on the command line
and got the following error:
What could be happening?
Thanks a lot
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] G_malloc errors in i.segment

[Markus Metz]

[please keep it in the list]

On Thu, Jun 21, 2018 at 9:12 AM, Paul Shapley  wrote:
>
> Thank you Markus...here are the results of g.region -p and r.info
>
> g.region -p

> projection: 99 (OSGB 1936 / British National Grid)
> zone:   0
> datum:  osgb36
> ellipsoid:  airy
> north:  242815
> south:  200862.25
> west:   263134.25
> east:   298833.75
> nsres:  0.25
> ewres:  0.25
> rows:   167811
> cols:   142798
> cells:  23963075178
> (Thu Jun 21 08:03:51 2018) Command finished (0 sec)
>
> (Thu Jun 21 08:08:02 2018)

> r.info map=APGB_aerial_1.1@PERMANENT

>
 ++
>  | Map:  APGB_aerial_1.1@PERMANENT  Date: Tue May 29 09:11:31
2018|
>  | Mapset:   PERMANENT  Login of Creator:
administrator   |
>  | Location: TempLocation
|
>  | DataBase: C:\
 |
>  | Title:APGB_aerial_1.1
 |
>  | Timestamp: none
 |
>
 ||
>  |
 |
>  |   Type of Map:  raster   Number of Categories: 0
|
>  |   Data Type:CELL
|
>  |   Rows: 167811
|
>  |   Columns:  142798
|
>  |   Total Cells:  23963075178
 |
>  |Projection: OSGB 1936 / British National Grid
|
>  |N: 242815S:  200862.25   Res:  0.25
|
>  |E:  298833.75W:  263134.25   Res:  0.25
|
>  |   Range of data:min = 0  max = 255
|
>  |
 |
>  |   Data Description:
 |
>  |generated by r.in.gdal
 |
>  |
 |
>  |   Comments:
 |
>  |r.in.gdal -o -k input="J:\Spatial
Data\Aerial\APGB_received_20180416\   |
>  |\source\RGB_25cm\output\test\JPEG.png" output="APGB_aerial_1"
memory\   |
>  |=300 offset=0 num_digits=0
 |
>  |
 |
>
 ++
> (Thu Jun 21 08:08:02 2018) Command finished (0 sec)

OK, so you really have a group of rasters with 24 billion cells. Still, do
you really need to run i.segment on the full extents with such a high
resolution? If yes, try i.segment with memory=25000. Even if the system has
more RAM, the operating system and any other programs also need some RAM,
therefore it is safer to not use all free memory. Be aware that i.segment
will take a long time (several days) to process such a large region.

>
> Should the output image from 'r.in.gdal' have had more memory allocated
than the 300mb?

The memory option of r.in.gdal applies to the input image, not the output
image. Sometimes more memory can help, sometimes it does not have any
effect. However, it does not affect subsequent processing steps.

Markus M

>
> Thanks again Markus...I appreciate your help.
>
> Paul Shapley
>
>
>
>
> On 20 June 2018 at 16:15, Markus Metz 
wrote:
>>
>>
>>
>> On Wed, Jun 20, 2018 at 1:30 PM, Paul Shapley 
wrote:
>> >
>> > Hi Users,
>> >
>> > Apologies if i'm posting this error again but i need to get pass the
memory allocation issue of trying to allocate 3gb memory. The Grass version
is (using file r.contour). Processor has 32 gb ram and i've allocated 3
mb under memory option of 'i.segment'.
>> >
>> > System Info

>> > GRASS version: 7.4.1

>> > GRASS SVN revision: r72807

>> > Build date: 2018-06-13

>> > Build platform: i386-w64-mingw32

>> > GDAL: 2.2.4

>> > PROJ.4: 4.9.3

>> > GEOS: 3.5.0

>> > SQLite: 3.17.0

>> > Python: 2.7.4

>> > wxPython: 2.8.12.1

>> > Platform: Windows-2008ServerR2-6.1.7601-SP1 (OSGeo4W)

>> >

>> >
>> > ERROR: G_malloc: unable to allocate 2995426350 bytes of memory at
imagery/i.segment/flag.c:25
>>
>> this error appears because all other memory has already been allocated,
there is less than 3 GB free RAM left.
>>
>> It seems that the current region has more than 20 billion grid cells.
Does this match the input to i.segment? You might want to check the current
region settings and compare them with extents and resolution as reported by
r.info on the input to i.segment.
>>
>> Please provide the output of g.region -p and r.info if you want more
detailed help.
>>
>> Markus M
>>
>> >
>> > --
>> > Paul J. Shapley MSc CGeog (GIS) FRGS
>> >
>> >
>> > ___
>> > grass-user mailing list
>> > grass-user@lists.osgeo.org
>> > https://lists.osgeo.org/mailman/listinfo/grass-user
>>
>
>
>
> --
> Paul J. Shapley MSc CGeog (GIS) FRGS
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user