Re: [GRASS-dev] v.in.ogr and v.import do not import all features in gpkg file
Hi Vero and Markus, >> I am not sure what to do about this. Disable this safety check again? > Maybe the bb safety check makes sense for features other than points, dunno. > Others can for sure tell some use cases that I am not aware of. But I can say > that it is pretty striking to see that some features are "eaten and lost" > when importing into GRASS while ogr and others show everything. > > What about a flag? Import all by default and the safety check with a flag? Or > at least a note in the manual page of v.in.ogr > My two cents' worth: from my perspective as a user, the main problem is that it drops points without a warning (most of the time I am blissfully unaware of the exact number of features that need import). So throwing a warning should be considered, with maybe a flag as suggested by Vero to void that check. Cheers, P ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Programmatically obtain GRASS colour ramps in Python
Hi all, I am trying to write a little Python extension wrapping r.color to use different kind of strecthes, It should be pretty simple, basically just builkding rules on-the-fly and pass them to r.color. But I can't quite seem how to retrieve the GRASS color ramps details to create my ruleset. Is there any portable way to actually to actually passthe name of a GRASS color ramp, and get the details (colours) of that colour ramp? Cheers, Pierre ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] a proposal to rename "location"
My two cents' worth: it is indeed an issue for beginners, and would be great to see new term for it, but I would stay away from using acronyms. P On 16 June 2018 at 23:28, Huidae Cho wrote: > Dear All, > > I agree that this terminology needs to be changed. "Project" seems to > simplify this issue too much because one project doesn't always involve with > only one SRS. My database folder looks like this: > > aea@ > epsg102681/ > srorg7873/ > utm52n@ > xy/ > > I try to be consistent in naming Locations and follow EPSG or SR-ORG names. > Symbolic links (*@) are just for me to remember "common" projection names. > Inside these Locations, project folders reside. In this sense, Mapset serves > as a project folder and there can be multiple Mapsets in different Locations > for one project. One issue with this approach is you have to actively look > into all Locations to find project-related Mapsets unless you remember which > SRSs you used for the project. Probably, combination of project and SRS > names? > > Maybe, it would be better to create a project "Database" and put all > project-related data (different SRSs, currently Locations, and possibly > different users, Mapsets) in that one Database, but I never had more than > one Database before. I can already see an issue with this approach. No > global data for all projects to share. > > I think the challenge here is how to organize data for one project in > different SRSs in a more intuitive and efficient way. > > Just my 2 cents. > Huidae > > > On Sun, Jun 3, 2018 at 8:09 AM, Nikos Alexandris > wrote: >> >> * Vaclav Petras [2018-06-02 11:14:57 -0400]: >> >> >>> On Fri, Jun 1, 2018 at 6:51 PM, Michael Barton >>> wrote: >>> As one of the most venerable desktop GIS packages and perhaps THE most venerable still in existence, GRASS has some quirks that harken back to its origins long ago. Most are simply quirky. But the folder hierarchy called a “location” is very confusing in today’s GIS world. Originally, it did primarily refer to maps referencing a geographic location in the world. Although that meaning still exists in the ‘default region’, GRASS locations primarily refer to a coordinate reference system (CRS). In fact, while the CRS of a location cannot be changed (unless you manually alter some of the files in the directory, at the risk of making maps unuseable), the default region can be. So a location now refers to a fixed CRS and a changeable geographic extent. Use of the anachronistic term “location” to refer to a CRS is a quirk that makes GRASS more confusing to initial users. >>> >>> I agree that the current situation is not satisfactory and I think your >>> description of the situation is very good. The "project location" or just >>> "project" or even "coordinate system" were all terms which were used in >>> the >>> 6.4 startup/welcome window: >>> >>> >>> https://trac.osgeo.org/grass/attachment/wiki/wxGUIDevelopment/New_Startup/ >>> startup_grass_6.4_wxpython.png >>> >>> I though it will be much better in order to avoid confusion to go with >>> just >>> one term and properly explain it. Without changing anything, I of course >>> needed to go with location in the new startup window and documentation: >>> >>> >>> https://trac.osgeo.org/grass/attachment/wiki/wxGUIDevelopment/New_Startup/ >>> startup_grass_7.5.png >>> https://grass.osgeo.org/grass74/manuals/grass_database.html >>> >>> However, I think it is still quite hard for users to understand and it >>> becomes difficult to talk about location because of the general meaning >>> of >>> that word. Possible solutions include better interface (e.g. the new >>> startup), change in paradigm (in interface or also in core), and a >>> different name. >>> >>> Generally, the new name should be considered together the related terms, >>> such as [default] region, database, mapset, and [vector] map. >>> >>> I'm not in favor of "CRS" because a CRS is description of the reference >>> system. It is a property of the data or a name of particular part of >>> metadata. Location in GRASS GIS is a collection of spatial data with a >>> common CRS. >>> >>> I've tried to use "Location" (with capital L) and "GRASS Location" to >>> make >>> it clear what location we are talking about, but it suffers from the same >>> issues as simple "location". For example: Is GRASS location directory on >>> your computer where you have GRASS GIS installation? >>> >>> Best, >>> Vaclav >> >> >> Dear Vaclav, >> >> When you start explaining the data base structure, in GRASS GIS, where >> do you start? Excluding the Mapsets (plus the PERMANENT Mapset) concept, >> >> I start with: >> " >> Think of a big box. Inside it, you can keep all items related to >> your (specific) project. Now, let use create this box, it's a directory >> (or folder). What will be its name? Name it the way you think is best, >> for your needs, so you k
Re: [GRASS-dev] GSoC introduction Roberta Fagandini
Hi Stefan and Roberta, We can probably help too -- I work on Antarctic datasets: relief, clouds, and very cold, white surface! Cheers, P On 17 May 2018 at 02:22, Stefan Blumentrath wrote: > Hi Roberta, > > > > Here in Norway we can do some “worst case” testing for your algorithm. > Plenty of snow and clouds in the mountains, and heavily rugged terrain, that > presumably has quite some effect on cloud shadows… > > > > Looking forward to following your project from the side! > > > > Kind regards, > > Stefan > > > > > > From: grass-dev On Behalf Of Roberta > Fagandini > Sent: onsdag 16. mai 2018 16.01 > To: Pierre Roudier > Cc: grass-dev > Subject: Re: [GRASS-dev] GSoC introduction Roberta Fagandini > > > > > > Thank you, Pierre!! I will keep the community constantly updated on the > progress of the module. > > Every feedback is welcome so please do not hesitate to send me yours! ;) > > > > Roberta > > > > 2018-05-15 23:46 GMT+02:00 Pierre Roudier : > > Interesting to hear your results, Roberta -- the reason I brought this > up is that some of my colleagues (non-GRASS users :( ) tried it very > successfully. > > Happy to follow up with them if need be, > > P > > > On 15 May 2018 at 22:03, Roberta Fagandini wrote: >> Hi Pierre! >> Thank you so much for your hints! >> I have already tested Fmask with Sentinel 2 images but I didn't have great >> results. However, it is worth investigating better! >> Thanks for all the references! >> >> Roberta >> >> >> 2018-05-15 0:51 GMT+02:00 Pierre Roudier : >>> >>> Hi Roberta, >>> >>> On top of the review linked by Vero, I thought I'd mention the Fmask >>> procedure -- it seems to give great results and there is a python >>> library on Github. >>> >>> *Relevant GRASS GIS tickets*: >>> >>> https://trac.osgeo.org/grass/ticket/3473 >>> https://trac.osgeo.org/grass/ticket/3283 >>> >>> *Papers*: >>> >>> >>> >>> https://www.researchgate.net/publication/270596187_Improvement_and_expansion_of_the_Fmask_algorithm_Cloud_cloud_shadow_and_snow_detection_for_Landsats_4-7_8_and_Sentinel_2_images >>> >>> >>> https://www.researchgate.net/publication/324836341_Improvement_of_the_Fmask_algorithm_for_Sentinel-2_images_Separating_clouds_from_bright_surfaces_based_on_parallax_effects >>> >>> *Software*: >>> >>> http://pythonfmask.org/en/latest/ >>> https://github.com/prs021/fmask >>> >>> Hopefully this is helpful, >>> >>> Pierre >>> >>> On 7 May 2018 at 19:49, Roberta Fagandini >>> wrote: >>> > >>> > >>> > 2018-05-06 21:52 GMT+02:00 Veronica Andreo : >>> >> >>> >> Hey Robi, >>> > >>> > >>> > Hi Vero!! >>> > >>> >> >>> >> >>> >> I just found this review [0]. It is for Landsat, but maybe some >>> >> insights >>> >> could be also useful for you (?) >>> > >>> > >>> > Thank you so much! I know this paper and it could be very useful >>> > especially >>> > for the second part of the procedure. >>> > I'll read it carefully! >>> > >>> >> >>> >> >>> >> Cheers :), >>> >> Vero >>> > >>> > >>> > Thanks! >>> > Robi >>> > >>> >> >>> >> >>> >> [0] >>> >> >>> >> >>> >> https://www.researchgate.net/publication/324975294_Cloud_and_Cloud_Shadow_Detection_for_Landsat_Images_The_Fundamental_Basis_for_Analyzing_Landsat_Time_Series >>> >> >>> >> El jue., 3 may. 2018 a las 22:06, Roberto Marzocchi >>> >> () escribió: >>> >>> >>> >>> Nice! The last step of the script you have written in python works as >>> >>> you >>> >>> expected. >>> >>> >>> >>> Now it is important to draw a diagram (or schema ) as a summary for >>> >>> you >>> >>> (you have worked a lot in the last few months) and to share it with >>> >>> Moritz >>> >>> and Markus. >>> >>> >>> >>> After that, test, test and test ;-) for validation/calibration of the >>> >>> automati
Re: [GRASS-dev] GSoC introduction Roberta Fagandini
Interesting to hear your results, Roberta -- the reason I brought this up is that some of my colleagues (non-GRASS users :( ) tried it very successfully. Happy to follow up with them if need be, P On 15 May 2018 at 22:03, Roberta Fagandini wrote: > Hi Pierre! > Thank you so much for your hints! > I have already tested Fmask with Sentinel 2 images but I didn't have great > results. However, it is worth investigating better! > Thanks for all the references! > > Roberta > > > 2018-05-15 0:51 GMT+02:00 Pierre Roudier : >> >> Hi Roberta, >> >> On top of the review linked by Vero, I thought I'd mention the Fmask >> procedure -- it seems to give great results and there is a python >> library on Github. >> >> *Relevant GRASS GIS tickets*: >> >> https://trac.osgeo.org/grass/ticket/3473 >> https://trac.osgeo.org/grass/ticket/3283 >> >> *Papers*: >> >> >> https://www.researchgate.net/publication/270596187_Improvement_and_expansion_of_the_Fmask_algorithm_Cloud_cloud_shadow_and_snow_detection_for_Landsats_4-7_8_and_Sentinel_2_images >> >> https://www.researchgate.net/publication/324836341_Improvement_of_the_Fmask_algorithm_for_Sentinel-2_images_Separating_clouds_from_bright_surfaces_based_on_parallax_effects >> >> *Software*: >> >> http://pythonfmask.org/en/latest/ >> https://github.com/prs021/fmask >> >> Hopefully this is helpful, >> >> Pierre >> >> On 7 May 2018 at 19:49, Roberta Fagandini wrote: >> > >> > >> > 2018-05-06 21:52 GMT+02:00 Veronica Andreo : >> >> >> >> Hey Robi, >> > >> > >> > Hi Vero!! >> > >> >> >> >> >> >> I just found this review [0]. It is for Landsat, but maybe some >> >> insights >> >> could be also useful for you (?) >> > >> > >> > Thank you so much! I know this paper and it could be very useful >> > especially >> > for the second part of the procedure. >> > I'll read it carefully! >> > >> >> >> >> >> >> Cheers :), >> >> Vero >> > >> > >> > Thanks! >> > Robi >> > >> >> >> >> >> >> [0] >> >> >> >> https://www.researchgate.net/publication/324975294_Cloud_and_Cloud_Shadow_Detection_for_Landsat_Images_The_Fundamental_Basis_for_Analyzing_Landsat_Time_Series >> >> >> >> El jue., 3 may. 2018 a las 22:06, Roberto Marzocchi >> >> () escribió: >> >>> >> >>> Nice! The last step of the script you have written in python works as >> >>> you >> >>> expected. >> >>> >> >>> Now it is important to draw a diagram (or schema ) as a summary for >> >>> you >> >>> (you have worked a lot in the last few months) and to share it with >> >>> Moritz >> >>> and Markus. >> >>> >> >>> After that, test, test and test ;-) for validation/calibration of the >> >>> automatic procedure. >> >>> >> >>> R >> >>> >> >>> 2018-05-03 18:48 GMT+02:00 Roberta Fagandini >> >>> : >> >>>> >> >>>> >> >>>> 2018-05-03 14:03 GMT+02:00 Moritz Lennert >> >>>> : >> >>>>> >> >>>>> Hi Roberta, >> >>>> >> >>>> >> >>>> Hi Moritz and Roberto! >> >>>> >> >>>>> >> >>>>> >> >>>>> On 25/04/18 18:03, Roberta Fagandini wrote: >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> 2018-04-25 16:03 GMT+02:00 Moritz Lennert >> >>>>>> > >>>>>> <mailto:mlenn...@club.worldonline.be>>: >> >>>>>> Looking at your bash scripts, I think the first thing to do >> >>>>>> during >> >>>>>> this bonding period is, as you planned yourself, to get >> >>>>>> familiar >> >>>>>> with the writing of GRASS modules in Python. You can have a >> >>>>>> look >> >>>>>> at >> >>>>>> existing scripts [1, 2] to get feeling for this works and how >> >>>>>> to >> >>>>>> structure ad
Re: [GRASS-dev] GSoC introduction Roberta Fagandini
Hi Roberta, On top of the review linked by Vero, I thought I'd mention the Fmask procedure -- it seems to give great results and there is a python library on Github. *Relevant GRASS GIS tickets*: https://trac.osgeo.org/grass/ticket/3473 https://trac.osgeo.org/grass/ticket/3283 *Papers*: https://www.researchgate.net/publication/270596187_Improvement_and_expansion_of_the_Fmask_algorithm_Cloud_cloud_shadow_and_snow_detection_for_Landsats_4-7_8_and_Sentinel_2_images https://www.researchgate.net/publication/324836341_Improvement_of_the_Fmask_algorithm_for_Sentinel-2_images_Separating_clouds_from_bright_surfaces_based_on_parallax_effects *Software*: http://pythonfmask.org/en/latest/ https://github.com/prs021/fmask Hopefully this is helpful, Pierre On 7 May 2018 at 19:49, Roberta Fagandini wrote: > > > 2018-05-06 21:52 GMT+02:00 Veronica Andreo : >> >> Hey Robi, > > > Hi Vero!! > >> >> >> I just found this review [0]. It is for Landsat, but maybe some insights >> could be also useful for you (?) > > > Thank you so much! I know this paper and it could be very useful especially > for the second part of the procedure. > I'll read it carefully! > >> >> >> Cheers :), >> Vero > > > Thanks! > Robi > >> >> >> [0] >> https://www.researchgate.net/publication/324975294_Cloud_and_Cloud_Shadow_Detection_for_Landsat_Images_The_Fundamental_Basis_for_Analyzing_Landsat_Time_Series >> >> El jue., 3 may. 2018 a las 22:06, Roberto Marzocchi >> () escribió: >>> >>> Nice! The last step of the script you have written in python works as you >>> expected. >>> >>> Now it is important to draw a diagram (or schema ) as a summary for you >>> (you have worked a lot in the last few months) and to share it with Moritz >>> and Markus. >>> >>> After that, test, test and test ;-) for validation/calibration of the >>> automatic procedure. >>> >>> R >>> >>> 2018-05-03 18:48 GMT+02:00 Roberta Fagandini : 2018-05-03 14:03 GMT+02:00 Moritz Lennert : > > Hi Roberta, Hi Moritz and Roberto! > > > On 25/04/18 18:03, Roberta Fagandini wrote: >> >> >> >> 2018-04-25 16:03 GMT+02:00 Moritz Lennert >> mailto:mlenn...@club.worldonline.be>>: >> Looking at your bash scripts, I think the first thing to do during >> this bonding period is, as you planned yourself, to get familiar >> with the writing of GRASS modules in Python. You can have a look >> at >> existing scripts [1, 2] to get feeling for this works and how to >> structure addon code in order to make it directly installable with >> g.extension. >> >> You can find the actual function definitions and documentation of >> the GRASS Python scripting library at [3]. The functions in that >> library should be more than enough to translate your scripts into >> a >> (or several) modules. >> >> Be aware that GRASS modules create their own GUI. So, unless you >> need some interactive features in your modules, you will not have >> to >> program your own GUI. >> >> >> Thank you for your precious suggestions! I'll start studying how to >> write a GRASS module in Python in the next days and at the same time I >> will >> keep on testing the procedures so as to show you some results and fix >> some >> open points. >> >> >> Something else you should probably do during this bonding time is >> to >> elaborate a schema of your algorithm, so that it is easier to >> understand what it does at each step. >> >> >> Yes, this could be very useful also for me in order to better organize >> and put in order everything! >> > > Have you advanced on any of this ? Do you have any questions ? Please > don't hesitate to ask on the mailing list. Yes, I started working with GRASS Python scripting library. I'm following the link [0] you suggested, I'm also looking at other existing GRASS scripts [1,2] and moreover, Roberto gave me one of his scripts as an example. I have just committed the first version of the python script I'm working on, it works and I'm quite satisfied ;-) Tomorrow I want to elaborate the schema of the algorithm and at the same time, I have to keep testing the procedure. As I wrote in the bash file, shadows detection seems to be strongly land cover dependent therefore I think it is necessary to test the procedure using several images sensed in different seasons, latitude, etc. Anyway, I'll commit some results tomorrow so as to show you something more concrete! > > > Best wishes, > Moritz Best regards, Roberta [0] https://grass.osgeo.org/grass75/manuals/libpython/script_intro.html [1] https://trac.osgeo.org/grass/browser/grass/trunk/scripts [2] https://trac.osgeo.org/grass/browser/grass
Re: [GRASS-dev] Weird bug in r.sun: command hangs forever for some day of the year
The problem seems to be fixed in the grass7.5-svn I last checked out from
SVN and compiled about 3 weeks ago.
Hum...
On 16 March 2018 at 11:22, Pierre Roudier wrote:
> OK, something additional I noticed: I obviously wrapped the calculations
> for each day of the year in a script.
>
> Somehow, it seems I can re-process manually a day that was hanging during
> the script.
>
> Below is the script I used:
>
> for DAY in $(seq 1 365);
> do
> DOY=$(printf "%03d\n" $((DAY)))
>
> echo "Processing day ${DOY} ..."
>
> eval `g.findfile element=cell file="glob_rad_${DOY}"`
>
> if [ ! "$file" ]
> then
>
> r.sun elev=dem_1k aspect=aspect_1k slope=slope_1k day=$DAY
> glob_rad=glob_rad_${DOY}
>
> sleep 15
>
> fi
> done
>
>
>
> On 16 March 2018 at 11:04, Pierre Roudier
> wrote:
>
>> Hi,
>>
>> Just bumped into the weirdest bug in r.sun on GRASS 7.4 as installed from
>> the Ubuntu repository.
>>
>> I am using r.sun in Mode 2 to compute the daily average global radiation.
>> The GRASS location is using EPSG:3031: this is data over the entire
>> Antarctica.
>>
>> For some specific days, that seem to be in winter, when most of the
>> continent doesn't recieve any solar radiation, the command would hang
>> forever at 9%:
>>
>> For example I had to kill this command:
>>
>> [Raster MASK present]
>> GRASS 7.4.0 (modis_lst_2015):/media/pierre/1TB_ext4/code > time r.sun
>> elev=dem_1k aspect=aspect_1k slope=slope_1k day=159 glob_rad=glob_rad_159
>> --o --verbose
>> Number of threads <1>
>> Mode 2: integrated daily irradiation for a given day of the year
>> Using Linke constant: 3.00
>> Using albedo constant: 0.20
>> Using slope map
>> Using aspect map
>> ^C 9%
>>
>> But for the day before and the day after the command was successful in
>> less than a minute:
>>
>> GRASS 7.4.0 (modis_lst_2015):/media/pierre/1TB_ext4/code > time r.sun
>> elev=dem_1k aspect=aspect_1k slope=slope_1k day=160 glob_rad=glob_rad_160
>> --o --verbose
>> Number of threads <1>
>> Mode 2: integrated daily irradiation for a given day of the year
>> Using Linke constant: 3.00
>> Using albedo constant: 0.20
>> Using slope map
>> Using aspect map
>> 100%
>>
>> real0m30.019s
>> user0m29.602s
>> sys0m0.372s
>>
>> It also happened on day 151... I'm a bit stuck, so any pointers would be
>> appreciated.
>>
>> Cheers,
>>
>> Pierre
>>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Weird bug in r.sun: command hangs forever for some day of the year
OK, something additional I noticed: I obviously wrapped the calculations
for each day of the year in a script.
Somehow, it seems I can re-process manually a day that was hanging during
the script.
Below is the script I used:
for DAY in $(seq 1 365);
do
DOY=$(printf "%03d\n" $((DAY)))
echo "Processing day ${DOY} ..."
eval `g.findfile element=cell file="glob_rad_${DOY}"`
if [ ! "$file" ]
then
r.sun elev=dem_1k aspect=aspect_1k slope=slope_1k day=$DAY
glob_rad=glob_rad_${DOY}
sleep 15
fi
done
On 16 March 2018 at 11:04, Pierre Roudier wrote:
> Hi,
>
> Just bumped into the weirdest bug in r.sun on GRASS 7.4 as installed from
> the Ubuntu repository.
>
> I am using r.sun in Mode 2 to compute the daily average global radiation.
> The GRASS location is using EPSG:3031: this is data over the entire
> Antarctica.
>
> For some specific days, that seem to be in winter, when most of the
> continent doesn't recieve any solar radiation, the command would hang
> forever at 9%:
>
> For example I had to kill this command:
>
> [Raster MASK present]
> GRASS 7.4.0 (modis_lst_2015):/media/pierre/1TB_ext4/code > time r.sun
> elev=dem_1k aspect=aspect_1k slope=slope_1k day=159 glob_rad=glob_rad_159
> --o --verbose
> Number of threads <1>
> Mode 2: integrated daily irradiation for a given day of the year
> Using Linke constant: 3.00
> Using albedo constant: 0.20
> Using slope map
> Using aspect map
> ^C 9%
>
> But for the day before and the day after the command was successful in
> less than a minute:
>
> GRASS 7.4.0 (modis_lst_2015):/media/pierre/1TB_ext4/code > time r.sun
> elev=dem_1k aspect=aspect_1k slope=slope_1k day=160 glob_rad=glob_rad_160
> --o --verbose
> Number of threads <1>
> Mode 2: integrated daily irradiation for a given day of the year
> Using Linke constant: 3.00
> Using albedo constant: 0.20
> Using slope map
> Using aspect map
> 100%
>
> real0m30.019s
> user0m29.602s
> sys0m0.372s
>
> It also happened on day 151... I'm a bit stuck, so any pointers would be
> appreciated.
>
> Cheers,
>
> Pierre
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Weird bug in r.sun: command hangs forever for some day of the year
Hi, Just bumped into the weirdest bug in r.sun on GRASS 7.4 as installed from the Ubuntu repository. I am using r.sun in Mode 2 to compute the daily average global radiation. The GRASS location is using EPSG:3031: this is data over the entire Antarctica. For some specific days, that seem to be in winter, when most of the continent doesn't recieve any solar radiation, the command would hang forever at 9%: For example I had to kill this command: [Raster MASK present] GRASS 7.4.0 (modis_lst_2015):/media/pierre/1TB_ext4/code > time r.sun elev=dem_1k aspect=aspect_1k slope=slope_1k day=159 glob_rad=glob_rad_159 --o --verbose Number of threads <1> Mode 2: integrated daily irradiation for a given day of the year Using Linke constant: 3.00 Using albedo constant: 0.20 Using slope map Using aspect map ^C 9% But for the day before and the day after the command was successful in less than a minute: GRASS 7.4.0 (modis_lst_2015):/media/pierre/1TB_ext4/code > time r.sun elev=dem_1k aspect=aspect_1k slope=slope_1k day=160 glob_rad=glob_rad_160 --o --verbose Number of threads <1> Mode 2: integrated daily irradiation for a given day of the year Using Linke constant: 3.00 Using albedo constant: 0.20 Using slope map Using aspect map 100% real0m30.019s user0m29.602s sys0m0.372s It also happened on day 151... I'm a bit stuck, so any pointers would be appreciated. Cheers, Pierre ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Untangling geoPAT installation when updating GRASS version
Dear Vaclav, Here's what I ended up doing: * I updated my GRASS trunk and compiled (./configure, make, then make install) * I applied your patch to geoPAT * I ran make MODULE_TOPDIR=/usr/local/src/grass7_trunk/ in the geoPAT directory Unfortunately still the same issue running it in grass75: GRASS 7.5.svn (modis_lst_2015):/usr/local/src/grass7_trunk > p.sig.grid --help ERROR: Module built against version $Revision: 70617 $ but trying to use version $Revision: 72230 $. You need to rebuild GRASS GIS or untangle multiple installations. Any idea what I might have missed? Cheers, Pierre On 26 February 2018 at 16:53, Vaclav Petras wrote: > > > On Sun, Feb 25, 2018 at 10:41 PM, Pierre Roudier > wrote: > >> Hi Vaclav, and thank you so much for your help, >> > > You are welcome. > > >> >> Do I understand correctly that I should compile a version of GRASS to use >> your patch? >> > > The patch is for geoPAT, but I tested the subsequent compilation of geoPAT > only against compiled GRASS (which is not `make install`ed). > > >> >> Cheers, >> >> P >> >> On 25 February 2018 at 15:52, Vaclav Petras wrote: >> >>> Dear all, >>> >>> this may not address this specific problem with multiple installations, >>> but it may help overall with debugging such problems because it is more >>> direct. I'm attaching a geoPAT patch which deals with the names of the >>> libraries and removes the need to modify GRASS source code before the >>> compilation happens. >>> >>> The following command executed in the directory with the source code >>> should be sufficient to compile modules with a self-compiled GRASS which is >>> not in system: >>> >>> make MODULE_TOPDIR=~/.../trunk/ GRASS_VERSION_NUMBER=7.5.svn >>> >>> Path to the GRASS GIS installation/code/dev files and the version needs >>> to be provided. This was tested with the current trunk in a home directory >>> and not with GRASS installed (`make install`-ed) in the system. >>> Nevertheless this removes the need to modify the source code and thus >>> increasing compatibility with different GRASS versions (which change the >>> copied and modified file). >>> >>> Besides the limited testing, there are three other issues: >>> >>> 1) g.extension is not able to install the code from a directory (or ZIP, >>> ...) because no system for C addon modules with libraries is in place (same >>> issue as with r.pi.* suite). When GRASS_VERSION_NUMBER is added to >>> g.extension code and HTML for the main directory is resolved/or ignored in >>> g.extension, modules at least compile, but nothing is installed (added) to >>> the local addons directory. >>> >>> 2) I don't understand why GRASS_VERSION_NUMBER isn't already defined. >>> >>> 3) I don't know how to contribute to the geoPAT repository. >>> >>> Best, >>> Vaclav >>> >>> >>> >>> On Fri, Feb 23, 2018 at 6:22 PM, Dylan Beaudette < >>> dylan.beaude...@gmail.com> wrote: >>> >>>> How about your GRASS "development" files: installed via package >>>> manager? Same version as the binaries? >>>> >>>> D >>>> >>>> On Fri, Feb 23, 2018 at 1:10 PM, Pierre Roudier >>>> wrote: >>>> > Thanks Dylan, >>>> > >>>> > I did install using `sudo sh install.sh grass72` -- then `sudo sh >>>> install.sh >>>> > grass74` after my Grass version got updated to 7.4 >>>> > >>>> > Cheers, >>>> > >>>> > P >>>> > >>>> > On 23 February 2018 at 18:41, Dylan Beaudette < >>>> dylan.beaude...@gmail.com> >>>> > wrote: >>>> >> >>>> >> Howdy Pierre! >>>> >> >>>> >> In my experience, the GeoPat modules need to know where several >>>> things >>>> >> are located, including (I think) parts of the GRASS source code. Have >>>> >> a look through the install.sh code: >>>> >> >>>> >> http://sil.uc.edu/gitlist/geoPAT/blob/stable/install.sh >>>> >> >>>> >> I was able to get these modules up and running by invoking >>>> install.sh like >>>> >> this: >>>> >> >>>> >> sh install.sh grass75 >>>> >> >&g
Re: [GRASS-dev] Problem compiling ximgview in the latest grass_trunk
Hi all, Just ran over that bug at compilation of the latest trunk (7.5-svn) on the latest Ubuntu LTS (16.04-1). The workaround (editing Platform.make file by hand) still works, but I was wondering whether other Ubuntu users had the same issue, Cheers, Pierre On 31 August 2012 at 15:01, Pierre Roudier wrote: > Ticket created here: http://trac.osgeo.org/grass/ticket/1713 > > Thanks, > > P > > 2012/8/31 Glynn Clements : > > > > Pierre Roudier wrote: > > > >> I still got the same problem - I'm happy to use the workaround and > >> edit the Platform.make file by hand, but should I lodge a bug report > >> in the tracker? > > > > Please do. > > > > Even though ximgview is redundant (the same functionality is available > > via both wximgview and wximgview.py), we need raw access to Xlib for > > reasons related to NVIZ. > > > > -- > > Glynn Clements > > > > -- > Scientist > Landcare Research, New Zealand > ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Untangling geoPAT installation when updating GRASS version
Hi Vaclav, and thank you so much for your help, Do I understand correctly that I should compile a version of GRASS to use your patch? Cheers, P On 25 February 2018 at 15:52, Vaclav Petras wrote: > Dear all, > > this may not address this specific problem with multiple installations, > but it may help overall with debugging such problems because it is more > direct. I'm attaching a geoPAT patch which deals with the names of the > libraries and removes the need to modify GRASS source code before the > compilation happens. > > The following command executed in the directory with the source code > should be sufficient to compile modules with a self-compiled GRASS which is > not in system: > > make MODULE_TOPDIR=~/.../trunk/ GRASS_VERSION_NUMBER=7.5.svn > > Path to the GRASS GIS installation/code/dev files and the version needs to > be provided. This was tested with the current trunk in a home directory and > not with GRASS installed (`make install`-ed) in the system. Nevertheless > this removes the need to modify the source code and thus increasing > compatibility with different GRASS versions (which change the copied and > modified file). > > Besides the limited testing, there are three other issues: > > 1) g.extension is not able to install the code from a directory (or ZIP, > ...) because no system for C addon modules with libraries is in place (same > issue as with r.pi.* suite). When GRASS_VERSION_NUMBER is added to > g.extension code and HTML for the main directory is resolved/or ignored in > g.extension, modules at least compile, but nothing is installed (added) to > the local addons directory. > > 2) I don't understand why GRASS_VERSION_NUMBER isn't already defined. > > 3) I don't know how to contribute to the geoPAT repository. > > Best, > Vaclav > > > > On Fri, Feb 23, 2018 at 6:22 PM, Dylan Beaudette < > dylan.beaude...@gmail.com> wrote: > >> How about your GRASS "development" files: installed via package >> manager? Same version as the binaries? >> >> D >> >> On Fri, Feb 23, 2018 at 1:10 PM, Pierre Roudier >> wrote: >> > Thanks Dylan, >> > >> > I did install using `sudo sh install.sh grass72` -- then `sudo sh >> install.sh >> > grass74` after my Grass version got updated to 7.4 >> > >> > Cheers, >> > >> > P >> > >> > On 23 February 2018 at 18:41, Dylan Beaudette < >> dylan.beaude...@gmail.com> >> > wrote: >> >> >> >> Howdy Pierre! >> >> >> >> In my experience, the GeoPat modules need to know where several things >> >> are located, including (I think) parts of the GRASS source code. Have >> >> a look through the install.sh code: >> >> >> >> http://sil.uc.edu/gitlist/geoPAT/blob/stable/install.sh >> >> >> >> I was able to get these modules up and running by invoking install.sh >> like >> >> this: >> >> >> >> sh install.sh grass75 >> >> >> >> ... where "grass75" is the binary compiled from grass_trunk. The >> >> install.sh code seemed to find the source code it needed and worked >> >> without issue. >> >> >> >> How did you install / upgrade the Geopat modules? Could it be that >> >> install.sh is "finding" the old source code / headers? Is there a >> >> package for both GRASS binaries and development files? >> >> >> >> Dylan >> >> >> >> >> >> On Thu, Feb 22, 2018 at 7:28 PM, Pierre Roudier >> >> wrote: >> >> > Hi, >> >> > >> >> > I've been compiling the geoPAT extensions for GRASS from >> >> > http://sil.uc.edu/gitlist/geoPAT/ >> >> > >> >> > At the time I was running GRASS 7.2.2 installed from the Ubuntu GIS >> >> > repository, but since this repo updated to GRASS 7.4, I have the >> >> > following >> >> > issue: >> >> > >> >> > GRASS 7.4.0 (modis_lst_2015):~ > p.sig.polygons --help >> >> > ERROR: Module built against version $Revision: 70617 $ but trying to >> use >> >> >version $Revision: 70829 $. You need to rebuild GRASS GIS or >> >> >untangle multiple installations. >> >> > [Raster MASK present] >> >> > >> >> > Any pointers about how to resolve the version tangling? I've tried >> >> > recompiling geoPAT, but that didn't work. >> >> > >> >> > Cheers, >> >> > >> >> > Pierre >> >> > >> >> > ___ >> >> > grass-dev mailing list >> >> > grass-dev@lists.osgeo.org >> >> > https://lists.osgeo.org/mailman/listinfo/grass-dev >> > >> > >> ___ >> grass-dev mailing list >> grass-dev@lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/grass-dev >> > > ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Untangling geoPAT installation when updating GRASS version
Hey Dylan, Yes, these were installed using the grass-dev package in the UnbuntuGIS repo, Cheers, P On 24 February 2018 at 12:22, Dylan Beaudette wrote: > How about your GRASS "development" files: installed via package > manager? Same version as the binaries? > > D > > On Fri, Feb 23, 2018 at 1:10 PM, Pierre Roudier > wrote: > > Thanks Dylan, > > > > I did install using `sudo sh install.sh grass72` -- then `sudo sh > install.sh > > grass74` after my Grass version got updated to 7.4 > > > > Cheers, > > > > P > > > > On 23 February 2018 at 18:41, Dylan Beaudette > > > wrote: > >> > >> Howdy Pierre! > >> > >> In my experience, the GeoPat modules need to know where several things > >> are located, including (I think) parts of the GRASS source code. Have > >> a look through the install.sh code: > >> > >> http://sil.uc.edu/gitlist/geoPAT/blob/stable/install.sh > >> > >> I was able to get these modules up and running by invoking install.sh > like > >> this: > >> > >> sh install.sh grass75 > >> > >> ... where "grass75" is the binary compiled from grass_trunk. The > >> install.sh code seemed to find the source code it needed and worked > >> without issue. > >> > >> How did you install / upgrade the Geopat modules? Could it be that > >> install.sh is "finding" the old source code / headers? Is there a > >> package for both GRASS binaries and development files? > >> > >> Dylan > >> > >> > >> On Thu, Feb 22, 2018 at 7:28 PM, Pierre Roudier > >> wrote: > >> > Hi, > >> > > >> > I've been compiling the geoPAT extensions for GRASS from > >> > http://sil.uc.edu/gitlist/geoPAT/ > >> > > >> > At the time I was running GRASS 7.2.2 installed from the Ubuntu GIS > >> > repository, but since this repo updated to GRASS 7.4, I have the > >> > following > >> > issue: > >> > > >> > GRASS 7.4.0 (modis_lst_2015):~ > p.sig.polygons --help > >> > ERROR: Module built against version $Revision: 70617 $ but trying to > use > >> >version $Revision: 70829 $. You need to rebuild GRASS GIS or > >> >untangle multiple installations. > >> > [Raster MASK present] > >> > > >> > Any pointers about how to resolve the version tangling? I've tried > >> > recompiling geoPAT, but that didn't work. > >> > > >> > Cheers, > >> > > >> > Pierre > >> > > >> > ___ > >> > grass-dev mailing list > >> > grass-dev@lists.osgeo.org > >> > https://lists.osgeo.org/mailman/listinfo/grass-dev > > > > > ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Untangling geoPAT installation when updating GRASS version
Thanks Dylan, I did install using `sudo sh install.sh grass72` -- then `sudo sh install.sh grass74` after my Grass version got updated to 7.4 Cheers, P On 23 February 2018 at 18:41, Dylan Beaudette wrote: > Howdy Pierre! > > In my experience, the GeoPat modules need to know where several things > are located, including (I think) parts of the GRASS source code. Have > a look through the install.sh code: > > http://sil.uc.edu/gitlist/geoPAT/blob/stable/install.sh > > I was able to get these modules up and running by invoking install.sh like > this: > > sh install.sh grass75 > > ... where "grass75" is the binary compiled from grass_trunk. The > install.sh code seemed to find the source code it needed and worked > without issue. > > How did you install / upgrade the Geopat modules? Could it be that > install.sh is "finding" the old source code / headers? Is there a > package for both GRASS binaries and development files? > > Dylan > > > On Thu, Feb 22, 2018 at 7:28 PM, Pierre Roudier > wrote: > > Hi, > > > > I've been compiling the geoPAT extensions for GRASS from > > http://sil.uc.edu/gitlist/geoPAT/ > > > > At the time I was running GRASS 7.2.2 installed from the Ubuntu GIS > > repository, but since this repo updated to GRASS 7.4, I have the > following > > issue: > > > > GRASS 7.4.0 (modis_lst_2015):~ > p.sig.polygons --help > > ERROR: Module built against version $Revision: 70617 $ but trying to use > >version $Revision: 70829 $. You need to rebuild GRASS GIS or > >untangle multiple installations. > > [Raster MASK present] > > > > Any pointers about how to resolve the version tangling? I've tried > > recompiling geoPAT, but that didn't work. > > > > Cheers, > > > > Pierre > > > > ___ > > grass-dev mailing list > > grass-dev@lists.osgeo.org > > https://lists.osgeo.org/mailman/listinfo/grass-dev > ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Untangling geoPAT installation when updating GRASS version
Hi, I've been compiling the geoPAT extensions for GRASS from http://sil.uc.edu/gitlist/geoPAT/ At the time I was running GRASS 7.2.2 installed from the Ubuntu GIS repository, but since this repo updated to GRASS 7.4, I have the following issue: GRASS 7.4.0 (modis_lst_2015):~ > p.sig.polygons --help ERROR: Module built against version $Revision: 70617 $ but trying to use version $Revision: 70829 $. You need to rebuild GRASS GIS or untangle multiple installations. [Raster MASK present] Any pointers about how to resolve the version tangling? I've tried recompiling geoPAT, but that didn't work. Cheers, Pierre ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] new addon: v.what.rast.multi
Hi Paulo, fl is used to store flags passed to the command. There was a typo in my code, and Moritz was kind enough to commit a corrected version of the add-on (thanks Moritz!), Would be more than happy to merge both addons, they do look similar enough to be merged. Cheers, P On 9 May 2017 at 19:30, Paulo van Breugel wrote: > Hi Pierre, > > I have one question about the code. In lines 126-130 you create an object > 'fl', which you subsequently do not seem to use. Perhaps in line 150 it > should be flags=fl ? > > Something else, last year I wrote an addon r.what.rastlabel ( > https://github.com/ecodiv/GRASS-scripts/tree/master/v.what.rastlabel) > which can be used to (multiple) raster values and labels. Optionally, it > can also upload raster values only, like your addon (that part uses the > same approach you use). I have not yet added it to the grass addon > repository. I might do that later, at which point we can also see if it > makes sense to merge the two. > > Cheers, > > Paulo > > > On 5/9/17 8:36 AM, Luca Delucchi wrote: > >> On 8 May 2017 at 07:16, Pierre Roudier wrote: >> >>> Hi all, >>> >>> Hi, >> >> FYI I just submitted my (first!) GRASS add-on, called v.what.rast.multi >>> [0]. >>> >>> It is a super simple Python wrapper around v.what.rast, and allows to >>> query >>> a suite of rasters in one go: >>> >>> thanks, it is useful >> to improve a little bit, you add multiprocessing to the module, for >> example a process for each raster >> > Interesting, could help to speed up with large point data layers. > >> >> Cheers, >>> >>> Pierre >>> >>> >> > ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] new addon: v.what.rast.multi
Thanks Luca, that would be a good idea indeed! Any pointers to implement this? I'm unfamiliar with parallel processing in Pygrass. Cheers, P On 9 May 2017 at 18:36, Luca Delucchi wrote: > On 8 May 2017 at 07:16, Pierre Roudier wrote: > > Hi all, > > > > Hi, > > > FYI I just submitted my (first!) GRASS add-on, called v.what.rast.multi > [0]. > > > > It is a super simple Python wrapper around v.what.rast, and allows to > query > > a suite of rasters in one go: > > > > thanks, it is useful > to improve a little bit, you add multiprocessing to the module, for > example a process for each raster > > > > > Cheers, > > > > Pierre > > > > > -- > ciao > Luca > > www.lucadelu.org > ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] new addon: v.what.rast.multi
Done -- thanks for the heads-up Moritz! On 8 May 2017 at 23:05, Moritz Lennert wrote: > On 08/05/17 07:16, Pierre Roudier wrote: > >> Hi all, >> >> FYI I just submitted my (first!) GRASS add-on, called v.what.rast.multi >> [0]. >> >> It is a super simple Python wrapper around v.what.rast, and allows to >> query a suite of rasters in one go: >> >> v.what.rast.multi map=mygeodetic_pts raster=elev_state_500m,slope,aspect >> columns=elevation,slope,aspect >> > > Very useful, thanks ! > > Don't forget to add the addon to the Makefile in the > grass-addons/grass7/vector directory. > > Moritz > ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] new addon: v.what.rast.multi
I guess I probably should have added the URL: https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.what.rast.multi Apologies! On 8 May 2017 at 17:16, Pierre Roudier wrote: > Hi all, > > FYI I just submitted my (first!) GRASS add-on, called v.what.rast.multi > [0]. > > It is a super simple Python wrapper around v.what.rast, and allows to > query a suite of rasters in one go: > > v.what.rast.multi map=mygeodetic_pts raster=elev_state_500m,slope,aspect > columns=elevation,slope,aspect > > Cheers, > > Pierre > > [0]: https://trac.osgeo.org/grass/browser/grass-addons/grass7/ > vector/v.what.rast.multi > ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] new addon: v.what.rast.multi
Hi all, FYI I just submitted my (first!) GRASS add-on, called v.what.rast.multi [0]. It is a super simple Python wrapper around v.what.rast, and allows to query a suite of rasters in one go: v.what.rast.multi map=mygeodetic_pts raster=elev_state_500m,slope,aspect columns=elevation,slope,aspect Cheers, Pierre [0]: https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.what.rast.multi ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] Object-based image classification in GRASS
Very useful resource Martin. FWIW, the translation of the page is very usable for non-Czech speakers: http://translate.google.com/translate?sl=cs&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fgeo.fsv.cvut.cz%2Fgwiki%2F153ZODH_%2F_15._cvi%25C4%258Den%25C3%25AD&act=url Pierre 2014-01-29 Martin Landa : > Hi Moritz, > > 2013-10-30 Moritz Lennert : > >> though some components would be nice to have in addition. Attached you can >> find a simple shell script which shows all the steps I went through. I >> commented it extensively, so it hopefully is easy to understand. > > I just wanted to thank you for the script and to the author(s) of > i.segment. Based on your script I was able in one day to prepare a new > lesson for my students [1] (in Czech only) ... > > Martin > > [1] http://geo.fsv.cvut.cz/gwiki/153ZODH_/_15._cvi%C4%8Den%C3%AD > ___ > grass-user mailing list > grass-u...@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Object-based image classification in GRASS
Moritz, Thanks heaps for the script. It's really is useful and will facilitate the adoption of i.segment. It certainly would be a nice addition to the wiki page. Unfortunately I can't comment too much on this, as my object-based classification projects are on hold, but I'll try to give that a shot sometime soon. It could also be interesting to try non-supervised approach using i.segment to limit the "salt and pepper" noise affecting such classifications. Cheers, Pierre 2013/10/31 Moritz Lennert : > Hello, > > Based on the great work on i.segment by Eric and MarkusM, I've been trying > to put up a complete workflow allowing object-based image classification in > GRASS. Conclusion: it is possible with currently available tools, even > though some components would be nice to have in addition. Attached you can > find a simple shell script which shows all the steps I went through. I > commented it extensively, so it hopefully is easy to understand. > > Some remarks: > > - This only works in GRASS 7. > > - It uses the v.class.mlpy addon module for classification, so that needs to > be installed. Kudos to Vaclav for that module ! It currently only uses the > DLDA classifier. The mlpy library offers many more, and I think it should be > quite easy to add them. Obviously, one could also simply export the > attribute table of the segments and of the training areas to csv files and > use R to do the classification. > > - At the top of the script are a series of parameters that have to be > defined before being able to use the script as such (but the script is more > meant as a proof-of-concept than as a real script) > > - Many other variables could be calculated for the segments: other texture > variables (possibly variables by segment, not as average of pixel-based > variables, cf [1]), other shape variables (cf the new work of MarkusM on > center lines and skeletons of polygons in v.voronoi), band indices, etc. It > would be interesting to hear what most people find useful. > > - I do the step of digitizing training areas in the wxGUI digitizer using > the attribute editing tool and filling in the 'class' attribute for those > polygons I find representative. As already mentioned in previous discussions > [2], I do think that it would be nice if we could have an attribute editing > form that is independent of the vector digitizer. > > More generally, it would be great to get feedback from interested people on > this approach to object-based image classification to see what we can do to > make it better. > > > Moritz > > [1] https://trac.osgeo.org/grass/ticket/2111 > [2] http://lists.osgeo.org/pipermail/grass-dev/2013-February/062148.html > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Problem installing r.modis on trunk
Hi, > On Fedora 19 no problem: > > GRASS 7.0.svn (nc_basic_spm_grass7):~ > g.extension r.modis > Fetching from GRASS-Addons SVN (be patient)... > Compiling... > Installing... > Updating metadata file... > Installation of successfully finished > Forgot to mention that I'm running Ubuntu 12.04.2. >> /usr/local/grass-7.0.svn/locale/scriptstrings/r.modis.download_to_translate.c: >> Directory nonexistent > > Does at least /usr/local/grass-7.0.svn/locale/ exist? > It does not - the correct path would be /usr/local/src/grass7_trunk/locale/scriptstrings. I am opening a bug in the trac, Pierre -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Problem installing r.modis on trunk
Hi, I'm having a wee problem trying to compile r.modis on the trunk version of GRASS. It does not seem to compile the pymodis library if I'm getting that right: GRASS 7.0.svn (eda-rsr):~ > g.extension ext=r.modis Fetching from GRASS-Addons SVN (be patient)... WARNING: gnome-keyring:: couldn't connect to: /tmp/keyring-CTEtVP/pkcs11: No such file or directory Compiling... /bin/sh: 1: cannot create /usr/local/grass-7.0.svn/locale/scriptstrings/r.modis.download_to_translate.c: Directory nonexistent sed: couldn't flush stdout: Broken pipe make[1]: [/usr/local/grass-7.0.svn/locale/scriptstrings/r.modis.download_to_translate.c] Error 2 (ignored) /bin/sh: 1: cannot create /usr/local/grass-7.0.svn/locale/scriptstrings/r.modis.import_to_translate.c: Directory nonexistent sed: couldn't flush stdout: Broken pipe make[1]: [/usr/local/grass-7.0.svn/locale/scriptstrings/r.modis.import_to_translate.c] Error 2 (ignored) Installing... Updating metadata file... Installation of successfully finished GRASS 7.0.svn (eda-rsr):~ > r.modis.import ERROR: modis library not found Is that a bug? Cheers, Pierre -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] i.segment: invalid region id 0
Any of you guys have code around to do hierarchical segmentation? Tried to do it in Python a few months ago, but failed (I'm not exactly a great Python coder it seems!). Cheers, Pierre 2013/7/31 Moritz Lennert : > On 27/07/13 00:19, Nikos Alexandris wrote: >> >> On Friday 26 of July 2013 15:41:25 Moritz Lennert wrote: >>> >>> On 26/07/13 15:17, Nikos Alexandris wrote: On Wednesday 17 of July 2013 12:56:58 Nikos Alexandris wrote: > > In any case, if wanted, I will try during the weekend to replicate a > Huge > region, as the one Moritz tested with a "rational" threshold (close to > zero). I couldn't make it -- my machine was under some sort of heavy reconstruction during the last weekend. Is this still of interest? Let a machine to chew-up a big region with i.segment? >>> >>> >>> Markus and I have been busy testing in the last weeks and thanks to >>> Markus' rapid reaction in correcting some bugs, we've been able to >>> segment an image with 555,727,911 non-null cells in a region with >>> 2,617,375,744 total cells. Markus' machine did this in just 15 hours ! >>> On mine it took much longer, but this is probably in large parts due to >>> a software raid 5 that makes disk io really slow. >> >> >> WoW! Great news! Lot of work behind the scenes I guess. Thanks a >> million... >> Let me know if and what I can test (besides my on-going work in which I do >> use >> i.segment). > > > Any feedback on your on-going work would already be helpful. Infos about > performance (speed, quality of segmentation, etc). Tests of hierarchical > segmentation with increasing thresholds. > > Moritz > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSOC Horizon based stratigraphy
Hi Ben,
You are right, these mass-preserving splines are for continuous data -
it seems I have been carried away from the original scope of the
project while writing my email :)
Cheers,
P
2013/6/27 Benjamin Ducke :
> On 06/26/2013 06:48 PM, Pierre Roudier wrote:
>>
>> Hi all,
>>
>>
>>> This is an excellent point. While I like the mention of AQP in this
>>> context,
>>> I totally support a GRASS-based implementation with as few dependencies
>>> as
>>> possible.
>>
>>
>> +1 - I think a native GRASS implementation would make a lot of sense.
>>
>>>> Yes, the thought of such "waffel voxels" is not exactly appealing.
>>>> However, they may be a smaller problem in practice, since the voxel
>>>> models themselves are often used to derive vertical slices
>>>> ("profiles"), and those might look perfectly fine, even if derived
>>>> from malformed voxels. GRASS does allow for individual X, Y and Z
>>>> dimensions of voxels, so there is no technical problem with this.
>>>> The results of the interpolation don't need to be beautiful, they
>>>> just need to be as accurate and as true to the data as possible.
>>>>
>>
>> That's the very nature of soils data - we soil scientists often deal
>> with pixels of 10 to 500m resolution, to observe processes that occur
>> generally in the first meter in the z axis! It is not a problem, and
>> the challenge is to come up with tools that allow us to store, query
>> and interpolate such data.
>>
>>> This is a popular topic in the soils literature-- vertical anisotropy can
>>> be
>>> an order of magnitude greater than what is found in the horizontal.
>>> Restricted cubic splines have some desirable characteristics for dealing
>>> with this kind of data-- however, these work best in the context of a
>>> regression model. Also, there are the mass-preserving splines that are
>>> more
>>> useful in the "interpolation along the soil profile" sense. For
>>> categorical
>>> data, I would recommend the ordinal-ratio logistic regression model,
>>> which
>>> generates class-wise probability estimates. I have found this quite
>>> useful
>>> for generating probability depth-functions for categorical soil
>>> properties.
>>> I can elaborate as needed.
>>
>>
>> The mass-preserving splines has become a key tool in the GlobalSoilMap
>> project. An implementation in R exists but is not very efficient. This
>> could be an opportunity to come up with a reference implementation! As
>> mentioned by Dylan, various interpolation methods are available,
>> restricted cubic splines look good as well.
>>
>
> But is that method suitable for categorized input data?
> Or does it only work for continuous soil properties?
> A spline-based interpolator from 3D vector to 3D raster
> already exists in GRASS (v.vol.rst).
>
> Best,
>
> Ben
>
>>
>> Cheers,
>>
>> P
>>
>
>
>
> --
> Dr. Benjamin Ducke, M.A.
> {*} Geospatial Consultant
> {*} GIS Developer
>
> bendu...@fastmail.fm
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Scientist
Landcare Research, New Zealand
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSOC Horizons and Stratigraphy
Hi Benjamin,
As far as soils data, we would probably often mask with depths min or
max, use a plan to cut the profile collection to return points ("give
the carbon value at 13.5cm depth for this collection of profiles").
Alternatively, we would try to interpolate a profile collection to
harmonise soil depths: while data is usually collected on
heterogeneous depths intervals, one might want to harmonise the
collection for quantitative analysis: for example the new depth
support might be {0-5cm, 5-10cm, 10-30 cm, 30-60cm, 60-100cm}.
Just 2 cents,
Pierre
2013/6/25 Benjamin Ducke :
> On 06/25/2013 10:00 AM, Tim Bailey wrote:
>>
>>
>>
>> Hi Ben,
>>
>> All that I meant by mask is, in this case, an r3 map that defines a
>> subset of space that subsequent operations are constrained to. I guess I
>> was just expressing worry about creating runaway data demands.The region
>> settings act as a three dimensional bounding cube, does not seem
>> adequate to constrain a tiling scheme with relatively sparse data.In the
>> compromise scenario that Dylan suggested with 10 meter xy and 1 cm z
>> resolution and 1 meter depth we would be looking at populating 1
>> voxels per hectare for a flat landscape. However if we were using a
>> simple bounding box to define the region and we had 5 meters of relief
>> we would end up with 5 or 6 voxels. As the area of coverage gets
>> bigger cost of the range in z values gets worse.
>>
>
> That's a good point that I hadn't thought about.
> Clearly, we don't want the interpolation to go
> beyond the limits of the terrain surface. It would
> probably be a good idea for the user to be able to
> supply an additional DEM input that could supply
> upper cut-off values. A lower cut-off could simply
> be defined as a constant depth value, and the same
> for the extents along the X-Y plane. Apart from that,
> the interpolator should use a configurable search
> radius for points, so that it won't start interpolating
> values in areas that have no sample data.
>
> Ben
>
>> Tim
>>
>>
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>
>
>
> --
> Dr. Benjamin Ducke, M.A.
> {*} Geospatial Consultant
> {*} GIS Developer
>
> bendu...@fastmail.fm
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Scientist
Landcare Research, New Zealand
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSOC Horizon based stratigraphy
Hi all,
> This is an excellent point. While I like the mention of AQP in this context,
> I totally support a GRASS-based implementation with as few dependencies as
> possible.
+1 - I think a native GRASS implementation would make a lot of sense.
>> Yes, the thought of such "waffel voxels" is not exactly appealing.
>> However, they may be a smaller problem in practice, since the voxel
>> models themselves are often used to derive vertical slices
>> ("profiles"), and those might look perfectly fine, even if derived
>> from malformed voxels. GRASS does allow for individual X, Y and Z
>> dimensions of voxels, so there is no technical problem with this.
>> The results of the interpolation don't need to be beautiful, they
>> just need to be as accurate and as true to the data as possible.
>>
That's the very nature of soils data - we soil scientists often deal
with pixels of 10 to 500m resolution, to observe processes that occur
generally in the first meter in the z axis! It is not a problem, and
the challenge is to come up with tools that allow us to store, query
and interpolate such data.
> This is a popular topic in the soils literature-- vertical anisotropy can be
> an order of magnitude greater than what is found in the horizontal.
> Restricted cubic splines have some desirable characteristics for dealing
> with this kind of data-- however, these work best in the context of a
> regression model. Also, there are the mass-preserving splines that are more
> useful in the "interpolation along the soil profile" sense. For categorical
> data, I would recommend the ordinal-ratio logistic regression model, which
> generates class-wise probability estimates. I have found this quite useful
> for generating probability depth-functions for categorical soil properties.
> I can elaborate as needed.
The mass-preserving splines has become a key tool in the GlobalSoilMap
project. An implementation in R exists but is not very efficient. This
could be an opportunity to come up with a reference implementation! As
mentioned by Dylan, various interpolation methods are available,
restricted cubic splines look good as well.
Cheers,
P
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSOC wk1 checkin
Hi Tim, Hamish et al., Just jumping in the discussion, FYI: I am following the project with much attention, in particular because I am working with soil data, both at the national scale in NZ, but also on international project that aim at storing important amounts of data [www.globalsoilmap.net]. The soil science community has recognised the difficulty to deal with the storage of soil horizon data, and a specific working group has been formed under the auspices of the International Union of Soil Sciences [www.soilinformationstandards.org/content/about]. We've already been developing data models for storing soil data, I'd be happy to point you towards these if that is of interest for your project. Tim, all the best for your summer project, Hamish, hang on tight for this cold winter blast! Talk soon, Pierre 2013/6/23 Hamish : > Hi Tim, glad to see you're underway. > > is it possible to post some data samples on your project's blog? (a > description + figure would be great) It would help to get a better idea of > what the import options would be for those three datasets. What form is the > Natural Resources Conservation Service survey data in? > If you like/need I can poke around here for some more datasets. > >> My work product next week is going to focus on the interpolation >> module. The abstract workflow for the module as whole is as follows >> >> Process for generation of r3 voxel grid from a population of xy >> located 1 dimensional horizon descriptions >> 1. Import of database horizon descriptions >> 2. Generation of line vector representing the path of the horizon >> description in xyz > > note that GRASS vector lines can not store per-vertex attribute data, > only per-line attribute data. Anything else must be stored as points; > see the v.in.gps module. one idea is to trick the vector engine into storing > depth vs. value1 [vs. value2] in x,y[,z] structure. then translate out the > results at the last step when you need real earth-coord x,y,z. > ? > >> 3. Segmentation of the line vector into n number xyz points > > so binning by depth segment? > >> 4. query of attribute values to points from attribute database >> 5. Generation of r3 region >> 6. Interpolation of point attribute values through geostatistical >> and/or logical operators onto voxel grid locations > > wrt to single x,y location well log, it seems to me like the r3.in.xyz > module already gives you most of that, bypassing the vector line stage > completely. binning 3D data into voxels using univariate statistics is > precisely what it does. > > are you looking to interpolate/aggregate vertically first, then > horizontally? would you interpolate at each depth band separately > then combine those together? > > how well does that work with dipping angles? perhaps v.vol.rst could help > too, to interpolate everything at once in a more 3D-influenced model? > >> One point that Ben articulated was that the interpolation assignment >> needs to be capable of operating on integer data so that it can work >> on > > that got cut off, but I guess you mean categorical value, so nearest > neighbour is needed, and not linear, cubic, or spline. > >> Best wishes on this first day of summer. > > Up to my knees in snow yesterday, but good mountain boots and funner than the > rain and sleet that was falling down in the valley. :) > > > regards, > Hamish > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] r.sun using EPSG:3031 projection gives strange results
Dear devs, I am working on Antarctica data, projected in Antarctic Polar Stereographic (EPSG:3031, [0,1]). This projection puts the South Pole in the "center" of the map. I have strange results in the Ross Sea Region using r.sun from GRASS 7 compiled from trunk (SVN checkout probably about less than one month ago): According to the r.sun results, the south facing slope receive more radiation than the north facing one, which doesn't add up. Is this a limitation of r.sun, a bug, or am I missing something here? Cheers, Pierre [0] http://spatialreference.org/ref/epsg/3031/ [1] http://nsidc.org/data/atlas/epsg_3031.html -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Backporting the start_rast option in r.walk
Hi, I am a happy user the start_rast option in r.walk in GRASS 7, Recently I realised that the option is not available on the stable version of GRASS (6.4.2) when a student here tried one of my scripts. Is there any plan to backport this, or should the student switch to GRASS 7? Cheers, Pierre -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] any example of direct use of pygrass through PyWPS?
Hi Luca, Yann and the list, That sounds very interesting - could it be possible to post code snippets somewhere on the wiki to get newbies like me going? Just a suggestion, Pierre 2013/5/15 Luca Delucchi : > On 15 May 2013 10:38, Yann Chemin wrote: >> Hi list, >> > > Hi Yann > >> PyWPS is Python based, GRASS returns directly GetCapability >> descriptions, is there an example of direct GRASS connection to PyWPS? >> >> Better. Is there anybody using pyGRASS directly in the PyWPS setup? >> > > I used pygrass with zoo-project to test it, it works well... > >> Cheers, >> Yann >> > > -- > ciao > Luca > > http://gis.cri.fmach.it/delucchi/ > www.lucadelu.org > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] i.segment at Community Sprint
Absolutely Markus. Let's also keep in mind that comparing segmentation results is a very tricky exercise. There's no such thing as a perfect segmentation result IMHO. Pierre 2013/2/12 Markus Metz : > On Mon, Feb 11, 2013 at 8:18 PM, Pierre Roudier > wrote: >> Thanks Markus and Eric, >> >> I have similar feedback when testing on various SPOT5 scenes. XL results are >> not entirely identical of course, but reasonably similar, so I support >> Markus' decision. > > I can make the results more similar, but one reason why results are > different between i.segment and i.segment.xl is that I had the > impression that i.segment is doing over-segmentation, i.e. merging too > liberally with the effect that some segments (objects), in particular > large segments, were more heterogeneous than justified by the given > merging threshold. With i.segment.xl, I tried to get results that are > very similar to the eCognition results. > > Markus M > >> >> Cheers, >> >> Pierre >> >> On Feb 11, 2013 10:53 PM, "Markus Metz" >> wrote: >>> >>> Hi all, >>> >>> I have tested again i.segment and discovered that for the NC Landsat >>> 2000 imagery the module takes nearly 7 hours for reasonable >>> segmentation. The i.segment.xl module does the same in 10 seconds. The >>> region consists of 250 000 cells, not so much. In the documentation it >>> says that processing the entire ortho image takes about a day. With >>> the xl version it takes about 10 minutes. I am going to move the xl >>> version to trunk and keep the original GSoC version in addons for >>> reference. >>> >>> Markus M >>> >>> >>> On Fri, Feb 8, 2013 at 5:47 AM, Eric Momsen wrote: >>> > Sorry for not responding right away, I hadn't realized the code sprint >>> > started (finished?!) already. There is a paper deadline this month and >>> > a >>> > thesis to write that has consumed my attention... I don't think I'll >>> > have >>> > time for anything in February. If noone else wants/needs to do it >>> > sooner, I >>> > hope to have a break between my thesis writing and starting work this >>> > summer. So in April(???) I will find some time to dedicate to GRASS >>> > code >>> > and/or documents again. >>> > >>> > -Eric >>> > >>> > >>> > On Mon, Feb 4, 2013 at 3:01 AM, Moritz Lennert >>> > wrote: >>> >> >>> >> On 02/02/13 17:37, Markus Metz wrote: >>> >>> >>> >>> On Sat, Feb 2, 2013 at 12:56 PM, Moritz Lennert >>> >>> wrote: >>> >>>> >>> >>>> Markus and Yann, >>> >>>> >>> >>>> If you have the time it might be a great opportunity to use the >>> >>>> community >>> >>>> sprint to get i.segment from the addons to trunk. What do you think ? >>> >>> >>> >>> >>> >>> I would prefer i.segment.xl for speed reasons and memory control, but >>> >>> the shape functionality in i.segment would need to be ported to >>> >>> i.segment.xl first. >>> >> >>> >> >>> >> I meant i.segment in a global sens, not distinguishing .xl, so that's >>> >> perfectly fine with me. >>> >> >>> >> Eric, any chance for you to look at integrating your work on shapes >>> >> into >>> >> i.segment.xl ? >>> >> >>> >> Moritz >>> > >>> > >>> ___ >>> grass-dev mailing list >>> grass-dev@lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/grass-dev -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] i.segment at Community Sprint
Thanks Markus and Eric, I have similar feedback when testing on various SPOT5 scenes. XL results are not entirely identical of course, but reasonably similar, so I support Markus' decision. Cheers, Pierre On Feb 11, 2013 10:53 PM, "Markus Metz" wrote: > Hi all, > > I have tested again i.segment and discovered that for the NC Landsat > 2000 imagery the module takes nearly 7 hours for reasonable > segmentation. The i.segment.xl module does the same in 10 seconds. The > region consists of 250 000 cells, not so much. In the documentation it > says that processing the entire ortho image takes about a day. With > the xl version it takes about 10 minutes. I am going to move the xl > version to trunk and keep the original GSoC version in addons for > reference. > > Markus M > > > On Fri, Feb 8, 2013 at 5:47 AM, Eric Momsen wrote: > > Sorry for not responding right away, I hadn't realized the code sprint > > started (finished?!) already. There is a paper deadline this month and a > > thesis to write that has consumed my attention... I don't think I'll > have > > time for anything in February. If noone else wants/needs to do it > sooner, I > > hope to have a break between my thesis writing and starting work this > > summer. So in April(???) I will find some time to dedicate to GRASS code > > and/or documents again. > > > > -Eric > > > > > > On Mon, Feb 4, 2013 at 3:01 AM, Moritz Lennert > > wrote: > >> > >> On 02/02/13 17:37, Markus Metz wrote: > >>> > >>> On Sat, Feb 2, 2013 at 12:56 PM, Moritz Lennert > >>> wrote: > > Markus and Yann, > > If you have the time it might be a great opportunity to use the > community > sprint to get i.segment from the addons to trunk. What do you think ? > >>> > >>> > >>> I would prefer i.segment.xl for speed reasons and memory control, but > >>> the shape functionality in i.segment would need to be ported to > >>> i.segment.xl first. > >> > >> > >> I meant i.segment in a global sens, not distinguishing .xl, so that's > >> perfectly fine with me. > >> > >> Eric, any chance for you to look at integrating your work on shapes into > >> i.segment.xl ? > >> > >> Moritz > > > > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.gui fails
Hi Anna, Weird - I can launch parallel g.gui instances without any problem in (X)Ubuntu 12.04.1, with grass70 compiled against the latest trunk. Cheers, Pierre 2013/2/11 Anna Kratochvílová : > Hi, > > I've upgraded today from ubuntu 10.04 to 12.04 and now I have problems > to start wxGUI. Launching grass is OK, the GUI appears but when I want > to open a new one with g.gui, it refuses to open because it is not > able to import wxversion and wx (in globalvar.py). When I launch > python in command line, I can import both wxversion and wx without > problems. Launching gui directly - python gui/wxpython/wxgui.py& - > works (using python 2.7). Is there something special about the g.gui > command? Any ideas where could be the problem? > > Thanks, > Anna > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] SVM classifier and MeanShift
Mohammed, For segmentation please get in touch with Eric Momsen who worked on i.segment recently, with great success. We were looking forward to add the mean shift option. Keep also Markus Metz in the loop - he was the mentor of the project and worked on i.segment.xl. Also, make sure you check out the orfeo toolbox library, they have several implementations of segmentation methods. SVM classification would also be useful. Not sure if anybody worked on it. Best, Pierre On Dec 24, 2012 4:57 PM, "Mohammed Rashad" wrote: > Hi All, > > I am planning to add SVM classifier to grass based on libsvm. I had a > basic version of it in my private repo. I am also planning to do meanshift > segmentation module. > > Is there anyone working on such things currently?. Any users interested? > > -- > Regards, >Rashad > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxGUI: supervised classification tool
Hi Markus et al., Just to throw my two cents, it would be great if we could generalise this UI to any classification workflow, including unsupervised. I could also see this UI as a nice way to integrate r.fuzzy.* maybe? Also, the excellent work on Markus M and Eric Momsen on i.segment could also be integrated alongside the older i.smap. Neat stuff, Pierre 2012/12/20 Markus Neteler : > Hi, > > while searching for the new i.class tool I have discovered > the "supervised classification tool" > in Imagery -> Classify Image -> Interactive input for supervised > classification > > Nice! /edit: I now see that it *is* the > http://grasswiki.osgeo.org/wiki/WxIClass > > I tried it with NC data and loaded the Landsat2002 group. > Now I would expect that I can select channels for display from > the group. Perhaps something with [x] checkboxes would be > good. The existing "free" choice of maps should remain of course. > > When I then digitize, it nicely opens the class dialog, ok. Then, > when running, it segfaults (entire wxGUI disappears, no error msg > visible). > > Suggestion: It may also become the tool for i.smap, just a method > dialog would be needed > >> Run Analysis > - MaxLik: i.maxlik > - SMAP: i.gensigset, i.smap > > to make it universal. However, great to have such a tool now. > > Markus > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Extracting coordinates of RasterNumpy objects (pygrass)
Sorry Pietro - more questions as I'm working my way through this new tool!
- As a follow-up from my last question, I am trying to convert the
pixels I have identified in my raster to a vector layer. While I
manage to create a Point() from scratch, I can't find out how I could
append coordinates to add more points to it. Using the previous
example:
>>> from grass import pygrass
>>> from pygrass.raster import RasterNumpy
>>> from pygrass.region import Region
>>> from pygrass.functions import pixel2coor
>>> elev = RasterNumpy("elevation")
>>> elev.open()
>>> a = elev > 144
>>> reg = Region()
>>> xcoords, ycoords = a.nonzero()
>>> # Switch to geographic space
>>> coords = [pixel2coor(pixel, reg) for pixel in zip(list(xcoords),
>>> list(ycoords))]
>>> # Add attribute column
>>> xyz = np.column_stack((np.asarray(coords), z))
>>> from pygrass.vector import *
>>> p = pygrass.vector.geometry.Point() # Works
>>> p = pygrass.vector.geometry.Point(x = xyz[:,0], y = xyz[:,1], z=xyz[:,2]) #
>>> Fails
- Is there a method to create a set of points (class Point) and write
it into the GRASS database?
- I would like to use this {x,y,z} set of points in v.surf.bspline. I
don't suppose I got another choice but write my numpy array into the
GRASS database first right?
Thanks again for your work,
Pierre
2012/12/18 Pierre Roudier :
> Thanks Pietro and Soeren,
>
> That's really great!
>
>
> I am looking forward to use this with v.surf.bspline to do on the fly
> interpolation (interpolation with SciPy is quite slow and memory
> hungry). I am coding an iterative process that calls the interpolation
> routine a lot of times (~10 to 40 interpolation steps), so I would
> like to make the most of GRASS interpolation power.
>
> Cheers,
>
> Pierre
>
> 2012/12/18 Pietro :
>> Hi Pierre,
>>
>> On Mon, Dec 17, 2012 at 9:44 PM, Pierre Roudier
>> wrote:
>>> Thanks Pietro,
>>>
>>> Yes that answers the question, but just partly: I was actually
>>> wondering whether it would be possible to get the extracted x and y
>>> coordinates in geographic space (as opposed to the Numpy array space)?
>>
>> aah sorry, I forgot to say that you can use pixel2coord... see the
>> example below:
>>
>>>>> from grass import pygrass
>>>>> from pygrass.raster import RasterNumpy
>>>>> from pygrass.region import Region
>>>>> from pygrass.functions import pixel2coor
>>>>> elev = RasterNumpy("elevation")
>>>>> elev.open()
>>>>> a = elev > 144
>>>>> reg = Region()
>>>>> xcoords, ycoords = a.nonzero()
>>>>> for pixel in zip(list(xcoords), list(ycoords))[:5]:
>> ... print pixel
>> ...
>> (0, 6)
>> (0, 7)
>> (0, 8)
>> (0, 9)
>> (0, 10)
>>>>> for pixel in zip(list(xcoords), list(ycoords))[:5]:
>> ...print pixel2coor(pixel, reg)
>> ...
>> (228440.0, 63.0)
>> (228430.0, 63.0)
>> (228420.0, 63.0)
>> (228410.0, 63.0)
>> (228400.0, 63.0)
>>
>> Best regards
>>
>> Pietro
>
>
>
> --
> Scientist
> Landcare Research, New Zealand
--
Scientist
Landcare Research, New Zealand
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Extracting coordinates of RasterNumpy objects (pygrass)
Thanks Pietro and Soeren,
That's really great!
I am looking forward to use this with v.surf.bspline to do on the fly
interpolation (interpolation with SciPy is quite slow and memory
hungry). I am coding an iterative process that calls the interpolation
routine a lot of times (~10 to 40 interpolation steps), so I would
like to make the most of GRASS interpolation power.
Cheers,
Pierre
2012/12/18 Pietro :
> Hi Pierre,
>
> On Mon, Dec 17, 2012 at 9:44 PM, Pierre Roudier
> wrote:
>> Thanks Pietro,
>>
>> Yes that answers the question, but just partly: I was actually
>> wondering whether it would be possible to get the extracted x and y
>> coordinates in geographic space (as opposed to the Numpy array space)?
>
> aah sorry, I forgot to say that you can use pixel2coord... see the
> example below:
>
>>>> from grass import pygrass
>>>> from pygrass.raster import RasterNumpy
>>>> from pygrass.region import Region
>>>> from pygrass.functions import pixel2coor
>>>> elev = RasterNumpy("elevation")
>>>> elev.open()
>>>> a = elev > 144
>>>> reg = Region()
>>>> xcoords, ycoords = a.nonzero()
>>>> for pixel in zip(list(xcoords), list(ycoords))[:5]:
> ... print pixel
> ...
> (0, 6)
> (0, 7)
> (0, 8)
> (0, 9)
> (0, 10)
>>>> for pixel in zip(list(xcoords), list(ycoords))[:5]:
> ...print pixel2coor(pixel, reg)
> ...
> (228440.0, 63.0)
> (228430.0, 63.0)
> (228420.0, 63.0)
> (228410.0, 63.0)
> (228400.0, 63.0)
>
> Best regards
>
> Pietro
--
Scientist
Landcare Research, New Zealand
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Extracting coordinates of RasterNumpy objects (pygrass)
Thanks Pietro, Yes that answers the question, but just partly: I was actually wondering whether it would be possible to get the extracted x and y coordinates in geographic space (as opposed to the Numpy array space)? Thanks again for the great work on pygrass, P 2012/12/17 Pietro : > Hi Pierre, > > On Mon, Dec 17, 2012 at 7:48 AM, Pierre Roudier > wrote: >> Hi, >> >> I am using (with enthusiasm!) Pietro's pygrass library to develop a raster >> module. I am using Numpy/Scipy as my working horse, so I manipulate a lot of >> the RasterNumpy objects that have been introduced with pygrass. > > I'm really happy that you are using the pygrass library! ;-) > > >> In a specific step, I am identifying pixels using a test (this would be >> similar to my_array < 100). I would like to extract the points that satisfy >> the test, and access not only their values and index in the array, but I >> would also go back to their coordinates to extract them as (x, y, z). >> >> Is there a way to do this using RasterNumpy and pygrass? > > yes, you should use the numpy stuff, something like: > >>>> import numpy as np >>>> a = np.arange(15).reshape(3, 5) >>>> a > array([[ 0, 1, 2, 3, 4], >[ 5, 6, 7, 8, 9], >[10, 11, 12, 13, 14]]) >>>> b = a>7 >>>> b1 > array([[False, False, False, False, False], >[False, False, False, True, True], >[ True, True, True, True, True]], dtype=bool) >>>> b.nonzero() # return two array with x and y and z if the array is 3D > (array([1, 1, 2, 2, 2, 2, 2]), array([3, 4, 0, 1, 2, 3, 4])) > > Please let me know if you find something that is not clear, or is not > working properly... > > All the best! > > Pietro -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Extracting coordinates of RasterNumpy objects (pygrass)
Hi, I am using (with enthusiasm!) Pietro's pygrass library to develop a raster module. I am using Numpy/Scipy as my working horse, so I manipulate a lot of the RasterNumpy objects that have been introduced with pygrass. In a specific step, I am identifying pixels using a test (this would be similar to my_array < 100). I would like to extract the points that satisfy the test, and access not only their values and index in the array, but I would also go back to their coordinates to extract them as (x, y, z). Is there a way to do this using RasterNumpy and pygrass? Cheers, Pierre ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Implementing MrVBF in GRASS
Greetings, devs, A popular covariate in the digital soil mapping community is the multiresolution valley bottom flatness (MrVBF) index, proposed by John Gallnd in 2003 [0]. While an open-source implementation is available in SAGA-GIS [1], I would like to be able to produce this in my favourite GIS environment. As I was getting started using pygrass, I realised that Python may be a bit slow for that sort of operations. Did anyone heard about an implementation (even partial) in C? Cheers, Pierre [0] http://www.agu.org/pubs/crossref/2003/2002WR001426.shtml [1] http://read.pudn.com/downloads84/sourcecode/app/321905/saga_2/src/modules_terrain_analysis/terrain_analysis/ta_morphometry/mrvbf.cpp__.htm -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Passing several floating values to one single option
Thanks all for the trick, > Added to > http://grass.osgeo.org/wiki/GRASS_Python_Scripting_Library#Parsing_the_options_and_flags Perfect place for it I reckon, Pierre -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Passing several floating values to one single option
Hi all, This might be very simple, but I can't find an answer in the doco - so here I am, I'm trying to pass several floats to a single option in a Python script: > python my.module.py input=input output=output myoption=0.1,0.2,0.5 Is there a clever way to declare myoption so that it would parse it as some 3 floats? Or do I need to define it as a string and parse it manually? Cheers, Pierre -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Please update "Compile on Ubuntu" page in Wiki
Hi Markus, Here is my configure script for grass_trunk on (X)ubuntu 12.04: ./configure --enable-64bit--with-libs=/usr/lib64 \ --with-cxx \ --with-readline \ --with-freetype=yes --with-freetype-includes="/usr/include/freetype2/" \ --enable-largefile=yes \ --with-proj-share=/usr/share/proj/ \ --with-geos=/usr/bin/geos-config \ --with-cairo \ --with-tcltk-includes="/usr/include/tcl8.5/" \ --with-wxwidgets \ --with-postgres=yes --with-postgres-includes=/usr/include/postgresql \ --with-sqlite=yes --with-sqlite-includes=/usr/include --with-sqlite-libs=/usr/lib \ --with-blas=yes --with-blas-includes=/usr/include/ --with-blas-libs=/usr/lib/ \ --with-mysql=yes --with-mysql-includes=/usr/include/mysql --with-mysql-libs=/usr/lib \ --with-odbc=yes \ --with-liblas=no \ --with-pthread \ --with-openmp \ --with-lapack \ --enable-w11 Note that I have to use this trick: http://osgeo-org.1560.n6.nabble.com/Problem-compiling-ximgview-in-the-latest-grass-trunk-tp4987855p4988331.html because of this bug: http://trac.osgeo.org/grass/ticket/1713 . Hope this helps, Pierre 2012/9/4 Vaclav Petras : > Hi, > > as I remember the pacakage list was ok when I was compiling grass 6 > and 7 on Ubuntu 12.04. I only added numpy but now it seems that > python-imaging package for PIL is missing too (probably needed only > for preview in Cartographic Composer). > > But I'm using different configure command parameters. I was always > afraid to change the command on the wiki because I don't understand it > completely. > > Anyway here is my "script_configure.sh" which I used for grass 6.4 on > Ubuntu 12.04: > > export CFLAGS="-ggdb -Wall -Werror-implicit-function-declaration" > export CXXFLAGS="-g -Wall" > ./configure --prefix=/usr/local \ > --with-postgres --with-postgres-includes=/usr/include/postgresql \ > --with-mysql --with-mysql-includes=/usr/include/mysql/ \ > --with-gdal \ > --with-proj \ > --with-proj-share=/usr/share/proj \ > --with-motif \ > --with-nls \ > --with-readline \ > --with-cxx \ > --x-includes=/usr/include/ \ > --x-libraries=/usr/lib/ \ > --with-freetype --with-freetype-includes=/usr/include/freetype2 \ > --with-sqlite \ > --with-odbc \ > --with-wxwidgets \ > --with-tcltk-includes=/usr/include/tcl/ --with-tcltk-libs=/usr/lib/ \ > --with-geos \ > --with-pthread \ > --enable-largefile \ > --with-python=/usr/bin/python2.7-config \ > --with-ffmpeg \ > --with-ffmpeg-includes="/usr/include/libavcodec > /usr/include/libavformat /usr/include/libswscale" \ > --with-cairo > > Only difference for 10.04 is that I don't have to specify X libs > paths, python is 2.6 and some thing with ffmpeg paths I guess. > > I'm using UbuntuGIS unstable but I'm not sure if this makes a difference. > > Sorry for being not so helpful. > > Vaclav > > > On 3 September 2012 20:04, Markus Neteler wrote: >> Hi, >> >> greetings from the GeoSTAT 2012 with many GRASS interested people. >> Since the official GRASS Ubuntu package is too old, some of them >> want to recompile. But also this page seesm to be wrong/outdated: >> >> http://grass.osgeo.org/wiki/Compile_and_Install_Ubuntu >> >> Can any Ubuntu-savvy person please update it (ehm, urgently, thanks, >> the course is tomorrow...). >> >> thanks >> Markus >> ___ >> grass-dev mailing list >> grass-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-dev > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Problem compiling ximgview in the latest grass_trunk
Ticket created here: http://trac.osgeo.org/grass/ticket/1713 Thanks, P 2012/8/31 Glynn Clements : > > Pierre Roudier wrote: > >> I still got the same problem - I'm happy to use the workaround and >> edit the Platform.make file by hand, but should I lodge a bug report >> in the tracker? > > Please do. > > Even though ximgview is redundant (the same functionality is available > via both wximgview and wximgview.py), we need raw access to Xlib for > reasons related to NVIZ. > > -- > Glynn Clements -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Problem compiling ximgview in the latest grass_trunk
Hi Glynn et al., I still got the same problem - I'm happy to use the workaround and edit the Platform.make file by hand, but should I lodge a bug report in the tracker? Cheers, Pierre 2012/7/14 Pierre Roudier : > Thanks heaps for your help Glynn, it worked. > > For reference, here's the workaround I used: > roudierp@mangatainoka:/usr/local/src/grass_trunk$ more > include/Make/Platform.make | grep -n XLIB > 86:XLIBPATH= -L/usr/bin > > Cheers, > > Pierre > > 2012/7/14 Glynn Clements : >> >> Pierre Roudier wrote: >> >>> Is there an easy work-around this? >> >> Provided that the configure script completes, you can edit >> include/Make/Platform.make by hand. The relevant variables are >> XLIBPATH and XLIB. >> >> -- >> Glynn Clements > > > > -- > Scientist > Landcare Research, New Zealand -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Problem compiling ximgview in the latest grass_trunk
Thanks heaps for your help Glynn, it worked. For reference, here's the workaround I used: roudierp@mangatainoka:/usr/local/src/grass_trunk$ more include/Make/Platform.make | grep -n XLIB 86:XLIBPATH= -L/usr/bin Cheers, Pierre 2012/7/14 Glynn Clements : > > Pierre Roudier wrote: > >> Is there an easy work-around this? > > Provided that the configure script completes, you can edit > include/Make/Platform.make by hand. The relevant variables are > XLIBPATH and XLIB. > > -- > Glynn Clements -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Problem compiling ximgview in the latest grass_trunk
Sorry, my bad: roudierp@mangatainoka:~/.config/Terminal$ apt-file find xmkmf xmanpages-ja: /usr/share/man/ja/man1/xmkmf.1.gz xutils-dev: /usr/bin/xmkmf xutils-dev: /usr/share/man/man1/xmkmf.1.gz So on ubuntu, xmkmf and imake are available through the xutils-dev package. However, I still run into the same error at compilation, P 2012/7/13 Pierre Roudier : > Glynn, > > Is there an easy work-around this? It's a bit weird as the compilation > goes well on my older machine. It seems to fail only on this newer > configuration. After a bit of googling, I *think* that the xutils-dev > package, which provides imake, does not provide the xmkmf script > anymore. > > I don't think I'm making any use of the ximgview module at the moment, > so I'm happy to try and drop it from my final install. I do need > grass7 to compile for testing Eric Momsen's GSoC project. > > Any help greatly appreciated, > > Cheers, > > P > > 2012/7/13 Glynn Clements : >> >> Pierre Roudier wrote: >> >>> : && gcc -L/usr/local/src/grass_trunk/dist.x86_64-unknown-linux-gnu/lib >>> -L/usr/local/src/grass_trunk/dist.x86_64-unknown-linux-gnu/lib >>> -Wl,--export-dynamic >>> -Wl,-rpath-link,/usr/local/src/grass_trunk/dist.x86_64-unknown-linux-gnu/lib >>> -o /usr/local/src/grass_trunk/dist.x86_64-unknown-linux-gnu/bin/ximgview >>> OBJ.x86_64-unknown-linux-gnu/color.o >>> OBJ.x86_64-unknown-linux-gnu/main.o-lgrass_gis.7.0.svn -L -lX11 >> ^^ >> >> The problem is the bare -L switch, which causes -lX11 to be treated as >> an argument to -L rather than a separate switch. >> >> Unfortunately, the AC_PATH_XTRA test which sets X_LIBS is part of >> autoconf, and not something which can easily be worked around. >> >> First it tries using imake (xmkmf), which may not exist on modern >> systems. If that fails, it tries a fixed set of plausible library >> directories, all of which use "lib" rather than e.g. "lib64", as the >> latter wasn't in common use when autoconf-2.13 was released (Jan >> 1999). >> >> It may be time to think about moving to a newer version of autoconf. >> It's much more stable now than it was in the period immediatley after >> 2.13. >> >> -- >> Glynn Clements > > > > -- > Scientist > Landcare Research, New Zealand -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Problem compiling ximgview in the latest grass_trunk
Glynn, Is there an easy work-around this? It's a bit weird as the compilation goes well on my older machine. It seems to fail only on this newer configuration. After a bit of googling, I *think* that the xutils-dev package, which provides imake, does not provide the xmkmf script anymore. I don't think I'm making any use of the ximgview module at the moment, so I'm happy to try and drop it from my final install. I do need grass7 to compile for testing Eric Momsen's GSoC project. Any help greatly appreciated, Cheers, P 2012/7/13 Glynn Clements : > > Pierre Roudier wrote: > >> : && gcc -L/usr/local/src/grass_trunk/dist.x86_64-unknown-linux-gnu/lib >> -L/usr/local/src/grass_trunk/dist.x86_64-unknown-linux-gnu/lib >> -Wl,--export-dynamic >> -Wl,-rpath-link,/usr/local/src/grass_trunk/dist.x86_64-unknown-linux-gnu/lib >> -o /usr/local/src/grass_trunk/dist.x86_64-unknown-linux-gnu/bin/ximgview >> OBJ.x86_64-unknown-linux-gnu/color.o >> OBJ.x86_64-unknown-linux-gnu/main.o-lgrass_gis.7.0.svn -L -lX11 > ^^ > > The problem is the bare -L switch, which causes -lX11 to be treated as > an argument to -L rather than a separate switch. > > Unfortunately, the AC_PATH_XTRA test which sets X_LIBS is part of > autoconf, and not something which can easily be worked around. > > First it tries using imake (xmkmf), which may not exist on modern > systems. If that fails, it tries a fixed set of plausible library > directories, all of which use "lib" rather than e.g. "lib64", as the > latter wasn't in common use when autoconf-2.13 was released (Jan > 1999). > > It may be time to think about moving to a newer version of autoconf. > It's much more stable now than it was in the period immediatley after > 2.13. > > -- > Glynn Clements -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Problem compiling ximgview in the latest grass_trunk
Thanks for your help Markus and Glynn, I do have libx11-dev installed (I'm running Xubuntu 12.04), but still get the same error unfortunately, Pierre 2012/7/12 Markus Neteler : > On Thu, Jul 12, 2012 at 9:02 AM, Pierre Roudier > wrote: >> Hi, >> >> I must be missing something because I can't compile grass7.svn on a >> new config. The compilation error is located in >> grass_trunk/visualization/ximgview (see below). > ... >> roudierp@mangatainoka:/usr/local/src/grass_trunk/visualization/ximgview$ make > ... >> OBJ.x86_64-unknown-linux-gnu/main.o: In function `draw': >> /usr/local/src/grass_trunk/visualization/ximgview/main.c:121: >> undefined reference to `XPutImage' > > You are likely missing the package "libX11-devel". > > Hope this helps, > Markus -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Problem compiling ximgview in the latest grass_trunk
Hi, I must be missing something because I can't compile grass7.svn on a new config. The compilation error is located in grass_trunk/visualization/ximgview (see below). Any pointer would be greatly appreciated, Cheers, Pierre roudierp@mangatainoka:/usr/local/src/grass_trunk/visualization/ximgview$ make : && gcc -L/usr/local/src/grass_trunk/dist.x86_64-unknown-linux-gnu/lib -L/usr/local/src/grass_trunk/dist.x86_64-unknown-linux-gnu/lib -Wl,--export-dynamic -Wl,-rpath-link,/usr/local/src/grass_trunk/dist.x86_64-unknown-linux-gnu/lib -o /usr/local/src/grass_trunk/dist.x86_64-unknown-linux-gnu/bin/ximgview OBJ.x86_64-unknown-linux-gnu/color.o OBJ.x86_64-unknown-linux-gnu/main.o-lgrass_gis.7.0.svn -L -lX11 -lm OBJ.x86_64-unknown-linux-gnu/main.o: In function `draw': /usr/local/src/grass_trunk/visualization/ximgview/main.c:121: undefined reference to `XPutImage' OBJ.x86_64-unknown-linux-gnu/main.o: In function `main_loop': /usr/local/src/grass_trunk/visualization/ximgview/main.c:156: undefined reference to `XPending' /usr/local/src/grass_trunk/visualization/ximgview/main.c:156: undefined reference to `XPending' /usr/local/src/grass_trunk/visualization/ximgview/main.c:159: undefined reference to `XNextEvent' OBJ.x86_64-unknown-linux-gnu/main.o: In function `draw': /usr/local/src/grass_trunk/visualization/ximgview/main.c:122: undefined reference to `XSync' OBJ.x86_64-unknown-linux-gnu/main.o: In function `create_window': /usr/local/src/grass_trunk/visualization/ximgview/main.c:62: undefined reference to `XOpenDisplay' /usr/local/src/grass_trunk/visualization/ximgview/main.c:72: undefined reference to `XCreateWindow' /usr/local/src/grass_trunk/visualization/ximgview/main.c:81: undefined reference to `XMapWindow' /usr/local/src/grass_trunk/visualization/ximgview/main.c:83: undefined reference to `XGetWindowAttributes' /usr/local/src/grass_trunk/visualization/ximgview/main.c:88: undefined reference to `XSetWindowColormap' /usr/local/src/grass_trunk/visualization/ximgview/main.c:90: undefined reference to `XCreateGC' /usr/local/src/grass_trunk/visualization/ximgview/main.c:93: undefined reference to `XCreateImage' /usr/local/src/grass_trunk/visualization/ximgview/main.c:99: undefined reference to `XFlush' OBJ.x86_64-unknown-linux-gnu/color.o: In function `try_get_grays': /usr/local/src/grass_trunk/visualization/ximgview/color.c:191: undefined reference to `XAllocColor' /usr/local/src/grass_trunk/visualization/ximgview/color.c:192: undefined reference to `XFreeColors' OBJ.x86_64-unknown-linux-gnu/color.o: In function `try_get_colors': /usr/local/src/grass_trunk/visualization/ximgview/color.c:159: undefined reference to `XAllocColor' /usr/local/src/grass_trunk/visualization/ximgview/color.c:160: undefined reference to `XFreeColors' OBJ.x86_64-unknown-linux-gnu/color.o: In function `InitColorTableFixed': /usr/local/src/grass_trunk/visualization/ximgview/color.c:273: undefined reference to `XFreeColormap' OBJ.x86_64-unknown-linux-gnu/color.o: In function `ramp_colormap': /usr/local/src/grass_trunk/visualization/ximgview/color.c:205: undefined reference to `XCreateColormap' /usr/local/src/grass_trunk/visualization/ximgview/color.c:220: undefined reference to `XStoreColor' collect2: ld returned 1 exit status make: *** [/usr/local/src/grass_trunk/dist.x86_64-unknown-linux-gnu/bin/ximgview] Error 1 -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Newbie question
Hi Owen, This page [0] is a good entry point, Pierre [0]: http://grass.osgeo.org/wiki/Development 2012/5/15 Owen Brown : > All, I am a “benched” developer at an IT contracting company looking to help > out on an open-source project. I primarily work with Java but understand C > pretty well. Would any of you have any suggestions on how I could contribute > to this project? > > > > > > Owen Brown > > Developer > > Catalyst IT Services > > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Introduction and GSoC
Hi, As a user, I would also find the integration of say OTB in GRASS being a plus - a very general segmentation algorithm like the watershed is provided by OTB and is a handy tool at times. OTB being based on VTK, maybe you could make use of some of Soeren's work on the vtk-grass-bridge? Pierre On Apr 4, 2012 4:47 PM, "Eric Momsen" wrote: > On Tue, Apr 3, 2012 at 9:57 AM, Moritz Lennert > wrote: > > I personally am a bit weary of increasing dependencies between packages, > but > > at the same time, why re-invent the wheel. Integrating the OTB algorithms > > into GRASS would definitely be a great plus. > > > > This said, several FOSS4G programs out there already play the role of > > integrators (e.g. QGIS, gvSIG) and I'm not sure that GRASS should try to > go > > the same direction. Generally, I'd say: let GRASS do really well what it > > does, and not try to integrate everything. > > > > This does sound critical to me. Being "new" to GIS, I have been > struggling to figure out what the differences (strength/weakness/etc) > are between GRASS, QGIS, etc. I started with GRASS and R and haven't > had time to try out the other programs, so am only comparing based on > what each website describes. I haven't found any feature comparison > table. So I am interested to hear what everyone has to say about what > packages should (or should not) be integrated into GRASS vs. what > packages GRASS is integrated into...but I suspect it is a bigger issue > than can be answered in a GSoC project. :) > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass geostatistics
Hi Rashad, I'd be interested to hear about HPGL. As Thomas mentioned, kriging is currently available through R using the gstat package - and has thus the some limitations in terms of efficiency, and also on the size of the data to be processed. Note that from 6.4, a python module is available for kriging (see v.krige.py). It is in the trunk for 7.0. Cheers, Pierre 2011/8/6 Mohammed Rashad : > Hi devs, > Does GRASS have any geostatistical tools. HPGL is ahigh performace library > for geostatistics > Simple Kriging (SK) > Ordinary Kriging (OK) > Indicator Kriging (IK) > Local Varying Mean Kriging (LVM Kriging) > Simple CoKriging (Markov Models 1 & 2) > Sequential Indicator Simulation (SIS) > Correlogram Local Varying Mean SIS (CLVM SIS) > Local Varying Mean SIS (LVM SIS) > Sequential Gaussian Simulation (SGS) > > are available in HPGL so let me know the comments and suggeation before > integrating HPGL to GRASS GIS > -- > Thanks && Regards > Rashad > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Segmentation fault using v.in.lidar
Doug, Markus, Thanks for the interesting discussion, > In the short term, use the las2las command from liblas.org to merge your > .las files into a single las file and then process the one file. > Yes at the moment, my workflow is: ls ID_*.las > las_list.txt lasmerge -i las_list.txt -o out.las v.in.lidar in=out.las out=lidar -trb Works very well. I was just wondering how difficult it would be to use wildcards directly in the input=... option. Obviously it requires some significant amount of work. > You will have to watch out for the 4 billion point limit that is currently in > the LAS file format, but for most folks that's not an issue. > Indeed, not an issue for me (unfortunately!), > In all GRASS versions, the limit with topology is at 2^31 - > 1 (about 2 billion) features. I usually never build the topology of my LiDAR point clouds. Should I do it? Cheers, Pierre > Pierre Roudier > Sent by: grass-dev-boun...@lists.osgeo.org > > 07/13/2011 03:05 AM > > To > Markus Metz > cc > grass-dev > Subject > Re: [GRASS-dev] Segmentation fault using v.in.lidar > > > > > Thanks for the quick answer Markus, > > That would be a nice feature to add though. A lot of the LAS files are > coming "tiled", and it'd be nice to be able to do something like: > > v.in.lidar in=*.las out=test_input_lidar -trb > > or > > v.in.lidar in=zone_32_*.las out=test_input_lidar -trb > > to import a special subset of LAS files. > > I've very few coding abilities, so this is just meant as another line > on the wishlist ;) > > Thanks heaps for your work on *.in.lidar, it is working well otherwise, > > Pierre > > 2011/7/13 Markus Metz : > > On Wed, Jul 13, 2011 at 2:08 AM, Pierre Roudier > > wrote: > >> Hi, > >> > >> I've been trying to use v.in.lidar. It yields good results on one LAS > >> file, but I get a segfault when trying it on several files: > >> > >>> v.in.lidar in=BD32_1610.las,BD32_1611.las out=test_input_lidar -trb > >> Segmentation fault > >>> v.in.lidar in=BD32_161*.las out=test_input_lidar -trb > >> Segmentation fault > >> > >> Am I missing something, or is it a bug? > > > > v.in.lidar takes only one input file at a time. > > > > Markus M > > > > > > -- > Scientist > Landcare Research, New Zealand > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Segmentation fault using v.in.lidar
Thanks for the quick answer Markus, That would be a nice feature to add though. A lot of the LAS files are coming "tiled", and it'd be nice to be able to do something like: v.in.lidar in=*.las out=test_input_lidar -trb or v.in.lidar in=zone_32_*.las out=test_input_lidar -trb to import a special subset of LAS files. I've very few coding abilities, so this is just meant as another line on the wishlist ;) Thanks heaps for your work on *.in.lidar, it is working well otherwise, Pierre 2011/7/13 Markus Metz : > On Wed, Jul 13, 2011 at 2:08 AM, Pierre Roudier > wrote: >> Hi, >> >> I've been trying to use v.in.lidar. It yields good results on one LAS >> file, but I get a segfault when trying it on several files: >> >>> v.in.lidar in=BD32_1610.las,BD32_1611.las out=test_input_lidar -trb >> Segmentation fault >>> v.in.lidar in=BD32_161*.las out=test_input_lidar -trb >> Segmentation fault >> >> Am I missing something, or is it a bug? > > v.in.lidar takes only one input file at a time. > > Markus M > -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Segmentation fault using v.in.lidar
Hi, I've been trying to use v.in.lidar. It yields good results on one LAS file, but I get a segfault when trying it on several files: > v.in.lidar in=BD32_1610.las,BD32_1611.las out=test_input_lidar -trb Segmentation fault > v.in.lidar in=BD32_161*.las out=test_input_lidar -trb Segmentation fault Am I missing something, or is it a bug? Cheers, Pierre -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Error compiling the latest grass7svn
Sorry, I did not include my ./configure line. I do have the --with-gdal=[path/to/gdal-config] option right. I did not changed my configure options, I used the usual ones, which compiled successfully on svn the last 6 months. Pierre 2011/6/8 Moritz Lennert : > On 08/06/11 05:01, Pierre Roudier wrote: >> >> Hi, >> >> I just encountered the following error while compiling the last svn up >> of grass_trunk: >> >> In file >> /usr/local/src/grass7-svn/grass_trunk/dist.x86_64-unknown-linux-gnu/include/grass/gprojects.h, >> couldn't find ogr_srs_api.h >> >> I turned ogr_srs_api.h to gdal/ogr_srs_api.h and it did pass the error >> and compiled. > > using --with-gdal=[path/to/gdal-config] as a configure option should do the > trick. > > Moritz > -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Error compiling the latest grass7svn
Hi, I just encountered the following error while compiling the last svn up of grass_trunk: In file /usr/local/src/grass7-svn/grass_trunk/dist.x86_64-unknown-linux-gnu/include/grass/gprojects.h, couldn't find ogr_srs_api.h I turned ogr_srs_api.h to gdal/ogr_srs_api.h and it did pass the error and compiled. Cheers, Pierre -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Installing own Python script
http://grass.osgeo.org/wiki/GRASS_and_Python#Parsing_the_options_and_flags http://grass.osgeo.org/wiki/GRASS_and_Python#Testing_and_installing_Python_extensions Feedback/corrections welcome. Thanks to Glynn for his great explanations! Pierre 2011/6/1 Markus Neteler : > On Wed, Jun 1, 2011 at 12:10 AM, Pierre Roudier > wrote: > ... >> Thanks heaps. Should that be on a wiki page somewhere? > > Please expand this page: > http://grass.osgeo.org/wiki/GRASS_and_Python > > thanks > Markus > -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Installing own Python script
Hi Glynn, > The build system merges the --html-description output with the > .html file (unless the .html file contains an > tag, in which case it is used verbatim; this is intended for modules > which don't recognise the --html-description switch, e.g. g.parser). > > Look at the .html files for existing scripts for reference. > They start with the DESCRIPTION section. Indeed, my bad - I did looked into it, but did not realized that. > If you're actively developing GRASS, you wouldn't normally install it. > Just run it using the bin./grass70 script. This will set the > environment variables (GISBASE, PATH, etc) to use the version in the > dist. staging directory. > > Running "make" in a module/script/library/etc directory places the > resulting files in the staging directory. If you're running GRASS from > the staging directory, subsequent commands will used the updated > files. > > Running "make install" from the top level just copies the whole of > dist. to the installation directory (e.g. /usr/local/grass70) > and bin./grass70 to the bin directory (e.g. /usr/local/bin), and > fixes any embedded paths in scripts and configuration files. > Thanks Glynn, this is all working! > The per-module "install" target (which doesn't exist for scripts at > present) copies a single module (along with its manual page in HTML > and man formats) from the dist. directory to the installation > directory. > > AFAICT, this is only useful if you're pushing your changes into the > installed version so frequently that having to do a full "make install" > from the top level each time would actually be a problem. Which could be interesting when developing that module/script? But for the time being, I'll use the "make on script directory"+"make install in the top dir" approach. Thanks heaps. Should that be on a wiki page somewhere? Pierre -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Installing own Python script
Hi Glynn, and thanks very much for taking the time to answer my newbie
questions,
> The r.mm.html file should not contain the parts which are generated by
> "r.mm.py --html-description". The build system does this automatically
> if the .html file doesn't contain an "" tag. This ensures that
> the .html file is kept up to date if options are added, removed or
> changed.
OK, so I understand the HTML file would be generated automatically at
build time (during the "make" from the top-level dir). Does that mean
that I can't add more descriptions/references/notes to the HTML file
manually?
> The per-module "install" targets are for developers wishing to install
> individual modules after modifications. As GRASS can be run from the
> staging directory without being installed, this isn't often required.
>
> If this feature is desired for scripts, it should just be a case of
> adding a slight modification of r43657 to Script.make (change "bin" to
> "scripts" in the first command).
What I would like is:
1 - Make my r.mm script available from the GRASS prompt, the same way
other Python scripts like r.grow or r.buffer are available, so I can
test it,
2 - Most importantly, I would like to access my r.mm module from other
Python scripts using eg grass.run_command('r.mm', input = input, ...,
flags = flags, quiet = quiet)
Does that mean I should recompile GRASS entirely after each
modification made to my r.mm module, or is the per-module install
option just doing that (sorry I'm not sure I got it right)?
Many thanks,
Pierre
--
Scientist
Landcare Research, New Zealand
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Installing own Python script
Hi,
I'm beginning to script GRASS using Python. Turns out it is very easy
and convivial, and in a very limited amount of time I was able to put
together a little extension to bring the main mathematical morphology
operators to GRASS.
The problem I got, however, is how to install that script into
path/to/grass_src/scripts. In that director, I created a folder named
after my extension (r.mm). It contains:
- my script, r.mm.py
- its doc, r.mm.html, generated by the command python r.mm.py
--html-description, and then completed by hand
- A Makefile
The Makefile is a simple file containing the following lines:
MODULE_TOPDIR = ../..
PGM = r.mm
include $(MODULE_TOPDIR)/include/Make/Script.make
default: script
I've been able to compile the thing once, using make. But I can't run
the make install:
roudierp@A208_RoudierP:/usr/local/src/grass7-svn/grass_trunk/scripts/r.mm> make
/usr/bin/install -c r.mm.py
/usr/local/src/grass7-svn/grass_trunk/dist.x86_64-unknown-linux-gnu/scripts/r.mm
if [
"/usr/local/src/grass7-svn/grass_trunk/dist.x86_64-unknown-linux-gnu/scripts/r.mm"
!= "" ] ; then
GISRC=/usr/local/src/grass7-svn/grass_trunk/dist.x86_64-unknown-linux-gnu/demolocation/.grassrc70
GISBASE=/usr/local/src/grass7-svn/grass_trunk/dist.x86_64-unknown-linux-gnu
PATH="/usr/local/src/grass7-svn/grass_trunk/dist.x86_64-unknown-linux-gnu/bin:$PATH"
PYTHONPATH="/usr/local/src/grass7-svn/grass_trunk/dist.x86_64-unknown-linux-gnu/etc/python:$PYTHONPATH"
LD_LIBRARY_PATH="/usr/local/src/grass7-svn/grass_trunk/dist.x86_64-unknown-linux-gnu/bin:/usr/local/src/grass7-svn/grass_trunk/dist.x86_64-unknown-linux-gnu/lib:/usr/local/src/grass7-svn/grass_trunk/dist.x86_64-unknown-linux-gnu/lib:"
LC_ALL=C
/usr/local/src/grass7-svn/grass_trunk/dist.x86_64-unknown-linux-gnu/scripts/r.mm
--html-description < /dev/null | grep -v '\|' >
r.mm.tmp.html ; fi
python
/usr/local/src/grass7-svn/grass_trunk/dist.x86_64-unknown-linux-gnu/tools/mkhtml.py
r.mm >
/usr/local/src/grass7-svn/grass_trunk/dist.x86_64-unknown-linux-gnu/docs/html/r.mm.html
VERSION_NUMBER=7.0.svn
/usr/local/src/grass7-svn/grass_trunk/dist.x86_64-unknown-linux-gnu/tools/g.html2man.py
/usr/local/src/grass7-svn/grass_trunk/dist.x86_64-unknown-linux-gnu/docs/html/r.mm.html
/usr/local/src/grass7-svn/grass_trunk/dist.x86_64-unknown-linux-gnu/man/man1/r.mm.1
GISRC=/usr/local/src/grass7-svn/grass_trunk/dist.x86_64-unknown-linux-gnu/demolocation/.grassrc70
GISBASE=/usr/local/src/grass7-svn/grass_trunk/dist.x86_64-unknown-linux-gnu
PATH="/usr/local/src/grass7-svn/grass_trunk/dist.x86_64-unknown-linux-gnu/bin:$PATH"
PYTHONPATH="/usr/local/src/grass7-svn/grass_trunk/dist.x86_64-unknown-linux-gnu/etc/python:$PYTHONPATH"
LD_LIBRARY_PATH="/usr/local/src/grass7-svn/grass_trunk/dist.x86_64-unknown-linux-gnu/bin:/usr/local/src/grass7-svn/grass_trunk/dist.x86_64-unknown-linux-gnu/lib:/usr/local/src/grass7-svn/grass_trunk/dist.x86_64-unknown-linux-gnu/lib:"
LC_ALL=C g.parser -t r.mm.py | sed s/\"/\"/g | sed 's/.*/_("&")/'
> /usr/local/src/grass7-svn/grass_trunk/locale/scriptstrings/r.mm_to_translate.c
rm r.mm.tmp.html
roudierp@A208_RoudierP:/usr/local/src/grass7-svn/grass_trunk/scripts/r.mm>
make install
make: *** No rule to make target `install'. Stop.
The wiki page [0] is great, but unfortunately does not provides much
information on that specific point (yet). I'd be more than happy to
contribute it.. as soon as I'll get my head around it!
Any help would be appreciated!
Cheers,
Pierre
[0] http://grass.osgeo.org/wiki/GRASS_and_Python
--
Scientist
Landcare Research, New Zealand
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] "Line too long" error in Python with grass.parser()
Thanks Luca, that did the trick. Cheers, Pierre 2011/5/27 Luca Delucchi : > 2011/5/27 Pierre Roudier : >> Hi, >> >> I must be missing something obvious here: I'm trying to do my first >> script in Python, and I go the following error when calling >> grass.parser(): >> Line too long or missing newline at line 63 >> >> Thinking my code must be bugged, I gave it a shot with the examples on >> the wiki (d.shademaps) and on the g.parser help page. I keep on having >> the same error. >> >> Any thoughts on what I might do wrong? > > Put an empty new line at the end of script > >> >> Cheers, >> >> Pierre >> > > -- > cheers > Luca > > http://gis.cri.fmach.it/delucchi/ > www.lucadelu.org > -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] "Line too long" error in Python with grass.parser()
Hi, I must be missing something obvious here: I'm trying to do my first script in Python, and I go the following error when calling grass.parser(): Line too long or missing newline at line 63 Thinking my code must be bugged, I gave it a shot with the examples on the wiki (d.shademaps) and on the g.parser help page. I keep on having the same error. Any thoughts on what I might do wrong? Cheers, Pierre -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] LiDAR LAS import
Hi Markus, Just compiled again liblas svn trunk, everything is working as expected so far. Thanks heaps for that new functionality, this is really very useful. Pierre 2011/5/25 Markus Metz : > Hi all, > > GRASS 7 has a new module v.in.lidar for importing LiDAR LAS files > (*.las or *.laz). The LAS file format is commonly used for storing > LiDAR point clouds, but is unfortunately not supported by OGR. > v.in.lidar uses the libLAS library [0] and is only compiled if the > libLAS library is present. > > I chose to use the library instead of writing a custom LAS reading > interface because the current LAS library version 1.6.1 is stable, > supports LAS file versions 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, each of > which can store LiDAR points in up to 5 different point formats. The > user and the interface do not need to know the file version and point > format of a given file, all that is conveniently handled by the libLAS > library in the background. The library has Large File Support (LFS) > and is well tested on different platforms, also with different > endian-ness. This functionality is not that easy to replicate. > > You will need to get the libLAS library and configure GRASS 7 with > --with-liblas in order to have the module available. Please test! > > Markus M > > [0] http://www.liblas.org > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.extension does not find any extension to install
Markus, >> Should I fill a bug? > > Yes please. Just filled http://trac.osgeo.org/grass/ticket/1341 > Sorry for the problem, No worries - thanks for making GRASS awesome :) Pierre ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.extension does not find any extension to install
Well, I think this is the case if svn is used. What is surprising though is that: svn co https://svn.osgeo.org/grass/grass-addons is working well. Should I fill a bug? Pierre 2011/3/31 Markus Neteler : > On Thu, Mar 31, 2011 at 1:27 AM, Pierre Roudier > wrote: >> Thanks Markus, >> >> Unfortunately, I still have the same behaviour after exporting my >> proxy settings to the HTTPS_PROXY envvar: >> >> GRASS 7.0.svn (NZTM2000):~ > g.extension -l >> svnurl=https://svn.osgeo.org/grass/grass-addons >> Fetching list of modules from GRASS-Addons SVN (be patient)... >> GRASS 7.0.svn (NZTM2000):~ > >> >> I'm wondering if I have to specify something special for https in my >> subversion conf file? >> > > .. no idea about subversion conf but I suspect that the g.extension > program may ignore the proxy envvar? > > Markus > -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.extension does not find any extension to install
Thanks Markus, Unfortunately, I still have the same behaviour after exporting my proxy settings to the HTTPS_PROXY envvar: GRASS 7.0.svn (NZTM2000):~ > g.extension -l svnurl=https://svn.osgeo.org/grass/grass-addons Fetching list of modules from GRASS-Addons SVN (be patient)... GRASS 7.0.svn (NZTM2000):~ > I'm wondering if I have to specify something special for https in my subversion conf file? Pierre 2011/3/30 Markus Neteler : > On Wed, Mar 30, 2011 at 3:13 AM, Pierre Roudier > wrote: >> Hi, >> >> No add-on seems to9 be available to my system when trying to use the >> g.extension command: >> >> GRASS 7.0.svn (NZTM2000):~ > g.extension -l >> svnurl=https://svn.osgeo.org/grass/grass-addons >> Fetching list of modules from GRASS-Addons SVN (be patient)... >> GRASS 7.0.svn (NZTM2000):~ > >> >> Therefore, it is not possible to install any: >> >> GRASS 7.0.svn (NZTM2000):~ > g.extension -s >> svnurl=https://svn.osgeo.org/grass/grass-addons extension=wx.psmap >> Fetching 'wx.psmap' from GRASS-Addons SVN (be patient)... >> svn: URL 'https://svn.osgeo.org/grass/grass-addons/wx/wx.psmap' doesn't exist >> ERROR: GRASS Addons 'wx.psmap' not found in repository >> GRASS 7.0.svn (NZTM2000):~ > >> >> If that's of any use, I'm running the last grass70 SVN version, on a >> Linux x86_64 platform. But I suspect this is related to the proxy of >> my institute, despite I got it specified in the HTTP_PROXY envvar, and >> in my ~/.subversion/servers file. > > I think that you also need to set the HTTPS proxy variable: > > https_proxy=http://username:password@host:port/ > export https_proxy > > Markus > -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] g.extension does not find any extension to install
Hi, No add-on seems to9 be available to my system when trying to use the g.extension command: GRASS 7.0.svn (NZTM2000):~ > g.extension -l svnurl=https://svn.osgeo.org/grass/grass-addons Fetching list of modules from GRASS-Addons SVN (be patient)... GRASS 7.0.svn (NZTM2000):~ > Therefore, it is not possible to install any: GRASS 7.0.svn (NZTM2000):~ > g.extension -s svnurl=https://svn.osgeo.org/grass/grass-addons extension=wx.psmap Fetching 'wx.psmap' from GRASS-Addons SVN (be patient)... svn: URL 'https://svn.osgeo.org/grass/grass-addons/wx/wx.psmap' doesn't exist ERROR: GRASS Addons 'wx.psmap' not found in repository GRASS 7.0.svn (NZTM2000):~ > If that's of any use, I'm running the last grass70 SVN version, on a Linux x86_64 platform. But I suspect this is related to the proxy of my institute, despite I got it specified in the HTTP_PROXY envvar, and in my ~/.subversion/servers file. Cheers, Pierre -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] text interface for GRASS70
Martin, Thanks very much for your help. That solved my problem. Cheers, Pierre FYI: pierrer@grass:~$ unset GISBASE pierrer@grass:~$ grass70 -c EPSG:4326 /home/pierrer/grassdata/test2 WELCOME TO GRASS 7.0.svn (2011) 1) Have at your side all available GRASS tutorials 2) When working on your location, the following materials are extremely useful: - A topo map of your area - Current catalog of available computer maps 3) Check the GRASS webpages for feedback mailinglists and more: http://grass.osgeo.org http://www.grass-gis.org Hit RETURN to continue Starting GRASS GIS... WARNING: It appears that the X Windows system is not active. A graphical based user interface is not supported. Switching to text based interface mode. Hit RETURN to continue __ ___ _____ / / __ \/ | / ___/ ___/ / / _/ ___/ / / __/ /_/ / /| | \__ \\_ \ / / __ / / \__ \ / /_/ / _, _/ ___ |___/ /__/ / / /_/ // / ___/ / \/_/ |_/_/ |_/// \/___/// Welcome to GRASS 7.0.svn (2011) GRASS homepage: http://grass.osgeo.org This version running through:Bash Shell (/bin/bash) Help is available with the command: g.manual -i See the licence terms with: g.version -c Start the GUI with: g.gui wxpython When ready to quit enter:exit GRASS 7.0.svn (test2):~ > g.proj -p -PROJ_INFO- name : Lat/Lon proj : ll datum : wgs84 ellps : wgs84 no_defs: defined -PROJ_UNITS unit : degree units : degrees meters : 1.0 2011/3/24 Martin Landa : > Hi, > > 2011/3/23 Pierre Roudier : >> pierrer@grass:~$ export GISBASE="" > > unset GISBASE > > Martin > > -- > Martin Landa * http://geo.fsv.cvut.cz/~landa > -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] text interface for GRASS70
Hi Martin,
> you are probably overriding GISBASE variable.
>
> What gives
>
> $ echo $GISBASE
Indeed:
pierrer@grass:~$ echo $GISBASE
/home/pierrer/grassdata/
So I turned it back to void:
pierrer@grass:~$ export GISBASE=""
pierrer@grass:~$ echo $GISBASE
But unfortunately the problem remains the same:
pierrer@grass:~$ grass70
Traceback (most recent call last):
File "/usr/local/bin/grass70", line 961, in
grass_intro()
File "/usr/local/bin/grass70", line 370, in grass_intro
f = open(path, 'r')
IOError: [Errno 2] No such file or directory: './etc/grass_intro'
However I do have a GISBASE envvar in root:
root@grass:/usr/local/src/grass_trunk# echo $GISBASE
/usr/local/grass-7.0.svn/
Here I can launch grass and initiate a location using the -c flag.
However, if I turn it to void, I can't launcg grass anymore:
root@grass:/usr/local/src/grass_trunk# export GISBASE=""
root@grass:/usr/local/src/grass_trunk# echo $GISBASE
root@grass:/usr/local/src/grass_trunk# grass70
Cleaning up temporary files...
Traceback (most recent call last):
File "/usr/local/bin/grass70", line 963, in
clean_temp()
File "/usr/local/bin/grass70", line 818, in clean_temp
call([gfile("etc", "clean_temp")], stdout = nul, stderr = nul)
File "/usr/local/bin/grass70", line 112, in call
return subprocess.call(cmd, **kwargs)
File "/usr/lib/python2.6/subprocess.py", line 470, in call
return Popen(*popenargs, **kwargs).wait()
File "/usr/lib/python2.6/subprocess.py", line 623, in __init__
errread, errwrite)
File "/usr/lib/python2.6/subprocess.py", line 1141, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] text interface for GRASS70
Hi Martin and others, and thanks very much for your answers, Your solution is working well Martin, however for some reason I have to be root to start grass successfuly. pierrer@grass:~$ grass70 -c /home/pierrer/grassdata/test2 Traceback (most recent call last): File "/usr/local/bin/grass70", line 961, in grass_intro() File "/usr/local/bin/grass70", line 370, in grass_intro f = open(path, 'r') IOError: [Errno 2] No such file or directory: '/home/pierrer/grassdata/etc/grass_intro' Pierre 2011/3/23 Martin Landa : > Hi, > > 2011/3/22 Martin Landa : >> at least we could use grass.create_location() [1] for unprojected >> locations, for the rest is needed running GRASS session (`g.proj`). >> >> Martin >> >> [1] >> http://grass.osgeo.org/programming7/namespacepython_1_1core.html#a0e55b38e9bb8c7b104e8884f26dc618a > > please try out r45726 > > $ grass70 -c /home/martin/grassdata/test1 >> g.proj -p > XY location (unprojected) > > $ grass70 -c ~/lakes.shp /home/martin/grassdata/test1 >> g.proj -p > -PROJ_INFO- > name : Lambert Conformal Conic > proj : lcc > datum : nad83 > ellps : grs80 > lat_1 : 36.16 > lat_2 : 34.34 > lat_0 : 33.75 > lon_0 : -79 > x_0 : 609601.22 > y_0 : 0 > no_defs : defined > -PROJ_UNITS > unit : Meter > units : Meters > meters : 1 > > Martin > > -- > Martin Landa * http://geo.fsv.cvut.cz/~landa > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] text interface for GRASS70
Thanks for your reply Glynn, > As suggested in the above message, specifying the path to an existing > mapset directory as an argument should work (but probably doesn't get > much testing). The "demolocation" location should be installed under > $GISBASE; you may be able to use that, provided that you own the > PERMANENT mapset. As root I can open the demolocation mapset: root@grass:/usr/local/src# grass70 /usr/local/grass-7.0.svn/demolocation/PERMANENT/ However it is impossible to do anything inside it -even create a new mapset or consult the help: GRASS 7.0.svn (demolocation):/usr/local/src > g.list rast,vect ERROR: MAPSET PERMANENT - permission denied > If you don't own the demolocation/PERMANENT directory, you can create > a copy which you do own with e.g. "cp -r ..." and use that. > I tried to copy + chown the demolocation to a single user, but grass won't start: root@grass:/usr/local/src# cp -R ../grass-7.0.svn/demolocation/ /home/pierrer/grassdata/ root@grass:/usr/local/src# chown -R pierrer:pierrer /home/pierrer/grassdata/demolocation/ pierrer@grass:~$ grass70 /home/pierrer/grassdata/demolocation/PERMANENT/ Traceback (most recent call last): File "/usr/local/bin/grass70", line 943, in grass_intro() File "/usr/local/bin/grass70", line 370, in grass_intro f = open(path, 'r') IOError: [Errno 2] No such file or directory: '/home/pierrer/grassdata/etc/grass_intro' > Ultimately, we really need to add e.g. a "-c" flag to the grass70 > script to allow the creation of a new database/location/mapset on > systems where the GUI cannot be used. That'd be great! Thanks again, Pierre > > -- > Glynn Clements > -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] text interface for GRASS70
Hi, I just compiled grass7-svn (revision 45721) on my server, but I can't initiate any mapset: pierrer@grass:~$ grass70 -text Unable to start GRASS. You can: - Launch GRASS with '-gui' switch (`grass70 -gui`) - Create manually GISRC file (/home/pierrer/.grass7/rc) - Launch GRASS with path to the location/mapset as an argument (`grass70 /path/to/location/mapset`) It is a remote machine without X, so I can't really use the graphical way. For the other options, I understand I should have a location + mapset already on my server (which is not the case). I could certainly copy one of my local projects on the server bu I was wondering if that was a bug of the text interface. I understand this is related to this bug: http://osgeo-org.1803224.n2.nabble.com/GRASS-7-CLI-startup-td5923640.html Cheers, Pierre -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Compilation error on grass7-svn
Thanks for your pointers, After a clean checkout and a make clean, it compiled successfully. Cheers, Pierre 2011/3/21 Glynn Clements : > > Pierre Roudier wrote: > >> I got the following error when compiling against the last update of >> the grass7 trunk: > >> OBJ.x86_64-unknown-linux-gnu/strings.o -c strings.c >> strings.c:136: error: conflicting types for �G_str_replace� >> /usr/local/src/grass_trunk/dist.x86_64-unknown-linux-gnu/include/grass/gisdefs.h:580: >> note: previous declaration of �G_str_replace� was here > >> Any suggestions? > > Are you running "make" from the top-level directory, or are you trying > to compile just part of the tree? > > r45541 modified the prototype for G_str_replace() in both > lib/gis/strings.c and include/gisdefs.h. Running "make" in the > "include" directory should install the updated gisdefs.h file to > dist./include/grass/gisdefs.h, but this won't happen if you try > to build the "lib" or "lib/gis" directories alone. > > In any case, running "make clean" first should fix the problem, even > though it shouldn't be necessary. > > FWIW, the lines in question should be: > > include/gisdefs.h:580: > > char *G_str_replace(const char *, const char *, const char *); > > (and also for dist./include/grass/gisdefs.h). > > lib/gis/strings.c:136: > > char *G_str_replace(const char *buffer, const char *old_str, const > char *new_str) > > -- > Glynn Clements > -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Compilation error on grass7-svn
Hi list, I got the following error when compiling against the last update of the grass7 trunk: gcc -g -fPIC -I/usr/local/src/grass_trunk/dist.x86_64-unknown-linux-gnu/include -I/usr/local/src/grass_trunk/dist.x86_64-unknown-linux-gnu/include -D_FILE_OFFSET_BITS=64 -DPACKAGE=\""grasslibs"\" -I/usr/local/src/grass_trunk/dist.x86_64-unknown-linux-gnu/include -I/usr/local/src/grass_trunk/dist.x86_64-unknown-linux-gnu/include -o OBJ.x86_64-unknown-linux-gnu/strings.o -c strings.c strings.c:136: error: conflicting types for ‘G_str_replace’ /usr/local/src/grass_trunk/dist.x86_64-unknown-linux-gnu/include/grass/gisdefs.h:580: note: previous declaration of ‘G_str_replace’ was here strings.c: In function ‘G_str_replace’: strings.c:160: warning: assignment discards qualifiers from pointer target type strings.c:182: warning: assignment discards qualifiers from pointer target type make: *** [OBJ.x86_64-unknown-linux-gnu/strings.o] Error 1 Any suggestions? Cheers, Pierre -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
