[GRASS-user] Bit rot in the Wiki (and other places)

[Peter Löwe via grass-user]

Hi all,

I just noticed by chance that we have some cases of bit rot in the Wiki: The 
webpages of past conferences have gone offline and the URL links in the Wiki 
are dead (e.g Trento 2001 / 2002, Bangkok 2002, probably more ). This is not a 
big deal as the pages have been preserved by the internet archive (e.g. 
https://web.archive.org/web/20030311060643/http://www.ing.unitn.it/~grass/conferences/GRASS2002/home.html)
 but might need to be adressed more generally.

This could be a topic for the Community Meeting in Prague.

Best,
Peter




> Gesendet: Mittwoch, 27. März 2024 um 21:00 Uhr
> Von: grass-user-requ...@lists.osgeo.org
> An: grass-user@lists.osgeo.org
> Betreff: grass-user Digest, Vol 215, Issue 25
>
> Send grass-user mailing list submissions to
>   grass-user@lists.osgeo.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://lists.osgeo.org/mailman/listinfo/grass-user
> or, via email, send a message with subject or body 'help' to
>   grass-user-requ...@lists.osgeo.org
> 
> You can reach the person managing the list at
>   grass-user-ow...@lists.osgeo.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of grass-user digest..."
> 
> 
> Today's Topics:
> 
>1. GRASS GIS Community Meeting in Prague, June 14-19, 2024
>   (Veronica Andreo)
> 
> 
> --
> 
> Message: 1
> Date: Tue, 26 Mar 2024 16:53:44 -0400
> From: Veronica Andreo 
> To: GRASS-announce list 
> Subject: [GRASS-user] GRASS GIS Community Meeting in Prague, June
>   14-19, 2024
> Message-ID:
>   
> Content-Type: text/plain; charset="utf-8"
> 
> Dear all,
> 
> The GRASS GIS team announces its annual Community Meeting!!
> 
> Join us in Prague (June 14-19) to:
> - Develop & Discuss: Code, docs, translations & integrations (QGIS, GDAL, R)
> - Plan the future: Chart the project roadmap & tackle big challenges!
> - Celebrate GRASS birthday & community achievements!
> 
> Get involved and support! We welcome in person and online participants!
> You can sign up at:
> https://grasswiki.osgeo.org/wiki/GRASS_Community_Meeting_Prague_2024
> 
> Sponsor us!
> https://opencollective.com/grass/contribute
> 
> Shall you have any further questions, contact Vero Andreo at <
> veroand...@gmail.com>
> 
> Looking forward to meeting you!
> The GRASS GIS team
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> 
> 
> --
> 
> Subject: Digest Footer
> 
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
> 
> 
> --
> 
> End of grass-user Digest, Vol 215, Issue 25
> ***
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Spearfish data set: Scientific reference by DOI

[Peter Löwe]

Hello list,

the Spearfish sample database for GRASS GIS can now be referenced in 
publications by a Digital Object Identifer (DOI).
This applies for particular earlier versions of the dataset for older GRASS GIS 
releases (by version DOI) and also for the overall dataset (concept DOI):

https://doi.org/10.5281/zenodo.7930522

Best,
Peter



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

Re: [GRASS-user] Spearfish datatset for GRASS 4.x and earlier.

[Peter Löwe]

Markus,

my bad: I should have spotted that one :-)

Thanks,
Peter




> Gesendet: Samstag, 13. Mai 2023 um 12:41 Uhr
> Von: "Markus Neteler" 
> An: "Peter Löwe" 
> Cc: grass-user@lists.osgeo.org
> Betreff: Re: [GRASS-user] Spearfish datatset for GRASS 4.x and earlier.
>
> Hi Peter,
> 
> On Sat, May 13, 2023 at 11:47 AM Peter Löwe  wrote:
> >
> > Hi all,
> >
> > (where) is the Spearfish demo data set still available online for GRASS 4.x 
> > and possibly also earlier GRASS versions ?
> 
> Please see here:
> https://grass.osgeo.org/sampledata/
> --> spearfish_grass4data.tar.gz1999-03-08 15:24 6.5M
> 
> Best,
> Markus
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Spearfish datatset for GRASS 4.x and earlier.

[Peter Löwe]

Hi all,

(where) is the Spearfish demo data set still available online for GRASS 4.x and 
possibly also earlier GRASS versions ?

Best,
Peter



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

[GRASS-user] Statement Peter Loewe

[Peter Löwe]

Hello GRASS community,

 

a big thanks to everybody who nominated me as a candidate for the next PSC term !

 

Over twenty years ago (1998) I discovered GRASS (4.2.1) to wrangle with weather radar data for a PhD project in South Africa. The PhD project led to one of first GRASS-centered LiveLinux CDs, to make scientific results, software, and data open, accessible and reusable [1]. In 2000 I joined the newly founded german GRASS Anwender Verein (now FOSSGIS), serving as Deputy Chair 2008 – 2009.

 

I have used GRASS professionally for the development of Tsunami early warning systems, satellite based remote sensing workflows, and cluster-based high performance computing. Currently I am responsible for the scientific infrastructure of the German Institute for Economic Research (DIW Berlin), where GRASS is used on a daily basis to process data from longitudinal surveys. DIW Berlin was also proud to host GRASS codesprint 2019.

 

GRASS has enabled me to explore new GIS use cases and to develop add-ons for GRASS 5.x/6.x, inluding expert system integration, 3d printing, and GRASS software citation, the latter with the support of Vaclav Petras.

 

Since 2007 I’ve been supporting OSGeo as an elected Charter member, becoming co-Chair of the Open Geoscience Committee (together with Maxi Cannata) in 2016, when the GRASS community also elected me to serve in the previous GRASS PSC term.

 

I advocate GRASS and OSGeo in the Earth and Space Informatics (ESSI) chapters of both the European Geoscience Union (EGU) and the American Geophysical Union (AGU), by organising annual Townhall events and have helped to negotiate a Memorandum of Understanding between OSGeo and AGU in 2017.

 

When working at the German National Library's of Science and Technology (TIB), I established the still continuing collection of OSGeo releated scientific videos and conference recordings in the TIB online collection for scientific video, beginning with the GRASS 1987 promotional video, narrated by William Shatner (-> Star Trek Original Series) [2][3].  Since then, every year over 100 hours of OSGeo-related video from FOSS4G conferences are now being preserved by TIB for education and research. This includes the beautiful renderings of the evolution of the GRASS codebase by Markus Neteler [4].


If I should be elected for the new PSC, I will push for these topics:

 

- Education and reach out to early career scientists to get new generations of users and developers on board, especially in developing nations.

 

- Professional recognition for GRASS related work by scientific citation and reference, both for new code but also maintenance of the codebase and generation of data.  

 

- Fostering exchange with organisations advancing the state-of-art of good scientific practice, like the FAIR prinicples (Findable, Accessible, Interoperable, Reusable) and Open Science. The GRASS community is a role model for this. They can learn from us and we can learn from them.

 

- Long term software curation and discovery: Now that the GRASS repo is git-based, we can tie into global repository infrastructures (Zenodo, re3data) for long term archiving and code preservation.

 

- Improving the discoverability and fostering reuse of the growing GRASS-/OSGeo-related video "library".

 

- A „historical“-section in the GRASS web presence to provide information about GRASS-related real-world memorabilia and artifacts of the last 37 years, including the GRASS manual signed by William Shatner, historic tape reels, T-Shirt designs from the 1980s, etc. 

 

Best,

Peter

 

[1] https://doi.org/10.5281/zenodo.1164724

[2] https://doi.org/10.5446/12963

[3] https://doi.org/10.5281/zenodo.1420936

[4] https://doi.org/10.5446/14652

 




 

 


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

[GRASS-user] Ground penetrating radar (GPR) 3D processing with GRASS, anyone ?

[Peter Löwe]

Hello list,

does anybody know about examples/documentation on GRASS GIS being used for the 
modelling of 3D subsurface structures, based on or derived from GPR-scans ?

Best,
Peter




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

[GRASS-user] Example project for a GRASS GIS module on GitHub

[Peter Löwe]

Hi Vasek,

thanks for setting up the demo module on GitHub!

To demonstrate how module authors can get credit by scientific citation, some 
kind of reference/howto describing how the integration of the GitHub project 
and the Zenodo data repositiory (https://www.zenodo.org/) can be achieved, as 
explained here: 
https://www.zenodo.org/login/?next=%2Faccount%2Fsettings%2Fgithub%2F  
https://guides.github.com/activities/citable-code/
By doing so, a persistent identifier (DOI) is assigned to the GRASS module 
codebase. Zenodo also offers a handy tool to provide citation strings for the 
modulde code in hundreds of citation styles.

Best regards,
Peter



> From: grass-user  On Behalf Of Vaclav 
> Petras
> Sent: torsdag 30. januar 2020 02:31
> To: grass-...@lists.osgeo.org; GRASS user list 
> Subject: [GRASS-user] Example project for a GRASS GIS module on GitHub
>
> Dear users and contributors,
>
> I've created an example project (repository) on GitHub. It is a GRASS GIS 
> module written in Python which simply adds two raster maps together. It uses 
> GitHub Actions to build the module and publish its documentation as a website 
> (using GitHub Pages).
>
> https://github.com/wenzeslaus/r.example.plus
>
> This is based on my earlier work on an example project on GitLab [1] and 
> includes several improvements and changes:
>
> * There is a test suite included with couple of test functions.
> * It uses Black for code formatting (assuming author runs it manually).
> * Repository is marked as a template (see the big "Use this template" button).
> * GitHub Actions are used for:
>   * compiling the module and running tests,
>   * checking code quality with Flake8 and Pylint, and
>   * checking code style with Black.
> * GitHub Actions are now used for publishing documentation (done by GitLab CI 
> before).
> * Option names now follow GRASS GIS standards more.
> * More documentation in the code and on how to use the code.
> * Badges are now in the README file (GitLab had those as project properties).
>
> Otherwise, I hope the project should describe itself and if something is 
> missing or is not documented enough, please open an issue or a pull request.
>
> Best,
> Vaclav
>
> PS: We can discuss on grass-dev if this should go under some organization and 
> how to improve the "what's next" part [2].
>
> [1] https://lists.osgeo.org/pipermail/grass-dev/2018-November/090438.html
> [2] https://github.com/wenzeslaus/r.example.plus#what-is-next

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

Re: [GRASS-user] Wrangling CityGML with GRASS ?

[Peter Löwe]

Hi Markus,
 

I am not sure whether GMLAS is currently supported:

ogr2ogr -f GeoJSON SMALL.json GMLAS:SMALL.gml -oo REMOVE_UNUSED_LAYERS=YES -oo REMOVE_UNUSED_FIELDS=YES -sql "SELECT * FROM groundsurface"

throws 

"FAILURE:
Unable to open datasource `GMLAS:SMALL.gml' with the following drivers.
  -> `OGR_GRASS'
  -> `PCIDSK'
  -> `PDF'

 [...]
"

-> with no mentioning of GMLAS as a driver option.

 

Best,

Peter

 






You need to rebuild GDAL accordingly, but

 

> override for the import-driver:
>  
> ogr2ogr -f GeoJSON SMALL.json GMLAS:SMALL.gml -oo REMOVE_UNUSED_LAYERS=YES -oo REMOVE_UNUSED_FIELDS=YES -sql "SELECT * FROM groundsurface"

 

apparently GMLAS is supported. What is the exact error message for " GDAL2.3.1 in GRASS refuses to accept the "GMLAS:""?

 

Markus M





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

Re: [GRASS-user] Wrangling CityGML with GRASS ?

[Peter Löwe]

Hi Markus, all,

 

one option to deal with this is in a structured way could be to use the GMLAS-driver of GDAL, prior to the import into GRASS via v.in.ogr, as 
Stelios Vitalis described it here: https://3d.bk.tudelft.nl/svitalis/citygml/gdal/2017/07/24/messing-around-with-citygml-on-gdal-2.2.html (last code example) 

 

For me, GDAL2.3.1 in GRASS refuses to accept the "GMLAS:" override for the import-driver:

 

ogr2ogr -f GeoJSON SMALL.json GMLAS:SMALL.gml -oo REMOVE_UNUSED_LAYERS=YES -oo REMOVE_UNUSED_FIELDS=YES -sql "SELECT * FROM groundsurface"

 

--> if GDAL-4-GRASS is currently built without GMLAS-support, it would be wortwhile to include it soonish (-> benefits: https://inspire.ec.europa.eu/sites/default/files/presentations/gml_application_schema_made_easy_in_gdal_ogr_and_qgis_-_gmlas_driver_0.pdf) 

 

Otherwise, the standard GML-driver doesn't feature the REMOVE_xxx options:

ogr2ogr -f GeoJSON SMALL.json SMALL.gml -oo REMOVE_UNUSED_LAYERS=YES -oo REMOVE_UNUSED_FIELDS=YES -sql "SELECT * FROM groundsurface"

 

Warning 6: driver GML does not support open option REMOVE_UNUSED_LAYERS
Warning 6: driver GML does not support open option REMOVE_UNUSED_FIELDS
ERROR 6: The GeoJSON driver does not overwrite existing files.
ERROR 1: GeoJSON driver failed to create SMALL.json
 

Best,

peter

 


 



 
 

Gesendet: Donnerstag, 08. August 2019 um 15:15 Uhr
Von: "Markus Metz" 
An: "Peter Löwe" 
Cc: grass-user 
Betreff: Re: [GRASS-user] Wrangling CityGML with GRASS ?



On Thu, Aug 8, 2019 at 2:59 PM "Peter Löwe" <peter.lo...@gmx.de> wrote:
>
> Hello Markus, Stefan, all,
>
> thanks for all your advice. New challenges have emerged, as the dataset is defined as a polyhedral surface:
>
> I upgraded to GRASS 7.6.1 which comes with GDAL 2.3.1.
>
> The data sources are official CityGML files provided by the German Federal Agency for Cartographyand Geodesy (Bundesamt für Kartographie), which have an ".xml"-extension.
>
> v.in.ogr -2 -o --o input=TEST.xml output=TEST01
> throws several warnings and creates an empty vector without an points/lines in it:
>
>  Warning 1: Unrecognized geometry type : 1015                            [<=== note this!]
> No projection information available for layer 
> Übersteuere die Überprüfung der Projektion.
> Check if OGR layer  contains polygons...
>  100%
> WARNUNG: Vektorkarte  existiert bereits und wird überschrieben.
> Creating attribute table for layer ...
> Importing 1 features (OGR layer )...
> WARNUNG: Skipping unsupported geometry type 'POLYHEDRALSURFACE'           [<=== note this!]
 

v.in.ogr could force-convert these polyhedral surfaces to multipolygons, at the risk of getting garbage.

 

The required change to v.in.ogr would be small, but it would be safer to skip these unsupported feature types in order to avoid garbage output.

 

Markus M

 

 




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

[GRASS-user] Wrangling CityGML with GRASS ?

[Peter Löwe]

Hello Markus, Stefan, all,

thanks for all your advice. New challenges have emerged, as the dataset is 
defined as a polyhedral surface:

I upgraded to GRASS 7.6.1 which comes with GDAL 2.3.1.

The data sources are official CityGML files provided by the German Federal 
Agency for Cartographyand Geodesy (Bundesamt für Kartographie), which have an 
".xml"-extension.

v.in.ogr -2 -o --o input=TEST.xml output=TEST01
throws several warnings and creates an empty vector without an points/lines in 
it:

 Warning 1: Unrecognized geometry type : 1015[<=== 
note this!]
No projection information available for layer 
Übersteuere die Überprüfung der Projektion.
Check if OGR layer  contains polygons...
 100%
WARNUNG: Vektorkarte  existiert bereits und wird überschrieben.
Creating attribute table for layer ...
Importing 1 features (OGR layer )...
WARNUNG: Skipping unsupported geometry type 'POLYHEDRALSURFACE'   [<=== 
note this!]
 100%
-
Erstelle Topologie für die Vektorkarte ...
Registriere Primitive...
WARNUNG: Input data contains 3D features. Created vector is 2D only,
 disable -2 flag to import 3D vector.


This problem seems to be ogr/gdal related:

ogrinfo -al TEST.xml
describes the geometry as a POLYHEDRALSURFACE Z (((412033.466 5812969.869 
...))).

ogr2ogr -f "GML" TEST.gml TEST.xml  fails (some effect when trying other target 
formats like CSV or ESRI shape:
Warning 1: Unrecognized geometry type : 1015
ERROR 6: Unsupported geometry type 3D PolyhedralSurface
ERROR 1: Export of geometry to GML failed
ERROR 1: Terminating translation prematurely after failed
translation of layer Building (use -skipfailures to skip errors)

There is GDAL documentation about surfaces 
(https://gdal.org/development/rfc/rfc64_triangle_polyhedralsurface_tin.html), 
but I couldn't find anything about transformations/pruning from 3D to 2D.

The CGAL library appears to be capable to handle such surfaces, but 
GIS-integration seems to be limited (https://www.cgal.org/).

Ideas on how to proceed, anyone ?

best,
Peter 








> Gesendet: Dienstag, 06. August 2019 um 14:46 Uhr
> Von: grass-user-requ...@lists.osgeo.org
> An: grass-user@lists.osgeo.org
> Betreff: grass-user Digest, Vol 160, Issue 5
>
> Send grass-user mailing list submissions to
>   grass-user@lists.osgeo.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://lists.osgeo.org/mailman/listinfo/grass-user
> or, via email, send a message with subject or body 'help' to
>   grass-user-requ...@lists.osgeo.org
> 
> You can reach the person managing the list at
>   grass-user-ow...@lists.osgeo.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of grass-user digest..."
> 
> 
> Today's Topics:
> 
>1. Re: Problems starting grass 7.4.1 in ubuntu (Markus Metz)
>2. Re: wms google (Micha Silver)
>    3. Re: Wrangling CityGML with GRASS ? (Stefan Blumentrath)
>4. Re: Wrangling CityGML with GRASS ? (Peter Löwe)
>5. Re: Wrangling CityGML with GRASS ? (Markus Metz)
> 
> 
> --
> 
> Message: 1
> Date: Mon, 5 Aug 2019 22:32:12 +0200
> From: Markus Metz 
> To: Sebastián Dietrich 
> Cc: grass-user 
> Subject: Re: [GRASS-user] Problems starting grass 7.4.1 in ubuntu
> Message-ID:
>   
> Content-Type: text/plain; charset="utf-8"
> 
> On Mon, Aug 5, 2019 at 5:35 PM Sebastián Dietrich 
> wrote:
> >
> > Hi everyone, when i try to launch g.gui i get the following message:
> >
> > GRASS 7.4.1 (EPSG5344):~/Documentos/grassdata > g.gui
> > Lanzando GUI  en el fondo, por favor espere...
> > Traceback (most recent call last):
> >   File "/usr/lib/grass74/gui/wxpython/wxgui.py", line 25, in 
> > from core import globalvar
> >   File "/usr/lib/grass74/gui/wxpython/core/globalvar.py", line 39, in
> 
> > 'locale')).ugettext
> > AttributeError: 'GNUTranslations' object has no attribute 'ugettext'
> > [MÁSCARA ráster presente]
> > GRASS 7.4.1 (EPSG5344):~/Documentos/grassdata >
> >
> > Can someone help with this issue?
> 
> GNUTranslations has an attribute ugettext only in Python2, not in Python3.
> Make sure that the link "python" points to "python2", test with "python
> --version"
> 
> Markus M
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.osgeo.org/pipermail/grass-user/attachments/20190805/c9190edf/attachment-0001.html>
> 
> --
> 
> Message: 2
> Date: Tue, 6 Aug 2019 09:19:31 +0300
> F

Re: [GRASS-user] Wrangling CityGML with GRASS ?

[Peter Löwe]

Hi Stefan,

thanks for the link: That's also the latest information we found so far, except 
for several OSGeo conference recordings (e.g. https://doi.org/10.5446/40913 
https://doi.org/10.5446/40694).
My colleagues have ingested CityGML datasets into R, which caused issues with 
the vector-topology for individual buildings. Also, we have to cope with 
significant amounts of CityGML datasets, which would require very large amounts 
of RAM, if the processing is done in R. Since GRASS locations are 
storage-effective AND GRASS handles vector topologies well, I had hoped that 
someone already explored this approach further :-)

If this should be not the case (yet) we'll gladly report at one of next years 
FOSS4G events.

Best,
peter   




> Gesendet: Dienstag, 06. August 2019 um 11:13 Uhr
> Von: "Stefan Blumentrath" 
> An: "Peter Löwe" , "grass-user@lists.osgeo.org" 
> 
> Betreff: RE: [GRASS-user] Wrangling CityGML with GRASS ?
>
> Hi Peter,
> 
> Not personally...
> I would guess you would import CityGML through GDAL:
> https://3d.bk.tudelft.nl/svitalis/citygml/gdal/2017/07/24/messing-around-with-citygml-on-gdal-2.2.html
> There you can create subsets and the like...
> 
> What are you planning to do with it, roughly?
> 
> Cheers
> Stefan
> 
> 
> -Original Message-
> From: grass-user  On Behalf Of "Peter 
> Löwe"
> Sent: torsdag 1. august 2019 11:10
> To: grass-user@lists.osgeo.org
> Subject: [GRASS-user] Wrangling CityGML with GRASS ?
> 
> Hi list,
> 
> I'm looking for information/howtos/etc. about how to deal with large CityGML 
> data sets using GRASS.
> 
> Has anybody already explored this ?
> 
> Best,
> Peter
> 
> 
> 
> ___
> 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] Wrangling CityGML with GRASS ?

[Peter Löwe]

Hi list,

I'm looking for information/howtos/etc. about how to deal with large CityGML 
data sets using GRASS.

Has anybody already explored this ?

Best,
Peter



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

[GRASS-user] How many subscribers on the GRASS user/dev mailing lists ?

[Peter Löwe]

Hi all,

is there a place to look up the current number of people subscribed to the 
users / dev mailing lists ?

Thanks,
Peter



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

[GRASS-user] Example project on GitLab: Access / discoverablity

[Peter Löwe]

Hi Vaclav,
 





 


Is it already possible to integrate this code into a local GRASS installation via g.extension (https://grass.osgeo.org/grass74/manuals/g.extension.html) ?

 

Yes, it is, but only on Linux, macOS and other unix-like systems.

 

-> That's great ! 

 


Can you give recomendations what keywords/metadata should be attached to such external GRASS repos so users will find them ?

 
I think that's a challenge and that's one of the reasons, the official GRASS GIS Addons repository is still the best option.

 

The search on GitLab as well as GitHub (and pretty much everywhere) does not distinguish keywords from names or descriptions, so as long as "GRASS GIS" and "module" is somewhere, it's good. However, this can also give a lot of results which are not GRASS GIS modules. The ultimate test is of course examining the content, e.g. the couple lines in the Makefile. Adding "g.extension" as a keyword and/or expecting in a README file might be a way, but still only approximate and it is an odd keyword to have.

 

 

-> Maybe at this point the Citation File Format, as already introduced through the g.citation module, could be a step forward: IF a repo contains the keyword "GRASS GIS" AND there is a CFF file, this could be mined for structured information about the code.

 

-> Currently, Zenodo (as a DOI generator) can only be linked to GitHub, but IMHO it's just a matter of time until they also support GitLab. Once that happens we should brace ourselves for a diaspora of GRASS mini-repos as the academia-based developers will go after scientific credit / citation by DOI. In such a situation finding/discovering useful add-ons will become a challenge (unless the code is placed in the canoncal GRASS project repos :-) ).

 

Best,

Peter



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

[GRASS-user] Example project on GitLab: Access / discoverablity

[Peter Löwe]

Hi Vaclav,

thanks for setting up the r.example.plus example GitLab project. This is an 
interesting reference case.

Is it already possible to integrate this code into a local GRASS installation 
via g.extension (https://grass.osgeo.org/grass74/manuals/g.extension.html) ?

Can you give recomendations what keywords/metadata should be attached to such 
external GRASS repos so users will find them ?

best,
Peter



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

[GRASS-user] GRASS GIS in Archaeology: how to get a cross section -> r3 volumes

[Peter Löwe]

Lluís,

your cross-sections seem to be comparable to geologic strata: Modelling them as 
3D-volumes works well in GRASS. 
(https://grass.osgeo.org/grass76/manuals/raster3dintro.html) 

Examples from a geologic strata-stack on slides 41 and 42:
https://www.slideshare.net/loewe/fossgis-portland-20143dprintingmidresrelease?qid=1e0d4b36-f2f1-4c19-a46d-af240ad9298a==_search=2

The data was imported from a vector sources, then converted to raster layers 
(2.5d) which where then blended together into a r3 volume (slide 47 lists the 
modules which were used).

best,
Peter





>4. GRASS GIS in Archaeology: how to get a cross section
>   (Lluís Vicens)
> 
> 
> --
> --
> 
> Message: 4
> Date: Mon, 12 Nov 2018 10:40:09 +0100
> From: Lluís Vicens 
> To: grass-user@lists.osgeo.org
> Subject: [GRASS-user] GRASS GIS in Archaeology: how to get a cross
>   section
> Message-ID: <623c6ad2-ca5a-bbba-7d49-2dcd49e6d...@udg.edu>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
> 
> Hi everyone,
> 
> Let me share some doubts and concerns regarding to a concrete 
> application of GRASS GIS to archaeology.
> 
> The point is that I would like to prepare some training exercises for a 
> group of archaeologists, and I'm dealing right now with the problem of 
> how to properly represent stratigraphic sections or cross sections over 
> an excavation site. I mean something like this:
> 
> stratigraphy
> 
> For the training exercises, I could own a collection or a series of 
> digital surface models (dsm), relative to every single step or 
> excavation phase on the excavation's site process. In a practical way, 
> that means that every time a stratum is removed, the archaeologists can 
> get a new digital surface model using a drone and a lidar sensor. Then 
> computing the difference between the previous dsm and the current one 
> (and so on, successively), they could obtain a collection of stratum or 
> layers to visualize it in a cross section diagram. I don't know if the 
> problem is enough well explained...
> 
> I've been reading and searching on the Internet for a while, about GRASS 
> GIS and stratigraphic/cross sections, but I've didn't find any hint 
> neither a clear clue about how to do it. So, the question is, is it 
> possible to get something similar to the previous or the following image 
> using GRASS GIS, as well as combined, with other tools or open source 
> software? Any answer, hint or clue will be really appreciated.
> 
> model
> 
> 
> Thanks,
> Lluís
> 
> -- 
> Lluís Vicens
> Servei de Sistemes d'Informació Geogràfica
> --
> Universitat de Girona
> --
> Pl. Ferrater Mora 1
> 17071   Girona
> Tel +34 972 418 039 (7025 intern)
> lluis.vic...@udg.edu
> 
> Lloc web:http://www.sigte.udg.edu
> Twitter:http://twitter.com/SIGTE_UdG
> 
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> 
> -- next part --
> A non-text attachment was scrubbed...
> Name: gall0302lrg.jpg
> Type: image/jpeg
> Size: 214771 bytes
> Desc: not available
> URL: 
> 
> -- next part --
> A non-text attachment was scrubbed...
> Name: original_model.jpg
> Type: image/jpeg
> Size: 66864 bytes
> Desc: not available
> URL: 
> 
> 
> --
> 
> Subject: Digest Footer
> 
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
> 
> --
> 
> End of grass-user Digest, Vol 151, Issue 30
> ***
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] GRASS museum !

[Peter Löwe]

Hi Rich, hi all,

there is already a number of physical artifacts which are significant to the 
GRASS project (printed documentation with autographs, tape reels, etc.).

Maybe there will be someday a "shrine of GRASS" in one particular physical 
location (Urbana-Champaign ? Hannover ? Baylor ?).

In the meantime we could list and track the artifacts in the wiki in a "virtual 
shrine", so we know who's currently the caretaker of each artifact and where 
it's located.
To make the artifacts citeable by DOI, we could assign "landing pages" for them 
in a repository, like Zenodo. Landing pages can be updated when the caretaker 
changes or the artefact is moved to another pyhsical location. 

This would be very easy to achieve, as all of the infrastructure is already in 
place.   

Shall we give this a try ?

best,
Peter



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

Re: [GRASS-user] Editing POINTS file vs wxGUI.gcp

[Peter Löwe]

Moritz,

thanks a bunch for pointing out i.gcp - that's exactly what is needed !

thx,
Peter




> Gesendet: Freitag, 17. August 2018 um 16:32 Uhr
> Von: "Moritz Lennert" 
> An: "Peter Löwe" 
> Cc: "Markus Neteler" , "GRASS user list" 
> 
> Betreff: Re: Editing POINTS file vs wxGUI.gcp
>
> On 17/08/18 13:07, "Peter Löwe" wrote:
> > Hi Moritz,
> > 
> > you are of course right, provided that the GRASS GUI can be used.
> > This case is a bit different, as a scripted workflow is needed, without 
> > user input through the GUI.
> > THe GCPs for all four corners of the image are known as WKT.
> > 
> 
> Check the i.gcp addon.
> 
> Moritz
> 
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Editing POINTS file vs wxGUI.gcp

[Peter Löwe]

Hi Moritz,

you are of course right, provided that the GRASS GUI can be used.
This case is a bit different, as a scripted workflow is needed, without user 
input through the GUI.
THe GCPs for all four corners of the image are known as WKT.

The rasters are not strictly north-south / east-west aligned, gdal_translate 
can't be used, as far as I understand.

Peter 





> Gesendet: Freitag, 17. August 2018 um 12:57 Uhr
> Von: "Moritz Lennert" 
> An: "Peter Löwe" , "Markus Neteler" 
> Cc: "GRASS user list" 
> Betreff: Re: [GRASS-user] workflow to import/georectify binary remote sensing 
> data: POINTS file editing
>
> On 17/08/18 10:11, "Peter Löwe" wrote:
> > Hi Markus, all,
> > 
> > thanks for the feedback. The new temporary location option is a great 
> > feature.
> > 
> > However, I wonder whether having to manually create a POINTS file within 
> > the locations file structure is (still) the proper way to handle the 
> > rectification process in GRASS 7.x. This approach dates back to GRASS 4.x. 
> > There are no references to it in the recent documentation, so its kind of a 
> > (old-fashioned?) hack.
> 
> 
> Do you mean how to georeference without definined ground control points ?
> 
> Normally, for creating GCPs, you would use 
> https://grass.osgeo.org/grass74/manuals/wxGUI.gcp.html.
> 
> What do you see as a more "modern" approach ?
> 
> Moritz
> 
> > 
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] workflow to import/georectify binary remote sensing data: POINTS file editing

[Peter Löwe]

Hi Markus, all,

thanks for the feedback. The new temporary location option is a great feature.

However, I wonder whether having to manually create a POINTS file within the 
locations file structure is (still) the proper way to handle the rectification 
process in GRASS 7.x. This approach dates back to GRASS 4.x. There are no 
references to it in the recent documentation, so its kind of a (old-fashioned?) 
hack.
   
best
Peter




> Gesendet: Donnerstag, 16. August 2018 um 17:17 Uhr
> Von: "Markus Neteler" 
> An: "Peter Löwe" 
> Cc: "GRASS user list" 
> Betreff: Re: [GRASS-user] workflow to import/georectify binary remote sensing 
> data
>
> Hi Peter,
> 
> On Wed, Aug 1, 2018 at 10:29 AM "Peter Löwe"  wrote:
> > Hello list,
> >
> > here is a question about what's currently the most effective way to ingest 
> > binary raster data which need to be georectified.
> >
> > The data source are calibrated weather radar precipitation rasters (lots of 
> > them), which come in a well documented binary format (+ GCPs), which is not 
> > (yet) supported by gdal.
> >
> > A "classical" approach could be:
> >
> > 1) Create XY location as source
> > 2) Create LatLon location as target
> 
> (probably a metric projection would be better?)
> 
> > 3) Ingest data via r.in.bin (to skip over file header) into XY location
> > 4) Use GCP to set up i.rectify within XY location
> > 5) Apply i.rectify
> > 6) Discard XY-location and continue work in LatLon location
> >
> > In there a more effective way, probably without using a XY location ?
> 
> Perhaps the new:
> grass75 --tmp-location ...
> 
> See
> https://grass.osgeo.org/grass75/manuals/grass7.html#batch-jobs-with-the-exec-interface
> --> Using temporary location
> ?
> 
> It also supports XY locations and all could be done in a script.
> 
> Best
> Markus
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] workflow to import/georectify binary remote sensing data

[Peter Löwe]

Hello list,

here is a question about what's currently the most effective way to ingest 
binary raster data which need to be georectified.

The data source are calibrated weather radar precipitation rasters (lots of 
them), which come in a well documented binary format (+ GCPs), which is not 
(yet) supported by gdal.

A "classical" approach could be:

1) Create XY location as source
2) Create LatLon location as target
3) Ingest data via r.in.bin (to skip over file header) into XY location
4) Use GCP to set up i.rectify within XY location
5) Apply i.rectify
6) Discard XY-location and continue work in LatLon location

In there a more effective way, probably without using a XY location ?

best,
Peter 


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

[GRASS-user] Global overview of GRASS HPC resources/installations ?

[Peter Löwe]

Hi all,

is there already some kind of up to date list / global map of GRASS 
installation in HPC-cluster environments ?

This would be handy to get a feeling about how much "big geospatial number 
crunching" is currently done with GRASS, and where to visit / whom to talk to 
to learn from others.

Best,
Peter


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

[GRASS-user] Ideas for a rush project (Thomas Adams): 400 parallel GRASS jobs on a cluster

[Peter Löwe]

Tom,

you will be able  to speed up your work (or compute more alternatives) if you 
can run your project on a computing cluster, maybe at a university or research 
institute ?

Some info here:
https://grasswiki.osgeo.org/wiki/Parallel_GRASS_jobs
https://courses.neteler.org/building-a-cluster-for-grass-gis-and-other-software-from-the-osgeo-stack/
http://gfzpublic.gfz-potsdam.de/pubman/item/escidoc:100071:1/component/escidoc:100070/5_GISDAY-2012_loewe_thaler_State_of_the_Cluster_bib.pdf%3Bjsessionid=87D8757B6257885C605BFDC531F067A3
  (-> slide 20 gives an overview over the time saved by going parallel).

Good luck with your project,
peter





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

[GRASS-user] Moon irradiance / r.sun

[Peter Löwe]

Hi all,

I'm looking for a solution to map out terrain coverage by moonlight. This is of 
interest for animal migration / wildlife biology.

Apparently there's no r.moon, similar to r.sun in GRASS (yet). Any ideas on how 
to tackle this would be much appreciated.

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

[GRASS-user] Hardware requirements to run GRASS: Small is beautiful ?

[Peter Löwe]

Luis, all,

FWIW a few years back I managed to build & run GRASS 6.x on a tiny NSLU2.

Specs:
266 MHz ARM Intel XScale
32 MB SDRAM, 8 MB flash
https://en.wikipedia.org/wiki/NSLU2

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

[GRASS-user] Download statistics for add-on modules ?

[Peter Löwe]

Hi all,

is there a (easy) way to get download statistics/metrics for individual GRASS 
add-on modules ?
 
https://www.openhub.net/p/grass_gis_addons seems to give only information about 
developer activities and code commits, correct ?

Best,
Peter



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

Re: [GRASS-user] grass 7 and KML vectors -- v.out.kml in GRASS7

[Peter Löwe]

>On 2016-07-01 at 15:41, Markus Neteler  wrote:
>> On Fri, Jul 1, 2016 at 5:09 PM, Ken Mankoff  wrote:
>> The script is here:
>> https://grass.osgeo.org/grass64/manuals/addons/v.out.kml.html
>>
>> but it was not yet (volunteers wanted) ported to GRASS GIS 7.
>
>>It appears to "just work" for me in 7.0.3.
>
>-k.

Hi all,
the current version of v.out.kml is a humble shell script based on GRASS 
modules. It should continue to work for GRASS 7.x on L!nux platforms but most 
likely not on Windows systems. I will _try_ to put work in a API-based 
Python-upgrade ASAP (aka: late '16/ early '17) unless someone (volunteers 
wanted) is willing to tackle this earlier.

Best, 
Peter   






> Gesendet: Samstag, 02. Juli 2016 um 21:00 Uhr
> Von: grass-user-requ...@lists.osgeo.org
> An: grass-user@lists.osgeo.org
> Betreff: grass-user Digest, Vol 123, Issue 2
>
> Send grass-user mailing list submissions to
>   grass-user@lists.osgeo.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   http://lists.osgeo.org/mailman/listinfo/grass-user
> or, via email, send a message with subject or body 'help' to
>   grass-user-requ...@lists.osgeo.org
> 
> You can reach the person managing the list at
>   grass-user-ow...@lists.osgeo.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of grass-user digest..."
> 
> 
> Today's Topics:
> 
>1. Re: grass 7 and KML vectors (Ken Mankoff)
>2. Re: python grass script error (Vinay Elothunkal)
>3. Re: python grass script error (Markus Neteler)
>4. Re: python grass script error (Massimiliano Cannata)
> 
> 
> --
> 
> Message: 1
> Date: Fri, 01 Jul 2016 15:47:07 -0400
> From: Ken Mankoff 
> To: Markus Neteler 
> Cc: grass-user 
> Subject: Re: [GRASS-user] grass 7 and KML vectors
> Message-ID: 
> Content-Type: text/plain
> 
> 
> On 2016-07-01 at 15:41, Markus Neteler  wrote:
> > On Fri, Jul 1, 2016 at 5:09 PM, Ken Mankoff  wrote:
> > The script is here:
> > https://grass.osgeo.org/grass64/manuals/addons/v.out.kml.html
> >
> > but it was not yet (volunteers wanted) ported to GRASS GIS 7.
> 
> It appears to "just work" for me in 7.0.3.
> 
>   -k.
> 
> 
> 
> --
> 
> Message: 2
> Date: Sat, 2 Jul 2016 12:54:35 +0900
> From: Vinay Elothunkal 
> To: Paulo van Breugel 
> Cc: Massimiliano Cannata ,  GRASS user
>   list 
> Subject: Re: [GRASS-user] python grass script error
> Message-ID:
>   
> Content-Type: text/plain; charset="utf-8"
> 
> Hi Paulo,
> 
> Thanks for your reply, I guess I didnt explain the question properly ,
> Inherently the problem is residing in @ mark as it shown in below
> example...
> 
> GRASS 7.0.4 (Peureto_rico):~/Home_copy/ > r.mapcalc
> Enter expressions, "end" when done.
> mapcalc> test10=Senti_AOI1_NIR_10m@Sentinel2+Senti_AOI1_SWIR_20m@Sentinel2
> mapcalc>
>  100%
> GRASS 7.0.4 (Peureto_rico):~/Home_copy/ > r.mapcalc
> Enter expressions, "end" when done.
> mapcalc> test10@Sentinel2=Senti_AOI1_NIR_10m@Sentinel2
> +Senti_AOI1_SWIR_20m@Sentinel2
> syntax error, unexpected '@', expecting '('
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> 
> 
> --
> 
> Message: 3
> Date: Sat, 2 Jul 2016 08:46:40 +0200
> From: Markus Neteler 
> To: Vinay Elothunkal 
> Cc: GRASS user list , Paulo van Breugel
>   
> Subject: Re: [GRASS-user] python grass script error
> Message-ID:
>   

[GRASS-user] GRASS-CGI integration: SlideLinks

[Peter Löwe]

Hi all,

the GRASS 5.0 tutor page refers to ancient ways to integrate GRASS modules in 
CGI (https://grass.osgeo.org/gdp/grass5tutor/HTML_en/c1806.html):

[...]Once these variables have been set, GRASS can also be integrated into 
CGI, PERL and other scripts. You can visit a quite complex example on the 
internet: SlideLinks which is an online GIS based completely on CGI scripts, a 
database management system and GRASS.[...]

Unfortunately, the link to SlideLinks is currently broken 
(http://gisws.media.osaka-cu.ac.jp/grasslinks/) 

Does anybody know about existing copies of the SlideLinks codebase ?

Best,
Peter

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

[GRASS-user] d.vect: How to achieve transparency ?

[Peter Löwe]

Hi all,

is there a known way to render a vector layer on a GRASS monitor (from the 
GRASS Shell, not through a GUI) with a level of transparency, except for 
r.composite-based  workarounds? Any solution for either GRASS7.x or GRASS6.x 
would be welcomed.

Best,
Peter

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

[GRASS-user] d.out.file / d.save - Shell-script use issues

[Peter Löwe]

Dear Csar, dear all,



thanks for your input, but the core problem remains:



When a Shell-script is invoked from the GRASS-shell (GRASS6.4.2 on Suse Linux on a HPC cluster) with a monitor (x0, PNG, etc.) being already activated (d.mon start / d.mon select), a g.gisenv _within_ the script will properly reference the active monitor (MONITOR=x0), BUT a d.save -c will throw a WARNING: No socket to connect to for monitor while d.out.file gives an ERROR: no monitor selected.



A feasible workaround would be to store the monitors content with d.save before running the script and recreating the content afterwards, but this is less than elegant.



Suggestions, anyone ?



Best,

Peter







peter.lo...@gmx.de




What I use on scripts is the PNG monitor setting the GRASS_PNGFILE, GRASS_HEIGHT and GRASS_WIDTH before starting the monitor.

Take a look at the PNG Driver manual pages for more variables: http://grass.osgeo.org/grass64/manuals/pngdriver.html

El lun, 10 de noviembre de 2014 17:42, Peter Lwe peter.lo...@gmx.de escribi:

Hi all,

Im trying call up d.out.file from within an add-on Shell-script for GRASS 6.=4, but keep getting the following error:
ERROR: No such monitor as GRASS_MONITOR
d.out.file output=test20141110 format=geotiff resolution=1 size=1440,720
ERROR: You must select a display monitor.

Lets assume that a GRASS monitor has been _started_ and _selected_ (x0, PNG, or similar) in the current GRASS session and some rasters and vectors have been drawn on it. Then, the script is invoked which needs to write out the content of the currently active monitor.

Up till now neither a simple export g.gisenv or an explicit re-selecting the monitor via d.mon select=THECURRENTMONITOR within the script improved the situation.

Hints and suggestions would be greatly appreciated.







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

Re: [GRASS-user] d.out.file / d.save - Shell-script use issues

[Peter Löwe]

Hi Csar,



thanks for your follow-up work in this issue: Thats exactly the workflow I was looking for. So the issue got already fixed between GRASS6.4.2 and 6.4.4. Could you please verify the behaviour of d.out.file in GRASS6.4.4 when a PNG monitor is being used ?



Best,

Peter



peter.lo...@gmx.de




Hello Peter,

Im sorry for misunderstanding your question, I thought that starting the monitor INSIDE the script would be adequate for you, I have tested this and couldnt reproduce your problem:


I created a test.sh file on my current directory and made it executable with the following contents:




#!/bin/bash

d.mon -p

d.out.file output=test20141110 format=geotiff resolution=1 size=1440,720




Then I started a monitor with some maps: d.mon x0, d.rast somerastermap, d.vect somevectormap



Then I executed the script with ./test.sh



I got this output:




Currently selected monitor: x0

Saving display from Monitor: [x0] to test20141110.tif.

Image size [1440 x 720]

100%

Screen export complete. (writing the file may take a small amount of time)

Image crop [720 x 720]

Waiting for file to write ...

Translating to GeoTIFF format

Done.




Im using GRASS 6.4.4 on Ubuntu 14.04 from ubuntugis PPA, let me now if Im not testing it correctly


El Tue Nov 11 2014 at 11:03:24 a. m., Peter Lwe peter.lo...@gmx.de escribi:




Dear Csar, dear all,



thanks for your input, but the core problem remains:



When a Shell-script is invoked from the GRASS-shell (GRASS6.4.2 on Suse Linux on a HPC cluster) with a monitor (x0, PNG, etc.) being already activated (d.mon start / d.mon select), a g.gisenv _within_ the script will properly reference the active monitor (MONITOR=x0), BUT a d.save -c will throw a WARNING: No socket to connect to for monitor while d.out.file gives an ERROR: no monitor selected.



A feasible workaround would be to store the monitors content with d.save before running the script and recreating the content afterwards, but this is less than elegant.



Suggestions, anyone ?



Best,

Peter







peter.lo...@gmx.de




What I use on scripts is the PNG monitor setting the GRASS_PNGFILE, GRASS_HEIGHT and GRASS_WIDTH before starting the monitor.

Take a look at the PNG Driver manual pages for more variables: http://grass.osgeo.org/grass64/manuals/pngdriver.html

El lun, 10 de noviembre de 2014 17:42, Peter Lwe peter.lo...@gmx.de escribi:

Hi all,

Im trying call up d.out.file from within an add-on Shell-script for GRASS 6.=4, but keep getting the following error:
ERROR: No such monitor as GRASS_MONITOR
d.out.file output=test20141110 format=geotiff resolution=1 size=1440,720
ERROR: You must select a display monitor.

Lets assume that a GRASS monitor has been _started_ and _selected_ (x0, PNG, or similar) in the current GRASS session and some rasters and vectors have been drawn on it. Then, the script is invoked which needs to write out the content of the currently active monitor.

Up till now neither a simple export g.gisenv or an explicit re-selecting the monitor via d.mon select=THECURRENTMONITOR within the script improved the situation.

Hints and suggestions would be greatly appreciated.















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

[GRASS-user] d.out.file - Shell-script use ?

[Peter Löwe]

Hi all,

I'm trying call up d.out.file from within an add-on Shell-script for GRASS 
6.=4, but keep getting the following error:
ERROR: No such monitor as GRASS_MONITOR
d.out.file output=test20141110 format=geotiff resolution=1 size=1440,720
ERROR: You must select a display monitor.

Let's assume that a GRASS monitor has been _started_ and _selected_ (x0, PNG, 
or similar) in the current GRASS session and some rasters and vectors have been 
drawn on it. Then, the script is invoked which needs to write out the content 
of the currently active monitor. 

Up till now neither a simple export `g.gisenv` or an explicit re-selecting 
the monitor via d.mon select=$THECURRENTMONITOR within the script improved 
the situation.

Hints and suggestions would be greatly appreciated.

Peter
peter.lo...@gmx.de
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] r3.mapcalc / r.mapcalc: Logical Operators , || behave differently

[Peter Löwe]

Hi all,

for r3.mapcalc and r.mapcalc, there seems to be a difference regarding the 
logical operators ( ||, etc.):

Assuming that two raster maps BAR and BAZ exist, the following statement 
creates new map content FOO whenever BAZ and BAR are not null:

r.mapcalc FOO='if((BAZ  BAR),42,null())'

Doing the same with volumes (BAZ3, BAR3) results in an error message:

r3.mapcalc FOO3='if((BAZ3  BAR3),42,null())'

=

Incorrect argument types to function or()
Parse error

Where's my mistake ?

FWIW: I'm using GRASS6.4.2 on Linux

GRASS 6.4.2 (2012)
Revision: 45934


Best,
Peter

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

Re: [GRASS-user] r3.mapcalc / r.mapcalc: Logical Operators , || behave differently

[Peter Löwe]

Glynn,

thanks for your quick response:
You are of course correct regarding the non-null/non-zero aspects and I stand 
corrected for the substellar cut'n past blunder :-)

Yet still I'm puzzled, as I hoped that type casting to INT would do the trick:

r3.mapcalc l01i='int(l01)'
r3.mapcalc l02i='int(l02)'

GRASS 6.4.2 (utm10n_wgs84):~  r3.mapcalc FOO3 = if((l01i || l02i),42,null())
Incorrect argument types to function or()
Parse error

same here:
GRASS 6.4.2 (utm10n_wgs84):~  r3.mapcalc FOO3 = if((l01i  l02i),42,null())
Incorrect argument types to function and()
Parse error

FWIW, the volumes are quite trivial:
GRASS 6.4.2 (utm10n_wgs84):~  r3.info l01i
 ++
 | Layer:l01i   Date: Wed Aug 20 22:32:46 2014|
 | Mapset:   PERMANENT  Login of Creator: ploewe  |
 | Location: utm10n_wgs84 |
 | DataBase: /home/cegit/ploewe/geodata/locations |
 | Title: ( l01i )|
 | Timestamp: none|
 ||
 ||
 |   Type of Map:  3d cell  Number of Categories: 0   |
 |   Data Type:double |
 |   Rows: 1400   |
 |   Columns:  979|
 |   Depths:   188|
 |   Total Cells:  257672800  |
 |Projection: UTM (zone 10)   |
 |N:5121985S:5107985   Res:10 |
 |E: 567605W: 557815   Res:10 |
 |T:   2550B:670   Res:10 |
 |   Range of data:   min =  1 max =  1   |
 ||
 |   Data Source: |
 ||
 ||
 ||
 |   Data Description:|
 |generated by r3.mapcalc |
 ||
 |   Comments:|
 |r3.mapcalc  |
 ||
 ++

Any further advice would be much appreciated.

Best,
Peter


peter.lo...@gmx.de


 Gesendet: Mittwoch, 20. August 2014 um 22:14 Uhr
 Von: Glynn Clements gl...@gclements.plus.com
 An: Peter Löwe peter.lo...@gmx.de
 Cc: grass-user@lists.osgeo.org
 Betreff: Re: [GRASS-user] r3.mapcalc / r.mapcalc: Logical Operators , || 
 behave differently

 
 Peter Löwe wrote:
 
  for r3.mapcalc and r.mapcalc, there seems to be a difference
  regarding the logical operators ( ||, etc.):
  
  Assuming that two raster maps BAR and BAZ exist, the following
  statement creates new map content FOO whenever BAZ and BAR are not
  null:
  
  r.mapcalc FOO='if((BAZ  BAR),42,null())'
 
 Not quite.
 
 The result will be 42 if both BAZ and BAR are non-null and non-zero. 
 If either are null or either are zero, the result will be null.
 
 Regarding :
 
 * A  B is null if either A or B are null, otherwise ...
 
 * A  B is zero if either A or B are zero, otherwise ...
 
 * A  B is one.
 
 Regarding if():
 
 * if(A,B,C) is null if A is null, otherwise ...
 
 * if(A,B,C) is B if A is non-zero, otherwise ...
 
 * if(A,B,C) is C
 
 So if either BAZ or BAR are null, (BAZ  BAR) will be null and the
 if() function will evaluate to null regardless of its second and third
 arguments.
 
 If neither are null, then (BAZ  BAR) will be 0 if either BAZ or BAR
 are zero, and 1 if both are non-zero.
 
  Doing the same with volumes (BAZ3, BAR3) results in an error message:
  
  r3.mapcalc FOO3='if((BAZ3  BAR3),42,null())'
 
 FWIW, you should change the quoting to:
 
   r3.mapcalc 'FOO3 = if((BAZ3  BAR3),42,null())'
 
 This will work in both 6.x and 7.x, whereas your original version will
 only work in 6.x (in 7.x, r.mapcalc/r3.mapcalc use the GRASS argument
 parser, so the expression musn't

[GRASS-user] GRASS download statistics ?

[Peter Löwe]

Hi,

where can current download statistics for GRASS binaries/sources be found: how 
many downloads - by the hour/day/month, - by platform(Linux/Mac/Win); how many 
active mirrors, etc ?

Best,
Peter

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

[GRASS-user] 3d vector cutting pane for 3d volumes ?

[Peter Löwe]

Hi,
is there a feasible approach in GRASS 6.X or 7.X to apply a 3d vector surface 
as a cutting pane to split 3D raster volume bodies ?

Best, 
Peter

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

[GRASS-user] How to remove surplus centroids sitting right on a boundary line ?

[Peter Löwe]

Hi all,

I have a vector layer (source: ESRI shape) consisting of areas and many surplus 
centroids, which need to be removed.
The surplus centroids are sitting right on the boundary lines of the areas: So 
each area has one proper centroid in its center, but also multiple fringe 
centroids sitting on its boundary line.

Which combo of v.clean tools (or other means) can handle the removal of the 
unwanted centroids ?

Peter 

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

[GRASS-user] Projected maps on WXgui/Monitor ?

[Peter Löwe]

Hi  happy new 2013 to you all,

is there a way to render GRASS layers in a given map projection (like 
Mollweide, Albers, Stereographic, etc) on a GRASS monitor (GRASS6.x) or the new 
WXGui (GRASS7.0) ?

[e.g: If a conic projection would be used, the data would indeed look conical 
on the screen]

I remember that add-on code for this existed in the days of GRASS4|5.x, which 
got lost.

All advice would be much appreciated.

Peter
-- 
Dr. Peter Löwe
peter.lo...@gmx.de





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

[GRASS-user] OSM import with gdal - which version ?

[Peter Löwe]

Hi Markus, hi Steve, hi list,

With OGR (recent!) you can apparently import OSM into
GRASS via v.in.ogr using this driver:

http://www.gdal.org/ogr/drv_osm.html

(did anyone try in this list?)


the latest stable release of gdal/ogr is 1.9.2 from October 2012.

But according to http://www.gdal.org/ogr/drv_osm.html, gdal/ogr must be = 
2.0.0 for this to work.

v2.0.0 is not available from the gdal/ogr site.

- Can anyone confirm that this works (already) with v1.9.2 ?

Peter
-- 
Dr. Peter Löwe
peter.lo...@gmx.de





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

[GRASS-user] vector export to DXF in 3d ?

[Peter Löwe]

Hi all,

how can a 3D vector in GRASS6.4  be exported into a DXF while preserving the 3D 
content ?

Example: Isohypses are created from the 10m DEM of the spearfish data set by 
r.contour.

v.info asserts that the newly created vector file is truly 3d. Also v.to.3d 
flatly refuses to work on the vector layer.

Alas, exporting the vector using v.to.dxf results in a perfectly flat DXF.


Does anybody of a good workaround for this one ?

Peter


-- 
Dr. Peter Löwe
peter.lo...@gmx.de





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

Re: [GRASS-user] Vector import combo: db.in.ogr/v.in.db data type casting problem

[Peter Löwe]

Hi Markus,

 
 Note that the default DBF driver does not support an unlimited
 amount of columns
 (the specs suggest 128 columns max).
 

 Please use SQLite instead, also as DB backend for such operations
 (ideally, due to recent fixes, the current 6.4.svn).

That's correct. Thanks for following up on this.

Peter
-- 
Dr. Peter Löwe
peter.lo...@gmx.de





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

Re: [GRASS-user] Bathymetric data

[Peter Löwe]

Lyle,

I'm searching for bathymetric data that can be uploaded of the bottom of the 
Atlantic Ocean that will include the seamounts. Basically at the same 
resolution that one sees with Google woud work for what I need. 

The GEBCO data is probably what you are looking for. Google uses it as well:
http://www.gebco.net/data_and_products/gridded_bathymetry_data/

Best,
Peter
-- 
Dr. Peter Löwe
peter.lo...@gmx.de





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

[GRASS-user] r.noise add-on ?

[Peter Löwe]

Hi,

I am looking for the code of the r.noise module, which was published for GRASS5 
in 2007.

Is the code still maintained somewhere ?

Peter
-- 
Dr. Peter Löwe
peter.lo...@gmx.de





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

[GRASS-user] Vector import combo: db.in.ogr/v.in.db data type casting problem

[Peter Löwe]

hi,

here is an issue (probably float/integer typcasting related) issue when 
importing a large CSV dataset of vector points into GRASS6.4.2.

The data set contains hundreds of columns, so v.in.ascii is not an option (the 
columns option-string would be ungodly long).

Instead, the data is transformed into a DBF and ingested as a table:

db.in.ogr dsn=FOO.dbf output=BAR key=the_id [works]

The integrity of the column data types is confirmed by:

db.describe -c BAR 

Result:

column:N1  [X column]
description:
type:DOUBLE PRECISION
len:20
scale:6
precision:18

column:N2  [Y column]
description:
type:DOUBLE PRECISION
len:20
scale:6
precision:18


Now a VECTOR is created from the table:

v.in.db table=BAR x=N1 y=N2 key=the_id output=BAZ --o 

[**Something strange happens at this point: Typecasting bug ? **]

Running a v.db.select over the new vector shows __INTEGER__ values for the X/Y 
columns N1 and N2 (which were originall EPSG lat/lon FLOAT values):

N1|N2|N3|N4
-9293467|43013833|33.4|1
-9293815|43004851|34.3|1
-9294164|42995869|41025|1

The data in column N3 is CHAR, so it only mimicks float values.


Does anybody know of a working recipe to avoid this FLOAT-INTEGER problem ?


peter

Peter
-- 
Dr. Peter Löwe
peter.lo...@gmx.de





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

Re: [GRASS-user] Point Cloud Library / Kinect

[Peter Löwe]

Hi Hamish,

 Peter wrote:
  where can I find information about FOSS-based
  georeferencing/processing of point clouds (like input coming
  from a NI device like a kinect or a xtion) - preferably done
  with GRASS ?
 
 Hi Peter,
 
 wrt GRASS:
 r.in.xyz can read unlimited delimited ascii from stdin for a 2D slice
 or 2.5D DEM. r3.in.xyz needs a disk file to work with (furthest developed
 in grass7, still a few things to backport to grass6 addons).
 
 how you get those inputs to ascii format is left as an exercise for
 the student. :)
 

the student will also look into Soeren's VTKGRASSBridge (vtkImages can be 
directly written as GRASS raster maps into a GRASS location) and the 
NI/PointCloud-Plugin for Paraview :-)

Thanks,
Peter


-- 
Dr. Peter Löwe
peter.lo...@gmx.de





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

[GRASS-user] g.copy vect=... DBF/SQLITE in GRASS6.4.2

[Peter Löwe]

Hi all,

I just noticed that copying a vector amongs mapsets in GRASS6.4.2 is nontrivial 
for differing database backends:

Let vector A reside in mapset Alpha, which is connected to a DBF database. 

Let there be vector B residing in mapset Beta, which is set to a SQLITE 
database.

Using g.copy vect=A@ALPHA,A_test to copy A into mapset Beta works without 
producing any errors or warnings.  

Unfortunately the attribute table is not copied in the process:  Is the 
user/operator really forced to fix this by hand every time ? Is there an 
elegant way to handle this ?

Peter
-- 
Dr. Peter Löwe
peter.lo...@gmx.de





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

[GRASS-user] Point Cloud Library / Kinect

[Peter Löwe]

Hi all,

where can I find information about FOSS-based georeferencing/processing of 
point clouds (like input coming from a NI device like a kinect or a xtion) - 
preferably done with GRASS ?

Peter
-- 
Dr. Peter Löwe
peter.lo...@gmx.de





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

[GRASS-user] Python scripting: Proper use of run_command / start_command

[Peter Löwe]

Hi all,

I am struggling with the proper use of start_command/run_command for Python 
scripting.

The programmers manual provides this simple example:  
p = grass.start_command(g.gisenv, stdout = subprocess.PIPE) 

What is the proper way to include keyword-arguments tuples ?

For example, g.list -f type=rast,vect should translate into something like:

grass.run_command(g.list,f,dict(type=rast,vect))
^- this invocation of the run_command fails: 

ERROR: Required parameter type not set:
(Data type)

Any advice on how to get this right would be much appreciated.

Peter
-- 
Dr. Peter Löwe
peter.lo...@gmx.de





Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] NVIZ / Povray Lighting

[Peter Löwe]

Hi all,

is there a way to determine the exact coordinates of a light-source in NVIZ ?

Using NVIZ in GRASS 6.4 Appearance-Position provides the current camera 
position and view point on the surface, but no info is given about the light 
source.

The additional lighting-info is needed to reenact the NVIZ-scene in Povray.

Peter
-- 
Dr. Peter Löwe
peter.lo...@gmx.de





Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!  
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.in.wms / Wheregroup OSM WMS

[Peter Löwe]

 Peter wrote:
  I`m trying to access a WMS service for european OSM data
  (german link:
 http://www.wheregroup.com/de/freier_wms_mit_openstreetmap_daten)
  in GRASS 6.4 with r.in.wms in an EXPSG4326 location
  
  r.in.wms --o v=5 layers=Wald
 mapserver=http://osm.wheregroup.com/cgi-bin/osm_basic.xml
  output=Wald

[...]

Hamish:
 
 I expect the wheregroup people are reading the OSM (vector) data from a
 WFS server, rendering it with Osmarender or Mapnik on-the-fly, then
 WMS'ing
 the rasterized result.
 
 and the problem is between them and their OSM vector source.
 

This has been confirmed: There are pecularities regarding the WMS. Thanks for 
the support, Hamish !
I guess r.in.wms would benefit from improved error checking in the future, as 
otherwise similar WMS-related postings might appear again and again on the list.

Peter


 
 ??,
 Hamish
 
 
 ps- for lots of Blue Marble you might as well download the large binary
 grids. ~ 1.4gb for the whole world.  or use r.in.onearth WMS frontend from
 wiki addons. look on the Global datasets page in the wiki. (currently
 stalled)
 
 
 
   

-- 
Dr. Peter Löwe
peter.lo...@gmx.de





GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Re: KML generator for GRASS 6.4 (Luis Lisboa)

[Peter Löwe]

Hi Luis,

Both v.out.kml (Vectors) and r.out.kml (Rasters) are for the time being GRASS 
add-ons (http://grass.osgeo.org/wiki/GRASS_AddOns). v.out.ogr is already part 
of the standard GRASS6.4 distribution.

Peter


-- 
Dr. Peter Löwe
peter.lo...@gmx.de





Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.patch fix/workaround needed

[Peter Löwe]

Hi 

 
  In a first step, a polygon (A) is created using v.patch from an
 outline and a centroid. This works fine.

v.patch: A-outline + A-centroid = A-polygon (-a Option)

 
  In a second step, the newly created polygon is added to a larger set of
 polygons (SET) using v.patch again.
 

v.patch -a A-polygon + Set = Set

  In a few cases (reproducable) the SET polygon is NOT extended by the
 proper polygon A but the centroid of A and the polyline of A (the
 process works correctly in 9 out of 10 cases).
 
  Since this process is to run as a script, how can the disjoint tuple of
 controid-A and polyline-A in the SET vector layer be mended again ?
 
 Before we start hunting bugs for nothing, could you please try
 GRASS 6.4? AFAIR there have been implemented some fixes in the
 topology engine... perhaps it already works?
 
 Markus

The results are the same on Grass6.4RC5.

I was able to track down to different phenomena.

Some background info:
The dataset Set consists of many squares (all imported as as A-polygons). 
SOME OF THEM OVERLAP.


1)
As long as the centroids of the affected squares are OUTSIDE of the overlapping 
area, everything is OK.

If the would centroids fall INSIDE the overlapping zone, the newly to be added 
polygon is only vpatched as a line and a controid.

Since the intentional use of overlapping polygons is surely a bad idea, this 
makes sense. However, some sort of feedback to the user would be a good thing 
to have if such a case occurs.

2)
Yet, there are cases without critical overlap resulting in 
centroid/line-pairs: In each case two identical centroids (holding identical 
attributes but different categories) were created.

  This could be a bug in v.patch.

Peter
  




-- 
Dr. Peter Löwe
peter.lo...@gmx.de





GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] m.proj transformation to EPSG3785 / KML

[Peter Löwe]

Hi Markus, hi Hamish,

thank you for your feedback and advice. The 900913-projection is a strange 
beast, indeed. But it's good that GRASS allows to communicate with communities 
which willfully avoid everything else.

Peter 

 Original-Nachricht 
 Datum: Mon, 20 Jul 2009 20:50:57 +0200
 Von: Markus Neteler nete...@osgeo.org
 An: Hamish hamis...@yahoo.com
 CC: grass-user@lists.osgeo.org, peter.lo...@gmx.de
 Betreff: Re: [GRASS-user] m.proj transformation to EPSG3785 / KML

 On Mon, Jul 20, 2009 at 8:16 PM, Hamishhamis...@yahoo.com wrote:
 ...
  FWIW  AFAIK, KML takes coordinates as wgs84 LL, and the Google
  projection is a highly dubious beast that should be avoided if
  at all possible.
 
 Yes!
 See also comment here:
 http://www.epsg-registry.org/export.htm?gml=urn:ogc:def:crs:EPSG::3857
 remarks
 Uses spherical development of ellipsoidal coordinates. Relative to an
 ellipsoidal development errors of up to 800 metres in position and 0.7
 percent in scale may arise. It is not a recognised geodetic system:
 see WGS 84 / World Mercator (CRS code 3395).
 /remarks
 
 
 The error is significant for many GIS applications.
 
 Markus

-- 
Dr. Peter Löwe
peter.lo...@gmx.de





Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.out.vtk RGB / input issue

[Peter Löwe]

Hi Soeren,

the bug/feature is also present in 6.4RC5

Best
Peter

 Original-Nachricht 
 Datum: Thu, 18 Jun 2009 08:57:33 +0200
 Von: Sören Gebbert soerengebb...@gmx.de
 An: peter.lo...@gmx.de, grass-user@lists.osgeo.org
 Betreff: Re: [GRASS-user] r.out.vtk RGB / input issue

 Hi,
 i will have a look on it.
 In case this is a bug, i will fix it and provide a patch.
 
 Best regards
 Soeren
 
  Original-Nachricht 
  Datum: Wed, 17 Jun 2009 15:18:23 +0200
  Von: peter.lo...@gmx.de
  An: grass-user@lists.osgeo.org
  Betreff: [GRASS-user] r.out.vtk RGB / input issue
 
  hi,
  
  i am using v.out.vtk on grass6.3 on suse.
  
  trying to export 2.5d rgb-maps to paraview using r.out.vtk always ends
 up
  with an error message:
  
  According to the module's manual it should be possible to export a
 RGBmap
  + dem by using the parameters
  
  rgbmaps=redmap,bluemap,greenmap elevation=my_dem output=result.vtk
  
  However, the module reports that the INPUT parameter has to be provided.
  
  trying 
  
  input=rgbmap rgbmaps=redmap,bluemap,greenmap elevation=my_dem
  output=result.vtk
  
  results in the same as 
  
  input=rgbmap elevation=my_dem output=result.vtk
  
  In both cases result.vtk is displayed with interpolated false colors.
  
  How can a RGB composite created in GRASS properly be transferred and
  displayed in Paraview ?
  
  Peter
  -- 
  Dr. Peter Löwe
  peter.lo...@gmx.de
  
  
  
  
  
  GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und
 Telefonanschluss
  für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02
  ___
  grass-user mailing list
  grass-user@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/grass-user
 
 -- 
 GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
 Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

-- 
Dr. Peter Löwe
peter.lo...@gmx.de





GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.out.vtk RGB / input issue

[Peter Löwe]

Hi Sören,

thanks for your fast help - the patch works.

However, only limited success on the paraview-side (Paraview 3.4.0)

 In paraview 3.x select the display tab and choose Color by to switch
 from input scalars to rgb scalars. 

This works, but results in a strangely colored image which bears little 
resemblance to the visualisation in GRASS with d.rgb or r.composite.

How can a similar coloring scheme be achieved in Paraview like the one for the 
source data in GRASS ?

Peter

 Original-Nachricht 
 Datum: Thu, 18 Jun 2009 13:09:58 +0200
 Von: Sören Gebbert soerengebb...@gmx.de
 An: peter.lo...@gmx.de, grass-user@lists.osgeo.org
 Betreff: Re: [GRASS-user] r.out.vtk RGB / input issue

 Hello Peter,
 i have checked this issue. 
 The behavior of r.out.vtk is correct.
 
 An input must be provided, this is not optional.
 To change this, you have to apply this little patch:
 
 ===
 --- parameters.c(Revision 37861)
 +++ parameters.c(Arbeitskopie)
 @@ -29,6 +29,7 @@
  void set_params()
  {
  param.input = G_define_standard_option(G_OPT_R_INPUTS);
 +param.input-required = NO;
 
 
 
 If you use the rgb and the input parameter (which is the default), 
 then you have to choose which data has should be displayed in your
 visualization software. By default, the input scalars are the active
 scalar array in the vtk output file.
 
 e.g:
 In paraview 3.x select the display tab and choose Color by to switch
 from input scalars to rgb scalars. 
 
 Best regards
 Soeren
 
  Original-Nachricht 
  Datum: Wed, 17 Jun 2009 15:18:23 +0200
  Von: peter.lo...@gmx.de
  An: grass-user@lists.osgeo.org
  Betreff: [GRASS-user] r.out.vtk RGB / input issue
 
  hi,
  
  i am using v.out.vtk on grass6.3 on suse.
  
  trying to export 2.5d rgb-maps to paraview using r.out.vtk always ends
 up
  with an error message:
  
  According to the module's manual it should be possible to export a
 RGBmap
  + dem by using the parameters
  
  rgbmaps=redmap,bluemap,greenmap elevation=my_dem output=result.vtk
  
  However, the module reports that the INPUT parameter has to be provided.
  
  trying 
  
  input=rgbmap rgbmaps=redmap,bluemap,greenmap elevation=my_dem
  output=result.vtk
  
  results in the same as 
  
  input=rgbmap elevation=my_dem output=result.vtk
  
  In both cases result.vtk is displayed with interpolated false colors.
  
  How can a RGB composite created in GRASS properly be transferred and
  displayed in Paraview ?
  
  Peter
  -- 
  Dr. Peter Löwe
  peter.lo...@gmx.de
  
  
  
  
  
  GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und
 Telefonanschluss
  für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02
  ___
  grass-user mailing list
  grass-user@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/grass-user
 
 -- 
 GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
 Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

-- 
Dr. Peter Löwe
peter.lo...@gmx.de





GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] GUI: Use SQL Query - lots of integers from a vector-category ?

[Peter Löwe]

Hi,

I am using Grass6.3 and the tcltk-GUI:

When displaying a vector layer, the 'query vectors for display' allows to 
provide a SQL query.

How can a SQL query of the following kind be entered ?
'my_integer_attribute IN (4,7,19,345,678,111)'

Using IN as described above results in an error:

DBMI-DBF driver error:
SQL parser error: syntax error, unexpected NAME processing 'IN'
in statement:
SELECT cat FROM country_FOO WHERE FOO_ID IN (2238509,3358510,445812)
Error in db_open_select_cursor()

---
Using an OR-construction as in
attribute=4 OR attribute=7 OR attribute=19 OR ...
gets pretty soon tedious.

Peter


-- 
Dr. Peter Löwe
peter.lo...@gmx.de





Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss 
für nur 17,95 Euro/mtl.!* 
http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Merging Boundaries and Centroids

[Peter Löwe]

The v.patch -a --o sequence is just what was needed.

Thank you !

Peter
 Original-Nachricht 
 Datum: Fri, 20 Mar 2009 12:53:46 +0200
 Von: Micha Silver mi...@arava.co.il
 An: Moritz Lennert mlenn...@club.worldonline.be
 CC: peter.lo...@gmx.de, grass-user@lists.osgeo.org
 Betreff: Re: [GRASS-user] Merging Boundaries and Centroids

 Hi Moritz:
 Thanks for the corrections.
 -- 
 Micha
 
 Moritz Lennert wrote:
 
   
  You can do this with v.patch, *provided* that both vectors have 
  equivalent attribute table columns.
 
  If you can use the append flag (-a) you don't need to have matching 
  tables. Just v.patch -a input=LayerA output=LayerB.
 
 
  From the man page:
 
  columns=name
  Column definition in SQL style (points mode)
 
  So, not possible for lines/areas. I guess this is due to the more 
  complicated file format for lines and areas which makes it difficult 
  to integrate attributes.
 
  Moritz
 

-- 
Dr. Peter Löwe
peter.lo...@gmx.de





Aufgepasst: Sind Ihre Daten beim Online-Banking auch optimal geschützt?
Jetzt absichern: https://homebanking.gmx.net/?mc=m...@footer.hb
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Original location: Hot to create from the command line ?

[Peter Löwe]

   To be precise: If GRASS is started for the first time in -text mode
   (=no GUI) ** without having a sample location like Spearfish or North
   Carolina around**, how can location parameters (projection, extent,
   EPSG...) be handed over to set up a very first location ?
 
  Just type in the name of the location you want to create and GRASS will
  prompt you for the parameters.
 
  Moritz
 
  That's true. But is there also a way to provide the parameters _without_
 interaction
  with the user (- GRASS scripting  automation) ?
 
 Sure.
 An older version of a shell script is here:
  http://www.grassbook.org/examples_menu2nd.php
  - create_location.sh
 
 Keeping in mind
 http://grass.osgeo.org/wiki/GRASS_and_Shell#GRASS_Batch_jobs
 it should be even easier to write it.
 
 Markus

Well, there seem still to be some issues to be dealt with:

I am defining all basic requirements for a location and GRASS session:

  #generate folders for temporal LOCATION and MAPSET
  mkdir -p $CURRENT_DIR/$THE_LOCATION/$THE_MAPSET

  #Set up a temporary grassrc-File:
  echo GISDBASE: $CURRENT_DIR
  LOCATION_NAME: $THE_LOCATION
  MAPSET: $THE_MAPSET
$TMPDIR/$THE_GRASSRC

 # Lets export the variables:
  export GISBASE=/opt/grass
  export PATH=$PATH:$GISBASE/bin:$GISBASE/scripts
  export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$GISBASE/lib

  # use process ID (PID) as lock file number:
  export GIS_LOCK=$$

The steps described so far (should) be sufficient to define a GRASS session, 
with newly created directories for the location and mapset.

Until this point, no information has been provided about the projection 
parameters.

This should be handled by the following commands:
g.proj -p [to see what the (default ?) project 
is]
g.proj -c epsg=4326  [to override the projection information]
g.region -s  n=90 s=-90 w=-180 e=180 res=1 [to define the default (- -s flag) 
region]
g.region -p[to check 
the results]

Unfortunately this results in:
ERROR: default region is not set
ERROR: default region is not set
ERROR: default region is not set
ERROR: default region is not set

What's missing ?

Peter



-- 
Dr. Peter Löwe
peter.lo...@gmx.de





Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] db.select limitation + psql workaround

[Peter Löwe]

Thanks for your work, Markus !

Peter
 Original-Nachricht 
 Datum: Sun, 18 Jan 2009 07:23:56 +0100
 Von: Markus Neteler nete...@osgeo.org
 An: Glynn Clements gl...@gclements.plus.com
 CC: GRASS user list grass-user@lists.osgeo.org, Peter Löwe 
 peter.lo...@gmx.de
 Betreff: Re: [GRASS-user] db.select limitation + psql workaround

 On Sat, Jan 17, 2009 at 8:27 PM, Glynn Clements
 gl...@gclements.plus.com wrote:
  Markus Neteler wrote:
 
   I do agree. However, since the statement begins with the
   SELECT-string, db.execute refuses to execute it.
  
   This is a bug in db.execute, and the only simple fix is to remove the
   check altogether.
 
  As simple as this?
 
  Yes.
 
 Done in 7.trunk, devel6 and 6.4.0svn.
 
 Markus

-- 
Dr. Peter Löwe
peter.lo...@gmx.de





Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL 
für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] vectors: how to find the gravitation centre of point data ?

[Peter Löwe]

[...]
  is there an easy way to derive the centre of a cloud of points ?
  
  I am aware that the set of vector points (cloud of points) could be
  used to stake out a polygon/boundary and use v.centroid etc etc to
  derive in turn its' centroid, but I am hoping for an easier solution
  .. ?
  
  This issue stems from working with v.to.db: currently it is not
  possible to upload xy coordinates for multiploygons into a
  database, i.e: Within a vector layer, there might be several
  boundaries which all share the same category value. If the
  gravitational centre/ super-centroid for these boundaries could be
  (conveniently) calculated, the v.to.db issue could be taken care of.
 
 
 Why not use v.dissolve on these polygons and then get the centroids of 
 the result ?

This option fails if the polygons don't have common borders. An example for 
this would be multiple polygons describing spatial exclaves of a 
territory/county/soil type, etc. 

 Another (very wild) guess: what about the mean of the coordinates of the 
 individual polygons' centroids ?

That would be great if it could be automated.

Peter

 
 Moritz

-- 
Dr. Peter Löwe
[EMAIL PROTECTED]





Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL 
für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] vectors: how to find the gravitation centre of point data ?

[Peter Löwe]

 Original-Nachricht 
 Datum: Fri, 05 Dec 2008 13:40:08 +0100
 Von: Moritz Lennert [EMAIL PROTECTED]
 An: Peter Löwe [EMAIL PROTECTED]
 CC: grass-user@lists.osgeo.org
 Betreff: Re: [GRASS-user] vectors: how to find the gravitation centre of 
 point data ?

 On 05/12/08 12:27, Peter Löwe wrote:
  [...]
  is there an easy way to derive the centre of a cloud of points ?
 
  I am aware that the set of vector points (cloud of points) could be
  used to stake out a polygon/boundary and use v.centroid etc etc to
  derive in turn its' centroid, but I am hoping for an easier solution
  .. ?
 
  This issue stems from working with v.to.db: currently it is not
  possible to upload xy coordinates for multiploygons into a
  database, i.e: Within a vector layer, there might be several
  boundaries which all share the same category value. If the
  gravitational centre/ super-centroid for these boundaries could be
  (conveniently) calculated, the v.to.db issue could be taken care of.
 
  Why not use v.dissolve on these polygons and then get the centroids of 
  the result ?
  
  This option fails if the polygons don't have common borders. An example
 for this would be multiple polygons describing spatial exclaves of a
 territory/county/soil type, etc. 
  
  Another (very wild) guess: what about the mean of the coordinates of
 the 
  individual polygons' centroids ?
  
  That would be great if it could be automated.
 
 Using a real DB-backend, it should be as easy as (assuming that when 
 you say boundaries, you mean areas, each of which has a centroid):
 
 - v.to.db type=centroid option=coor
 - SELECT cat, avg(X), avg(Y) from TABLE group by cat
 

Very good point.
If this is combined with a previous step to create individual CATs for the 
exclave areas while preserving the original CAT in another column, we can 
successfully apply v.to.db even while several areas share the same ID (having 
the centroids xy-coordinates for all exclave-area) _plus_ having the 
coordinates for the super-centroid of all exclaves.

Northern winter might be the perfect time to write GRASS scripts for this kind 
of stuff..

Thanks,
Peter

 
 If you have boundaries with categories, but no centroids, I imagine that 
 v.centroids + v.distance with upload=cat should do the trick to transfer 
 boundary cats to their centroids.
 
 Moritz

-- 
Dr. Peter Löwe
[EMAIL PROTECTED]





Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL 
für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] How to copy vector columns between databases

[Peter Löwe]

Excellent. Thank you Markus!
Another proof how the community benefits when simple minds address stuff they 
can't figure out by themselves,

Simple minded,
Peter
 Original-Nachricht 
 Datum: Thu, 27 Nov 2008 11:39:14 +0100
 Von: Markus Neteler [EMAIL PROTECTED]
 An: [EMAIL PROTECTED]
 CC: GRASS user list grass-user@lists.osgeo.org
 Betreff: Re: [GRASS-user] How to copy vector columns between databases

 (back from grass-dev)
 
 On Thu, Nov 27, 2008 at 10:06 AM, Moritz Lennert
 [EMAIL PROTECTED] wrote:
 ...
  And to respond to Peter's original query, i.e:
 
  I have a vector layer FOO which is linked to two tables in layers 1 and
 2.
  The categories for each vector element are different in layer 1 and
 (e.g.
  a certain area may have the cat value 51 in layer 1 and a cat value
 of
  42 in layer 2).
  Let's assume that layer one has a VARCHAR column containing the names
 of
  the region (e.g. database_layer_1: 51,Wolfenstein database_layer_2:
 42 )
 
  If a new VARCHAR column is added to layer 2 by v.db.adcol,
  how can the the names from layer 1 be copied into it?
 
 
  it should actually be (assuming that the varchar attribute in layer 1 is
  called 'name':
 
  v.db.addcol FOO layer=2 col='name varchar(Size)'
  v.to.db myroads layer=2 option=query col=name qlayer=1 qcolumn=name
 
 Now a FAQ:
 
 
 http://grass.osgeo.org/wiki/Vector_map_attribute_transfer_between_connected_tables
 
 Markus

-- 
Dr. Peter Löwe
[EMAIL PROTECTED]





Sensationsangebot nur bis 30.11: GMX FreeDSL - Telefonanschluss + DSL 
für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] How to copy vector columns between databases

[Peter Löwe]

Moritz,

thanks for your response. I didn't  think of the option to use v.build yet and 
will try to set up an awk-script eventually.

One thing I have been confronted with before was the desire to create a
second layer with exactly the same category values (which didn't start
at 1 and which had no regular step as they were statistical id codes of
municipalities) which currently isn't possible.

That's where I also started...

Thanks,
Peter

 Original-Nachricht 
 Datum: Wed, 26 Nov 2008 14:34:17 +0100
 Von: Moritz Lennert [EMAIL PROTECTED]
 An: [EMAIL PROTECTED]
 CC: grass-user@lists.osgeo.org
 Betreff: Re: [GRASS-user] How to copy vector columns between databases

 On 25/11/08 16:29, [EMAIL PROTECTED] wrote:
  Hi,
  
  I have a vector layer FOO which is linked to two tables in layers 1 and
 2.
  The categories for each vector element are different in layer 1 and
 (e.g. a certain area may have the cat value 51 in layer 1 and a cat value of
 42 in layer 2).
  Let's assume that layer one has a VARCHAR column containing the names of
 the region (e.g. database_layer_1: 51,Wolfenstein database_layer_2: 42 )
  
  If a new VARCHAR column is added to layer 2 by v.db.adcol,
  how can the the names from layer 1 be copied into it?
  
  [Goal: database_layer_1: 51,Wolfenstein database_layer_2:
 42,Wolfenstein ]
  
  Unfortunately, v.db.update seems only to work within one layer.
  
  An UPDATE/SELECT SQL-statement will not be possible unless a table can
 be produced which holds the categories for both database layers for each
 geometry element.
  
  How can this be solved ?
 
 At this stage, the only way I can see to solve this problem is using 
 v.build option=cdump. This gives you something like this:
 
 -- CATEGORY INDEX DUMP: Number of layers: 2 
  --
 Layer  1  number of unique cats:   6  number of cats:   6 
 number of  types: 1
 
 --
  type | count
 1 | 6
   category | type | line/area
  1 |1 | 1
  2 |1 | 2
  3 |1 | 3
  4 |1 | 4
  5 |1 | 5
  6 |1 | 6
 
 --
 Layer  2  number of unique cats:   6  number of cats:   6 
 number of  types: 1
 
 --
  type | count
 1 | 6
   category | type | line/area
  1 |1 | 1
  3 |1 | 2
  5 |1 | 3
  7 |1 | 4
  9 |1 | 5
 11 |1 | 6
 
 
 So, you see that the line/area id can be used to find the correspondance 
 between the category values in both layers (i.e. in this case cat 3 in 
 layer 1 is the same object as cat 5 in layer 2.
 
 Unfortunately, there is no script friendly output from v.build 
 (ToDo...), but still it should be possible to wrap this into a script 
 with some python or awk magic. The easiest would probably be to use a 
 real SQL backend (i.e. not dbf) and to add a column with the line id to 
 each feature (i.e. 'v.db.update col=lineid value=$line where=cat=$cat' 
 where $line and $cat are the variables of the script read from the 
 v.build ouput...
 
 If you come up with a script, I think that this would be very useful. 
 One thing I have been confronted with before was the desire to create a 
 second layer with exactly the same category values (which didn't start 
 at 1 and which had no regular step as they were statistical id codes of 
 municipalities) which currently isn't possible.
 
 But adding a clayer option to v.db.update might be another solution.
 
 Moritz

-- 
Dr. Peter Löwe
[EMAIL PROTECTED]





Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.generalize / reanimation of dead lines ?

[Peter Löwe]

Hi,

I second the unclean deletion theory as I encountered this phenomenon before. 
Also, when generalizing areas which are attached to each other, while the 
overall appearance of the generalized borderlines is ok, more than 50 % of 
the areas cease to exist, which needs further investigation: Apart from dead 
lines we're dealing with area mutilation and centroid abduction!

The (topological) truth is somewhere out there,
Peter


 Original-Nachricht 
 Datum: Fri, 29 Aug 2008 19:17:46 +0300
 Von: Wolf Bergenheim [EMAIL PROTECTED]
 An: [EMAIL PROTECTED]
 CC: grass-user@lists.osgeo.org, [EMAIL PROTECTED], [EMAIL PROTECTED], Daniel 
 Bundala [EMAIL PROTECTED]
 Betreff: Re: [GRASS-user] v.generalize / reanimation of dead lines ?

 On 29.08.2008 18:54, Dylan Beaudette wrote:
  
  I have noticed this behavior as well when using v.generalize. I will try
 and 
  dig up the exact situation that caused it-- but I am pretty sure that
 the 
  initial linework was correct = unclean deletion.
  
 
 That is very much possible. This module is still quite young and hasn't
 gone through a lot of live testing yet. Dylan, I'd be vey interested in
 this, if you can give me a simple case where it goes wrong.
 
 --Wolf
 
 Adding Daniel Bundala to the Cc list, as he wrote it last summer.
 
 -- 
 
 :3 ) Wolf Bergenheim ( 8:

-- 
Dr. Peter Löwe
[EMAIL PROTECTED]





Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.in.gns problem in epsg4326 location

[Peter Löwe]

Hi Markus: 

Good to hear that the problem has been fixed in the svn versions.

FYI: The latest downloadable version of the native Windoze version still ships 
with this bug.

best,
Peter

 Original-Nachricht 
 Datum: Mon, 7 Jul 2008 13:38:01 +0200
 Von: Markus Neteler [EMAIL PROTECTED]
 An: [EMAIL PROTECTED]
 CC: grass-user@lists.osgeo.org
 Betreff: Re: [GRASS-user] v.in.gns problem in epsg4326 location

 On Mon, Jul 7, 2008 at 1:33 PM,  [EMAIL PROTECTED] wrote:
  hello list,
 
  trying to import a GNS file in an empty location (wgs84/EPSG:4326)
 resulted in the following error:
 
  -
  Unparsable latitude value: LAT
  Cannot open existing vector [EMAIL PROTECTED] on level [2]
  
 
  The problem is reproducable and occurs both on a linux built (Debian,
 locally compiled) and a precompiled native XP version.
 
  Are there known workarounds ?
 
 Yes - update GRASS :)
 We have fixed that recently (6.4.svn and 7.svn), it was a buffer overflow
 in
 v.in.ascii in case of long column fields (long citiy names etc).
 
 Markus

-- 
Dr. Peter Löwe
[EMAIL PROTECTED]





Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Re: Any freely available topographical maps for

[Peter Löwe]

Hi,

I didn't follow the full discussion, but this one might be at least of 
scientific interest regarding the TOP50-CD/DVDs:
http://www.mfraenz.de/top50/index.html

Regards,
Peter
-- 
Dr. Peter Löwe
[EMAIL PROTECTED]





Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Re: grass-user Digest, Vol 24, Issue 9: Problems with NVIZ Volume

[Peter Löwe]

Suenia:

I would assume that the setting of elevation of the location causes the trouble.

Maybe this will help you to set up the loaction properly:

Have a look at the code of r.in.srtm
(http://grass.itc.it/grass63/manuals/html63_user/r.in.srtm.html)
and/or consult the article by Markus Neteler about it in GRASS NEWS, VOl 3:
http://grass.itc.it/newsletter/GRASSNews_vol3.pdf

Cheers,
Peter

 --
 
 Message: 1
 Date: Tue, 8 Apr 2008 11:09:04 +0200 (CEST)
 From: suenia [EMAIL PROTECTED]
 Subject: [GRASS-user] Problems with NVIZ Volume (3dGRID) Visualization
   !
 To: grass-user@lists.osgeo.org
 Message-ID: [EMAIL PROTECTED]
 Content-Type: text/plain; charset=iso-8859-1
 
 Hello together !
   I have problems with NVIZ Volume visualization !
  Here I made an example generating a simple 3dgrid volume assuming
 subterranean data and the failing of visualizing it. I would really appreciate
 some help !  
   Here the short workflow:
 #Generating three surfaces which will model the volume.
 GRASS 6.2.2 (4326):~  r.mapcalc dem.t=0
 GRASS 6.2.2 (4326):~  r.mapcalc dem.m=-10
 GRASS 6.2.2 (4326):~  r.mapcalc dem.b=-20
   #My region settings
 GRASS 6.2.2 (4326):~  g.region -p3
 projection: 3 (Latitude-Longitude)
 zone:   0
 datum:  wgs84
 ellipsoid:  a=6378137 es=0.006694379990141316
 north:  24:56:24N
 south:  12:54S
 west:   75:52:12E
 east:   114:17:24E
 top:0.
 bottom: -20.
 nsres:  0:59:44.842105
 nsres3: 0:59:44.842105
 ewres:  1:00:39.789474
 ewres3: 1:00:39.789474
 tbres:  1
 rows:   38
 rows3:  38
 cols:   38
 cols3:  38
 depths: 20
 cells:  1444
 3dcells:28880
 
  
   #Generating the 3d grid volume
 GRASS 6.2.2 (4326):~  r.to.rast3 input=dem.b,dem.m,dem.t output=dem –o  
 #Visualizing it!
 GRASS 6.2.2 (4326):~  nviz volume=dem elevation=dem.t
  
  When visualizing the 3dgrid volume dem, together with the raster
 surfaces, only outlines in form of a cube volume are drawn whenever 
 navigating in
 space !!! else nothing is seen but the raster surfaces.  
   When adding a new constant value, for example -10, to the raster volume,
 an associated unique colored surface at the bottom of the cube is
 observable.
   So, I´m not sure about what could be the problem or my mistake in the
 settings selection.
   Furthermore I would like to know how to change g.region res3,
 respectivly tbres for latitude longitude locations, when I try to change
 res30:59:44.842105 or tbres my region get's destroyed, definitely.
 For what stands the default value 1 of tbres ? 
   
  Could somebody offer more information about vertical resolution
 specifications for latitude longitude locations.
   That works : Slovakia3d can be visualised by adding new constant
 value for the raster volume. 
 
 Many thanks !
 Suena
  
  
-- 
Dr. Peter Löwe
[EMAIL PROTECTED]





Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] SHELL Variable problem: Workaround

[Peter Löwe]

Hello Oggi,

this is a quick workaround if you prefer for some reason not to nuke the user 
account anyway:

Set the variable manually on the shell:

SHELL=/bin/bash

and start GRASS. 

Cheers,
Peter


-- 
Dr. Peter Löwe
[EMAIL PROTECTED]





Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user