Re: [GRASS-user] ESRI formats: gdb and shp

[Daniel Victoria]

Rich,

This is an old PDF (2009) but it lists some advantages of file geodatabase.
https://www.esri.com/news/arcuser/0309/files/9reasons.pdf

Another thing worth mentioning is that in order to do topological analysis
in ESRIs world, you would need to use geodatabases since shapefiles does
not carry topology information.

But you mentioned that you are dealing with point data. I never heard of
using topology with point data. So you are probably fine importing from
either one (shape or gdb)
Also, don't know it the topology part of a GDB file is recognized by
OGR/grass. I believe Grass generates the topology once it's imports vector
data, be it from shapefile or GDB.

Now, if the attribute table has long column names, accents and things like
that, it's probably correct in the GDB. Remember that shapefiles use DBF
for attribute table...

Disclaimer: I haven´t used an ESRI product in a long time. So the
information in here could be outdated

Cheers
Daniel



On Tue, Feb 11, 2020 at 1:56 PM Rich Shepard 
wrote:

> On Tue, 11 Feb 2020, Daniel Victoria wrote:
>
> > What do you mean by better? Correct data? Easier to import?
>
> Daniel,
>
> More complete topographic information. I recall learning a long time ago
> that shapefiles are not as topographically complete as other formats such
> as
> the older (and excellent) .e00 files. Do gdb files have any additional
> information compared with shp files? Are they preferred for some reason?
>
> 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] ESRI formats: gdb and shp

[Daniel Victoria]

What do you mean by better? Correct data? Easier to import?

If they contain the same data I think it does not matter which one you use.
Specially because you are talking about point data. But, if there is a
difference in the data, then you have another problem. Figuring out which
one is correct

Cheers

On Tue, Feb 11, 2020 at 1:13 PM Rich Shepard 
wrote:

> I have two files of point locations: sites.gdb and sites.shp. I also have a
> file with (I assume) the same data. Am I correct is assuming that the .gdb
> file would be topographically preferred over the .shp file and the better
> one to import?
>
> 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] Null values in attribute table get converted to 0 (zero) during v.to.rast

[Daniel Victoria]

I was traveling so could not respond. So sorry to chime in a bit late. For
me it was a bit counter intuitive that polygons with null attributes became
zero in the finished raster. What if I had attributes with zero value in it?

I liked the idea of issuing a warning and using the `where` parameter.

Anyway, thanks for the help and fix

Cheers
Daniel

On Fri, Nov 1, 2019 at 12:33 PM Micha Silver  wrote:

>
> On 01/11/2019 9:38, Markus Metz wrote:
>
>
>
> On Fri, Nov 1, 2019 at 12:11 AM Veronica Andreo 
> wrote:
> >
> > Hi Micha
> >
> > El jue., 31 oct. 2019 a las 22:36, Micha Silver ()
> escribió:
> >>
> >>
> >> On 31/10/2019 22:20, Markus Metz wrote:
> >>
> >>
> >>
> >> On Tue, Oct 29, 2019 at 7:40 PM Veronica Andreo 
> wrote:
> >> >
> >> > Hi Daniel,
> >> >
> >> > I agree that if there's a NULL in the column, there should be NULL in
> the resulting raster. I suggest to open a ticket here:
> https://trac.osgeo.org/grass/
> >>
> >> easy solution: v.to.rast where=" is not null"
> >>
> >> or the new PR #173
> >> https://github.com/OSGeo/grass/pull/173
> >> if an attribute value is null, the corresponding vector features will
> not be rasterized
> >>
> >> Markus M
> >>
> >> I'm not sure I agree with the approach that a polygon with missing
> attribute should become NULL. In my view, NULL should be used only for
> pixels not covered at all by any polygon.
> >
> > but in the resulting raster (in rasters in general), there's no
> difference, it's rather NULL or it has a value... it does not matter if the
> null comes from areas originally covered by a polygon or not...
>
> I think it depends on the particular use case if it matters where a NULL
> raster value comes from: a polygon with empty attribute or no polygon at
> all for that cell.
>
> >>
> >> Perhaps an additional input parameter "missing_attribute" so the user
> can choose a value to enter into the raster if the attribute is missing. If
> no parameter is supplied, and the chosen attribute column has missing
> values, I'd prefer that the script exit gracefully, with a message that a
> "missing_attribute" value is required.
>
> This can easily be done with existing tools:
> - convert only those polygons with a valid attribute value: v.to.rast
> where="attribute is not null"
> - replace missing attribute values with a valid value: v.db.update
> where="attribute is null", then v.to.rast
>
> I'm changing my PR to issue a warning if empty attribute values are found
> and replaced with zero.
>
>
> IMHO, that's probably the best way to deal with this.
>
>
>
> Markus M
>
> >
> > yes, this could be a solution to keep track of where you had polygons,
> but then you would need to use r.null anyway, no? I try to think of use
> cases in which one uses a vector attribute to convert to raster, but then
> still needs to know where the polygons were... because, for example, to
> query a raster map with another raster map representing zones one would
> convert the vector of polygons using cat and not an attribute, no?
> >
> > cheers,
> > Vero
> >>
> >>
> >> > El jue., 24 oct. 2019 a las 14:40, Daniel Victoria (<
> daniel.victo...@gmail.com>) escribió:
> >> >>
> >> >> Hi list,
> >> >>
> >> >> I have a vector polygon map that I'm converting to raster. The
> attribute column that I process has some empty rows (no data / null). When
> I run v.to.rast, these empty rows become 0 (zero) on my resulting raster
> map.
> >> >>
> >> >> Shouldn't v.to.rast respect the empty attribute table and create
> null values for those polygons?
> >> >>
> >> >> For now I'll use r.null to fix this problem. But what if 0 is a
> valid value?
> >> >>
> >> >> Cheers
> >> >> Daniel
> >> >>
> >> >> PS - Running Grass 7.6.1 on Ubuntu
> >> >> ___
> >> >> 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
> >>
> >> --
> >> Micha Silver
> >> Ben Gurion Univ.
> >> Sde Boker, Remote Sensing Lab
> >> cell: +972-523-665918
>
> --
> Micha Silver
> Ben Gurion Univ.
> Sde Boker, Remote Sensing Lab
> cell: +972-523-665918
>
> ___
> 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] Null values in attribute table get converted to 0 (zero) during v.to.rast

[Daniel Victoria]

Hi list,

I have a vector polygon map that I'm converting to raster. The attribute
column that I process has some empty rows (no data / null). When I run
v.to.rast, these empty rows become 0 (zero) on my resulting raster map.

Shouldn't v.to.rast respect the empty attribute table and create null
values for those polygons?

For now I'll use r.null to fix this problem. But what if 0 is a valid
value?

Cheers
Daniel

PS - Running Grass 7.6.1 on Ubuntu
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Read only mapsets

[Daniel Victoria]

You could use the PERMANENT mapset for this purpose. Also, the AFAIK
mapsets are writable by the directory owner. So you could use the
filesystem setting to achieve what you want to do.

There is a more detailed explanation here
https://grasswiki.osgeo.org/wiki/Location_and_Mapsets

Cheers

On Fri, Apr 26, 2019 at 6:53 AM Panagiotis Mavrogiorgos 
wrote:

> Hello everyone,
>
> I was wondering, is there a way to enforce a Mapset to be read-only? I
> guess that this can always be enforced on the Filesystem level with
> something like this:
>
> find . -type f -exec chmod a-w {} \;
>
>
> but then again some file might need to be writable afterall (sqlite.db?)
>
> So is there a way to e.g. open specific maps in read-only mode?
>
> all the best,
> Panos
> ___
> 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] estimate impervious areas from satellite imagery

[Daniel Victoria]

There are many articles dealing with this topic [1]. You will have to find
what method best suits your needs. You can then apply it using GRASS GIS

Cheers

1:
https://scholar.google.com.br/scholar?q=map+impervious+surface+remote+sensing=en_sdt=0_vis=1=scholart

On Sun, Apr 21, 2019 at 10:16 AM Francois Chartier 
wrote:

> Hi,
>
> is it possible to process satellite imagery, even if just google
> satellite, and estimate percentage of impervious (hard surfaces such as
> paved and roof) areas.  this would useful for estimating infiltration and
> runoff from a watershed.
>
> thanks
> f.
> ___
> 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] Uploading NumPy array as a new column to a vector map

[Daniel Victoria]

Never tried it but you got me curious.

It looks simpler to define a new function or the database using python
sqlite3 libs

https://docs.python.org/2/library/sqlite3.html#sqlite3.Connection.create_function

Cheers


On Thu, Feb 14, 2019 at 12:50 PM César Augusto Ramírez Franco <
caesar...@gmail.com> wrote:

> Greetings,
>
> I have a municipality polygon layer with a poverty index (percent) and a
> population count, I'm multiplying them to visualize the vulnerability for
> each municipality, due to the distribution of that new variable I want to
> compute the logarithm, which is not possible in sqlite, so I tried reading
> the column with numpy and issuing a np.log10(). I'm happy with the result,
> but how can I get this new numpy array to a new column in the vector map in
> a simple way?
>
> This is what I already have:
>
> #!/usr/bin/env python
>
> import grass.script as gs
> import numpy as np
> import matplotlib.pyplot as plt
>
> nbi_pob = np.array(gs.vector_db_select("muniant", columns =
> "nbi_pob")["values"].values()).astype(float).squeeze()
>
> plt.hist(nbi_pob)
> plt.show()
>
> log_nbi_pob = np.log10(nbi_pob)
>
> plt.hist(log_nbi_pob)
> plt.show()
>
> I'm trying to introduce this kind of analysis to students who are not
> familiar nor proficient with programming (this is an GIS introductory
> course) so the numpy bit is already complex enough to them, and I'd like to
> avoid using for loops with cursors to achieve this.
>
> Is there a simple solution to this?
>
> --
> *César Augusto Ramírez Franco*
> ___
> 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] Digitizing from or converting Google Earth maps

[Daniel Victoria]

Hi Rich,

Regarding the use of Google Maps for digitizing, I just bumped into another
site stating the permissions.
I'm not a lawyer so I'm not sure I understood everything correctly. But
from the site, I could not find anything prohibiting the use of Google Maps
to digitize things 'not for profit'.

https://www.google.com/permissions/geoguidelines/

Of course, I could be wrong...

As for your other question, about using v.digit, I'm afraid I can't give
much help.

Cheers
Daniel

On Mon, Feb 4, 2019 at 11:11 PM Rich Shepard 
wrote:

> On Mon, 4 Feb 2019, Daniel Victoria wrote:
>
> > Not sure if r.in.gdal or r.in.wms can load Google Earth tiles.
>
> Daniel,
>
> Both are worth a try.
>
> > QGIS has a nice way of loading external tiles and WMS servers as a
> > background image. You could than digitize on top of that. But since
> Google
> > changed their MAPs API, I'm not sure if QGIS is loading Google Earth
> > Images straight out of the box. It's been a while since I've used this
> > feature.
>
> Also something for me to consider.
>
> > Also, I'm not sure what to make of this part of the Google Maps Platform
> > terms of service, in the section about "restrictions against misusing"
>
> > (a)  No Scraping.  Customer will not extract, export, scrape, or cache
> > Google Maps Content for use outside the Services. For example, Customer
> > will not:(i) pre-fetch, index, store, reshare, or rehost Google Maps
> > Content outside the services; (ii) bulk download geocodes; (iii) copy
> > business names, addresses, or user reviews; or (iv) use Google Maps
> Content
> > with text-to-speech services. Caching is permitted for certain Services
> as
> > described in the Maps Service Specific Terms.
> >
> > (b) No Creating Content From Google Maps Content. Customer will not
> create
> > content based on Google Maps Content, including tracing, digitizing, or
> > creating other datasets based on Google Maps Content
>
> I read the above as prohibiting re-using GE maps in web applications or for
> profit as products, but not prohibiting using the tiles as background for
> maps produced by a GIS.
>
> The other part of my question, which was not clearly stated, is how to use
> v.edit or the GUI digitizing tool to closely follow an edge in a background
> map. Perhaps the way to do this is to zoom in on a small section, digitize
> a
> series of short arcs, save the work and exit digitizing, then pan the
> working widow and repeat the above. I've not been able to digitize a
> project
> area, for example, while viewing the entire area.
>
> Thanks for your reply,
>
> 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] Digitizing from or converting Google Earth maps

[Daniel Victoria]

Not sure if r.in.gdal or r.in.wms can load Google Earth tiles.

QGIS has a nice way of loading external tiles and WMS servers as a
background image. You could than digitize on top of that. But since Google
changed their MAPs API, I'm not sure if QGIS is loading Google Earth Images
straight out of the box. It's been a while since I've used this feature.

Also, I'm not sure what to make of this part of the Google Maps Platform
terms of service, in the section about "restrictions against misusing"

https://cloud.google.com/maps-platform/terms/

3.2.4 Restrictions Against Misusing the Services.

(a)  No Scraping.  Customer will not extract, export, scrape, or cache
Google Maps Content for use outside the Services. For example, Customer
will not:(i) pre-fetch, index, store, reshare, or rehost Google Maps
Content outside the services; (ii) bulk download geocodes; (iii) copy
business names, addresses, or user reviews; or (iv) use Google Maps Content
with text-to-speech services. Caching is permitted for certain Services as
described in the Maps Service Specific Terms.

(b) No Creating Content From Google Maps Content. Customer will not create
content based on Google Maps Content, including tracing, digitizing, or
creating other datasets based on Google Maps Content

Cheers
Daniel


On Sat, Feb 2, 2019 at 3:57 PM Rich Shepard 
wrote:

> If someone has a work flow for digitizing boundaries (e.g., river banks)
> from Google Earth images I would appreciate learning how to do this better
> than my previous efforts. Or, if there's a way to convert a GE map to a
> raster that can be used and analyzed in GRASS that would be even better.
>
> Regards,
>
> 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] buffer to wrap points

[Daniel Victoria]

Or are you looking at a way to wrap all points? Like v.hull [1]
There is also an addon for concave hull [2]

Cheers

[1] - https://grass.osgeo.org/grass74/manuals/v.hull.html
[2] - https://grass.osgeo.org/grass74/manuals/addons/v.concave.hull.html

On Thu, Nov 29, 2018 at 10:10 AM Ken Mankoff  wrote:

> Hi Frank,
>
> On 2018-11-29 at 12:46 +0100, Frank David  wrote:
> > I did not find in v.buffer the way to create a common buffer on points
> > if I want the buffer wraps all my points. Is there any tricks ?
>
> Can you explain what you did and what happened and what you expected to
> happen? There is a section in the v.buffer man page "Circles around input
> points" that provides an example. Does this work for you?
>
>   -k.
> ___
> 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] Create_iwave.py script error for template creation -i.atcorr module-reg

[Daniel Victoria]

I looks like you have a mixed python installation, with some libraries
coming from ArcGIS and others from your grass installation. Not sure that's
a problem but, if it works on Markus M computer, it's worth checking it out.

On Wed, Oct 24, 2018 at 5:08 PM Markus Metz 
wrote:

>
>
> On Wed, Oct 24, 2018 at 8:28 AM kameswari devi 
> wrote:
> >
> > Please check the file i have used and error received as an
> > attachment.I tried to interpolate using Create_iwave.py script for
> > i.atcorr module but errors are observed. please suggest me thank you
>
> Using create_iwave.py in GRASS 7.7,
>
> python create_iwave.py sensors_csv/testint_B131to142.csv
>
> works fine without errors. Which GRASS version are you using?
>
> Markus M
> >
> > --
> > Regards
> > kameswari devi P
> > ___
> > 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] db.out.ogr issues

[Daniel Victoria]

The lat/long coordinates you get from DB.out.ogr probably comes from your
vector attributes, which contains the old coordinates.

When you project the data in Grass, the coordinates in the vector geometry
are updated but the attribute table is not changed. Try using v.to.db to
add the coordinates of each point to the attribute table and then export it
using DB.out.ogr.

Cheers
Daniel

On Thu, Aug 9, 2018, 19:54 Rich Shepard  wrote:

>I have precipitation data for all stations within a county. The
> geographic
> coordinates of the source are lon/lat. These were imported to a lon/lat
> directory using v.in.ogr then reprojected (v.proj) to the standard state
> projection (EPSG 2838).
>
>I want to run spatial analyses on these data in R using the state
> projection coordinates, so I used db.out.ogr and was surprised to see the
> output is still in lon/lat. The project directory's PROJ_INFO led me to
> believe the attribute database values should be converted, but they're not.
>
>Do I run proj.4 on the command line to transform the lon/lat to EPSG
> 2838
> or can I do this within grass7.x?
>
> 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] Rotating raster maps

[Daniel Victoria]

Some satellite images comes rotated, with black borders. But if we rotate
them prior to patching, we mess up the georeferencing. The process then is
setting those borders to null and then patching.

If this is your case, then I'd try running `r.null` to set those borders as
no-data and then use `r.patch`.

But again, not sure if this is your case

Cheers

On Wed, Jul 18, 2018 at 12:06 PM Rich Shepard 
wrote:

> On Wed, 18 Jul 2018, Daniel Victoria wrote:
>
> > But are those tif images? Or GeoTiff? Because, if those are geotiffs,
> with
> > correct georeferencing, I believe rotating will mess things up.
>
> Daniel,
>
>Probably GeoTIFF. If rotating is not the solution is there another way
> to
> patch them together without thin wedges?
>
> Regards,
>
> 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] Rotating raster maps

[Daniel Victoria]

But are those tif images? Or GeoTiff? Because, if those are geotiffs, with
correct georeferencing, I believe rotating will mess things up.

On Wed, Jul 18, 2018 at 11:48 AM Markus Neteler  wrote:

> On Wed, Jul 18, 2018 at 2:53 PM, Rich Shepard 
> wrote:
> >   I have .tif images at 1:5000 or 1:6000 scale that are each slightly
> > rotated clockwise on their rectangular backgrounds. The imported raster
> maps
> > are also slightly torqued so edges do not properly align (see attached
> > screenshot).
> >
> >   Is there an i.* module that can rotate them
>
> Yes:
> https://grass.osgeo.org/grass74/manuals/addons/#i
> -> i.rotate
>
> Markus
>
> > so when patched together there
> > are no gaps?
> >
> > 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] r,in.gdal error when importing a jpeg2000 image

[Daniel Victoria]

Did you try running gdalinfo on your image? Does it work?

The GDAL raster format page [1] lists that JPEG2000 support is not compiled
by default. So it could be that your gdal installation does not recognize
this file

[1] http://www.gdal.org/formats_list.html

On Wed, Jul 18, 2018 at 5:33 AM Paul Shapley  wrote:

> Hi Users,
>
> Trying to import an 8.7gb (jpeg2000) image into Grass 7.4.1 64 bit. I get
> the error below. Tested the image in another OS GIS package and it opens
> without issue. Not sure why Grass wont import it.
>
> Thanks everyone!
>
> Paul Shapley
>
>
> (Wed Jul 18 09:19:16 2018)
>
> r.in.gdal -o input=J:\Spatial
> Data\Aerial\APGB_received_20180416\aerial_25cm.jp2
> output=aerial_25cm_master memory=3000
> Over-riding projection check
> Importing 3 raster bands...
> Importing raster map ...
> ERROR 1: Marker is not compliant with its position
> ERROR 1: opj_decode() failed
> ERROR 1: J:\Spatial
> Data\Aerial\APGB_received_20180416\aerial_25cm.jp2, band 1:
> IReadBlock failed at X offset 0, Y offset 0
> ERROR 1: GetBlockRef failed at X block offset 0, Y block
> offset 0
> ERROR 1: Marker is not compliant with its position
> ERROR 1: opj_decode() failed
> ERROR 1: J:\Spatial
> Data\Aerial\APGB_received_20180416\aerial_25cm.jp2, band 1:
> IReadBlock failed at X offset 0, Y offset 0
> ERROR 1: GetBlockRef failed at X block offset 0, Y block
> offset 0
> ERROR 1: Marker is not compliant with its position
> ERROR 1: opj_decode() failed
> ERROR 1: J:\Spatial
> Data\Aerial\APGB_received_20180416\aerial_25cm.jp2, band 1:
> IReadBlock failed at X offset 0, Y offset 0
> ERROR 1: GetBlockRef failed at X block offset 0, Y block
> offset 0
> ERROR 1: Marker is not compliant with its position
> ERROR 1: opj_decode() failed
> ERROR 1: J:\Spatial
> Data\Aerial\APGB_received_20180416\aerial_25cm.jp2, band 1:
> IReadBlock failed at X offset 0, Y offset 0
> ERROR 1: GetBlockRef failed at X block offset 0, Y block
> offset 0
> ERROR 1: Marker is not compliant with its position
> ERROR 1: opj_decode() failed
> ERROR 1: J:\Spatial
> Data\Aerial\APGB_received_20180416\aerial_25cm.jp2, band 1:
> IReadBlock failed at X offset 0, Y offset 0
> ERROR 1: GetBlockRef failed at X block offset 0, Y block
> offset 0
> ERROR 1: Marker is not compliant with its position
> ERROR 1: opj_decode() failed
> ERROR 1: J:\Spatial
> Data\Aerial\APGB_received_20180416\aerial_25cm.jp2, band 1:
> IReadBlock failed at X offset 0, Y offset 0
> ERROR 1: GetBlockRef failed at X block offset 0, Y block
> offset 0
> ERROR 1: Marker is not compliant with its position
> ERROR 1: opj_decode() failed
> ERROR 1: J:\Spatial
> Data\Aerial\APGB_received_20180416\aerial_25cm.jp2, band 1:
> IReadBlock failed at X offset 0, Y offset 0
> ERROR 1: GetBlockRef failed at X block offset 0, Y block
> offset 0
> ERROR 1: Marker is not compliant with its position
> ERROR 1: opj_decode() failed
> ERROR 1: J:\Spatial
> Data\Aerial\APGB_received_20180416\aerial_25cm.jp2, band 1:
> IReadBlock failed at X offset 0, Y offset 0
> ERROR 1: GetBlockRef failed at X block offset 0, Y block
> offset 0
> ERROR 1: Marker is not compliant with its position
> ERROR 1: opj_decode() failed
> ERROR 1: J:\Spatial
> Data\Aerial\APGB_received_20180416\aerial_25cm.jp2, band 1:
> IReadBlock failed at X offset 0, Y offset 0
> ERROR 1: GetBlockRef failed at X block offset 0, Y block
> offset 0
> ERROR 1: Marker is not compliant with its position
> ERROR 1: opj_decode() failed
> ERROR 1: J:\Spatial
> Data\Aerial\APGB_received_20180416\aerial_25cm.jp2, band 1:
> IReadBlock failed at X offset 0, Y offset 0
> ERROR 1: GetBlockRef failed at X block offset 0, Y block
> offset 0
> ERROR 1: Marker is not compliant with its position
> ERROR 1: opj_decode() failed
> ERROR 1: J:\Spatial
> Data\Aerial\APGB_received_20180416\aerial_25cm.jp2, band 1:
> IReadBlock failed at X offset 0, Y offset 0
> ERROR 1: GetBlockRef failed at X block offset 0, Y block
> offset 0
> ERROR 1: Marker is not compliant with its position
> ERROR 1: opj_decode() failed
> ERROR 1: J:\Spatial
> Data\Aerial\APGB_received_20180416\aerial_25cm.jp2, band 1:
> IReadBlock failed at X offset 0, Y offset 0
> ERROR 1: GetBlockRef failed at X block offset 0, Y block
> offset 0
> ERROR 1: Marker is not compliant with its position
> ERROR 1: opj_decode() failed
> ERROR 1: J:\Spatial
> Data\Aerial\APGB_received_20180416\aerial_25cm.jp2, band 1:
> IReadBlock failed at X offset 0, Y offset 0
> ERROR 1: GetBlockRef failed at X block offset 0, Y block
> offset 0
> ERROR 1: Marker is not compliant with its position
> ERROR 1: opj_decode() failed
> ERROR 1: J:\Spatial
> Data\Aerial\APGB_received_20180416\aerial_25cm.jp2, band 1:
> IReadBlock failed at X offset 0, Y offset 0
> ERROR 1: GetBlockRef failed at X block offset 0, Y block
> offset 0
> ERROR 1: Marker is not compliant with its position
> ERROR 1: opj_decode() failed
> ERROR 1: J:\Spatial
> Data\Aerial\APGB_received_20180416\aerial_25cm.jp2, band 1:
> IReadBlock failed at X offset 0, 

Re: [GRASS-user] Importing .tif

[Daniel Victoria]

Rich,

I copied 3 examples from the man page. The last one was:

*grass74 -c myraster.tif $HOME/grassdata/mylocation*

That's probably what you are looking for.

On Mon, Jul 16, 2018 at 4:52 PM Rich Shepard 
wrote:

> On Mon, 16 Jul 2018, Daniel Victoria wrote:
>
> > The manual [1] gives the following examples. Did you try that?
> >
> > *grass74 -c EPSG:5514:3 $HOME/grassdata/mylocation* Creates new GRASS
>
> Daniel,
>
>I've used the '-c EPSG:' option before. The issue with the DLQs is
> what EPSG code to use. Markus M pointed out that the ones shown by gdalinfo
> refer to aspects of the SRS, not the entire projection. That's why I used
> the proj.4 string, apparently under the mis-impression that it provides
> location projection information for importing raster files.
>
> 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] Importing .tif

[Daniel Victoria]

Rich,

The manual [1] gives the following examples. Did you try that?

*grass74 -c EPSG:5514:3 $HOME/grassdata/mylocation* Creates new GRASS
location with EPSG code 5514 (S-JTSK / Krovak East North - SJTSK) with
datum transformation parameters used in Czech Republic in the specified
GISDBASE *grass74 -c myvector.shp $HOME/grassdata/mylocation* Creates new
GRASS location based on georeferenced Shapefile *grass74 -c myraster.tif
$HOME/grassdata/mylocation* Creates new GRASS location based on
georeferenced GeoTIFF file

I think the last example is the one you want

Cheers
Daniel

[1] https://grass.osgeo.org/grass74/manuals/grass7.html

On Mon, Jul 16, 2018 at 3:38 PM Rich Shepard 
wrote:

> On Mon, 16 Jul 2018, Markus Metz wrote:
>
> > The proj4 string can not contain all the information present in WKT. As I
> > mentioned before, the safest is to create a new location directly from
> the
> > data to be imported, unless there is a good reason to assume that the srs
> > info in the data as reported by gdalinfo is wrong.
>
> Markus,
>
>If I don't use the proj4 string provided by gdalinfo how do I create a
> new
> location directly from the data to be imported? In the case of these DLQs
> there are four files, e.g.: *.aux, *.tfw, *.tif, and *.tif.xml.
>
>Do I type, 'r.in.gdal -c new_loc/PERMANENT' then start grass with
> 'grass75
> new_loc/PERMANENT' and run 'r.in.gdal in=/path/to/filename.tif
> out=new_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] Problem with half basins becoming fragmented using r.watershed

[Daniel Victoria]

Not sure what's going on since I've not seen this before. But have you
tried different threshold values?

On Fri, Jul 13, 2018 at 2:06 PM Erin Hanan  wrote:

> Hello,
>
> I am new to the list; please let me know if my question should be
> formatted differently.
>
> I have been running r.watershed on a large (>400 km2) basin using a 10 m
> resolution dem. I am finding that it produces some half basins that are
> either fragmented or very small (i.e., just a few pixels). This seems to
> happen mostly in areas bordering the stream, though I do sometimes get half
> basins that are also not connected to the stream. I'm attaching a zoomed in
> screen shot that illustrates some very strange sliver and fragmented basins
> that are bordering larger, more appropriately delineated half basins. In
> this case, the inappropriate basins all border the stream.
>
> I have tried running r.watershed using GRASS6.4 and GRASS7. I have also
> tried using SFD, MFD with a range of convergence values, and the -4 flag.
> These options produced different half basin delineations, but the problem
> with sliver basins and basin fragments has not gone away.
>
> I also checked the dem values for the inappropriate half basins, and they
> are very similar to the values for neighboring normal basins. So at this
> point, I'm not sure how to fix the problem. Any advice from the GRASS
> community would be greatly appreciated.
>
> Thank you,
>
> Erin
> ___
> 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] Finding EPSG code based on prj.adf; importing with v.in.gdal

[Daniel Victoria]

The prj.adf says you have a Lambert Conformal Conic. Since you are working
with data from oregon, a quick search in Spatialreference.org resulted in
this:
Oregon State Plane
http://spatialreference.org/ref/sr-org/7327/

Thake a look at the HUman readable OGC WKT. Looks the same.
I don't think there is a EPSG code for this but, as Markus wrote, you can
use r.in.gdal to create a location based on your file

Cheers
Daniel

On Thu, Jul 5, 2018 at 9:46 AM Rich Shepard 
wrote:

> On Thu, 5 Jul 2018, Markus Metz wrote:
>
> > EPSG:4019 is not the EPSG code of the SRS, but of one of its components
> > (there are 5 different EPSG codes within this SRS). The SRS itself does
> > not have an EPSG code, therefore you can create a new location with
> g.proj
> > georef= or r.in.gdal location=
>
> Markus,
>
>I wondered about 4019; most SRS reports have a legitimate EPSG code as
> the
> final one and I was uncertain about this one.
>
>So I'll have grass figure out the appropriate projection from the
> prj.adf
> file.
>
> 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] Inconsistent number of column in the table

[Daniel Victoria]

Hi Micha,

It worked! I only had to make a minor change to process all inside grass.
So for future reference, what I did was:

db.execute sql='update solos set horizonte = replace(horizonte, char(10), "
")'

I could not use the line break in the db.execute sql statement. But I found
that char(10) is the same thing [1].

Cheers
Daniel

[1] -
https://stackoverflow.com/questions/23930865/new-line-character-n-in-sqlite-concatenate

On Tue, Jul 3, 2018 at 5:53 PM Micha Silver  wrote:

>
>
> On 07/03/2018 10:39 PM, Daniel Victoria wrote:
>
> Hi list,
>
> Sorry to resurface an old problem. At the time I was able to 'circle
> around' this 'inconsistent number of column' issue. But now it came back
> (like all good problems do).
>
> Anyway, I imported a large soil map with v.in.ogr, whitout errors. But
> when I try to open the attribute table (Show attribute table in GUI
> dialog), I get an error saying "Inconsistent number of column in the
> table". The Attribute table manager then opens but I can't browse the data.
>
> v.db.select on the CLI works fine so I suspect it's a problem with special
> characters in the attribute table messing up with the attribute table GUI.
>
> The data has lots of special characters (accents) and they show up fine in
> v.db.select. But I suspect the main problem is that the attribute table has
> line breaks! Yes, someone has placed line brakes in the attribute table.
> Yikes...
>
> Any idea how to clean this attribute table? The only thing I could think
> of is opening the shapefile in R or Python and try to substitute the "\n"
> character.
>
> I think you can do this straight in sqlite (assuming your backend db for
> this vector is sqlite) using the builtin sql function replace().
> Here's an example:
>
> sqlite> create table t1 (id integer primary key, label text);
> sqlite> insert into t1 (label) values ('ab
>...>   cd');
> sqlite> insert into t1 (label) values ('xyz
>...>  abc');
> sqlite>
> sqlite> select * from t1;
> 1|ab
>   cd
> 2|xyz
>  abc
>
> Now the replace trick:
>
> sqlite> update t1 set label=replace(label, '
>...> ', '');
> sqlite> select * from t1;
> 1|ab  cd
> 2|xyz abc
> sqlite>
>
> HTH
>
>
> Cheers
> Daniel
>
> On Tue, Jan 16, 2018 at 10:13 PM Daniel Victoria <
> daniel.victo...@gmail.com> wrote:
>
>> That is probably the case.
>> Is there a way to 'sanitize' this shapefile DBF prior to v.in.ogr?
>>
>> Or the fact that v.db.select works on the CLI means that the attribute
>> table is OK. It's more a visualization problem with the GUI attribute table
>> manager.
>>
>> Thanks
>> Daniel
>>
>>
>> On Tue, Jan 16, 2018 at 6:15 PM Helmut Kudrnovsky  wrote:
>>
>>> DanielV wrote
>>> > Hi List,
>>> >
>>> > I imported a large vector shapefile into grass. v.in.ogr did not report
>>> > any
>>> > errors. However, when I try to open the attribute table (Show attribute
>>> > table in GUI dialog), I get an error saying "Inconsistent number of
>>> column
>>> > in the table". The Attribute table manager then opens but I can't
>>> browse
>>> > the data. However, table is correctly described (column names and data
>>> > type).
>>> >
>>> > From the CLI, v.db.select will print the contents of the attribute
>>> table
>>> > without any complains.
>>> >
>>> > Any idea how to troubleshoot this?
>>>
>>> are there any special characters in the table content, e.g. ' or " or ;
>>> or ,
>>> or / or \  etc?
>>>
>>>
>>>
>>> -
>>> 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
>>
>>
>
> ___
> grass-user mailing 
> listgrass-user@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/grass-user
>
>
> --
> Micha Silver
> Ben Gurion Univ.
> Sde Boker, Remote Sensing Lab
> cell: +972-523-665918
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Inconsistent number of column in the table

[Daniel Victoria]

Hi list,

Sorry to resurface an old problem. At the time I was able to 'circle
around' this 'inconsistent number of column' issue. But now it came back
(like all good problems do).

Anyway, I imported a large soil map with v.in.ogr, whitout errors. But when
I try to open the attribute table (Show attribute table in GUI dialog), I
get an error saying "Inconsistent number of column in the table". The
Attribute table manager then opens but I can't browse the data.

v.db.select on the CLI works fine so I suspect it's a problem with special
characters in the attribute table messing up with the attribute table GUI.

The data has lots of special characters (accents) and they show up fine in
v.db.select. But I suspect the main problem is that the attribute table has
line breaks! Yes, someone has placed line brakes in the attribute table.
Yikes...

Any idea how to clean this attribute table? The only thing I could think of
is opening the shapefile in R or Python and try to substitute the "\n"
character.

Cheers
Daniel

On Tue, Jan 16, 2018 at 10:13 PM Daniel Victoria 
wrote:

> That is probably the case.
> Is there a way to 'sanitize' this shapefile DBF prior to v.in.ogr?
>
> Or the fact that v.db.select works on the CLI means that the attribute
> table is OK. It's more a visualization problem with the GUI attribute table
> manager.
>
> Thanks
> Daniel
>
>
> On Tue, Jan 16, 2018 at 6:15 PM Helmut Kudrnovsky  wrote:
>
>> DanielV wrote
>> > Hi List,
>> >
>> > I imported a large vector shapefile into grass. v.in.ogr did not report
>> > any
>> > errors. However, when I try to open the attribute table (Show attribute
>> > table in GUI dialog), I get an error saying "Inconsistent number of
>> column
>> > in the table". The Attribute table manager then opens but I can't browse
>> > the data. However, table is correctly described (column names and data
>> > type).
>> >
>> > From the CLI, v.db.select will print the contents of the attribute table
>> > without any complains.
>> >
>> > Any idea how to troubleshoot this?
>>
>> are there any special characters in the table content, e.g. ' or " or ;
>> or ,
>> or / or \  etc?
>>
>>
>>
>> -
>> 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
>
>
___
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

[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

[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] Spatial data exchange formats

[Daniel Victoria]

Hi Rich,

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 beeing another vector format).

LiDAR data is obtained as XYZ point cloud. That's why you probably have
vector data. Further processing is needed to transform it to a raster
format.

Cheers
Daniel

On Mon, Jun 18, 2018 at 11:25 AM Rich Shepard 
wrote:

> On Mon, 18 Jun 2018, Daniel Victoria wrote:
>
> > Actually, your ADF file is part of a vector format from ESRI named
> > Coverage, that includes some files in a folder with the name of your data
> > and some other data in a folder called INFO. Here is some more info on
> the
> > Coverage format [1]
>
> Daniel,
>
>I thought a grid meant raster, not vector. I wonder why LiDAR data is
> presented in a vector format rather than a raster DEM. Off-hand, I don't
> know how I'll use vector maps for hydrological modeling, particularly storm
> water runoff.
>
>In the meantime, I've switched focus to munging 30 years of river stage
> height data. Still have 7 years to go. Tedious, even with emacs macros and
> awk scripts, but I'll finish this effort before returning to the
> topography.
>
> Many 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

[Daniel Victoria]

Hi Rich,

Actually, your ADF file is part of a vector format from ESRI named
Coverage, that includes some files in a folder with the name of your data
and some other data in a folder called INFO. Here is some more info on the
Coverage format [1]

GDAL OGR can handle both shape and coverage formats so you could import any
of the two. I believe it does not matter which one you choose. Just fire up
GRASS and import your vector file.

To import the Coverage, I believe in GRASS you have to select the ADF file
inside the coverage directory. To import the shapefile, just select the
file with the shp extension

Cheers
Daniel

[1] - https://support.esri.com/en/technical-article/07209



On Fri, Jun 8, 2018 at 3:15 PM Rich Shepard 
wrote:

> On Wed, 30 May 2018, Helmut Kudrnovsky wrote:
>
> > So you have to look by ogrinfo/gdalinfo --formats; you can get further
> > information on the GDAL Website.
>
>I have LiDAR files in two ESRI formats and don't know which would be the
> better one to use: .shp and .adf.
>
>My research taught me that .adf is Amiga Data File, and I thought that
> Amiga died several decades ago. Seems that ESRI is using that format for
> some reason and it does not appear to be supported by gdal.
>
>The directories with the adf files also contain .dat, .nit, and .dir
> files and come in three versions: bare earth, highest hits, and intensity.
>
>My use of these DEMs is for hydrological modeling, including storm
> runoff
> with times of concentration for specified 24-hour storm hydrographs. So, I
> want to become informed about my choices. Recommended readings also
> appreciated.
>
> Regards,
>
> 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] screenshot of old i.class interactive module ?

[Daniel Victoria]

I later noticed that the manual contains only ASCII art.

Anyway, the site http://www.dtic.mil is an archive of several reports
funded by the US Defense. And a quick search showed that there are several
GRASS related documents there, such as the 3.0 programmer manual...

On Thu, Feb 1, 2018 at 2:03 PM Moritz Lennert <mlenn...@club.worldonline.be>
wrote:

> On 01/02/18 16:42, Daniel Victoria wrote:
> > I tried to find something and was not successful. But in my Google
> > search I bumped into the Grass 4.0 users manual from 1992.
> > Don't know if it's of interest to anyone. But here goes the (quite slow)
> > link
> >
> > http://www.dtic.mil/dtic/tr/fulltext/u2/a255218.pdf
>
> Thanks to both of you. Your screenshot is perfect, Markus, thanks !
> Daniel, thanks for the link. Unfortunately, these manuals do not include
> screenshots.
>
> Moritz
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] screenshot of old i.class interactive module ?

[Daniel Victoria]

I tried to find something and was not successful. But in my Google search I
bumped into the Grass 4.0 users manual from 1992.
Don't know if it's of interest to anyone. But here goes the (quite slow)
link

http://www.dtic.mil/dtic/tr/fulltext/u2/a255218.pdf

Cheers


On Thu, Feb 1, 2018 at 1:02 PM Markus Neteler  wrote:

> On Thu, Feb 1, 2018 at 3:34 PM, Moritz Lennert
>  wrote:
> > Hi everyone,
> >
> > For our presentation at FOSDEM this Sunday I'm looking for a screenshot
> of
> > the old i.class module in action on an x-monitor. Does anyone know where
> I
> > might find one ?
>
> Please find a screenshot attached - from our GRASS GIS book (grassbook.org
> ).
> If it needs to be older, I can search further.
>
> Best,
> Markus
>
> --
> Markus Neteler, PhD
> http://www.mundialis.de - free data with free software
> http://grass.osgeo.org
> http://courses.neteler.org/blog
> ___
> 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] i.atcorr with Sentinel2

[Daniel Victoria]

It's been a while since I wrote that script. Glad to see it's still of use
:)

Anyway, I'm a bit overwhelmed so I won't be able to look at the changes
asked. But I'm glad Stefan can take a look. And I can help out in any
questions that might come up.

Cheers
Daniel

On Tue, Jan 23, 2018 at 11:50 AM Markus Metz 
wrote:

>
>
> On Tue, Jan 23, 2018 at 2:19 PM, Stefan Blumentrath <
> stefan.blumentr...@nina.no> wrote:
> >
> > OK, will give it a try.
> >
> The first part is more important because it 1) fixes the interpolation to
> 2.5 nm steps, and 2) helps iwave.cpp to load the response values.
> >
> > For the second part I am not sure if I properly understood where min –
> max wavelength for each band should be printed to.
> >
> > Do you mean to replace
> >
> > # convert limits from nanometers to micrometers
> >
> > lowerlimit = wavelengths[0]/1000
> >
> > upperlimit = wavelengths[-1]/1000
> >
> >
> >
> > Or just as a screen output?
>
> Just a screen output to help update the manual
>
> >
> > You did not mean band value limits, right?
>
> No, e.g. in the manual is
>
> Sentinel2A Coastal blue band B1 (430nm - 457nm)
>
> and this range could be printed out to screen based on the actual
> response. This range can then be copied to the manual, making life a bit
> easier for the person updating the manual.
> >
> > Not sure I am of help/useful for fixing create_iwave.py, but I`ll do my
> best…
>
> Your help is welcome!
>
> Markus M
>
> >
> > Cheers
> >
> > Stefan
> >
> >
> >
> >
> >
> > From: Markus Metz [mailto:markus.metz.gisw...@gmail.com]
> > Sent: tirsdag 23. januar 2018 13.02
> > To: Stefan Blumentrath 
> > Cc: Markus Neteler ; GRASS user list <
> grass-user@lists.osgeo.org>
> >
> >
> > Subject: Re: [GRASS-user] i.atcorr with Sentinel2
> >
> >
> >
> >
> >
> > On Tue, Jan 23, 2018 at 12:25 PM, Stefan Blumentrath <
> stefan.blumentr...@nina.no> wrote:
> > >
> > > No problem. Any chance I can contribute to maintenance of
> create_iwave.py?
> > >
> > > What needs to be done? Take your latest changes into account?
> >
> > nodata handling should be changed. In read_input(), missing values
> should be set to zero. Then for each band, leading and trailing zeros would
> be set to -1. This helps interpolate_band() to get the correct subrange.
> >
> > For each band, create_iwave.py should print out the band name and the
> wavelength as min - max. Care must be taken when finding reasonable min and
> max wavelengths: find the max response, then go back while response >
> threshold to find the min wavelength. Go forward while response > threshold
> to find the max wavelength. As threshold I suggest 0.1 to eliminate noise
> in the response values.
> >
> > Markus M
> >
> > >
> > >
> > >
> > > If you think it makes sense I will try to create a patch for adding
> S2B to i.atcorr (would be a nice exercise and does not seem too complex)?
> Will open a ticket and start working on it unless you tell me different.
> > >
> > >
> > >
> > > Cheers
> > >
> > > Stefan
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > From: grass-user [mailto:grass-user-boun...@lists.osgeo.org] On
> Behalf Of Markus Metz
> > > Sent: tirsdag 23. januar 2018 12.03
> > > To: Markus Neteler 
> > > Cc: GRASS user list 
> > > Subject: Re: [GRASS-user] i.atcorr with Sentinel2
> > >
> > >
> > >
> > >
> > >
> > > On Tue, Jan 23, 2018 at 11:51 AM, Markus Neteler <
> > > nete...@osgeo.org> wrote:
> > >
> > > >
> > > > On Tue, Jan 23, 2018 at 11:09 AM, Žofie Cimburová
> > > > <
> > > zoficimbur...@gmail.com> wrote:
> > >
> > > > > Forgot to cc the list.
> > > > >
> > > > > The CSV and the cpp template:
> > > > >
> > >
> https://www.dropbox.com/sh/9cnhsl59kvmx4o1/AABwnEVHdxfW_PqrB5Xcpczda?dl=0
> > >
> > > >
> > > > Great! Would you mind to also convert the S2A table? AFAIK it got
> > > > updated due to recalibration compared to what we currently have.
> > >
> > > please wait a bit with creating the cpp template, create_iwave.py
> needs some maintenance
> > >
> > > Markus M
> > >
> > >
> > >
> > > >
> > > > markusN
> > > > ___
> > > > 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] Calculating cost to port - now with rail

[Daniel Victoria]

Hi list,

A while ago I asked a similar question about calculating cost to port
considering a road network. I got this sorted out and results look nice.
But now I'd like to include some rail lines in the analysis.

The problem is that if I just add rail lines to my cell cost raster, the
rail lines will be treated as roads, that is, I could 'board a train'
anywhere along the rail line and not only at the stations.

I though about adding a buffer to the rail line with a very high cost (or
null value). But that would fail where roads crosses rail lines. Is it
possible to solve this using r.cost? Or do I need to use some other method,
like v.net?

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

Re: [GRASS-user] r.watershed

[Daniel Victoria]

Hi Shane,

I don't know the internals of r.watershed but your best option is to take a
look at the man page [1] and the references listed at the bottom. It
contains all the references for the algorithms used.

Cheers
Daniel
[1] - https://grass.osgeo.org/grass72/manuals/r.watershed

On Wed, Jan 17, 2018 at 3:30 PM Shane Carey  wrote:

> Hi,
>
> I was wondering if someone could tell me how r.watershed works in terms of
> creating stream network. I was of the opinion it just mapped a river from A
> to B based on the least cost search algorithm where elevation is the "cost"!
>
> However, it also calculates flow directions and flow accumulations - Are
> these just an added bonus?
>
> Thanks
>
> --
> Le gach dea ghui,
> *Shane Carey*
>
> ___
> 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] Inconsistent number of column in the table

[Daniel Victoria]

That is probably the case.
Is there a way to 'sanitize' this shapefile DBF prior to v.in.ogr?

Or the fact that v.db.select works on the CLI means that the attribute
table is OK. It's more a visualization problem with the GUI attribute table
manager.

Thanks
Daniel


On Tue, Jan 16, 2018 at 6:15 PM Helmut Kudrnovsky  wrote:

> DanielV wrote
> > Hi List,
> >
> > I imported a large vector shapefile into grass. v.in.ogr did not report
> > any
> > errors. However, when I try to open the attribute table (Show attribute
> > table in GUI dialog), I get an error saying "Inconsistent number of
> column
> > in the table". The Attribute table manager then opens but I can't browse
> > the data. However, table is correctly described (column names and data
> > type).
> >
> > From the CLI, v.db.select will print the contents of the attribute table
> > without any complains.
> >
> > Any idea how to troubleshoot this?
>
> are there any special characters in the table content, e.g. ' or " or ; or
> ,
> or / or \  etc?
>
>
>
> -
> 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
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Inconsistent number of column in the table

[Daniel Victoria]

Hi List,

I imported a large vector shapefile into grass. v.in.ogr did not report any
errors. However, when I try to open the attribute table (Show attribute
table in GUI dialog), I get an error saying "Inconsistent number of column
in the table". The Attribute table manager then opens but I can't browse
the data. However, table is correctly described (column names and data
type).

>From the CLI, v.db.select will print the contents of the attribute table
without any complains.

Any idea how to troubleshoot this?

Cheers
Daniel

PS - Running Grass 7.2.2 on Ubuntu
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Calculating cost to port

[Daniel Victoria]

Wow, that was fast. I was just about to reply the I found out I should put
the ports as starting points. And that is clearly stated in the manual

https://grass.osgeo.org/grass70/manuals/r.cost.html#shortest-distance-surfaces

Thanks all
Cheers

On Fri, Nov 10, 2017 at 2:21 PM Moritz Lennert <mlenn...@club.worldonline.be>
wrote:

> Le Fri, 10 Nov 2017 16:03:45 +,
> Daniel Victoria <daniel.victo...@gmail.com> a écrit :
>
> > Hi list,
> >
> > I want to calculate a cost of getting from any cell in my raster to
> > some ports, considering roads network, and I though r.cost could
> > solve this.
> >
> > What I have is:
> > 1) Cost raster map with cost per cell (10 for normal cells, 1 if it's
> > a road)
> > 2) vector map containing several ports
> > 3) start_raster has the same extent of the cost raster, but all cells
> > == 1
> >
> > This is the command I'm using
> > r.cost input=cost_map output=cum_cost stop_points=ports
> > start_raster=my_region
>
> Just try it with r.cost input=cost_map output=cum_cost
> start_points=ports
>
> Moritz
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Calculating cost to port

[Daniel Victoria]

Hi list,

I want to calculate a cost of getting from any cell in my raster to some
ports, considering roads network, and I though r.cost could solve this.

What I have is:
1) Cost raster map with cost per cell (10 for normal cells, 1 if it's a
road)
2) vector map containing several ports
3) start_raster has the same extent of the cost raster, but all cells == 1

This is the command I'm using
r.cost input=cost_map output=cum_cost stop_points=ports
start_raster=my_region

However, my results is a map will all values equal zero. Is it because the
stop_points in ports lay inside my start_raster? Thus r.cost reaches the
stop point right from the start?

My final result should be a map of distance to ports considering the roads
network.

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

Re: [GRASS-user] P value for slope from r.series

[Daniel Victoria]

Hi Markus M,

Thanks for your input. But one thing is still confusing me. From what I
understood, the multiple comparison problem would arise if I calculated one
p-value for all the regressions in a computational region. Say I have a 100
x 100 raster, chances are one of those 10,000 pixels would yield me a
significant regression. But in my case, I'm calculating a p-value raster
that is, each pixel has it's own p-value and I'm interested in the slopes
that have a significant trend (p <= 0.05). Thus each pixel regression is
(sort of) independent.

In essence. If I generate a raster with regression slope and p-value, and I
mask out the areas with high p (above 5%), the slope values in the
remaining regions would be significant correct? What you are saying is that
I might be overestimating the area with significant slope?

Cheers and thanks
Daniel

On Wed, Oct 18, 2017 at 6:06 PM Markus Metz <markus.metz.gisw...@gmail.com>
wrote:

>
>
> On Wed, Oct 18, 2017 at 7:19 PM, Daniel Victoria <
> daniel.victo...@gmail.com> wrote:
> >
> > I just read on the p-value regression ticket a comment from Markus Metz
> [1]. If I understood correctly, he mentions that the chances of getting
> small p-values at random is high and we should do a correction. But this
> would result in non-significant p-values. He concludes that it would be
> more "appropriate to make prior assumptions about slope, intercept, and
> effect size, then judge the results according to these prior assumptions".
> >
> > Does this means that I should not rely on the p-value obtained?
>
> Yes and no. The p-value needs to be interpreted correctly. Commonly used
> thresholds are alpha = 0.05 and alpha = 0.01. That means if p <= alpha, the
> result is statistically significant. Problems occur if you repeat the test
> with the same dataset several times:
> https://en.wikipedia.org/wiki/Multiple_comparisons_problem
>
> In these cases, alpha needs to be corrected in order to decide if a
> p-value is significant or not. Regarding r.series, millions of repeated
> tests might be performed (one for each cell in the current computational
> region). Any standard correction method would thus render pretty much all
> p-values non-significant. Instead, Bayesian statistics might be a solution.
>
> Markus M
>
> >
> > Where can I find more information about this? Some colleagues and I are
> in the process of finishing a paper that uses applies a regression to
> annual NDVI data and right now, we are discussing if we should (or not)
> consider the p-values obtained.
> >
> > Thanks and sorry if this is a bit of topic
> >
> > Cheers
> > Daniel
> >
> > [1] https://trac.osgeo.org/grass/ticket/2376#comment:3
> >
> >
> > On Mon, Oct 16, 2017 at 2:12 PM Daniel Victoria <
> daniel.victo...@gmail.com> wrote:
> >>
> >> Replying to self and in case helps anyone.
> >>
> >> Solved it by using R and the raster package. Here is a Stackoverflow
> post about it
> >>
> >>
> https://stackoverflow.com/questions/20262999/how-to-output-regression-summarye-g-p-value-and-coeff-into-a-rasterbrick
> >>
> >> Cheers
> >> Daniel
> >>
> >> On Wed, Oct 11, 2017 at 10:44 AM Daniel Victoria <
> daniel.victo...@gmail.com> wrote:
> >>>
> >>> OK, dumb question since I'm a bit (or very) bad at stats.
> >>>
> >>> I'm calculating the slope from a series of rasters using r.series. I
> see that I can also get the t-value and the coefficient of determination.
> Is there a way to get the p-value for the regression?
> >>>
> >>> I've seen that this question has been asked before (in 2012) [1] and
> it ended with the addition of the t-value calculation in r.series. But I
> failed to see how the p-value can be obtained.
> >>>
> >>> I also found this ticket [2], related to the p-value question.
> >>>
> >>> Thanks
> >>> Daniel
> >>>
> >>> [1] -
> http://osgeo-org.1560.x6.nabble.com/Calculate-p-value-for-regression-slope-in-r-series-td5014228.html
> >>>
> >>> [2]  https://trac.osgeo.org/grass/ticket/2376
> >>>
> >
> > ___
> > 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] P value for slope from r.series

[Daniel Victoria]

I just read on the p-value regression ticket a comment from Markus Metz
[1]. If I understood correctly, he mentions that the chances of getting
small p-values at random is high and we should do a correction. But this
would result in non-significant p-values. He concludes that it would be
more "appropriate to make prior assumptions about slope, intercept, and
effect size, then judge the results according to these prior assumptions".

Does this means that I should not rely on the p-value obtained?

Where can I find more information about this? Some colleagues and I are in
the process of finishing a paper that uses applies a regression to annual
NDVI data and right now, we are discussing if we should (or not) consider
the p-values obtained.

Thanks and sorry if this is a bit of topic

Cheers
Daniel

[1] https://trac.osgeo.org/grass/ticket/2376#comment:3

On Mon, Oct 16, 2017 at 2:12 PM Daniel Victoria <daniel.victo...@gmail.com>
wrote:

> Replying to self and in case helps anyone.
>
> Solved it by using R and the raster package. Here is a Stackoverflow post
> about it
>
>
> https://stackoverflow.com/questions/20262999/how-to-output-regression-summarye-g-p-value-and-coeff-into-a-rasterbrick
>
> Cheers
> Daniel
>
> On Wed, Oct 11, 2017 at 10:44 AM Daniel Victoria <
> daniel.victo...@gmail.com> wrote:
>
>> OK, dumb question since I'm a bit (or very) bad at stats.
>>
>> I'm calculating the slope from a series of rasters using r.series. I see
>> that I can also get the t-value and the coefficient of determination. Is
>> there a way to get the p-value for the regression?
>>
>> I've seen that this question has been asked before (in 2012) [1] and it
>> ended with the addition of the t-value calculation in r.series. But I
>> failed to see how the p-value can be obtained.
>>
>> I also found this ticket [2], related to the p-value question.
>>
>> Thanks
>> Daniel
>>
>> [1] -
>> http://osgeo-org.1560.x6.nabble.com/Calculate-p-value-for-regression-slope-in-r-series-td5014228.html
>>
>> [2]  https://trac.osgeo.org/grass/ticket/2376
>>
>>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] P value for slope from r.series

[Daniel Victoria]

Replying to self and in case helps anyone.

Solved it by using R and the raster package. Here is a Stackoverflow post
about it

https://stackoverflow.com/questions/20262999/how-to-output-regression-summarye-g-p-value-and-coeff-into-a-rasterbrick

Cheers
Daniel

On Wed, Oct 11, 2017 at 10:44 AM Daniel Victoria <daniel.victo...@gmail.com>
wrote:

> OK, dumb question since I'm a bit (or very) bad at stats.
>
> I'm calculating the slope from a series of rasters using r.series. I see
> that I can also get the t-value and the coefficient of determination. Is
> there a way to get the p-value for the regression?
>
> I've seen that this question has been asked before (in 2012) [1] and it
> ended with the addition of the t-value calculation in r.series. But I
> failed to see how the p-value can be obtained.
>
> I also found this ticket [2], related to the p-value question.
>
> Thanks
> Daniel
>
> [1] -
> http://osgeo-org.1560.x6.nabble.com/Calculate-p-value-for-regression-slope-in-r-series-td5014228.html
>
> [2]  https://trac.osgeo.org/grass/ticket/2376
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] P value for slope from r.series

[Daniel Victoria]

OK, dumb question since I'm a bit (or very) bad at stats.

I'm calculating the slope from a series of rasters using r.series. I see
that I can also get the t-value and the coefficient of determination. Is
there a way to get the p-value for the regression?

I've seen that this question has been asked before (in 2012) [1] and it
ended with the addition of the t-value calculation in r.series. But I
failed to see how the p-value can be obtained.

I also found this ticket [2], related to the p-value question.

Thanks
Daniel

[1] -
http://osgeo-org.1560.x6.nabble.com/Calculate-p-value-for-regression-slope-in-r-series-td5014228.html

[2]  https://trac.osgeo.org/grass/ticket/2376
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [snap pour point for r.water.outlet]

[Daniel Victoria]

I think you must use the accumulation map in the r.distance command. But
bear in mind that you don't need the accumulation map but only your
drainedge lines. Thus, you can threshold the flow accum map in order to
delineate the rivers. And that could be a bit smaller than your complete
flow accumulation map.

Cheers
Daneil

On Wed, Mar 29, 2017 at 1:24 PM Ang Sherpa <angsherpa...@gmail.com> wrote:

> Thanks Daniel,
>
> Since I am developing Grass Gis based interactive app to delineate
> watershed basin, I have to bundle those raster files along with other
> python packages. When the users installs the app, these files will be
> automatically copied and ready to use for "r.water.outlet" module through
> python script i.e. users just have to enter coordinate in the GUI.There
> will be just a single pair of coordinate at a time.
>
> My concern is that whether drainage direction raster map can be used for
> r.distance or not? Do we achieve the same result?
>
> Bundling the accumulation raster file massively increases the app setup
> file size whereas drainage direction only accounts 1/4th size of
> accumulation raster file.
>
> *Best,*
> *Ang*
>
> On Wed, Mar 29, 2017 at 9:49 PM, Daniel Victoria <
> daniel.victo...@gmail.com> wrote:
>
> Hi Ang,
>
> I had replied off list. I'm now replying to the list so other can comment
>
> The idea is that to delineate watersheds, the outlet has to lie in a place
> with high accumulation. So if you get your outlet points a bit messed up, a
> way to force them to go to the right place is to use r.distance.
>
> I don't have a specific code nor I recall the steps I've taken back in
> 2010, when I did this. But, looking at the r.distance manual [1], this is
> what I'd try if I had to repeat the process today:
>
> 1) Convert my outlet points to raster, each with a different category
> 2) Threshold your flow accumulation map in order to delineate the rivers
> (high flow accumulation)
> 3) Run r.distance to find the closest river line to each of your output
> point. Check that you don't create any points to far away from the original
> position.
> 4) Use the output of r.distance as the coordinates in r.water.outlet
>
> Cheers
> Daniel
>
> [1] - https://grass.osgeo.org/grass72/manuals/r.distance.html
>
> On Wed, Mar 29, 2017 at 12:55 PM Ang Sherpa <angsherpa...@gmail.com>
> wrote:
>
> Hi users,
>
> While using "r.water.outlet" to delineate watershed basin, although the
> coordinates of the stream was noted from google earth and fed into
> "r.water.outlet" module, it produces plain raster.
>
> Is there any solution to make sure that the coordinates of outlet point
> automatically snaps to the nearest line of stream in drainage direction map?
>
>
> Any words will be appreciated.
>
>
> *Best,*
> *Ang*
> ___
> 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] [snap pour point for r.water.outlet]

[Daniel Victoria]

Hi Ang,

I had replied off list. I'm now replying to the list so other can comment

The idea is that to delineate watersheds, the outlet has to lie in a place
with high accumulation. So if you get your outlet points a bit messed up, a
way to force them to go to the right place is to use r.distance.

I don't have a specific code nor I recall the steps I've taken back in
2010, when I did this. But, looking at the r.distance manual [1], this is
what I'd try if I had to repeat the process today:

1) Convert my outlet points to raster, each with a different category
2) Threshold your flow accumulation map in order to delineate the rivers
(high flow accumulation)
3) Run r.distance to find the closest river line to each of your output
point. Check that you don't create any points to far away from the original
position.
4) Use the output of r.distance as the coordinates in r.water.outlet

Cheers
Daniel

[1] - https://grass.osgeo.org/grass72/manuals/r.distance.html

On Wed, Mar 29, 2017 at 12:55 PM Ang Sherpa  wrote:

> Hi users,
>
> While using "r.water.outlet" to delineate watershed basin, although the
> coordinates of the stream was noted from google earth and fed into
> "r.water.outlet" module, it produces plain raster.
>
> Is there any solution to make sure that the coordinates of outlet point
> automatically snaps to the nearest line of stream in drainage direction map?
>
>
> Any words will be appreciated.
>
>
> *Best,*
> *Ang*
> ___
> 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] r.buffer not working

[Daniel Victoria]

Hi Helmut,

You are right, It's probably an out of memory problem. By reducing the
resolution, r.buffer runs without a problem.

Thanks
Daniel

On Mon, Nov 7, 2016 at 10:08 AM, Helmut Kudrnovsky  wrote:

> DanielV wrote
> > Hi List,
> >
> > Trying to run r.buffer on a map with values 1 or null (it's an
> agriculture
> > area map with only one class). I tried with multiple distances and only
> > one
> > distance and in both cases, I recieve an error that Grass 7 stoped
> working
> > and that windows will close the program.
> >
> > I'm running grass7 on Win10, installed throuhg OsGeo4W 64bit. I get the
> > same error using Grass 7.0.5 and 7.3.svn. I'm running this on a quite
> > large
> > region...
> >
> > projection: 99 (Polyconic (American))
> > zone:   0
> > datum:  towgs84=0,0,0,0,0,0,0
> > ellipsoid:  grs80
> > north:  9800010
> > south:  705
> > west:   420
> > east:   645
> > nsres:  30
> > ewres:  30
> > rows:   91667
> > cols:   75000
> > cells:  6875025000
> >
> > Anyone seen this problem?
>
> testing here on
>
> System Info
> GRASS Version: 7.3.svn
> GRASS SVN revision: r69783
> Build date: 2016-11-07
> Build platform: x86_64-w64-mingw32
> GDAL: 2.1.2
> PROJ.4: 4.9.3
> GEOS: 3.5.0
> SQLite: 3.14.1
> Python: 2.7.5
> wxPython: 2.8.12.1
> Platform: Windows-8-6.2.9200 (OSGeo4W)
>
> in the NC sample data set:
>
> g.region -p
> projection: 99 (Lambert Conformal Conic)
> zone:   0
> datum:  nad83
> ellipsoid:  a=6378137 es=0.006694380022900787
> north:  228500
> south:  215000
> west:   63
> east:   645000
> nsres:  0.2
> ewres:  0.2
> rows:   67500
> cols:   75000
> cells:  506250
>
> r.buffer --verbose input=myrast@user1 output=myrast_buffer3 distances=500
> Lese Eingabe-Rasterkarte ...
>
> here it uses quite a lot of memory, slows down the computer and it takes a
> long time to finisg ... so it's maybe an running-out-of-memory on your
> side?
>
>
>
>
> -
> best regards
> Helmut
> --
> View this message in context: http://osgeo-org.1560.x6.
> nabble.com/r-buffer-not-working-tp5294594p5294597.html
> Sent from the Grass - Users mailing list archive at Nabble.com.
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] r.buffer not working

[Daniel Victoria]

Hi List,

Trying to run r.buffer on a map with values 1 or null (it's an agriculture
area map with only one class). I tried with multiple distances and only one
distance and in both cases, I recieve an error that Grass 7 stoped working
and that windows will close the program.

I'm running grass7 on Win10, installed throuhg OsGeo4W 64bit. I get the
same error using Grass 7.0.5 and 7.3.svn. I'm running this on a quite large
region...

projection: 99 (Polyconic (American))
zone:   0
datum:  towgs84=0,0,0,0,0,0,0
ellipsoid:  grs80
north:  9800010
south:  705
west:   420
east:   645
nsres:  30
ewres:  30
rows:   91667
cols:   75000
cells:  6875025000

Anyone seen this problem?
Cheers
Daniel
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Importing MrSID files [RESOLVED]

[Daniel Victoria]

>From what I read, you should point to the .sid file. But check if your gdal
is compiled with MrSID support. A gdalinfo on the file should inform you if
your gdal install can handle such files

On Tue, Sep 20, 2016 at 4:07 PM, Rich Shepard 
wrote:

> On Tue, 20 Sep 2016, Rich Shepard wrote:
>
>  Never mind. I looked up the EPSG code and entered that directly.
>>
>
>However, I'm not finding the correct file at which to point grass.
> r.in.gdal fails because it cannot find any bands. My web searches on how to
> import a MrSID file all point me to the r.in.gdal manual page and no
> example
> there seems to apply to the files I have.
>
> Suggestions?
>
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Problem with v.edit delete tool

[Daniel Victoria]

Thanks Moritz,

v.extract did the job. The only downside is that I need to keep creating
temporary layers since I'll have to do a series of edits. But no problem.
It can be done.

Cheers
Daniel

On Wed, Aug 31, 2016 at 11:40 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> On 31/08/16 16:32, Daniel Victoria wrote:
>
>> Hi List,
>>
>> This is probably more due to my lack of understanding of how v.edit
>> works. But here it goes.
>>
>> I have a polygon vector layer where some of the polygons have a 'No
>> data' label. I'd like to delete those polygons so I ran the command,
>> with the following output:
>>
>> v.edit map=teste@isna tool=delete where="label like '%no data%'"
>> Selecting features...
>> 207 of 7200 features selected from vector map <teste@isna>
>> 207 features deleted
>> Building topology for vector map <teste@isna>...
>> Registering primitives...
>> 6993 primitives registered
>> 29546 vertices registered
>> Building areas...
>> 2195 areas built
>> 264 isles built
>> Attaching islands...
>> Attaching centroids...
>> Number of nodes: 3086
>> Number of primitives: 6993
>> Number of points: 0
>> Number of lines: 0
>> Number of boundaries: 5017
>> Number of centroids: 1976
>> Number of areas: 2195
>> Number of isles: 264
>> v.edit complete.
>>
>> After that, the offending polygons where deleted however, their
>> boundaries are still present. That is, when I load the vector in the map
>> display, I still see the boundaries in some polygons, even though the
>> area is not filled. Is this the intended behavior? I tried using the
>> areadel tool but then the whong polygon was deleted. I'm guessing the
>> shared boundary of a valid polygon was removed and his caused problems.
>>
>> Attached is a sample of what I'm seeing after v.edit delete
>>
>>
> Attributes of areas are linked to the centroid of the area. So the
> features you select through your query are these centroids, not the
> boundaries.
>
> It would probably be nice to have a type=area option in v.edit.
>
> To get the same result, you could use v.extract -r type=area.
>
> Moritz
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Problem with v.edit delete tool

[Daniel Victoria]

Oops, forgot to mention I'm using Grass 7.0.4 from OSGeo4Win 64 bits

On Wed, Aug 31, 2016 at 11:32 AM, Daniel Victoria <daniel.victo...@gmail.com
> wrote:

> Hi List,
>
> This is probably more due to my lack of understanding of how v.edit works.
> But here it goes.
>
> I have a polygon vector layer where some of the polygons have a 'No data'
> label. I'd like to delete those polygons so I ran the command, with the
> following output:
>
> v.edit map=teste@isna tool=delete where="label like '%no data%'"
> Selecting features...
> 207 of 7200 features selected from vector map <teste@isna>
> 207 features deleted
> Building topology for vector map <teste@isna>...
> Registering primitives...
> 6993 primitives registered
> 29546 vertices registered
> Building areas...
> 2195 areas built
> 264 isles built
> Attaching islands...
> Attaching centroids...
> Number of nodes: 3086
> Number of primitives: 6993
> Number of points: 0
> Number of lines: 0
> Number of boundaries: 5017
> Number of centroids: 1976
> Number of areas: 2195
> Number of isles: 264
> v.edit complete.
>
> After that, the offending polygons where deleted however, their boundaries
> are still present. That is, when I load the vector in the map display, I
> still see the boundaries in some polygons, even though the area is not
> filled. Is this the intended behavior? I tried using the areadel tool but
> then the whong polygon was deleted. I'm guessing the shared boundary of a
> valid polygon was removed and his caused problems.
>
> Attached is a sample of what I'm seeing after v.edit delete
>
> Thanks
> Daneil
> [image: Inline image 1]
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Problem with v.edit delete tool

[Daniel Victoria]

Hi List,

This is probably more due to my lack of understanding of how v.edit works.
But here it goes.

I have a polygon vector layer where some of the polygons have a 'No data'
label. I'd like to delete those polygons so I ran the command, with the
following output:

v.edit map=teste@isna tool=delete where="label like '%no data%'"
Selecting features...
207 of 7200 features selected from vector map 
207 features deleted
Building topology for vector map ...
Registering primitives...
6993 primitives registered
29546 vertices registered
Building areas...
2195 areas built
264 isles built
Attaching islands...
Attaching centroids...
Number of nodes: 3086
Number of primitives: 6993
Number of points: 0
Number of lines: 0
Number of boundaries: 5017
Number of centroids: 1976
Number of areas: 2195
Number of isles: 264
v.edit complete.

After that, the offending polygons where deleted however, their boundaries
are still present. That is, when I load the vector in the map display, I
still see the boundaries in some polygons, even though the area is not
filled. Is this the intended behavior? I tried using the areadel tool but
then the whong polygon was deleted. I'm guessing the shared boundary of a
valid polygon was removed and his caused problems.

Attached is a sample of what I'm seeing after v.edit delete

Thanks
Daneil
[image: Inline image 1]
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] OSGeo4 WWinGrass and msys

[Daniel Victoria]

Worked like a charm. Thanks Martin

On Tue, Apr 5, 2016 at 9:00 AM, Martin Landa <landa.mar...@gmail.com> wrote:

> Hi,
>
> 2016-04-05 13:43 GMT+02:00 Daniel Victoria <daniel.victo...@gmail.com>:
> > I'm using Grass 7.0.3 (64 bit) installed from OSGeo4W package. I noticed
> > that the command line interface that winGrass uses is windowss CMD. But
> I'd
> > like to be able to use some bash shell syntax, like using g.list as
> input to
> > r.series. Is there a way to use MSys as the Grass 7 command line
> interface?
>
> yes, add to your apps/grass/grass7.0.3/etc/env.bat file:
>
> set GRASS_SH=%OSGEO4W_ROOT%\apps\msys\bin\sh.exe
>
> Ma
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] OSGeo4 WWinGrass and msys

[Daniel Victoria]

Hi list,

I'm using Grass 7.0.3 (64 bit) installed from OSGeo4W package. I noticed
that the command line interface that winGrass uses is windowss CMD. But I'd
like to be able to use some bash shell syntax, like using g.list as input
to r.series. Is there a way to use MSys as the Grass 7 command line
interface?

Thanks
Daniel
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] i.atcorr returning empty raster and not respecting input parameters [WAS: i.atcorr - segfault on OSX]

[Daniel Victoria]

Hi Carlos,

>From the manual [1], the 0-255 rescaling is default. So I believe if you
want to use some other rescaling, you have to do it manually. To be honest,
I never understood what are the best options to use in the rescale
parameter. I imagine the 0-255 is reminiscent from the 8-bit images. So
what about higher bit images. Should we use other rescaling factors?



[1]: https://grass.osgeo.org/grass71/manuals/i.atcorr.html

On Mon, Mar 21, 2016 at 11:40 AM, Carlos Grohmann <carlos.grohm...@gmail.com
> wrote:

> Thanks Daniel!
>
> That was really dumb of not double-checking the input parameters..
>
> Now another problem: the resulting image is empty! r.info returns "min =
> nan  max = nan".
>
> I tried with radiance and reflectance as inputs. One thing that I realized
> is that, even though I'm not setting it to rescale the output range, it's
> doing it:
>
>  |   Comments:
>|
>  |i.atcorr --overwrite --verbose -r
> input="ast_18560.01.toa_reflectanc\   |
>  |e@lateritas" range=0,255 elevation="srtm_xingu_3sec@lateritas"
> param\   |
>  |
>  eters="/Volumes/MacintoshHD2/Dropbox/USP/projetosPesquisa/Xingu_late\   |
>  |ritas/aster/params6s_ast_18560.txt"
> output="ast_18560.01.toa_reflect\   |
>  |ance_atcorr_6s" rescale=0,255
>
> Here I didn't set neither range nor rescale (left them blank), but
> apparently the command is not respecting my choices. bug detected?
>
> After this I tried setting the input range and rescale options, but
> without success. Still an empty raster...
>
> best
>
> Carlos
>
>
>
>
>
> On Mon, Mar 21, 2016 at 8:54 AM, Daniel Victoria <
> daniel.victo...@gmail.com> wrote:
>
>> Carlos,
>>
>> The aerosol model is the 4th line in the parameter file. You have set the
>> aerosol model to 15. But in the i.atcor manual, the values range from 0 to
>> 11. Could that be the problem? i.atcor issues an unknown aerosol model
>> warning and assumes you are trying to enter aerosol models by hand. Hence
>> it sets your visibility to -0.1 (ground altitude) and other parameters
>> wrong.
>>
>> Cheers
>> Daniel
>>
>>
>>
>>
>> On Fri, Mar 18, 2016 at 4:49 PM, Carlos Grohmann <
>> carlos.grohm...@gmail.com> wrote:
>>
>>> Hi all.
>>>
>>> I'm trying to run some atmospheric correction of ASTER images. First I
>>> calculated radiance and reflectance (with my own script, not
>>> i.aster.toar).  I've tried with radiance and reflectance as input, but both
>>> end up in a segfault.. the parameters file has this content:
>>>
>>> 10
>>> 6 22 13.99 -51.931 -3.355
>>> 1
>>> 15
>>> -0.100
>>> -1000
>>> 72
>>>
>>>
>>> and this is the call to i.atcorr and the error:
>>> (region is defined to the raster)
>>>
>>>  i.atcorr --overwrite --verbose input=ast_18560.01.radiance
>>> elevation=srtm_xingu_3sec parameters=params6s_ast_18560.txt
>>> output=ast_18560.01.radiance_atcorr
>>>
>>> WARNING: Unknown aerosol model!
>>>  wavelength  less  than  0.25  micron:
>>>  let's take s(l)=s(0.25)
>>>
>>>
>>>
>>> * ** 6s version 4.2b
>>> ** *
>>> *geometrical conditions identity
>>>*
>>> *---
>>>*
>>> *ASTERobservation
>>> *
>>> *
>>> *
>>> *month: 6 day: 22
>>>*
>>> *solar zenith angle:   34.61 deg  solar azimuthal angle:   38.12
>>> deg   *
>>> *view zenith angle: 0.00 deg  view azimuthal angle: 0.00
>>> deg   *
>>> *scattering angle:145.39 deg  azimuthal angle difference:  38.12
>>> deg   *
>>> *
>>> *
>>> *atmospheric model description
>>>*
>>> *-
>>>*
>>> *atmospheric model identity :
>>> *
>>> *tropical(uh2o=4.12g/cm2,uo3=.247cm-atm)
>>>*
>>> *
>>> *
>>> *aerosols type identity :
>>> *
>>> * user defined aerosols model
>>> *
>>> *
>>> *
>>> *optical condition identity 

Re: [GRASS-user] r.out.gdal in GRASS 7.0 beta (windows OS) fails to export merged coloured-shade tiff

[Daniel Victoria]

Is your elevation raster (in Grass) a single band or a 3 band composite?
It looks as though you have a single band elevation raster in Grass that
has some nice colortable and, when you open it in ArcMap, you loose the
colotable information (it's not in the tif file). Have you tried changing
the color properties in ArcMap (layer properties / symbolizer - I think)?

Daniel

On Wed, Jan 13, 2016 at 12:55 PM, Rengifo Ortega  wrote:

> Hei Martin... you are right. I just  got confused since I still have a
> beta version installed.
>
> [image: Bild einbinden]
>
> ERRATA: GRASS 7.0.0 is what I am using.
> Rengifo
>
>
>
>
> Martin Landa  schrieb am 15:49 Mittwoch,
> 13.Januar 2016:
>
>
> Hi,
>
> 2016-01-13 15:41 GMT+01:00 Rengifo Ortega :
> > Ps: below some details om my  grass 7.0.0 beta version. Installed using
> > OsGeo4W installer.
> >
> > Welcome to GRASS GIS 7.0.0
> > GRASS GIS homepage:  http://grass.osgeo.org
> > This version running through:Command Shell
> > (C:\Windows\system32\cmd.
> > exe)
> > Help is available with the command:  g.manual -i
> > See the licence terms with:  g.version -c
> > If required, restart the GUI with:  g.gui wxpython
> > When ready to quit enter:exit
> >
> > Launching  GUI in the background, please wait...
> > Microsoft Windows [Versjon 6.1.7601]
> > Copyright (c) 2009 Microsoft Corporation. Med enerett.
>
>
> I don't see any "beta" here, it seems to be version 7.0.0. Martin
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
>
>
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Regarding Atmospheric Correction Model Output

[Daniel Victoria]

Dir you try to do a color balance on the corrected images? It's been a
while since I've done this but I believe i.colors.enhance should do it.
https://grass.osgeo.org/grass70/manuals/i.colors.enhance.html

On Sun, Nov 15, 2015 at 12:57 AM, iat bd  wrote:

> Date: November 15, 2015
>
>
> Hi All,
>
>
> Following are my procedure, observation and question/ request:
>
>
> Data Source: Earth Explorer Landsat 8
>
> Grass GIS Version: 7.0.2 RC1
>
> Windows 7 32 bit OS
>
>
> I have been trying to conduct an Atmospheric correction using the Grass
> wiki reference
>
> https://grasswiki.osgeo.org/wiki/Atmospheric_correction
>
> https://grass.osgeo.org/grass64/manuals/i.atcorr.html
>
> https://grass.osgeo.org/grass64/manuals/i.landsat.toar.html
>
>
> Step 01:
>
>
> I skipped using the Toar Tool and used Raster map calculator to generate
>
> a). Reflectance = REFLECTANCE_MULT_BAND_X*DN + REFLECTANCE_ADD_BAND_X
>
> b). Reflectance with correction of sun angle = Reflectance/ Sin(Ɵ)
>
>
> Step 02:
>
>
> Plugged in to i.atcorr the Reflectance bands generated at Step 01 for band
> 4, 3, 2 amd 8 along with their respective control file.
>
>
> Step 03: IHS Pan Sharpened band 4,3,2 with band 8
>
>
> Step 04: Generated a RGB composite using Red = band 4, Green = band 3 and
> Blue = band 2.
>
>
> I am attaching the resultant image and original unadjusted 432 composites
> for comparison. Obviously, I missed something. Atmospherically adjusted
> Image should’ve been clearer. Its not even looking like an RGB image.
>
>
> Also attaching the Command outputs so that you may follow my steps, to
> notice if there was anything unusual and a control file for reference. I
> used Tropical Atmospheric model and Urban Aerosol model. The values used in
> the control file were collected from Atmospheric correction wiki.
>
>
> I’ll appreciate it if anyone of you can share your insight and tell me how
> I can get a correct atmospherically adjusted image. Also, I noticed there
> is no longer any i.landsat.dehaze extension available. Could you please
> tell me how dehazing may be possible absent the extension?
>
>
> Do let me know if there is anything missing or not clearly explained.
>
>
>
> Thanks in advance.
>
>
>
> Regards,
>
>
>
> Imtiaz
>
>
>
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] thematic map legend text not shown

[Daniel Victoria]

I've  had some problems with legend text in grass gui. I fixed it by
setting the font explicitly (Arial for example). Not sure if it's your case
since I was using the gui to create the legend. But worth a try.

Cheers
Daniel
On Jul 16, 2015 4:22 AM, henk witte henk.wi...@groenholland.nl wrote:

  Dear All,



 I am running GRASS 7.0



 I have been using GRASS GIS for a short time now but am impressed with the
 possibilities. However, I may have run into a problem. I have created a
 thematic map (d.vect.thematic) and saved the legend. I then use d.graph to
 display the legend. The class colors show up fine, but the accompanying
 text is not displayed. I have been playing around with d.graph, manually
 trying to draw text, but I cannot get any text to display.



 The legend file looks like:



 size 8 8

 symbol basic/box 25 5 10 black 255:255:204

 move 8 9

 text 0.00 - 0.308333 | 133

 symbol basic/box 25 5 16 black 217:240:163

 move 8 15

 text 0.308333 - 0.616667 | 282

 symbol basic/box 25 5 22 black 173:221:142

 move 8 21

 text 0.616667 - 0.925000 | 114

 symbol basic/box 25 5 28 black 120:198:121

 move 8 27

 text 0.925000 - 1.23 | 92

 symbol basic/box 25 5 34 black 49:163:84

 move 8 33

 text 1.23 - 1.541667 | 0

 symbol basic/box 25 5 40 black 0:104:55

 move 8 39

 text 1.541667 - 1.85 | 2



 I have also tried, for instance:

 color black

 size 20

 move 10 50

 text ThequickbrownfoxThequickbrownfox

 draw 100 10



 Here I try to draw some big text. I also draw a line (which displays
 fine), the idea being that the start of the line should change if I make
 the text longer. However, the line always starts at the same position.



 I hope someone knows a solution!



 Thanks,



 Henk Witte

 Groenholland Geo-energysystems

 Valschermkade 26

 1059CD Amsterdam



 T: +31 (0)20 6159050

 M: +31 (0)628176535

 E: henk.wi...@groenholland.nl



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

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

Re: [GRASS-user] thematic map legend text not shown

[Daniel Victoria]

Forwarding to the list. Is this something that needs fixing?
On Jul 22, 2015 7:50 AM, henk witte henk.wi...@groenholland.nl wrote:

  Thanks for the suggestion. I actually found the same solution and it
 does solve the problem.



 Thanks again



 Henk Witte



 *From:* Daniel Victoria [mailto:daniel.victo...@gmail.com]
 *Sent:* 22 July 2015 12:23
 *To:* henk witte
 *Cc:* grass
 *Subject:* Re: [GRASS-user] thematic map legend text not shown



 I've  had some problems with legend text in grass gui. I fixed it by
 setting the font explicitly (Arial for example). Not sure if it's your case
 since I was using the gui to create the legend. But worth a try.

 Cheers
 Daniel

 On Jul 16, 2015 4:22 AM, henk witte henk.wi...@groenholland.nl wrote:

  Dear All,



 I am running GRASS 7.0



 I have been using GRASS GIS for a short time now but am impressed with the
 possibilities. However, I may have run into a problem. I have created a
 thematic map (d.vect.thematic) and saved the legend. I then use d.graph to
 display the legend. The class colors show up fine, but the accompanying
 text is not displayed. I have been playing around with d.graph, manually
 trying to draw text, but I cannot get any text to display.



 The legend file looks like:



 size 8 8

 symbol basic/box 25 5 10 black 255:255:204

 move 8 9

 text 0.00 - 0.308333 | 133

 symbol basic/box 25 5 16 black 217:240:163

 move 8 15

 text 0.308333 - 0.616667 | 282

 symbol basic/box 25 5 22 black 173:221:142

 move 8 21

 text 0.616667 - 0.925000 | 114

 symbol basic/box 25 5 28 black 120:198:121

 move 8 27

 text 0.925000 - 1.23 | 92

 symbol basic/box 25 5 34 black 49:163:84

 move 8 33

 text 1.23 - 1.541667 | 0

 symbol basic/box 25 5 40 black 0:104:55

 move 8 39

 text 1.541667 - 1.85 | 2



 I have also tried, for instance:

 color black

 size 20

 move 10 50

 text ThequickbrownfoxThequickbrownfox

 draw 100 10



 Here I try to draw some big text. I also draw a line (which displays
 fine), the idea being that the start of the line should change if I make
 the text longer. However, the line always starts at the same position.



 I hope someone knows a solution!



 Thanks,



 Henk Witte

 Groenholland Geo-energysystems

 Valschermkade 26

 1059CD Amsterdam



 T: +31 (0)20 6159050

 M: +31 (0)628176535

 E: henk.wi...@groenholland.nl




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


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

Re: [GRASS-user] [GRASS-dev] QGIS GRASS Plugin Upgrade Crowdfunding

[Daniel Victoria]

Hi Radim,

I'm using grass 7 and QGis installed from OSGeo4Win so maybe it was
compiled against some old libraries? I've no idea how to compile in windows
so I'll just try to re-install everything and hope things work...

Daniel

On Tue, Mar 24, 2015 at 4:18 PM, Radim Blazek radim.bla...@gmail.com
wrote:

 On Tue, Mar 24, 2015 at 5:31 PM, Daniel Victoria
 daniel.victo...@gmail.com wrote:
  Hi Radim,
 
  Is this why my QGis crashes when i try to load a Grass 7.0 vector file?
 [1]

 AFAIC, it should only crash if you try to open a GRASS mapset with
 GRASS 6 vectors in QGIS browser compiled and run with GRASS 7
 provider. It is described here:
 http://lists.osgeo.org/pipermail/qgis-user/2015-March/031177.html

 I think that I know already what the problem is. If GRASS 7 lib is
 tries to open a vector which it is not in format 7, it calls
 G_fatal_error(), which normally opens a warning dialog. Because items
 in the browser are populated in threads, it happens on non GUI thread,
 but to open a dialog with an icon, it has to use QIcon which can only
 be used on GUI thread.


 Radim


  Thanks
  Daniel
 
  [1] -
 
 http://gis.stackexchange.com/questions/138477/loading-grass-7-0-vectors-in-qgis-broken
 
  On Tue, Mar 24, 2015 at 11:47 AM, Vaclav Petras wenzesl...@gmail.com
  wrote:
 
  On Tue, Mar 24, 2015 at 5:56 AM, Radim Blazek radim.bla...@gmail.com
  wrote:
 
   Are there functions in time series implementation which need to be
   called directly from the plugin or everything may be done just
 calling
   t.rast.* modules?
  
   Most of the temporal functionality is available through the temporal
   modules. However some important algorithms (temporal re-sampling) are
   available only in the Python framework. This is needed for time
 series
   animation creation. Using the framework directly will speed things
 up,
   because the module calls, the parsing and interpretation of the
 module
   outputs can be avoided.
 
  If it should be used for dynamic animation in QGIS canvas you could
  consider the possibility to subclass raster renderer in Python and
  insert it into raster layer pipe from Python plugin.
 
 
  Speaking about animations, some things from GRASS GIS GUI could be
 perhaps
  used directly in the same was as Tcl/Tk NVIZ is used in processing for
 GRASS
  6. Animation tool is one of them. This would be great since we would
 get al
  least some functionality/code sharing between GRASS and QGIS GUIs which
 is
  otherwise not possible due to Python/wxPython and C++/Qt (and would be
 only
  possible if both things would be at least in the same language).
 
  This is of course not fulfilling the requirement to be general, i.e.
 work
  with other data providers in QGIS, but surely some things just have to
 be
  like that if they are using GRASS-specific formats (temporal data) or
  algorithms (e.g. algorithms to work with temporal data, their topology,
  ...).
 
  Vaclav
 
  ___
  grass-user mailing list
  grass-user@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/grass-user
 
 

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

Re: [GRASS-user] [GRASS-dev] QGIS GRASS Plugin Upgrade Crowdfunding

[Daniel Victoria]

Hi Radim,

Is this why my QGis crashes when i try to load a Grass 7.0 vector file? [1]

Thanks
Daniel

[1] -
http://gis.stackexchange.com/questions/138477/loading-grass-7-0-vectors-in-qgis-broken

On Tue, Mar 24, 2015 at 11:47 AM, Vaclav Petras wenzesl...@gmail.com
wrote:

 On Tue, Mar 24, 2015 at 5:56 AM, Radim Blazek radim.bla...@gmail.com
 wrote:

  Are there functions in time series implementation which need to be
  called directly from the plugin or everything may be done just calling
  t.rast.* modules?
 
  Most of the temporal functionality is available through the temporal
  modules. However some important algorithms (temporal re-sampling) are
  available only in the Python framework. This is needed for time series
  animation creation. Using the framework directly will speed things up,
  because the module calls, the parsing and interpretation of the module
  outputs can be avoided.

 If it should be used for dynamic animation in QGIS canvas you could
 consider the possibility to subclass raster renderer in Python and
 insert it into raster layer pipe from Python plugin.


 Speaking about animations, some things from GRASS GIS GUI could be perhaps
 used directly in the same was as Tcl/Tk NVIZ is used in processing for
 GRASS 6. Animation tool is one of them. This would be great since we would
 get al least some functionality/code sharing between GRASS and QGIS GUIs
 which is otherwise not possible due to Python/wxPython and C++/Qt (and
 would be only possible if both things would be at least in the same
 language).

 This is of course not fulfilling the requirement to be general, i.e. work
 with other data providers in QGIS, but surely some things just have to be
 like that if they are using GRASS-specific formats (temporal data) or
 algorithms (e.g. algorithms to work with temporal data, their topology,
 ...).

 Vaclav

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

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

[GRASS-user] v.out.ogr dialog ask for user to type entire output path

[Daniel Victoria]

Hi List,

Just an observation and an improvement idea.
I'm exporting some vector files with v.out.ogr (Grass 7.0 on Win7)

In the 'Name of output OGR datasource' field, the user has to type the
entire path, which some times can be quite long. Of course I can copy/paste
the output path but couldn't we have a directory or file chooser dialog
there?

Cheers
Daniel
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] v.what.vect interface listing table columns from wrong layer

[Daniel Victoria]

Hi all,

Using Grass7 n wndows (osgeo4win).

I'm running v.what.vect and in the GUI, when I select the query column, the
columns shows are the ones from the layer to be update and not from the
query layer.

I can run the command correctily if I type the correct query column name.
It's just the dropdown list that is incorrect.

Cheers
Daniel
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Syncronizing two displays

[Daniel Victoria]

Hi Markus,

Thanks, g.gui.mapswipe seems very nice. I just haven't been able to use it
because it's not loading my data. I'm trying to use it for comparing vector
networks (31 thousand lines). I can load the left layer but when I try to
load the right layer, the dialogs just won't respond.

Does g.gui.swipe works vectors?
I'm using Grass 7 from OSGeo4Win

Thanks
Daniel

On Tue, Mar 3, 2015 at 9:29 AM, Markus Neteler nete...@osgeo.org wrote:

 On Tue, Mar 3, 2015 at 1:18 PM, Daniel Victoria
 daniel.victo...@gmail.com wrote:
  Is there a way to link two map displays in grass so that when I zoom into
  one display, the other follows? This would be very usefull for comparing
  raster and vector data, for instance.

 For example, the g.gui.mapswipe does this.

 Markus

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

Re: [GRASS-user] v.net tools with polygons

[Daniel Victoria]

Hi Mark,

Thanks for your tips. The use of a regular lattice is very interesting. But
I won't need anything that fancy so v.net.iso will most likely fill my
needs. I'm particularly interested in what you said about capacity
limitations and transport costs. How would you go about modeling that?
Change the node costs?

Thanks
Daniel

On Wed, Mar 4, 2015 at 8:03 AM, Mark Wynter m...@dimensionaledge.com
wrote:

 Just recalling the v.net techniques I used on a mining project a year ago
 where we had to optimize the infrastructure build and operational logistics
 for over 2000 drill sites, feeding several downstream processing plants.

 V.net.distance in reverse will do what you need if each trip is being made
 independently (farmers act as individual agents and cart their own goods to
 the processing plant).

 If a transport haulage firm calls on multiple farms as part of the same
 trip, then traveling sales person might be relevant to your needs.

 Situations may also arise where you need to use v.net.spanningtree or
 Steiner.  For example, if you need to build roads or pipelines connecting
 various facilities, or supply aggregation points, then this problem needs
 to be solved, before you apply v.net.distance, or v.net.iso which assume
 the network infrastructure is already built.

 If the network infrastructure is already built, and the agents act
 independently with no supply chain aggregation, then V.net.iso is an
 alternative to v.net.distance if all you need is the travel cost contours
 radiating out from the processing plants and not the route paths
 themselves. if you have numerous processing plants, you can run v.net.iso
 for each plant. Then you combine cost surfaces by taking the plant with the
 least cost value, giving you a minimum cost surface.

 With v.net.iso, your decision model doesn't  always have to assume the
 farmer will choose the plant with the lowest transport cost. It pays to
 keep each v.net.iso cost surface, because sometimes plants have capacity
 limitations - in which case agents may choose to incur a higher transport
 cost and still be profit maximizing.  the v.net.iso approach allows you to
 consider the economics of lots of different processing plant and network
 configuration scenarios without having to always re-run v.net.distance
 every time.

 Sorry if this sounds overwhelming - but v.net should give you all the
 tools you need. It's a case of knowing what tool for what job.  My advice
 is to be really clear on your modeling assumptions that underlie each
 method.

 Sing out if you want to test your methodology on me. Just email me..

 - mark

 Sent from my iPhone

  On 4 Mar 2015, at 7:48 am, Mark Wynter m...@dimensionaledge.com wrote:
 
  Hi Daniel,
 
  I've done something similar - I call it off road routing, and uses a
 regular lattice of nodes and arcs. You can then constrain the off road
 network by closing arcs that cross major watercourses, fence lines or
 where the terrain or vegetation is non navigatable. For farms, I added
 paddock boundaries as rings, as well as gate nodes that constrain movement
 between paddocks. In essence you build a network topology that reflects the
 off-road aspect of your network.  Relevant to mining as well as agriculture.
 
 
 
  Ok Moritz,
 
  Thanks for the tips. I'll try to go the centroids way
 
  Cheers
  Daniel
 
  On Tue, Mar 3, 2015 at 5:35 AM, Moritz Lennert 
 mlenn...@club.worldonline.be
  wrote:
 
  On 02/03/15 21:39, Daniel Victoria wrote:
 
  Hi list,
 
  I'm beginning to learn and use the v.net http://v.net tools in
 Grass
  in order to evaluate the distance from several crop fields to a
  processing plant.
 
  I've successfully build the road network with the end nodes but now
 I'm
  in doubt. My starting points in the analysis are crop fields, which
 are
  polygons. So what is the best (or most common) practice?
 
  1) Use the field centroids as starting nodes?
  2) Add field polygon boundaries to the network and run v.net.distance
  backwards (from mill to fields)?
  3) Some other option?
 
 
  I don't think that there is a best practice for this. It all depends on
  your application and the desired outcome. Do you want average
 time/distance
  from anywhere in the field to the plant ? Then probably the centroid
 is ok.
  Or do you want distance from the point of the field that is closest to
 the
  network ? Then you could get the coordinates of that point through
  v.distance (with upload=to_x,to_y) and use these points as nodes.
 
 
 
  Also, if I'm to add the field boundaries to the network, how would I go
  about it? Should I first v.patch the field with the roads layer and
 then
  run v.net http://v.net?
 
  Adding field boundaries still does not answer the question of where to
 put
  the start/stop point of your paths...
 
  If you want to add them to the network then yes, patching would be the
  best option, AFAIK.
 
  Moritz
 
  *

___
grass-user mailing list

Re: [GRASS-user] v.net tools with polygons

[Daniel Victoria]

Ok Moritz,

Thanks for the tips. I'll try to go the centroids way

Cheers
Daniel

On Tue, Mar 3, 2015 at 5:35 AM, Moritz Lennert mlenn...@club.worldonline.be
 wrote:

 On 02/03/15 21:39, Daniel Victoria wrote:

 Hi list,

 I'm beginning to learn and use the v.net http://v.net tools in Grass
 in order to evaluate the distance from several crop fields to a
 processing plant.

 I've successfully build the road network with the end nodes but now I'm
 in doubt. My starting points in the analysis are crop fields, which are
 polygons. So what is the best (or most common) practice?

 1) Use the field centroids as starting nodes?
 2) Add field polygon boundaries to the network and run v.net.distance
 backwards (from mill to fields)?
 3) Some other option?



 I don't think that there is a best practice for this. It all depends on
 your application and the desired outcome. Do you want average time/distance
 from anywhere in the field to the plant ? Then probably the centroid is ok.
 Or do you want distance from the point of the field that is closest to the
 network ? Then you could get the coordinates of that point through
 v.distance (with upload=to_x,to_y) and use these points as nodes.



  Also, if I'm to add the field boundaries to the network, how would I go
 about it? Should I first v.patch the field with the roads layer and then
 run v.net http://v.net?


 Adding field boundaries still does not answer the question of where to put
 the start/stop point of your paths...

 If you want to add them to the network then yes, patching would be the
 best option, AFAIK.

 Moritz


 Thanks
 Daniel


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




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

[GRASS-user] Syncronizing two displays

[Daniel Victoria]

Is there a way to link two map displays in grass so that when I zoom into
one display, the other follows? This would be very usefull for comparing
raster and vector data, for instance.

Cheers

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

[GRASS-user] v.net tools with polygons

[Daniel Victoria]

Hi list,

I'm beginning to learn and use the v.net tools in Grass in order to
evaluate the distance from several crop fields to a processing plant.

I've successfully build the road network with the end nodes but now I'm in
doubt. My starting points in the analysis are crop fields, which are
polygons. So what is the best (or most common) practice?

1) Use the field centroids as starting nodes?
2) Add field polygon boundaries to the network and run v.net.distance
backwards (from mill to fields)?
3) Some other option?

Also, if I'm to add the field boundaries to the network, how would I go
about it? Should I first v.patch the field with the roads layer and then
run v.net?

Thanks
Daniel
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Lost in encoding problem, v.in.ogr

[Daniel Victoria]

Thanks Ana,

Setting the attributes / encoding to windows-1252 fixed the query results
windows problem. But as you mentioned, it did not help with the Attribute
table manager.

Also, v.db.select works from the command console in the layer manager but
it does not work in the windows command line

Cheers
Daneil

On Fri, Feb 27, 2015 at 12:16 AM, Anna Petrášová kratocha...@gmail.com
wrote:



 On Thu, Feb 26, 2015 at 1:35 PM, Daniel Victoria 
 daniel.victo...@gmail.com wrote:

 Hi List,

 I'm having trouble importing a shapefile with v.in.ogr that has some
 accented characters (like não, rodoviária).
 The shapefile opend fine in QGIS and I can open the dbf on libreoffice,
 setting the encoding to (windows-1252/winlatin 1).
 I imported the shapefile and if I run v.db.select or if I open the
 attribute data, accented characters are messed up. However, when I try to
 query the layer, an error message (png attached) will show telling me to
 check database settings and then gives me the reason for the failure. I can
 then see that the queried attributes in this windows all have the accented
 character.

 Has anyone had any luck with accented characters in v.in.ogr? I tried
 changing the encoding option in v.in.ogr but could not get it to work.
 I'm using grass7 from OSGeo4Win. Attached is the shapefile that I'm
 trying to import.


 Try to specify the encoding in GUI settings - Attributes - encoding -
 windows-1252.
 But it probably won't help with displaying in Attribute table manager.

 To developers:
 I am totally confused how the attribute encoding is currently implemented.
 The ATM fails to display the characters correctly since environmental
 variable GRASS_DB_ENCODING is not set. I can't find any place where it
 would be set. The list of grass variable says that there is GRASS gisenv
 variable GRASS_DB_ENCODING. Grep shows usage of GRASS_DB_ENCODING only in
 gui and it is not set anywhere. Any idea someone?

 Anna


 Thanks
 Daniel

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



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

[GRASS-user] Lost in encoding problem, v.in.ogr

[Daniel Victoria]

Hi List,

I'm having trouble importing a shapefile with v.in.ogr that has some
accented characters (like não, rodoviária).
The shapefile opend fine in QGIS and I can open the dbf on libreoffice,
setting the encoding to (windows-1252/winlatin 1).
I imported the shapefile and if I run v.db.select or if I open the
attribute data, accented characters are messed up. However, when I try to
query the layer, an error message (png attached) will show telling me to
check database settings and then gives me the reason for the failure. I can
then see that the queried attributes in this windows all have the accented
character.

Has anyone had any luck with accented characters in v.in.ogr? I tried
changing the encoding option in v.in.ogr but could not get it to work.
I'm using grass7 from OSGeo4Win. Attached is the shapefile that I'm trying
to import.

Thanks
Daniel


pontes.7z
Description: Binary data
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] v.external adding layers to layer tree even though I did not ask for

[Daniel Victoria]

Hi folks,

Using Grass 7.0.0 on windows, installed via OSGeo4Win.
I'm linking a bunch of shapefiles inside a directory using v.external. I
did not select the Add linked layers into layer tree but grass still adds
the layers to my layer tree and tries to render it.

I've also realized that the add linked layers text is refering to raster
data. It says: (this might not work for multiple bands)

Cheers
Daniel
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Checking and fixing roads for network analysis

[Daniel Victoria]

Thanks for the video and tips Mark. I'll try to fix the topology by hand.
My roads network is not that large so it won't take too much time.


On Sun, Jan 18, 2015 at 9:00 AM, Mark Wynter m...@dimensionaledge.com
wrote:

 Daniel, have you seen this example of using grass with QGIS?

 https://www.youtube.com/watch?v=YvEPOfSzhO0

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

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

Re: [GRASS-user] Checking and fixing roads for network analysis

[Daniel Victoria]

Hi Mark and others,

I figured out where the error I'm getting from v.net.components is coming
from. I just don't know how to fix it.
The problem is that when I clean my roads network it's breaking some lines
and these are kept with the same categories. So when I run v.net.components
it tries to calculate the connectivity of the components based on the cat
value. Since there are some repeated values for broken roads, it can't
continue. So I believe I need to get new cat values for the network. Just
don't know ow to do it (been away from GRASS for a while)...

How can I get new cat values? And can I keep the old values in order to
keep the DB link to the roads network?

Cheers
Daniel

On Fri, Jan 16, 2015 at 3:35 PM, Daniel Victoria daniel.victo...@gmail.com
wrote:

 Hi Mark,

 I tried using v.clean with break, rmdup and snap. However, when I try to
 run v.net.components I get an error saying that

 v.net.components input=rede_brk_rmdup_snap@PERMANENT node_layer=1
 output=component_brk_rmdup_snap method=weak
 Building graph...
 Registering arcs...
 Flattening the graph...
 Graph was built
 ERROR: Cannot insert new record: insert into component_brk_rmdup_snap
 values (3689, 1)

 I'm using Grass v7RC1 on Windows and v.net.components work if I use only
 the snap tool in my roads network

 Cheers
 Daniel

 On Thu, Jan 15, 2015 at 7:40 PM, Mark Wynter m...@dimensionaledge.com
 wrote:

 Hi Daniel
 When you ran v.clean, did you v.clean tool=break,rmdupl ?

 I suspect you still may encounter a problem with road T junctions if the
 vectors don't cross or intersect.  Take this simple example of 2 roads -
 NS, and EW.  Each line has only 2 nodes - at the line’s  start and end
 points.
 |—
 The problem is when the horizontal line “undershoots” the vertical line.
 The break command will have no effect, and snapping won’t make any
 difference because there is no midpoint node to which the horizontal line
 can attach itself to.

 I’d be interested to hear how others have dealt with what is essentially
 a “data preparation” issue in GRASS?

 [The solution I ended up implementing used a PostGIS SQL custom function
 to “break” overshoots and undershoots, with rules for correct treatment of
 bridges and tunnels. The function is fast, and can be run in parallel when
 working with continental-sized road networks.
 After PostGIS, I import the “broken-up” network into GRASS and use
 v.clean to snap the nodes, but NOT break the lines - as my PostGIS function
 has already dealt with this.
 The GRASS procedure involves running the v.clean in 5 steps, to avoid
 inadvertently snapping a tunnel node to say a bridge node, just because
 they are spatially close.
 1) v.clean tool=snap # no bridges, no tunnels
 2) v.clean tool=snap # bridges only
 3) v.clean tool=snap # tunnels only
 4) v.patch (steps 1-3)
 5) v.clean tool=snap # on the patched layer, with a much smaller
 tolerance to that used in steps 1-3 to again avoid say tunnel nodes
 inadvertently snapping to bridge nodes.
 We’re then good to go with v.net analysis.]

 This may sound like a complicated process, but when using imperfect data
 to model complex road networks in dense urban areas, its important to get
 the vector topology as close as possible to the real world.  I’ve found
 this process generates a highly representative, routable vector topology
 from imperfect OSM data.

 Your situation might be much simpler, which is not to say you won’t
 encounter anomalies like you’ve already identified.

 Mark



 --

 Message: 1
 Date: Thu, 15 Jan 2015 15:22:27 -0200
 From: Daniel Victoria daniel.victo...@gmail.com
 To: grass grass-user@lists.osgeo.org
 Subject: [GRASS-user] Checking and fixing roads for network analysis
 Message-ID:
 
 ca+irsjjekzq9eqq7igzcgl92k7umfdkujv6a-kvbtp7wn-x...@mail.gmail.com
 Content-Type: text/plain; charset=utf-8

 Hi List,

 I'll need to perform some network analysis and right now I'm trying to see
 if my roads map is all good. I know that there are some clearly isolated
 areas on my roads network but I'd like to identify and fix the less
 obvious
 ones.

 Here is what I did:
 1) Import road lines (v.in.ogr)
 2) Clean the topology with snap tool, thresh=0.0001 (it's a latlong
 location)
 2) Create network (v.net using the nodes option --not sure if that was
 the
 correct option)
 3) Ran v.net.components to find the weakly connected components, not
 setting any cost columns
 4) Color roads lines according to the component number

 By doing that I could spot the lines that were clearly disconnected
 (net_components_unlink.png).
 But I also found some lines that where disconnected even thou there are
 nodes (red squares) linking them (apparently) -
 net_components_pseudo_link.png

 Should I increase my snapping threshold?
 How can I see if my nodes are endnodes or located between two lines?

 Thanks
 Daniel
 -- next part --
 An HTML attachment

Re: [GRASS-user] Checking and fixing roads for network analysis

[Daniel Victoria]

Thanks Moritz,

I was just getting confused because of the layers. I've now added a new
layer to my roads vector, added new cats and created the network.
v.net.components worked nicely. I just need to study more how these layers
work so I can have a layer with the new categories and not loose the link
with the old cats, where the roads name and type are stored.

Cheers
Daniel

On Mon, Jan 19, 2015 at 2:11 PM, Moritz Lennert 
mlenn...@club.worldonline.be wrote:

 On 19/01/15 16:48, Daniel Victoria wrote:

 Hi Mark and others,

 I figured out where the error I'm getting from v.net.components is
 coming from. I just don't know how to fix it.
 The problem is that when I clean my roads network it's breaking some
 lines and these are kept with the same categories. So when I run
 v.net.components it tries to calculate the connectivity of the
 components based on the cat value. Since there are some repeated values
 for broken roads, it can't continue. So I believe I need to get new cat
 values for the network. Just don't know ow to do it (been away from
 GRASS for a while)...

 How can I get new cat values? And can I keep the old values in order to
 keep the DB link to the roads network?


 v.category option=add.

 You can create new cat values on another layer and keep the old ones on
 layer 1.

 Moritz


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

Re: [GRASS-user] Checking and fixing roads for network analysis

[Daniel Victoria]

Hi Mark,

I tried using v.clean with break, rmdup and snap. However, when I try to
run v.net.components I get an error saying that

v.net.components input=rede_brk_rmdup_snap@PERMANENT node_layer=1
output=component_brk_rmdup_snap method=weak
Building graph...
Registering arcs...
Flattening the graph...
Graph was built
ERROR: Cannot insert new record: insert into component_brk_rmdup_snap
values (3689, 1)

I'm using Grass v7RC1 on Windows and v.net.components work if I use only
the snap tool in my roads network

Cheers
Daniel

On Thu, Jan 15, 2015 at 7:40 PM, Mark Wynter m...@dimensionaledge.com
wrote:

 Hi Daniel
 When you ran v.clean, did you v.clean tool=break,rmdupl ?

 I suspect you still may encounter a problem with road T junctions if the
 vectors don't cross or intersect.  Take this simple example of 2 roads -
 NS, and EW.  Each line has only 2 nodes - at the line’s  start and end
 points.
 |—
 The problem is when the horizontal line “undershoots” the vertical line.
 The break command will have no effect, and snapping won’t make any
 difference because there is no midpoint node to which the horizontal line
 can attach itself to.

 I’d be interested to hear how others have dealt with what is essentially a
 “data preparation” issue in GRASS?

 [The solution I ended up implementing used a PostGIS SQL custom function
 to “break” overshoots and undershoots, with rules for correct treatment of
 bridges and tunnels. The function is fast, and can be run in parallel when
 working with continental-sized road networks.
 After PostGIS, I import the “broken-up” network into GRASS and use v.clean
 to snap the nodes, but NOT break the lines - as my PostGIS function has
 already dealt with this.
 The GRASS procedure involves running the v.clean in 5 steps, to avoid
 inadvertently snapping a tunnel node to say a bridge node, just because
 they are spatially close.
 1) v.clean tool=snap # no bridges, no tunnels
 2) v.clean tool=snap # bridges only
 3) v.clean tool=snap # tunnels only
 4) v.patch (steps 1-3)
 5) v.clean tool=snap # on the patched layer, with a much smaller tolerance
 to that used in steps 1-3 to again avoid say tunnel nodes inadvertently
 snapping to bridge nodes.
 We’re then good to go with v.net analysis.]

 This may sound like a complicated process, but when using imperfect data
 to model complex road networks in dense urban areas, its important to get
 the vector topology as close as possible to the real world.  I’ve found
 this process generates a highly representative, routable vector topology
 from imperfect OSM data.

 Your situation might be much simpler, which is not to say you won’t
 encounter anomalies like you’ve already identified.

 Mark



 --

 Message: 1
 Date: Thu, 15 Jan 2015 15:22:27 -0200
 From: Daniel Victoria daniel.victo...@gmail.com
 To: grass grass-user@lists.osgeo.org
 Subject: [GRASS-user] Checking and fixing roads for network analysis
 Message-ID:
 
 ca+irsjjekzq9eqq7igzcgl92k7umfdkujv6a-kvbtp7wn-x...@mail.gmail.com
 Content-Type: text/plain; charset=utf-8

 Hi List,

 I'll need to perform some network analysis and right now I'm trying to see
 if my roads map is all good. I know that there are some clearly isolated
 areas on my roads network but I'd like to identify and fix the less obvious
 ones.

 Here is what I did:
 1) Import road lines (v.in.ogr)
 2) Clean the topology with snap tool, thresh=0.0001 (it's a latlong
 location)
 2) Create network (v.net using the nodes option --not sure if that was the
 correct option)
 3) Ran v.net.components to find the weakly connected components, not
 setting any cost columns
 4) Color roads lines according to the component number

 By doing that I could spot the lines that were clearly disconnected
 (net_components_unlink.png).
 But I also found some lines that where disconnected even thou there are
 nodes (red squares) linking them (apparently) -
 net_components_pseudo_link.png

 Should I increase my snapping threshold?
 How can I see if my nodes are endnodes or located between two lines?

 Thanks
 Daniel
 -- next part --
 An HTML attachment was scrubbed...
 URL: 
 http://lists.osgeo.org/pipermail/grass-user/attachments/20150115/0dd532a1/attachment.html
 
 -- next part --
 A non-text attachment was scrubbed...
 Name: net_components_unlink.png
 Type: image/png
 Size: 25250 bytes
 Desc: not available
 URL: 
 http://lists.osgeo.org/pipermail/grass-user/attachments/20150115/0dd532a1/attachment.png
 
 -- next part --
 A non-text attachment was scrubbed...
 Name: net_components_pseudo_link.png
 Type: image/png
 Size: 15279 bytes
 Desc: not available
 URL: 
 http://lists.osgeo.org/pipermail/grass-user/attachments/20150115/0dd532a1/attachment-0001.png
 

 --

 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http

[GRASS-user] removing non-existing raster does not gives a warning

[Daniel Victoria]

WinGrass v7RC1

If if use the command line to delete a map (vector or raster) and the map
does not exist, I won't receive a warning about the typo

C:\g.remove raster name=bogus
The following data base element files would be deleted:
You must use the force flag (-f) to actually remove them. Exiting.

C:\g.remove raster name=bogus -f

C:\

Sholdn't there be a warning?

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

Re: [GRASS-user] r.terraflow on massive DEM

[Daniel Victoria]

THANKS!

I was downloading the SRTM data from earthexplorer and I choose the dataset
that appeared under Digita Elevation/SRTM/SRTM 1 Arc-Second Global.
The srtmgl1 dataset is hidden under NASA LPDAAC Collections / Nasa SRTM
(SRTM 3) Collections / NASA SRTM3 SRTMGL1.

Back to downloading the data...

Cheers and thanks once again
Daniel

On Thu, Jan 15, 2015 at 5:59 AM, Markus Metz markus.metz.gisw...@gmail.com
wrote:

 On Wed, Jan 14, 2015 at 11:48 AM, Daniel Victoria
 daniel.victo...@gmail.com wrote:
  Hi Markus,
 
  I was using r.terraflow because I had converted my voids to negative
 values
  while the areas outside the country where set to null.
  But the data is proving to be too big and I'll just skip the gap-filling
 for
  now. Might do it later on, filling the gaps in the import process.
 
  The SRTM v3 you pointed out is very good but it's the 3-arcsec
 resolution.
  I'm working with the 1-arcsec res.

 Then you could try the gap-filled 1 arc sec version of SRTM v3:

 https://lpdaac.usgs.gov/products/measures_products_table/srtmgl1

 Markus M

 
  Cheers and thanks
  Daniel
 
  On Tue, Jan 13, 2015 at 5:40 PM, Markus Metz 
 markus.metz.gisw...@gmail.com
  wrote:
 
  On Tue, Jan 13, 2015 at 7:52 PM, Daniel Victoria
  daniel.victo...@gmail.com wrote:
  
   Now, the thing is, my main interest is to fill the voids in the SRTM
   data.
   So I though about using r.terraflow to get the filled elevation.
 Should
   I
   continue on that path or would it be better to use r.fill.null on a
   large
   dataset?
 
  r.terraflow does not fill voids, it fills sinks. Use SRTM v3 [0], this
  is gap-filled. Using r.fill.null on SRTM v2 will not give you the same
  quality. r.terraflow has a limit on the number of rows and columns
  (max 32,767 each). r.watershed also has a limit on the number of rows
  and columns, but that is max 2,147,483,647 each. In any case, you
  should use GRASS 7 for such large datasets.
 
  Markus M
 
  [0] https://lpdaac.usgs.gov/products/measures_products_table/srtmgl3
 
  
   Thanks
   Daniel
  
   On Tue, Jan 13, 2015 at 1:46 PM, Daniel Victoria
   daniel.victo...@gmail.com
   wrote:
  
   Charlie,
  
   I just downloaded some SRTM 1arc sec. from EarthExplorer. The data is
   supplied in 3 different file types, GeoTIFF, DTED or BIL and they are
   all in
   Integer values (Int16). No floating point elevation values.
  
   Cheers
   Daniel
  
   On Tue, Jan 13, 2015 at 12:12 PM, Charlie Shobe 
 chsh5...@colorado.edu
   wrote:
  
   Hi Daniel,
  
   I believe that SRTM data does in fact provide floating point
 elevation
   values, so you may want to try working with the DEM as type FCELL
 from
   the
   very beginning. I don't know if this will help solve your problem,
 but
   the
   last time I brought in SRTM (1 arc second) data it was type FCELL
 and
   contained several decimal places of precision.
  
   Good luck,
  
   Charlie
  
  
   On Jan 13, 2015, at 4:00 AM, Daniel Victoria
   daniel.victo...@gmail.com
   wrote:
  
   Stephan, I'll give r.watershed a try and let it run for a couple of
   days.
   Thanks
  
   Thayer, I used r.recode because the person that sent me the data
   messed
   up the null values. So in order to fix that I did:
   1) use r.external to bring the data to Grass
   2) fix null values with r.recode, which was faster than r.null
  
   But I gave up on that path and since imported the data (r.in.gdal)
 and
   fixed the null values with r.null.
   I'm also using integer values (CELL type) because from what I heard,
   SRTM
   does not provide floating point data.
  
   Now I tried to run r.terraflow but I got a type error which asked me
   to
   use r.terraflow.short. Since I don't have that command in my grass
   instalatin, I converted the SRTM data to float. But that was to no
   avail
   since it's now giving me a dimensions type overflow error and asking
   me to
   change the dimension_type and recompile.
  
   I'll give r.watershed a try. If that does not work, I'll see if I
 can
   recompile.
  
   Thanks
   Daniel
  
   On Mon, Jan 12, 2015 at 9:22 PM, Thayer Young thaye...@yahoo.com
   wrote:
  
   With regards to the size of DEM, if you can get the command to run
 it
   may take several days to finish, this is more than twice the size
 of
   the
   Washington State DEM that took the authors 33 hours in 2003 (Arge,
   Chase,
   Halpin, Toma, Urban, Vitter, Wickremesinghe  Efficient Flow
   Computation on
   Massive Grid Terrain Datasets Geoinformatica Volume 7 Issue 4,
   December 2003
   Pages 283 - 313 ).  My mid-2014 computer runs at about twice the
   speed
   quoted in the paper.
  
   Did you r.recode it to make it smaller?  In flat areas you need the
   data
   contained after the decimal point to allow the flow a chance to
 make
   it down
   hill, otherwise you can get streams going no where near where they
 do
   in
   real life.  I have never tried running r.terraflow on an integer
   raster, I
   know that it works on decimal rasters

[GRASS-user] vector editing not working

[Daniel Victoria]

Hi list,

Using Grass 7beta4 on Win7, installed using osgeo4w.

I tried to create a vector file following the steps:
1) Add a base vector file to the map display
2) Create a new vector map
3) Change the map display to the digitizer
   When I do that, my map display goes blank and I have to hit the refresh
button
4) select the vector I want to edit on the edit toolbar
5) select the add point tool
When I click on the map display to add a point, I get the error No vector
map selected for editing

Anyone with the same issue?
Thanks
Daniel
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.terraflow on massive DEM

[Daniel Victoria]

Hi Markus,

I was using r.terraflow because I had converted my voids to negative values
while the areas outside the country where set to null.
But the data is proving to be too big and I'll just skip the gap-filling
for now. Might do it later on, filling the gaps in the import process.

The SRTM v3 you pointed out is very good but it's the 3-arcsec resolution.
I'm working with the 1-arcsec res.

Cheers and thanks
Daniel

On Tue, Jan 13, 2015 at 5:40 PM, Markus Metz markus.metz.gisw...@gmail.com
wrote:

 On Tue, Jan 13, 2015 at 7:52 PM, Daniel Victoria
 daniel.victo...@gmail.com wrote:
 
  Now, the thing is, my main interest is to fill the voids in the SRTM
 data.
  So I though about using r.terraflow to get the filled elevation. Should I
  continue on that path or would it be better to use r.fill.null on a large
  dataset?

 r.terraflow does not fill voids, it fills sinks. Use SRTM v3 [0], this
 is gap-filled. Using r.fill.null on SRTM v2 will not give you the same
 quality. r.terraflow has a limit on the number of rows and columns
 (max 32,767 each). r.watershed also has a limit on the number of rows
 and columns, but that is max 2,147,483,647 each. In any case, you
 should use GRASS 7 for such large datasets.

 Markus M

 [0] https://lpdaac.usgs.gov/products/measures_products_table/srtmgl3

 
  Thanks
  Daniel
 
  On Tue, Jan 13, 2015 at 1:46 PM, Daniel Victoria 
 daniel.victo...@gmail.com
  wrote:
 
  Charlie,
 
  I just downloaded some SRTM 1arc sec. from EarthExplorer. The data is
  supplied in 3 different file types, GeoTIFF, DTED or BIL and they are
 all in
  Integer values (Int16). No floating point elevation values.
 
  Cheers
  Daniel
 
  On Tue, Jan 13, 2015 at 12:12 PM, Charlie Shobe chsh5...@colorado.edu
  wrote:
 
  Hi Daniel,
 
  I believe that SRTM data does in fact provide floating point elevation
  values, so you may want to try working with the DEM as type FCELL from
 the
  very beginning. I don't know if this will help solve your problem, but
 the
  last time I brought in SRTM (1 arc second) data it was type FCELL and
  contained several decimal places of precision.
 
  Good luck,
 
  Charlie
 
 
  On Jan 13, 2015, at 4:00 AM, Daniel Victoria 
 daniel.victo...@gmail.com
  wrote:
 
  Stephan, I'll give r.watershed a try and let it run for a couple of
 days.
  Thanks
 
  Thayer, I used r.recode because the person that sent me the data messed
  up the null values. So in order to fix that I did:
  1) use r.external to bring the data to Grass
  2) fix null values with r.recode, which was faster than r.null
 
  But I gave up on that path and since imported the data (r.in.gdal) and
  fixed the null values with r.null.
  I'm also using integer values (CELL type) because from what I heard,
 SRTM
  does not provide floating point data.
 
  Now I tried to run r.terraflow but I got a type error which asked me to
  use r.terraflow.short. Since I don't have that command in my grass
  instalatin, I converted the SRTM data to float. But that was to no
 avail
  since it's now giving me a dimensions type overflow error and asking
 me to
  change the dimension_type and recompile.
 
  I'll give r.watershed a try. If that does not work, I'll see if I can
  recompile.
 
  Thanks
  Daniel
 
  On Mon, Jan 12, 2015 at 9:22 PM, Thayer Young thaye...@yahoo.com
 wrote:
 
  With regards to the size of DEM, if you can get the command to run it
  may take several days to finish, this is more than twice the size of
 the
  Washington State DEM that took the authors 33 hours in 2003 (Arge,
 Chase,
  Halpin, Toma, Urban, Vitter, Wickremesinghe  Efficient Flow
 Computation on
  Massive Grid Terrain Datasets Geoinformatica Volume 7 Issue 4,
 December 2003
  Pages 283 - 313 ).  My mid-2014 computer runs at about twice the speed
  quoted in the paper.
 
  Did you r.recode it to make it smaller?  In flat areas you need the
 data
  contained after the decimal point to allow the flow a chance to make
 it down
  hill, otherwise you can get streams going no where near where they do
 in
  real life.  I have never tried running r.terraflow on an integer
 raster, I
  know that it works on decimal rasters.
 
  -Thayer
 
 
 
  
 
  Date: Mon, 12 Jan 2015 09:59:40 -0200
  From: Daniel Victoria daniel.victo...@gmail.com
  To: grass grass-user@lists.osgeo.org
  Subject: [GRASS-user] r.terraflow on massive DEM
  Message-ID:
  CA+irsJjf7xhWgU968D+4+xc2YGJ=_
 n4xjtp0_weu1zportt...@mail.gmail.com
  Content-Type: text/plain; charset=utf-8
 
 
  Hi list,
 
  I'm trying to run r.terraflow on a very large DEM but I wander if it's
  __too large__.
 
  The region dimensions are:
  ncol=141114
  nrow=140487
  Data type = CELL
 
  The map is actually a reclass map of a raster that I imported using
  r.external.
 
  When I run r.terraflow I get:
 
  r.terraflow elevation=srtm_brasil@PERMANENT filled=srtm_fill
  direction=flowdir swatershed=sink accumulation=flowacc tci=srtm_tci
  directory=E:\terraflow_temp

Re: [GRASS-user] r.terraflow on massive DEM

[Daniel Victoria]

Well, r.terraflow does run on my machine.
It took 52 minutes to process the following region:

projection: 3 (Latitude-Longitude)
zone:   0
datum:  wgs84
ellipsoid:  wgs84
north:  18:59:59S
south:  22S
west:   52W
east:   49:59:59W
nsres:  0:00:01
ewres:  0:00:01
rows:   10801
cols:   7201
cells:  8001

My computer is a core i3 (Win7) and I gave the process only 600mb of ram.

Now, the thing is, my main interest is to fill the voids in the SRTM data.
So I though about using r.terraflow to get the filled elevation. Should I
continue on that path or would it be better to use r.fill.null on a large
dataset?

Thanks
Daniel

On Tue, Jan 13, 2015 at 1:46 PM, Daniel Victoria daniel.victo...@gmail.com
wrote:

 Charlie,

 I just downloaded some SRTM 1arc sec. from EarthExplorer. The data is
 supplied in 3 different file types, GeoTIFF, DTED or BIL and they are all
 in Integer values (Int16). No floating point elevation values.

 Cheers
 Daniel

 On Tue, Jan 13, 2015 at 12:12 PM, Charlie Shobe chsh5...@colorado.edu
 wrote:

 Hi Daniel,

 I believe that SRTM data does in fact provide floating point elevation
 values, so you may want to try working with the DEM as type FCELL from the
 very beginning. I don't know if this will help solve your problem, but the
 last time I brought in SRTM (1 arc second) data it was type FCELL and
 contained several decimal places of precision.

 Good luck,

 Charlie


 On Jan 13, 2015, at 4:00 AM, Daniel Victoria daniel.victo...@gmail.com
 wrote:

 Stephan, I'll give r.watershed a try and let it run for a couple of days.
 Thanks

 Thayer, I used r.recode because the person that sent me the data messed
 up the null values. So in order to fix that I did:
 1) use r.external to bring the data to Grass
 2) fix null values with r.recode, which was faster than r.null

 But I gave up on that path and since imported the data (r.in.gdal) and
 fixed the null values with r.null.
 I'm also using integer values (CELL type) because from what I heard, SRTM
 does not provide floating point data.

 Now I tried to run r.terraflow but I got a type error which asked me to
 use r.terraflow.short. Since I don't have that command in my grass
 instalatin, I converted the SRTM data to float. But that was to no avail
 since it's now giving me a dimensions type overflow error and asking me to
 change the dimension_type and recompile.

 I'll give r.watershed a try. If that does not work, I'll see if I can
 recompile.

 Thanks
 Daniel

 On Mon, Jan 12, 2015 at 9:22 PM, Thayer Young thaye...@yahoo.com wrote:

 With regards to the size of DEM, if you can get the command to run it
 may take several days to finish, this is more than twice the size of the
 Washington State DEM that took the authors 33 hours in 2003 (Arge, Chase,
 Halpin, Toma, Urban, Vitter, Wickremesinghe  Efficient Flow Computation on
 Massive Grid Terrain Datasets Geoinformatica Volume 7 Issue 4, December
 2003 Pages 283 - 313 ).  My mid-2014 computer runs at about twice the
 speed quoted in the paper.

 Did you r.recode it to make it smaller?  In flat areas you need the data
 contained after the decimal point to allow the flow a chance to make it
 down hill, otherwise you can get streams going no where near where they do
 in real life.  I have never tried running r.terraflow on an integer raster,
 I know that it works on decimal rasters.

 -Thayer



  --

 Date: Mon, 12 Jan 2015 09:59:40 -0200
 From: Daniel Victoria daniel.victo...@gmail.com
 To: grass grass-user@lists.osgeo.org
 Subject: [GRASS-user] r.terraflow on massive DEM
 Message-ID:
 CA+irsJjf7xhWgU968D+4+xc2YGJ=_n4xjtp0_weu1zportt...@mail.gmail.com
 Content-Type: text/plain; charset=utf-8


 Hi list,

 I'm trying to run r.terraflow on a very large DEM but I wander if it's
 __too large__.

 The region dimensions are:
 ncol=141114
 nrow=140487
 Data type = CELL

 The map is actually a reclass map of a raster that I imported using
 r.external.

 When I run r.terraflow I get:

 r.terraflow elevation=srtm_brasil@PERMANENT filled=srtm_fill
 direction=flowdir swatershed=sink accumulation=flowacc tci=srtm_tci
 directory=E:\terraflow_temp

 WARNING: raster srtm_brasil is of type CELL_TYPE --you should use
 r.terraflow.short
 ERROR: [nrows=140487, ncols=141114] dimension_type overflow -- change
 dimension_type and recompile
 (Mon Jan 12 09:57:18 2015) Command finished (0
 sec)

 However, I don't have an r.terraflow.short command
 I'm running Grass 7.0.0beta4 from OsGeo4W

 Cheers
 Daniel
 -- next part --
 An HTML attachment was scrubbed...
 URL: 
 http://lists.osgeo.org/pipermail/grass-user/attachments/20150112/a27c139f/attachment-0001.html
 

 --

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

 End of grass-user Digest, Vol 105, Issue 16

Re: [GRASS-user] r.terraflow on massive DEM

[Daniel Victoria]

Stephan, I'll give r.watershed a try and let it run for a couple of days.
Thanks

Thayer, I used r.recode because the person that sent me the data messed up
the null values. So in order to fix that I did:
1) use r.external to bring the data to Grass
2) fix null values with r.recode, which was faster than r.null

But I gave up on that path and since imported the data (r.in.gdal) and
fixed the null values with r.null.
I'm also using integer values (CELL type) because from what I heard, SRTM
does not provide floating point data.

Now I tried to run r.terraflow but I got a type error which asked me to use
r.terraflow.short. Since I don't have that command in my grass instalatin,
I converted the SRTM data to float. But that was to no avail since it's now
giving me a dimensions type overflow error and asking me to change the
dimension_type and recompile.

I'll give r.watershed a try. If that does not work, I'll see if I can
recompile.

Thanks
Daniel

On Mon, Jan 12, 2015 at 9:22 PM, Thayer Young thaye...@yahoo.com wrote:

 With regards to the size of DEM, if you can get the command to run it may
 take several days to finish, this is more than twice the size of the
 Washington State DEM that took the authors 33 hours in 2003 (Arge, Chase,
 Halpin, Toma, Urban, Vitter, Wickremesinghe  Efficient Flow Computation on
 Massive Grid Terrain Datasets Geoinformatica Volume 7 Issue 4, December
 2003 Pages 283 - 313 ).  My mid-2014 computer runs at about twice the
 speed quoted in the paper.

 Did you r.recode it to make it smaller?  In flat areas you need the data
 contained after the decimal point to allow the flow a chance to make it
 down hill, otherwise you can get streams going no where near where they do
 in real life.  I have never tried running r.terraflow on an integer raster,
 I know that it works on decimal rasters.

 -Thayer



  --

 Date: Mon, 12 Jan 2015 09:59:40 -0200
 From: Daniel Victoria daniel.victo...@gmail.com
 To: grass grass-user@lists.osgeo.org
 Subject: [GRASS-user] r.terraflow on massive DEM
 Message-ID:
 CA+irsJjf7xhWgU968D+4+xc2YGJ=_n4xjtp0_weu1zportt...@mail.gmail.com
 Content-Type: text/plain; charset=utf-8


 Hi list,

 I'm trying to run r.terraflow on a very large DEM but I wander if it's
 __too large__.

 The region dimensions are:
 ncol=141114
 nrow=140487
 Data type = CELL

 The map is actually a reclass map of a raster that I imported using
 r.external.

 When I run r.terraflow I get:

 r.terraflow elevation=srtm_brasil@PERMANENT filled=srtm_fill
 direction=flowdir swatershed=sink accumulation=flowacc tci=srtm_tci
 directory=E:\terraflow_temp

 WARNING: raster srtm_brasil is of type CELL_TYPE --you should use
 r.terraflow.short
 ERROR: [nrows=140487, ncols=141114] dimension_type overflow -- change
 dimension_type and recompile
 (Mon Jan 12 09:57:18 2015) Command finished (0
 sec)

 However, I don't have an r.terraflow.short command
 I'm running Grass 7.0.0beta4 from OsGeo4W

 Cheers
 Daniel
 -- next part --
 An HTML attachment was scrubbed...
 URL: 
 http://lists.osgeo.org/pipermail/grass-user/attachments/20150112/a27c139f/attachment-0001.html
 

 --

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

 End of grass-user Digest, Vol 105, Issue 16
 ***



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

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

Re: [GRASS-user] r.terraflow on massive DEM

[Daniel Victoria]

That's a good point Thayer. Will do. Will do

On Tue, Jan 13, 2015 at 1:02 PM, Thayer Young thaye...@yahoo.com wrote:

 Daniel,

 Before you go through the trouble of recompiling you may want to try
 downloading a smaller SRTM DEM from Earth Explorer and make sure it works
 with r.terraflow.  I would recommend making sure r.terraflow works at all
 on your system.  Then scale up to the full mosaic and see if you still have
 a problem.

 -Thayer


   --
  *From:* Daniel Victoria daniel.victo...@gmail.com
 *To:* Charlie Shobe chsh5...@colorado.edu
 *Cc:* Thayer Young thaye...@yahoo.com; grass-user@lists.osgeo.org 
 grass-user@lists.osgeo.org
 *Sent:* Tuesday, January 13, 2015 9:17 AM
 *Subject:* Re: [GRASS-user] r.terraflow on massive DEM

 Ouch! That means that probably, the person who imported the data,
 converted it to integer without knowing...

 Anyway, I'll still need to recompile r.terraflow if I'm to use on such a
 large region (ncol=141114 x nrow=14048).

 Thanks
 Daniel



 On Tue, Jan 13, 2015 at 12:12 PM, Charlie Shobe chsh5...@colorado.edu
 wrote:

 Hi Daniel,

 I believe that SRTM data does in fact provide floating point elevation
 values, so you may want to try working with the DEM as type FCELL from the
 very beginning. I don't know if this will help solve your problem, but the
 last time I brought in SRTM (1 arc second) data it was type FCELL and
 contained several decimal places of precision.

 Good luck,

 Charlie


 On Jan 13, 2015, at 4:00 AM, Daniel Victoria daniel.victo...@gmail.com
 wrote:

 Stephan, I'll give r.watershed a try and let it run for a couple of days.
 Thanks

 Thayer, I used r.recode because the person that sent me the data messed up
 the null values. So in order to fix that I did:
 1) use r.external to bring the data to Grass
 2) fix null values with r.recode, which was faster than r.null

 But I gave up on that path and since imported the data (r.in.gdal) and
 fixed the null values with r.null.
 I'm also using integer values (CELL type) because from what I heard, SRTM
 does not provide floating point data.

 Now I tried to run r.terraflow but I got a type error which asked me to
 use r.terraflow.short. Since I don't have that command in my grass
 instalatin, I converted the SRTM data to float. But that was to no avail
 since it's now giving me a dimensions type overflow error and asking me to
 change the dimension_type and recompile.

 I'll give r.watershed a try. If that does not work, I'll see if I can
 recompile.

 Thanks
 Daniel

 On Mon, Jan 12, 2015 at 9:22 PM, Thayer Young thaye...@yahoo.com wrote:

 With regards to the size of DEM, if you can get the command to run it may
 take several days to finish, this is more than twice the size of the
 Washington State DEM that took the authors 33 hours in 2003 (Arge, Chase,
 Halpin, Toma, Urban, Vitter, Wickremesinghe  Efficient Flow Computation on
 Massive Grid Terrain Datasets Geoinformatica Volume 7 Issue 4, December
 2003 Pages 283 - 313 ).  My mid-2014 computer runs at about twice the
 speed quoted in the paper.

 Did you r.recode it to make it smaller?  In flat areas you need the data
 contained after the decimal point to allow the flow a chance to make it
 down hill, otherwise you can get streams going no where near where they do
 in real life.  I have never tried running r.terraflow on an integer raster,
 I know that it works on decimal rasters.

 -Thayer



  --

 Date: Mon, 12 Jan 2015 09:59:40 -0200
 From: Daniel Victoria daniel.victo...@gmail.com
 To: grass grass-user@lists.osgeo.org
 Subject: [GRASS-user] r.terraflow on massive DEM
 Message-ID:
 CA+irsJjf7xhWgU968D+4+xc2YGJ=_n4xjtp0_weu1zportt...@mail.gmail.com
 Content-Type: text/plain; charset=utf-8


 Hi list,

 I'm trying to run r.terraflow on a very large DEM but I wander if it's
 __too large__.

 The region dimensions are:
 ncol=141114
 nrow=140487
 Data type = CELL

 The map is actually a reclass map of a raster that I imported using
 r.external.

 When I run r.terraflow I get:

 r.terraflow elevation=srtm_brasil@PERMANENT filled=srtm_fill
 direction=flowdir swatershed=sink accumulation=flowacc tci=srtm_tci
 directory=E:\terraflow_temp

 WARNING: raster srtm_brasil is of type CELL_TYPE --you should use
 r.terraflow.short
 ERROR: [nrows=140487, ncols=141114] dimension_type overflow -- change
 dimension_type and recompile
 (Mon Jan 12 09:57:18 2015) Command finished (0
 sec)

 However, I don't have an r.terraflow.short command
 I'm running Grass 7.0.0beta4 from OsGeo4W

 Cheers
 Daniel
 -- next part --
 An HTML attachment was scrubbed...
 URL: 
 http://lists.osgeo.org/pipermail/grass-user/attachments/20150112/a27c139f/attachment-0001.html
 

 --

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

 End of grass-user Digest, Vol 105, Issue 16

Re: [GRASS-user] r.terraflow on massive DEM

[Daniel Victoria]

Charlie,

I just downloaded some SRTM 1arc sec. from EarthExplorer. The data is
supplied in 3 different file types, GeoTIFF, DTED or BIL and they are all
in Integer values (Int16). No floating point elevation values.

Cheers
Daniel

On Tue, Jan 13, 2015 at 12:12 PM, Charlie Shobe chsh5...@colorado.edu
wrote:

 Hi Daniel,

 I believe that SRTM data does in fact provide floating point elevation
 values, so you may want to try working with the DEM as type FCELL from the
 very beginning. I don't know if this will help solve your problem, but the
 last time I brought in SRTM (1 arc second) data it was type FCELL and
 contained several decimal places of precision.

 Good luck,

 Charlie


 On Jan 13, 2015, at 4:00 AM, Daniel Victoria daniel.victo...@gmail.com
 wrote:

 Stephan, I'll give r.watershed a try and let it run for a couple of days.
 Thanks

 Thayer, I used r.recode because the person that sent me the data messed up
 the null values. So in order to fix that I did:
 1) use r.external to bring the data to Grass
 2) fix null values with r.recode, which was faster than r.null

 But I gave up on that path and since imported the data (r.in.gdal) and
 fixed the null values with r.null.
 I'm also using integer values (CELL type) because from what I heard, SRTM
 does not provide floating point data.

 Now I tried to run r.terraflow but I got a type error which asked me to
 use r.terraflow.short. Since I don't have that command in my grass
 instalatin, I converted the SRTM data to float. But that was to no avail
 since it's now giving me a dimensions type overflow error and asking me to
 change the dimension_type and recompile.

 I'll give r.watershed a try. If that does not work, I'll see if I can
 recompile.

 Thanks
 Daniel

 On Mon, Jan 12, 2015 at 9:22 PM, Thayer Young thaye...@yahoo.com wrote:

 With regards to the size of DEM, if you can get the command to run it
 may take several days to finish, this is more than twice the size of the
 Washington State DEM that took the authors 33 hours in 2003 (Arge, Chase,
 Halpin, Toma, Urban, Vitter, Wickremesinghe  Efficient Flow Computation on
 Massive Grid Terrain Datasets Geoinformatica Volume 7 Issue 4, December
 2003 Pages 283 - 313 ).  My mid-2014 computer runs at about twice the
 speed quoted in the paper.

 Did you r.recode it to make it smaller?  In flat areas you need the data
 contained after the decimal point to allow the flow a chance to make it
 down hill, otherwise you can get streams going no where near where they do
 in real life.  I have never tried running r.terraflow on an integer raster,
 I know that it works on decimal rasters.

 -Thayer



  --

 Date: Mon, 12 Jan 2015 09:59:40 -0200
 From: Daniel Victoria daniel.victo...@gmail.com
 To: grass grass-user@lists.osgeo.org
 Subject: [GRASS-user] r.terraflow on massive DEM
 Message-ID:
 CA+irsJjf7xhWgU968D+4+xc2YGJ=_n4xjtp0_weu1zportt...@mail.gmail.com
 Content-Type: text/plain; charset=utf-8


 Hi list,

 I'm trying to run r.terraflow on a very large DEM but I wander if it's
 __too large__.

 The region dimensions are:
 ncol=141114
 nrow=140487
 Data type = CELL

 The map is actually a reclass map of a raster that I imported using
 r.external.

 When I run r.terraflow I get:

 r.terraflow elevation=srtm_brasil@PERMANENT filled=srtm_fill
 direction=flowdir swatershed=sink accumulation=flowacc tci=srtm_tci
 directory=E:\terraflow_temp

 WARNING: raster srtm_brasil is of type CELL_TYPE --you should use
 r.terraflow.short
 ERROR: [nrows=140487, ncols=141114] dimension_type overflow -- change
 dimension_type and recompile
 (Mon Jan 12 09:57:18 2015) Command finished (0
 sec)

 However, I don't have an r.terraflow.short command
 I'm running Grass 7.0.0beta4 from OsGeo4W

 Cheers
 Daniel
 -- next part --
 An HTML attachment was scrubbed...
 URL: 
 http://lists.osgeo.org/pipermail/grass-user/attachments/20150112/a27c139f/attachment-0001.html
 

 --

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

 End of grass-user Digest, Vol 105, Issue 16
 ***



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


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


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

[GRASS-user] r.terraflow on massive DEM

[Daniel Victoria]

Hi list,

I'm trying to run r.terraflow on a very large DEM but I wander if it's
__too large__.

The region dimensions are:
ncol=141114
nrow=140487
Data type = CELL

The map is actually a reclass map of a raster that I imported using
r.external.

When I run r.terraflow I get:

r.terraflow elevation=srtm_brasil@PERMANENT filled=srtm_fill
direction=flowdir swatershed=sink accumulation=flowacc tci=srtm_tci
directory=E:\terraflow_temp

WARNING: raster srtm_brasil is of type CELL_TYPE --you should use
r.terraflow.short
ERROR: [nrows=140487, ncols=141114] dimension_type overflow -- change
dimension_type and recompile
(Mon Jan 12 09:57:18 2015) Command finished (0
sec)

However, I don't have an r.terraflow.short command
I'm running Grass 7.0.0beta4 from OsGeo4W

Cheers
Daniel
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Distributed modeling animation rendered in GRASS70

[Daniel Victoria]

Very nice results and a great way to visualize model output.

Cheers
On Nov 13, 2014 4:19 AM, Thomas Adams tea...@gmail.com wrote:

 All,

 After running a distributed hydrologic model I did some shell/GRASS
 scripting to import the NEXRAD radar precipitation data and model output
 flow grids into GRASS 7. Making use of ps.map, I generated a series of
 hourly (2185) png images.

 Markus Neteler pointed me to the GRASS location
 http://grasswiki.osgeo.org/wiki/Movies, where I simply did this:

  mencoder mf:///home/teaiii/grass/data/output/png_files/*.png -mf fps=15
 -o type=png out.avi -ovc lavc -lavcopts vcodec=mpeg4:vhq:vbitrate=1800
 -ffourcc MP4

 I posted the resulting video on Mimeo: https://vimeo.com/111696348

 There should be a High-def version available at some point.

 Cheers!
 Tom

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

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

Re: [GRASS-user] rastization failed : can't allocate memory

[Daniel Victoria]

I never realized there was a rows parameter. oops

The message is understandable but I was thinking more in terms of the users
who have set the resolution too high without realizing, or using wrong
setting in the beginning. So maybe, add:
adjust 'rows' parameter or check region resoluiton with g.region



On Sat, Sep 6, 2014 at 1:24 PM, Markus Neteler nete...@osgeo.org wrote:

 On Sat, Sep 6, 2014 at 12:32 PM, Daniel Victoria
 daniel.victo...@gmail.com wrote:
  Maybe, instead of throwing a memory error, grass could check the region
 size
  and if the number of cells is too high, ask for user confirmation or
 suggest
  how the user can change the region.

 I have for now added a message:

 # test case:
 GRASS 7.1.svn (nc_spm_08_grass7):~  g.region vect=zipcodes_wake res=5 -pa
 projection: 99 (Lambert Conformal Conic)
 zone:   0
 datum:  nad83
 ellipsoid:  a=6378137 es=0.006694380022900787
 north:  258110
 south:  196320
 west:   610040
 east:   677070
 nsres:  5
 ewres:  5
 rows:   12358
 cols:   13406
 cells:  165671348

 # new message about RAM added:
 GRASS 7.1.svn (nc_spm_08_grass7):~  v.to.rast zipcodes_wake
 out=zipcodes_wake_area use=attr attrcol=SHAPE_Area --o
 Using at least 0.4 GB of RAM (adjust with 'rows' parameter)
 Pass 1 of 4:
 Reading areas...
 [...]



 # other test case:
 GRASS 7.1.svn (nc_spm_08_grass7):~  g.region vect=zipcodes_wake res=1 -pa
 projection: 99 (Lambert Conformal Conic)
 ...
 rows:   61780
 cols:   67020
 cells:  4140495600

 GRASS 7.1.svn (nc_spm_08_grass7):~  v.to.rast zipcodes_wake
 out=zipcodes_wake_area use=attr attrcol=SHAPE_Area --o rows=1
 Using at least 4.6 GB of RAM (adjust with 'rows' parameter)
 ...

 Is that new message understandable?

 Markus

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

Re: [GRASS-user] rastization failed : can't allocate memory

[Daniel Victoria]

Maybe, instead of throwing a memory error, grass could check the region
size and if the number of cells is too high, ask for user confirmation or
suggest how the user can change the region.
 On Sep 5, 2014 11:10 PM, Markus Neteler nete...@osgeo.org wrote:

 On Sat, Sep 6, 2014 at 1:50 AM, christophe joey
 christophe0j...@gmail.com wrote:
  thank you daniel victoria.
  in the options i had by default rows = 4000 so i reduce it.

 I think we should develop some magic to better decide how many rows
 are processed in v.to.rast in parallel.
 Suggestions?

 It also affects v.rast.stats which internally calls v.to.rast.

 Markus

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

Re: [GRASS-user] rastization failed : can't allocate memory

[Daniel Victoria]

Check your region resolution. It's probably too high and so gives you lots
of row and cols
 On Sep 5, 2014 7:01 PM, christophe joey christophe0j...@gmail.com
wrote:

 hello


 i'm trying to rasterize my vector layer but i got this error for all
 of my vectors :

 v.to.rast input=pedo@mapset output=pedorast use=attr column=valeur
 labelcolumn=SOL
 Loading data...
 Région actuelle 51365 lignes, 56484 colonnes
 ERROR: G_calloc: impossible d'allouer 231358464 * 1 octets de mémoire
 à raster.c:79
 (Fri Sep 05 22:51:55 2014) La commande s'est terminée (0 sec)

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

Re: [GRASS-user] create a common colour scale

[Daniel Victoria]

Hi Raphael,

I do recommend upgrading and going the way Anna mentioned, especially if
you are dealing with a large number of maps. But if that is not an option
here are the steps I'd take:

1) run r.info -r on each map to get the min/max range
2) user r.colors with one of the maps and the rule option to set you color
table to that map. Your rules might look something like this
min_value red
(max - min)/2 yellow
max_value blue
end
-- by substituting the min / max in the above you get a colortable going
from red to blue with yellow in the middle
3) copy the color table you just set to the other maps using r.color rast
option. Take a look at r.color man page for more info
http://grass.osgeo.org/grass64/manuals/r.colors.html

Daniel


On Tue, Jul 22, 2014 at 11:46 PM, raphael.viscarra-ros...@csiro.au wrote:

  Thank you Daniel and Anna for the suggestions.
 Daniel, I wonder how I might display the ‘common’ colour legend when
 visualising the maps?
 When the maps are visualised, the colour legend changes to the min max of
 the current map displayed.

  Anna, I use GRASS 6.4.2 – so I guess I should upgrade…

  Thank you again.
 Raphael.


 __

 Raphael *VISCARRA ROSSEL* | Principal Research Scientist | CSIRO Land and
 Water | Bruce E. Butler Laboratory, Clunies Ross St, Black Mountain, Acton
 ACT 2601 | PO BOX 1666 Canberra ACT 2600 | t. +61 2 6246 5945 | m. +61
 467 769 364 | Chair International Union of Soil Science Working Group on
 Proximal Soil Sensing | www.researcherid.com/rid/B-4061-2011 |
 scholar.google.com.au/citations?hl=enuser=KpJdvKEJ




   From: Anna Petrášová kratocha...@gmail.com
 Date: Wednesday, 23 July 2014 12:15 pm
 To: Daniel Victoria daniel.victo...@gmail.com
 Cc: Viscarra Rossel, Raphael (LW, Black Mountain) 
 raphael.viscarra-ros...@csiro.au, grass grass-user@lists.osgeo.org
 Subject: Re: [GRASS-user] create a common colour scale

   Hi,

  in case you use GRASS 7, r.colors accepts multiple maps or a file with
 the map names. So this should do it:
 r.colors map=precip1,precip2,precip3 color=precipitation

  Also, have a look at temporal modules (GRASS 7 only). You can register
 the series of maps as a dataset (t.create, t.register) and then you can
 easily get the min, max values for the entire series and there is also
 t.rast.colors.

  Anna


 On Tue, Jul 22, 2014 at 9:41 PM, Daniel Victoria 
 daniel.victo...@gmail.com wrote:

 Hi Raphael,

  This is what I did some time ago when I had the same problem
  1) Find out the overall minimun and maximum precipitation over all maps.
  2) Use r.colors with the rules option to compose a colortable that cover
 my entire precip range.
  3) Apply the same colortable to all maps
  4) plot and be happy

  Hope it helps
  Daniel


  On Tue, Jul 22, 2014 at 10:01 PM, raphael.viscarra-ros...@csiro.au
 wrote:

   Hello
 I wonder if anyone knows how to create a common colour scale for
 different raster maps?
 I want to display all six maps on the same page with the single colour
 scale but I cannot find how to do this in GRASS.

  More specifically, I have six raster maps of rainfall for different
 time periods (each has a different range of values) and I would like to
 display them all with the same colour scale. The colour scale needs to be
 constructed using the min and max values of the set of six maps (and not
 just individual maps.

  Will appreciate any input please. Thank you,

  Raphael.

  __

 Raphael *VISCARRA ROSSEL* | Principal Research Scientist | CSIRO Land
 and Water | Bruce E. Butler Laboratory, Clunies Ross St, Black Mountain,
 Acton ACT 2601 | PO BOX 1666 Canberra ACT 2600 | t. +61 2 6246 5945 |
 m. +61 467 769 364 | Chair International Union of Soil Science Working
 Group on Proximal Soil Sensing | www.researcherid.com/rid/B-4061-2011 |
 scholar.google.com.au/citations?hl=enuser=KpJdvKEJ




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



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



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

Re: [GRASS-user] create a common colour scale

[Daniel Victoria]

Hi Raphael,

This is what I did some time ago when I had the same problem
1) Find out the overall minimun and maximum precipitation over all maps.
2) Use r.colors with the rules option to compose a colortable that cover my
entire precip range.
3) Apply the same colortable to all maps
4) plot and be happy

Hope it helps
Daniel


On Tue, Jul 22, 2014 at 10:01 PM, raphael.viscarra-ros...@csiro.au wrote:

  Hello
 I wonder if anyone knows how to create a common colour scale for different
 raster maps?
 I want to display all six maps on the same page with the single colour
 scale but I cannot find how to do this in GRASS.

  More specifically, I have six raster maps of rainfall for different time
 periods (each has a different range of values) and I would like to display
 them all with the same colour scale. The colour scale needs to be
 constructed using the min and max values of the set of six maps (and not
 just individual maps.

  Will appreciate any input please. Thank you,

  Raphael.

 __

 Raphael *VISCARRA ROSSEL* | Principal Research Scientist | CSIRO Land and
 Water | Bruce E. Butler Laboratory, Clunies Ross St, Black Mountain, Acton
 ACT 2601 | PO BOX 1666 Canberra ACT 2600 | t. +61 2 6246 5945 | m. +61
 467 769 364 | Chair International Union of Soil Science Working Group on
 Proximal Soil Sensing | www.researcherid.com/rid/B-4061-2011 |
 scholar.google.com.au/citations?hl=enuser=KpJdvKEJ




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

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

Re: [GRASS-user] logarithmic scale in raster legend

[Daniel Victoria]

What if you use r.mapcalc and apply log to your map to make a new one with
rescaled values?
On Jun 9, 2014 12:36 PM, Veronica Andreo veroand...@gmail.com wrote:

 Hi list!

 I have these raster maps of chlorophyll concentration (mg/m3) with a lot
 of very small values (from 0.02 to 1.5) and few high values (between 20 and
 100)... I managed to create my own color table to get a good visualization
 of the variation... but when I display the legend, i loose the color
 variation in smaller values...

 Is it possible to create a logarithmic legend or at least determine which
 tick-marks I'm interested in?? I've tried with use parameter in d.legend
 (which seemed to meet my needs) setting it to: 0.01,0.1,1,10,100, but works
 only for categories... There's no such a thing in ps.map, either... which
 would be the right approach? any ideas?

 Thanks much in advance!
 Best,

 Vero

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

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

Re: [GRASS-user] logarithmic scale in raster legend

[Daniel Victoria]

You are correct. Then I have no idea how to do this...


On Tue, Jun 10, 2014 at 9:32 AM, Veronica Andreo veroand...@gmail.com
wrote:

 Yeah, I also tried that, and of course, I get a nice gradient in the
 legend, but then I need to somehow edit tick-marks.
 Logarithm of chlorophyll concentration is, from my point of view,
 uninformative. I need the actual values.
 I just want to change the display of the legend, like making log of x or y
 axis in a plot, that you do not change the
 values themselves, just rescale the axis for better visualization... but
 maybe not (yet) possible in GRASS ;)

 Thanks much!
 Vero


 2014-06-10 7:40 GMT-03:00 Daniel Victoria daniel.victo...@gmail.com:

 What if you use r.mapcalc and apply log to your map to make a new one
 with rescaled values?
 On Jun 9, 2014 12:36 PM, Veronica Andreo veroand...@gmail.com wrote:

 Hi list!

 I have these raster maps of chlorophyll concentration (mg/m3) with a lot
 of very small values (from 0.02 to 1.5) and few high values (between 20 and
 100)... I managed to create my own color table to get a good visualization
 of the variation... but when I display the legend, i loose the color
 variation in smaller values...

 Is it possible to create a logarithmic legend or at least determine
 which tick-marks I'm interested in?? I've tried with use parameter in
 d.legend (which seemed to meet my needs) setting it to: 0.01,0.1,1,10,100,
 but works only for categories... There's no such a thing in ps.map,
 either... which would be the right approach? any ideas?

 Thanks much in advance!
 Best,

 Vero

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



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

Re: [GRASS-user] Crown shape drawing

[Daniel Victoria]

Hi all,

A while ago I had to do a similar task for Lidar analysis So I
made a quick python program for it. The only problem is that it spits
out boxes and not nice round shapes. The code will create both GRASS
ASCII vector format or a csv file that can be used to subset las data.
Also, since I created the program specifically for our needs, the
column numbers are fixed.

Anyway, the code is attached. Hope it helps.

Cheers
Daniel

PS1 - I'm no professional coder so I'm certain there are flaws and
leftover lines in the code. But it worked for me...
PS2 - I have another version that will generate a shapefile with
ellipses as crowns but the code is too messy. I'd like to make it more
presentable before releasing it but, if you can stomach poorly writen
python, just let me know...


On Fri, Oct 25, 2013 at 8:33 AM, Nikos Alexandris
n...@nikosalexandris.net wrote:
 On Friday 25 of October 2013 07:56:32 Matteo Mura wrote:
 Dear all,

 I have a vector-points file containing the points of trees location in a 100
 x 100 square, it is a permanent plot. The database of this vector contains
 for each sampled tree the crown projection for each direction (N-S-E-W). I
 need to convert the points to polygons which shape and size is determined
 by the crown projection measures. In other therms I would like to have the
 polygon file which describe the tree crown shape and dimension.

 Is it possible to do in GRASS? If yes, how can I?

 Not a reply, just a comment: this is a very nice question! If this gets a
 smart solution consider posting it at GIS@SE. GRASS GIS deserves/needs to
 attract more points over there.

 Nikos
 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user
# -*- coding: utf-8 -*-

Created on Mon Jun 11 17:45:47 2012

Code to create canopy boxes around stem locations
works for field data from Reserva Duke - Maria Hunter
as exported by Grass db.select!!

Altered on 8/8/2012 to work with directly with the csv data

@author: Daniel Victoria daniel.victo...@gmail.com
Sustainable Landscapes Brazil project


class boxCanopy():
Class to create and export canopy box around stem

def __init__(self, trans, stem, utm_e, utm_n, cnpN, cnpS, cnpE, cnpW):

Initialize canopy box.
stem: Stem number
utm_e  n: stem position
cnpyN,S,E,W: crown dimensions


# cleaning extra s
stem = stem.replace('','')
self.stem = 'stem_'+stem
self.cat = stem
self.trans = trans
self.utm_e = float(utm_e)
self.utm_n = float(utm_n)
self.cnpN = float(cnpN)
self.cnpS = float(cnpS)
self.cnpE = float(cnpE)
self.cnpW = float(cnpW)

# calculating N, S, E, W extremes
self.N = self.utm_n + self.cnpN
self.S = self.utm_n - self.cnpS
self.E = self.utm_e + self.cnpE
self.W = self.utm_e - self.cnpW

def spitAscii(self):  
Return canopy box in Grass ascii format
if self.skip == 1:
#print(No data for this point)
return
linha = []
linha.append(B 5\n)
linha.append(  %.8f %.8f\n % (self.W, self.S))
linha.append(  %.8f %.8f\n % (self.E, self.S))
linha.append(  %.8f %.8f\n % (self.E, self.N))
linha.append(  %.8f %.8f\n % (self.W, self.N))
linha.append(  %.8f %.8f\n % (self.W, self.S))
linha.append(C 1 1\n)
linha.append(  %.8f %.8f\n % (self.utm_e, self.utm_n))
linha.append(  1 %s\n % (self.cat))
return linha

def lasSubset(self):
Return csv file appropriate for subseting las files
using the QRSC Lidar program.
CSV must have: id, easting, northing, major, minor axis, azimuth
When subsetting rectangles, major axis is N-S dir
azimuth is clockwise from north
#if self.skip == 1:
##print(No data for this point)
#return
l = (self.stem, (self.E + self.W)/2, (self.N + self.S)/2, (self.cnpN + self.cnpS)/2, (self.cnpE + self.cnpW)/2)
linha = (%s, %.8f, %.8f, %.4f, %.4f, 0\n % l)
return linha



def processGrass(infile, outfile):
Process file with the data for GRASS output
entrada = open(infile,'r')
#skipping header
entrada.readline()
dados = entrada.readlines()
entrada.close()
saida = open(outfile, 'w')
saida.write(VERTI:\n)
for i in dados:
p = i.split('|')
if [p[2], p[4], p[5], p[13], p[14], p[15], p[16]].count('NA') == 0:
# there is data to process...
ponto = boxCanopy(p[1], p[2], p[4], p[5], p[13], p[14], p[15], p[16])
linhas = ponto.spitAscii()
for i in linhas:
saida.write(i)
saida.close()
return

def processLasSubset(infile, outfile, point_filter = ''):
Process file

Re: [GRASS-user] i.landsat.toar comments have only 0 value

[Daniel Victoria]

On Fri, Oct 18, 2013 at 12:30 PM, Nikos Alexandris
n...@nikosalexandris.net wrote:
 Daniel Victoria wrote:

 Niko,

 (thanks for paying attention to details, correct, in Greek you have to omit
 the final s when you call someone by its name, the vocative case!)


It was actually a typo! I forgot to hit the S key. I was not aware of
those differences in Greek. But hey, it worked :)

Just another piece of information. Even though the r.info output shows
all zeros, both the radiance and TOA reflectance values looks correct.
At least for band 1, when compared with radiance and reflectance
calculated manually (using gain/bias and Solar radiance formulas).

Cheers
Daniel
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] i.landsat.toar comments have only 0 value

[Daniel Victoria]

Hi all,

I'm also noticing the same problem that Beatrice and Yasser mentioned.
I'm using WinGrass7_svn rev 58021 (installed using OSGeo4W).

If I run i.landsat.toar and ask it to print the metadata (-p flag), it
gives me the correct information from the MTL file
---
(Thu Oct 17 17:26:35 2013)
i.landsat.toar -p --overwrite --verbose input_prefix=tm5_2005_orig.
output_prefix=reflec_topo_2005.
metfile=C:\projetos\agspec\correcao_landsat\LT52180762005135CUB00\LT52180762005135CUB00_MTL.txt
lsatmet=number,creation,date,sun_elev,sensor,bands,sunaz,time
number=5
creation=2012-12-01
date=2005-05-15
sun_elev=37.184012
sensor=TM
bands=7
sunaz=39.877237
Metada file is MTL file: new format
---

But when I actually run i.landsat.toar (no -p flag), I get a bunch off zeros:
---
i.landsat.toar --overwrite --verbose input_prefix=tm5_2005_orig.
output_prefix=reflec_topo_2005.
metfile=C:\projetos\agspec\correcao_landsat\LT52180762005135CUB00\LT52180762005135CUB00_MTL.txt
lsatmet=number,creation,date,sun_elev,sensor,bands,sunaz,time
Metada file is MTL file: new format
RADIANCE  QUANTIZE from data of the metadata file
 LANDSAT: 5 SENSOR: TM
 ACQUISITION DATE 2005-05-15 [production date 2012-12-01]
   Earth-sun distance= 0.
   Solar elevation angle = 0.
   Atmospheric correction: UNCORRECTED
---
 BAND 1 (code 1)
   calibrated digital number (DN): 0.0 to 0.0
   calibration constants (L): 0.0 to 0.0
   at-sensor radiance = -0. * DN + -0.0
   mean solar exoatmospheric irradiance (ESUN): -0.0
   at-sensor reflectance = radiance / -0.0
---
 BAND 2 (code 2)
   calibrated digital number (DN): 0.0 to 0.0
   calibration constants (L): 0.0 to 0.0
   at-sensor radiance = 0. * DN + -0.0
   mean solar exoatmospheric irradiance (ESUN): 0.0
   at-sensor reflectance = radiance / 0.0
-- clip --

I seem to recall the command was working fine on Linux but I'm not sure...

Cheers
Daniel

On Sat, Oct 5, 2013 at 11:27 PM, Yasser Said Lopez de Olmos Reyes
biolyas...@gmail.com wrote:
 I used osgeo4w stable version and 6.5.x svn yesterday's version. Both had 0s
 in verbose output. Sorry, I'm not in my desktop right now.


 2013/10/5 Markus Neteler neteler.os...@gmail.com

 On Sat, Oct 5, 2013 at 5:20 AM, Yasser Said Lopez de Olmos Reyes
 biolyas...@gmail.com wrote:
  I just noticed the same. Does this mean that i.landsat.toar did not read
  the
  values from the MTL file and, as a consequence, reflectances are wrong
  or is
  just a verbose display issue?

 Do you use the bugfixed version in from current SVN? Please post the
 output of
 g.version

 Markus




 --
 Saludos,

 Yasser

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

Re: [GRASS-user] i.landsat.toar comments have only 0 value

[Daniel Victoria]

Updating my last email. I also see the same problem in WinGrass 6.4.3

And on a similar topic, i.landsat.toar in Grass6 has one extra
correction method when compared with Grass7.
In grass6 there is a Corrected at-sensor values options which I don't
see in Grass7. Why is that?

Cheers
Daniel

On Thu, Oct 17, 2013 at 5:45 PM, Daniel Victoria
daniel.victo...@gmail.com wrote:
 Hi all,

 I'm also noticing the same problem that Beatrice and Yasser mentioned.
 I'm using WinGrass7_svn rev 58021 (installed using OSGeo4W).

 If I run i.landsat.toar and ask it to print the metadata (-p flag), it
 gives me the correct information from the MTL file
 ---
 (Thu Oct 17 17:26:35 2013)
 i.landsat.toar -p --overwrite --verbose input_prefix=tm5_2005_orig.
 output_prefix=reflec_topo_2005.
 metfile=C:\projetos\agspec\correcao_landsat\LT52180762005135CUB00\LT52180762005135CUB00_MTL.txt
 lsatmet=number,creation,date,sun_elev,sensor,bands,sunaz,time
 number=5
 creation=2012-12-01
 date=2005-05-15
 sun_elev=37.184012
 sensor=TM
 bands=7
 sunaz=39.877237
 Metada file is MTL file: new format
 ---

 But when I actually run i.landsat.toar (no -p flag), I get a bunch off zeros:
 ---
 i.landsat.toar --overwrite --verbose input_prefix=tm5_2005_orig.
 output_prefix=reflec_topo_2005.
 metfile=C:\projetos\agspec\correcao_landsat\LT52180762005135CUB00\LT52180762005135CUB00_MTL.txt
 lsatmet=number,creation,date,sun_elev,sensor,bands,sunaz,time
 Metada file is MTL file: new format
 RADIANCE  QUANTIZE from data of the metadata file
  LANDSAT: 5 SENSOR: TM
  ACQUISITION DATE 2005-05-15 [production date 2012-12-01]
Earth-sun distance= 0.
Solar elevation angle = 0.
Atmospheric correction: UNCORRECTED
 ---
  BAND 1 (code 1)
calibrated digital number (DN): 0.0 to 0.0
calibration constants (L): 0.0 to 0.0
at-sensor radiance = -0. * DN + -0.0
mean solar exoatmospheric irradiance (ESUN): -0.0
at-sensor reflectance = radiance / -0.0
 ---
  BAND 2 (code 2)
calibrated digital number (DN): 0.0 to 0.0
calibration constants (L): 0.0 to 0.0
at-sensor radiance = 0. * DN + -0.0
mean solar exoatmospheric irradiance (ESUN): 0.0
at-sensor reflectance = radiance / 0.0
 -- clip --

 I seem to recall the command was working fine on Linux but I'm not sure...

 Cheers
 Daniel

 On Sat, Oct 5, 2013 at 11:27 PM, Yasser Said Lopez de Olmos Reyes
 biolyas...@gmail.com wrote:
 I used osgeo4w stable version and 6.5.x svn yesterday's version. Both had 0s
 in verbose output. Sorry, I'm not in my desktop right now.


 2013/10/5 Markus Neteler neteler.os...@gmail.com

 On Sat, Oct 5, 2013 at 5:20 AM, Yasser Said Lopez de Olmos Reyes
 biolyas...@gmail.com wrote:
  I just noticed the same. Does this mean that i.landsat.toar did not read
  the
  values from the MTL file and, as a consequence, reflectances are wrong
  or is
  just a verbose display issue?

 Do you use the bugfixed version in from current SVN? Please post the
 output of
 g.version

 Markus




 --
 Saludos,

 Yasser

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

Re: [GRASS-user] access to multispectral landsat data for the UK

[Daniel Victoria]

Hi Hamish,

I was not aware of EOLi (and eolisa). Just installed and it looks lika a
nice app. But I could not figure out if there were any free satellite
images besides landsat. Do you know what images can we obtain for free,
through eolisa?

Cheers and thanks
Daniel


On Thu, Jun 20, 2013 at 8:34 PM, Hamish hamis...@yahoo.com wrote:

 Daniel wrote:

   I don't know where you are looking for these landsat images but they
 are
   free of cost for everyone. Take a look at the Earth Explorer[1] site
 from
   USGS. Even Landsat 8 data is available. I just cheched and found about
 60
   Landsat8 images over UK and Ireland with less then 30% cloud cover.
 
   [1] - http://earthexplorer.usgs.gov/

 Nikos:
  Count also glovis.usgs.org in.


 not specifically limited to landsat, but these are great resources too:

 nice MODIS etc. data portal:  http://oceancolor.gsfc.nasa.gov

 EOLi:  http://earth.esa.int/EOLi/EOLi.html   (`eolisa` java app)

 VISAT/BEAM:  http://www.brockmann-consult.de/cms/web/beam/
 (`visat` is yet another java app)


 Hamish

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

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

Re: [GRASS-user] image spatial syncronization

[Daniel Victoria]

You are right Hamish, the software is quite old and unmantained. So maybe,
the best bet would be to use the auto-pano tools Neteler suggested. I also
found the web-page of one of the developers.

http://www.dimin.net/software/scientific.html

Cheers
Daniel


On Wed, Jun 19, 2013 at 11:57 PM, Hamish hamis...@yahoo.com wrote:

 Daniel wrote:
  You could also try a software called regimy (or some other
  spelling). If I recall correctly, it was developed by some
  guys at inpe

 this seems to be the one: REGEEMY
   http://regima.dpi.inpe.br


  and it finds matching control points between a set of images.
  We have been using it for some old landsat images.

 Restrictive license, no linux binary since 2006 and no source
 code to recompile it for 64bit, so I won't bother to add it
 to the wiki (but if it's super useful I don't mind), but seeing
 they haven't touched in in years maybe the authors could be
 convinced to set it free?


 Hamish


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

Re: [GRASS-user] access to multispectral landsat data for the UK

[Daniel Victoria]

Hi Colin,

I don't know where you are looking for these landsat images but they are
free of cost for everyone. Take a look at the Earth Explorer[1] site from
USGS. Even Landsat 8 data is available. I just cheched and found about 60
Landsat8 images over UK and Ireland with less then 30% cloud cover.

Cheers
Daniel

[1] - http://earthexplorer.usgs.gov/


On Thu, Jun 20, 2013 at 3:57 PM, Dr Colin Hindmarch 
colinhindma...@talktalk.net wrote:

   Hi,

 I have have no institutional or academic affiliations and it seems that
 this limits my access (free of cost) to Landsat data for the UK. This
 wasn’t always the case, I am sure, but I gather everything these days is
 highly commercialised and tightly controlled, with little prospect of an
 unsupported loaner getting access to basic data (except for Google earth
 PNG ‘snips’ and some very useful global DEM Explorer data).

 Has anyone any ideas about open source multispectral UK data?

 I should explain that I am an ecologist on a limited budget who is
 updating using open source data and freeware programmes like GRASS, and who
 is very keen to apply these to large-scale landscapes in support of
 personal and professional development. I don’t have a research proposal in
 mind, but I am scoping opportunities as I get to grips with the software
 and the associated analytical techniques, and may at some point work up a
 few ideas.

 Colin.


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


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

Re: [GRASS-user] image spatial syncronization

[Daniel Victoria]

Hi Miltinho,

You could also try a software called regimy (or some other spelling). If I
recall correctly, it was developed by some guys at inpe and it finds
matching control points between a set of images. We have been using it for
some old landsat images.

Cheers
Daniel
On Jun 17, 2013 2:35 PM, miltinhoastronauta . 
miltinho.astrona...@gmail.com wrote:

 WAW!!! Great suggestions, let try it!

 [ ]s

 milton

 2013/6/16, Nikos Alexandris n...@nikosalexandris.net:
  Markus Neteler wrote:
   The easiest thing might be to use a SIFT algorithm in order to find
 the
   GCPs automatically. Then use those as an input for i.rectify or
   similar.
   SIFT is used by Hugin for example.
 
   I used autopano-sift-C for a similar task (Fedora, rpmfusion-free
   repository).
 
  Hamish wrote:
  link:
http://grasswiki.osgeo.org/wiki/Stereoscopic_analysis#See_also
 
  Really nice!  Thank you, N
 


 --
 Miltinho - m...@rc.unesp.br
 Laboratório de Ecologia Espacial e Conservação - LEEC
 Depto de Ecologia - UNESP - Rio Claro
 Av. 24A, 1515- Bela Vista
 13506-900 Rio Claro, SP, Brasil

 Fone: +55 19 3526-9647 (office)  19 3526-9680 (lab)
 Cel: 19 9853-3220 / 19 9853-5430

 Depto Ecologia http://www.rc.unesp.br/ib/ecologia/

 PG ECO  BIODIV
 http://www.rc.unesp.br/ib/ecologia/posbiodiversidade/index.php

 CV
 http://buscatextual.cnpq.br/buscatextual/visualizacv.do?id=K4792988H6mostrarNroCitacoesISI=truemostrarNroCitacoesScopus=true

 Google citations http://scholar.google.com/citations?user=OWX_2eAJ
 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user

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

Re: [GRASS-user] HydroFlow: Stream order soleley based on shape files/vectors

[Daniel Victoria]

Hi,

I used the software some time ago and it worked nicely. And as Johannes
explained, the only data needed is the river network and the basin boundary.

I'll try to translate the algorithm behind the software but I'm a bit
confused by it so I could be doing a worse job then a google translator...

1) If a river segment is connected to the river network at only one point
and the segment does not touch the basin boundary, those are the first
order streams rivers and their flow direction can be defined from the
unconnected end to the connected end

2) If the endpoint of a river segment touches other segments that have
their flow directions determined and the flows converge, then:
   The flowdirection of the segment goes from the examined endpoint to the
other end;
   You can calculate the stream order by looking at the stream orders of
the segments that flow into the analyzed segment.

If the segments that touch an endpoint does not have their flowdirection
determined, then the flowdirection the analyzed endpoint cannot be
determined and that indefinition caries out throuhg the river network (fig2
in the example).
The software does not work if you have loops in your river network.

Here is the link of the manual explaining the algorithm, but it's in
portuguese
http://www.fgel.uerj.br/labgis/hydroflow/Help/helphydroflow.html

Cheers
Daniel

On Tue, Jun 18, 2013 at 11:19 AM, Johannes Radinger 
johannesradin...@gmail.com wrote:

 1) Concerning the flow direction / network direction

 So far what I can understand from the html-manual, the only two
 input data is the map with the river network and a line or polygon file
 the defines the catchement. The flow direction within the network
 is then defined by the outflow point which is the only line of the river
 that touches or intersects with the catchment border. Unfortunately,
 neither I am a native Brasilian (which makes reading the manual difficult)
 nor
 I am able to read or understand the source code behind the model

 2) Concerning the license
 It is licensed under GNU GPL:
 http://www.fgel.uerj.br/labgis/hydroflow/Help/helphydroflow.html?{D3EB24A2-0B1B-4CA1-B0C6-F05855A23C8D}.htm

 @Madi: No unfortunately I haven't tried HydroFlow yet. I first have to
 figure out how to compile it using qmake on my ubuntu machine. Concerning
 v.strahler: AFAIK also this module needs a DEM to identify flow direction,
 which is often not available when you have only the river vector. And of
 course HydroFlow also provides other measures of stream order beside
 Strahler...

 I hopefully get the tool installed quite soon. I will then report how well
 it is working.

 /Johannes


 On Tue, Jun 18, 2013 at 3:08 PM, Markus Metz 
 markus.metz.gisw...@gmail.com wrote:

 On Tue, Jun 18, 2013 at 1:52 PM, Johannes Radinger
 johannesradin...@gmail.com wrote:
  Hi,
 
  I found following interesting Brasilian program called HydroFlow:
  http://www.fgel.uerj.br/labgis/hydroflow/en/downloads_ingles.html
 
  This tools calculates the Stream order (e.g. Strahler, Shreve)
  based on a shapefile input of the river network and a shapefile that
 defines
  the border (catchment?). If I am informed correctly such a tool that
 does
  not require any form of a DEM (or accumulation map etc.) is not
 existing for
  GRASS yet.

 One bit of requirement information must be provided in addition to the
 shapefile: the outlet of a river network. If the lines of the
 shapefile follow drainage dirction, this is possible, because then per
 network only one line will go towards an end point. You could look at
 the description or source code if possible to find out how HydroFlow
 identifies the outlet of a river network.

 Markus M


 
  There are just two questions that appeared to me:
 
  1) Has anyone installed and tried the programm already in Ubuntu/Linux?
 
  2) The tool is licensed as open source. So, could such a algorithm also
 be
  implemented as
  a add-on to GRASS? I am not sure but I can imagine that this might be of
  interest also to
  other GRASS users!?
 
  /johannes
 
  ___
  grass-user mailing list
  grass-user@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/grass-user
 



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


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

Re: [GRASS-user] Making images colours uniform

[Daniel Victoria]

I never used it but I believe there is an addon I.hist.match for histogram
matching
On Mar 27, 2013 7:35 AM, Paolo Cavallini cavall...@faunalia.it wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Il 27/03/2013 11:32, Moritz Lennert ha scritto:

  I'm not sure if I completely understand what you are looking for, but
 does
 
  r.colors raster=
 
  do what you want ?

 Sorry I was unclear. I have a series of ortophotos, each of them with a
 different
 colour blend; when mosaicked, the result is ugly. My objective is to make
 them look
 more similar.
 Thanks.

 - --
 Paolo Cavallini - Faunalia
 www.faunalia.eu
 Full contact details at www.faunalia.eu/pc
 Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.12 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAlFSy1MACgkQ/NedwLUzIr4ZIwCgj8R3/V0cejYeXu3lYxh+THnB
 XLUAnRMR80cB3Bj5LSSh52BDiBph3dll
 =2KOs
 -END PGP SIGNATURE-
 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user

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

Re: [GRASS-user] GRASS 6.4 Windows - How to change current directory

[Daniel Victoria]

Are you putting a : between the cd and the path (d:\dir)?
If yes,  remove that :

Daniel
On Mar 27, 2013 11:04 AM, BLANDENIER Lucien lucien.blanden...@unine.ch
wrote:

 Hi all,

 I have some problem to change the current directory on the windows
 terminal. I used cd : d:\directory but I stay in the same directory...

 Do someone knows how to do that on windows?

 Thanks for your help.


 Lucien


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

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

Re: [GRASS-user] RE : GRASS 6.4 Windows - How to change current directory

[Daniel Victoria]

Hi Lucien,

I sent the email but I did not test. Now I'm sitting in front of my winbox
and indeed, it does not work.
In winGrass v7 the command terminal is kept open so you can issue commands
like change directory and the likes. But I'm not able to do it in 6.4

Daniel


On Wed, Mar 27, 2013 at 1:20 PM, BLANDENIER Lucien 
lucien.blanden...@unine.ch wrote:

 Hi Daniel,

 Thank you for your suggestion but it neither works.

 Others idea?

 
 De : Daniel Victoria [daniel.victo...@gmail.com]
 Date d'envoi : mercredi 27 mars 2013 16:54
 À : BLANDENIER Lucien
 Cc: grass
 Objet : Re: [GRASS-user] GRASS 6.4 Windows - How to change current
 directory


 Are you putting a : between the cd and the path (d:\dir)?
 If yes,  remove that :

 Daniel

 On Mar 27, 2013 11:04 AM, BLANDENIER Lucien lucien.blanden...@unine.ch
 mailto:lucien.blanden...@unine.ch wrote:
 Hi all,

 I have some problem to change the current directory on the windows
 terminal. I used cd : d:\directory but I stay in the same directory...

 Do someone knows how to do that on windows?

 Thanks for your help.


 Lucien


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

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

Re: [GRASS-user] use grass to process data for R biomod

[Daniel Victoria]

Take a look at v.what.rast
It will upload raster values to an attribute table. That might do what you
are looking for.

Daniel
On Mar 2, 2013 4:44 AM, 孔晓泉 u1mail...@gmail.com wrote:

 Hi,

 I'm working on my paper, which i will use R package biomod. In
 biomod manual, i found it support such table format (other format? i
 don't konw, i am a newer to R and grass).

  Idw   X Y Var1 Var2  Var3 Var4  Var5   Sp281  Sp191
  73 -9.288 38.62 0.6683 4296 770.1 39.33 295.11  0
  74 -9.292 39.52 0.7596 4174 928.1 57.32 348.70  1


 - Idw: An Id to keep track of the row numbers
 - X and Y: longitude and latitude of our sites (used for plotting)
 - Var1 to Var5: Environmental variables (bioclimatic in that case)
 - Sp281 Sp191: Presence/absence of 2 species.

 I get the species data from web( shapefile format) and the
 envirmonental data (Rast format).
 For so far, i only kown r.mapcalc new_var = if(var,env1), so i can
 get the env1 data when specie is presence,but this is not what i want.
 so, someone can help me? give me some point, please.
 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user

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