Re: [GRASS-user] v.patch segmentation fault

[Daniel McInerney]

Hi Markus, cc: List,

thanks for your reply. I've reproduced the segmentation fault using the
roads dataset from the Spearfish dataset. I've split the roads into
three separate vector layers, and then patched them together as follows:

v.extract input=roads output=roads_interstate where="label='interstate'"
v.extract input=roads output=roads_primary where="label LIKE 'primary%'"
v.extract input=roads output=roads_secondary where="label LIKE 'secondary%'"

##here I patch one set of vectors without -e

v.patch input=roads_primary,roads_secondary out=roads_12

v.patch -e input=roads_12,roads_interstate output=roads_patch

Segmentation fault

As mentioned previously this was caused by an oversight on my side, but
it might be useful to check if all inputs to v.patch have a (valid)
database table attached as well as the correct set of columns, rather
than returning the segmentation fault.

Hope that helps.

best regards,
Daniel

On 28/03/2021 22:07, Markus Neteler wrote:
> Hi Daniel,
>
> On Thu, Mar 11, 2021 at 11:35 AM Daniel McInerney
>  wrote:
>> Hi List,
>>
>> I was running a series of steps in a workflow that patched different
>> line vector datasets together using v.patch, but at one stage I got a
>> Segmentation Fault without any indication of the cause. I soon realised
>> that one of the inputs that I had previously generated with v.patch, did
>> not have an attribute table as I had omitted the -e flag in error. Below
>> is the command that lead to the seg fault (including the gdb outputs),
>> where 'fishnet_1' did not have an attribute table.
>>
>> Starting program: /usr/local/grass79/bin/v.patch -e
>> input=fishnet_1,fishnet_2 out=fishnet_all
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>> [New Thread 0x7fffecf09700 (LWP 18601)]
>> [New Thread 0x7fffec708700 (LWP 18602)]
>> [New Thread 0x7fffe9f07700 (LWP 18603)]
>> [New Thread 0x7fffe5706700 (LWP 18604)]
>> [New Thread 0x7fffe2f05700 (LWP 18605)]
>> [New Thread 0x7fffe0704700 (LWP 18606)]
>> [New Thread 0x7fffddf03700 (LWP 18607)]
>>
>> Thread 1 "v.patch" received signal SIGSEGV, Segmentation fault.
>> db_get_table_number_of_columns (table=0x0) at table.c:140
>>
>> 140 return table->numColumns;
>>
>> When I recreated 'fishnet_1' and included -e, and then re-ran the above
>> command, the process completed successfully. I'm therefore wondering if
>> it would be possible for v.patch  to check whether all of the inputs
>> have valid attribute tables/dblinks attached, in a similar way it checks
>> that all inputs have the same number of columns. I appreciate that I may
>> be overlooking a more fundamental reason why this can't be done, but
>> perhaps an error message could be included in lieu or in addition to the
>> segmentation fault. The above was tested on grass-gis 7.9 dev with both
>> sqlite and pg db drivers.
>>
>> thanks in advance,
>>
>> Daniel
> Do you see a chance to provide a reproducible example?
> Then we could run the debugger on it.
> Certainly you may do that as well, with your data:
>
> https://grasswiki.osgeo.org/wiki/GRASS_Debugging#Using_GDB
>
> It may give some insights why the segfault happens.
>
> Best,
> Markus

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

Re: [GRASS-user] Dates when g.extension not working

[Markus Neteler]

Hi,

ming han  schrieb am Di., 30. März 2021, 14:04:

> Hi Everyone
>
> Are there any scheduled dates for g.extension not working?  I will ask
> several people to install grass and some grass addons, just need to let
> them know when the g.extension won't work.
>

It should (!) always be working. Occasionally the server has issues but to
my knowledge no downtimes are planned.

Best,

Markus


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

[GRASS-user] FOSS4G 2021: Call for Papers for Talks and Workshops Deadline Extended

[Veronica Andreo]

View this email in your browser


*SUBMIT AN ABSTRACT FOR FOSS4G 2021*
*Deadline for Talks and Workshops extended until April 19th 2021!*

It's your chance to be part of this FOSS4G 2021, online edition!
As a local organizing team, we are very excited to learn how you apply your
FOSS technologies to your projects, or daily jobs, as well, we are hungry
for new knowledge.
Do not miss it!
SUBMIT HERE

*WORKSHOPS*
Workshops are hands-on sessions in which attendees have the chance to learn
about FOSS4G software with direct interaction.
Share your knowledge and help others learn through these sessions.

*TALKS*
Talks will be assigned a 25 minutes slot: 15 minutes for the talk itself
and 10 for Q&A.
Remember that although we have few places for talks in Spanish or
Portuguese, you have more chances that your talk will be accepted if
submitted in English.



*ACADEMIC*
The Academic track is the perfect place to showcase your latest research
and innovation. If you are looking for exposure and collaborations, this is
the perfect place to present your results.
With a peer reviewed process, the selected papers will be pusblished
through ISPRS Archives.
*You can still send your proposal before tomorrow!*


[image: Twitter]

[image: Facebok]

[image: Instragram]

[image: LinkedIn]

[image: Email] 
[image: Website]

OSGeo Foundation
You can update your preferences

or unsubscribe from this list

.
FOSS4G 2021 - 9450 SW Gemini Dr - Beaverton, Oregon 97008 - United States
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.watershed identify inland watershed

[ming han]

Got it, thanks everyone~
Ming

Micha Silver  于2021年3月29日周一 下午2:40写道：

> Hello:
>
> You might try `r.param.scale`, or even better `r.geomorphons` modules to
> identify geomorphology features, then filter out all pixels identified
> as pits.
>
>
> r.watershed is purposely designed to overcome depressions, and find flow
> routing thru these spots. So I don't think you can use that module to
> identify depressions.
>
>
> On 3/27/21 8:49 PM, ming han wrote:
> > Hi  Everyone
> >
> >  When I do watershed delineation using r.watershed for great salt
> > lake watershed. I found r.watershed always tried to assign an outlet
> > for a great salt lake, which does actually not exist because it is an
> > inland lake and the great salt lake has no watershed outlet at all.
> >
> >   I noticed that there is a depression option. But is there any
> > way that  r.watershed can automatically identify depressions while
> > defining flow accumulation and stream network?
> >
> > Thanks
> > Ming
> >
> > ___
> > grass-user mailing list
> > grass-user@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-user
>
> --
> Micha Silver
> Ben Gurion Univ.
> Sde Boker, Remote Sensing Lab
> cell: +972-523-665918
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Dates when g.extension not working

[ming han]

Hi Everyone

Are there any scheduled dates for g.extension not working?  I will ask
several people to install grass and some grass addons, just need to let
them know when the g.extension won't work.

Thanks

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