Re: [GRASS-dev] [release planning] GRASS GIS 8.3.2

2024-03-14 Thread Peter Löwe via grass-dev
Hi Markus, all,

good news: 
Zenodo just fixed the issue for GRASS (an error on their side): 
https://zenodo.org/records/10817962

Best,
Peter




> Gesendet: Dienstag, 12. März 2024 um 18:23 Uhr
> Von: "Markus Neteler" 
> An: "Peter Löwe" 
> Cc: "GRASS developers list" 
> Betreff: Re: [GRASS-dev] [release planning] GRASS GIS 8.3.2
>
> Hi Peter, all,
> 
> So GRASS GIS 8.3.2 has been published and no trace of it in Zenodo:
> 
> https://zenodo.org/records/10685321
> 
> The GitHub-Zenodo bridge seems to be unstable?
> 
> Ideas welcome,
> Markus
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev


Re: [GRASS-dev] [release planning] GRASS GIS 8.3.2

2024-03-12 Thread Peter Löwe via grass-dev
Hi Markus, all,

sorry to hear about this fuss. I will contact Zenodo asap.

On the bright side, this is another proof of the (frustrating) service quality 
hickups we encounter. 

EGU has invited me to talk about these issues in April and I will use this 
opportunity to demonstrate our case.
https://doi.org/10.5194/egusphere-egu24-6254.  

Best,
Peter




> Gesendet: Dienstag, 12. März 2024 um 18:23 Uhr
> Von: "Markus Neteler" 
> An: "Peter Löwe" 
> Cc: "GRASS developers list" 
> Betreff: Re: [GRASS-dev] [release planning] GRASS GIS 8.3.2
>
> Hi Peter, all,
> 
> So GRASS GIS 8.3.2 has been published and no trace of it in Zenodo:
> 
> https://zenodo.org/records/10685321
> 
> The GitHub-Zenodo bridge seems to be unstable?
> 
> Ideas welcome,
> Markus
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev


[GRASS-dev] Stuck version DOI registration for 8.3.2. RC1: Feedback from Zenodo

2024-02-29 Thread Peter Löwe via grass-dev
Hi all,

here's feedback from Zenodo about the "stuck" version DOI registration for 
8.3.2. RC1:

"With these events it is often minor, unnoticeable, downtimes which prevents 
events from being sent or received which results in these failures.
In order to fix it we have to kickstart the DataCite DOI registration process 
again.
Hopefully we can do a better job catching these issues in the future, but in 
the meantime letting us know through support is ideal".

So there is nothing wrong with the current GitHub/Zenodo-bridge workflow :-)

Best,
Peter



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


Re: [GRASS-dev] [release planning] GRASS GIS 8.3.2

2024-02-29 Thread Peter Löwe via grass-dev
Hi Markus, all,

the friendly people at Zenodo fixed the issue: 
https://doi.org/10.5281/zenodo.10685321 now resolves to the GRASS GIS 8.3.2RC1 
codebase (timestamp: Feb 20 2024).

I have asked them for forensics/reasons why the issue occured and will report 
back once I get a response. 

Congratulations to this new version DOI for GRASS GIS !


Best,
Peter




> Gesendet: Montag, 26. Februar 2024 um 21:34 Uhr
> Von: "Markus Neteler" 
> An: "Peter Löwe" 
> Cc: "GRASS developers list" 
> Betreff: Re: Re: [GRASS-dev] [release planning] GRASS GIS 8.3.2
>
> Hi Peter,
> 
> On Sun, Feb 25, 2024 at 12:20 AM Peter Löwe  wrote:
> >
> > Markus, all,
> >
> > minting a DOI should take minutes/seconds, not days.
> >
> > Can more in depth info / metadata about the particular transaction be 
> > provided, which states that "https://doi.org/10.5281/zenodo.10685321; 
> > should be the new version DOI for GRASS GIS 8.3.2RC1 ?
> 
> Sure:
> 
> Version 8.3.2RC1: https://zenodo.org/records/10685321
> --> see left side
>--> DOI: https://doi.org/10.5281/zenodo.10685321
>  ---> still missing while advertised on the Zenodo page.
> 
> Not sure how that could happen?
> 
> Best,
> Markus
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev


Re: [GRASS-dev] [release planning] GRASS GIS 8.3.2

2024-02-24 Thread Peter Löwe via grass-dev
Markus, all,

minting a DOI should take minutes/seconds, not days.

Can more in depth info / metadata about the particular transaction be provided, 
which states that "https://doi.org/10.5281/zenodo.10685321; should be the new 
version DOI for GRASS GIS 8.3.2RC1 ?

Best,
Peter




> Gesendet: Freitag, 23. Februar 2024 um 11:26 Uhr
> Von: "Markus Neteler" 
> An: "Peter Löwe" 
> Cc: "GRASS developers list" 
> Betreff: Re: [GRASS-dev] [release planning] GRASS GIS 8.3.2
>
> Dear Peter,
> 
> On Thu, Feb 22, 2024 at 7:33 PM Veronica Andreo  wrote:
> >
> > Markus, all,
> >
> > Great! Thanks a lot!
> >
> > Zenodo link works, but the doi link yields doi not found page... is it ok 
> > for the resolver link to take a couple of days?
> 
> Still not generated:
> https://doi.org/10.5281/zenodo.10685321
> 
> Peter, do you have an idea what could be wrong?
> 
> thanks,
> Markus
> 
> 
> > Vero
> >
> > El mar, 20 feb 2024 a las 19:45, Markus Neteler via grass-dev 
> > () escribió:
> >>
> >> Hi devs,
> >>
> >> On Thu, Feb 1, 2024 at 10:40 PM Markus Neteler  wrote:
> >> > We have accumulated a number of fixes in the past weeks.
> >> >
> >> > Here the milestone:
> >> > https://github.com/OSGeo/grass/milestone/24
> >>
> >> The RC1 release is now available, please test it:
> >> https://github.com/OSGeo/grass/releases/tag/8.3.2RC1
> >>
> >> The open issues/PR I have moved to a new 8.3.3 milestone. But let's
> >> focus on 8.4.0.
> >>
> >> And yay, the Zenodo bridge works again:
> >> Version 8.3.2RC1: https://zenodo.org/records/10685321
> >> DOI: https://doi.org/10.5281/zenodo.10685321 (resolver link will work
> >> in some hs from now)
> >>
> >> Hopefully no RC2 is needed.
> >>
> >> Thanks to all contributors,
> >> Markus
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev


Re: [GRASS-dev] Version DOI missing for GRASS 8.3.0

2023-08-16 Thread Peter Löwe
+1

Best,
Peter




> Gesendet: Mittwoch, 16. August 2023 um 12:01 Uhr
> Von: "Markus Neteler" 
> An: "Peter Löwe" 
> Cc: "GRASS developers list" 
> Betreff: Re: Re: Re: [GRASS-dev] Version DOI missing for GRASS 8.3.0
>
> On Wed, Aug 16, 2023 at 8:31 AM Peter Löwe  wrote:
> >
> > Hi Markus,
> >
> > Zenodo says that another release by the GRASS project is necessary to 
> > retrieve the changes.
> 
> Well, so that sounds like manual upload if we want to see 8.3.0 there.
> 
> > Maybe a "minor technical maintenance" release could be considered ?
> 
> That would be 8.3.1 then, right? ... planned for Oct. 2023:
> https://github.com/OSGeo/grass/milestone/21
> 
> Best,
> Markus
> 
> > Other projects did such minor relase to obtain a DOI for the references in 
> > the Handbook of Geographic
> > Information, since the publication deadlines were not in synch with the 
> > release cycles of the projects.
> >
> > Best,
> > Peter
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev


Re: [GRASS-dev] Version DOI missing for GRASS 8.3.0

2023-08-16 Thread Peter Löwe
Hi Markus,

Zenodo says that another release by the GRASS project is necessary to retrieve 
the changes.

Maybe a "minor technical maintenance" release could be considered ?

Other projects did such minor relase to obtain a DOI for the references in the 
Handbook of Geographic Information, since the publication deadlines were not in 
synch with the release cycles of the projects.

Best,
Peter








> Gesendet: Dienstag, 15. August 2023 um 22:27 Uhr
> Von: "Markus Neteler" 
> An: "Peter Löwe" 
> Cc: "GRASS developers list" 
> Betreff: Re: Re: [GRASS-dev] Version DOI missing for GRASS 8.3.0
>
> Hi Peter,
> 
> On Mon, Aug 14, 2023 at 2:50 PM Markus Neteler  wrote:
> >
> > Hi Peter,
> >
> > On Mon, Aug 14, 2023 at 1:23 PM Peter Löwe  wrote:
> > >
> > > Vacek, Markus, all,
> > >
> > > according to the Zenodo helpdesk there are still issues with the CFF file 
> > > of GRASS GIS 8.3:
> >
> > Ok, got it. And fixed:
> >
> > https://github.com/OSGeo/grass/pull/3123
> 
> Merged. The updated CITATION.cff is now in place in GitHub (main, 8.3,
> 8.2 branches).
> 
> For our case:
> https://github.com/OSGeo/grass/blob/releasebranch_8_3/CITATION.cff
> 
> May the Zenodo helpdesk try again?
> 
> Best,
> Markus
> 
> 
> -- 
> Markus Neteler, PhD
> https://www.mundialis.de - free data with free software
> https://grass.osgeo.org
> https://courses.neteler.org/blog
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev


Re: [GRASS-dev] Version DOI missing for GRASS 8.3.0

2023-08-14 Thread Peter Löwe
Vacek, Markus, all,

 

according to the Zenodo helpdesk there are still issues with the CFF file of GRASS GIS 8.3:

 

---


Your CITATION.cff seems to be problematic still. You can validate it using tools like https://github.com/citation-file-format/cff-converter-python

 

 

jsonschema.exceptions.ValidationError: Additional properties are not allowed ('citation' was unexpected)

 

Failed validating 'additionalProperties' in schema:
    {'$id': 'https://citation-file-format.github.io/1.2.0/schema.json',


---
 

Best,

Peter

 



 
 

Gesendet: Dienstag, 08. August 2023 um 18:58 Uhr
Von: "Vaclav Petras" 
An: "Markus Neteler" 
Cc: "Peter Löwe" , "GRASS developers list" 
Betreff: Re: [GRASS-dev] Version DOI missing for GRASS 8.3.0



 
 


On Tue, 8 Aug 2023 at 12:26, Markus Neteler <nete...@osgeo.org> wrote:

Hi Peter,

On Tue, Aug 8, 2023 at 5:04 PM Peter Löwe <peter.lo...@gmx.de> wrote:
>
> Hi Markus,
> the licence ID for GRASS GIS 7.8.8. on its landing page reads:
> "Other (Open)"

I have seen it, too. Unfortunately not the precise licence description.

> This setting goes back to GRASS GIS 7.8.6.
> Since this is (just) landing page metadata, this can be changed after the minting of the DOI and the file upload into Zenodo.
>
> The landing page for GRASS GIS 8.2.0 (https://zenodo.org/record/6612307) has different licence metadata: "GNU General Public License v2.0 or later", which points to https://opensource.org/license/gpl-2-0/
>
> Did GRASS GIS 8.2.0 get maybe manually checked into Zenodo ?

I am not aware that anyone manually uploaded a GRASS GIS release to Zenodo.

> Otherwise this could be a Zenodo-sided bug ("worked before")..?

Probably they treated non-SPDX conformant license identifiers (here:
"GPL-2.0-or-later") differently?
Just guessing: In the past they changed it to "Other (Open)" and now
it is (randomly) failing?

 
I think it was two different things. The 7.8 branch info for Zenodo is just picked from GitHub metadata, while 8.2 and 8.3 are using the CFF file. Between the latest 8.2 and 8.3.0, Zenodo also happened to change how a non-conformat license entry is handled.





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


Re: [GRASS-dev] Version DOI missing for GRASS 8.3.0

2023-08-09 Thread Peter Löwe
Markus, all,
I have asked the Zenodo helpdesk to retrigger the deposit of GRASS8.3.0 and 
GRASS 8.3RC1.

Best,
Peter




> Gesendet: Dienstag, 08. August 2023 um 18:26 Uhr
> Von: "Markus Neteler" 
> An: "Peter Löwe" 
> Cc: "GRASS developers list" 
> Betreff: Re: Re: Re: Re: [GRASS-dev] Version DOI missing for GRASS 8.3.0
>
> Hi Peter,
> 
> On Tue, Aug 8, 2023 at 5:04 PM Peter Löwe  wrote:
> >
> > Hi Markus,
> > the licence ID for GRASS GIS 7.8.8. on its landing page reads:
> > "Other (Open)"
> 
> I have seen it, too. Unfortunately not the precise licence description.
> 
> > This setting goes back to GRASS GIS 7.8.6.
> > Since this is (just) landing page metadata, this can be changed after the 
> > minting of the DOI and the file upload into Zenodo.
> >
> > The landing page for GRASS GIS 8.2.0 (https://zenodo.org/record/6612307) 
> > has different licence metadata: "GNU General Public License v2.0 or later", 
> > which points to https://opensource.org/license/gpl-2-0/
> >
> > Did GRASS GIS 8.2.0 get maybe manually checked into Zenodo ?
> 
> I am not aware that anyone manually uploaded a GRASS GIS release to Zenodo.
> 
> > Otherwise this could be a Zenodo-sided bug ("worked before")..?
> 
> Probably they treated non-SPDX conformant license identifiers (here:
> "GPL-2.0-or-later") differently?
> Just guessing: In the past they changed it to "Other (Open)" and now
> it is (randomly) failing?
> 
> Anyway, we now have updated the CITATION.cff with the correct SPDX
> license identifier "GPL-2.0-or-later" in GRASS GIS 8.x.
> 
> It would be cool if Zenodo helpdesk could retrigger the 8.3.0 upload.
> 
> Best,
> Markus
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev


Re: [GRASS-dev] Version DOI missing for GRASS 8.3.0

2023-08-08 Thread Peter Löwe
Hi Markus,
the licence ID for GRASS GIS 7.8.8. on its landing page reads:
"Other (Open)"
This setting goes back to GRASS GIS 7.8.6.
Since this is (just) landing page metadata, this can be changed after the 
minting of the DOI and the file upload into Zenodo.

The landing page for GRASS GIS 8.2.0 (https://zenodo.org/record/6612307) has 
different licence metadata: "GNU General Public License v2.0 or later", which 
points to https://opensource.org/license/gpl-2-0/

Did GRASS GIS 8.2.0 get maybe manually checked into Zenodo ? Otherwise this 
could be a Zenodo-sided bug ("worked before")..?

Best,
Peter




> Gesendet: Dienstag, 08. August 2023 um 12:33 Uhr
> Von: "Markus Neteler" 
> An: "Peter Löwe" 
> Cc: "GRASS developers list" 
> Betreff: Re: Re: Re: [GRASS-dev] Version DOI missing for GRASS 8.3.0
>
> HI Peter,
> 
> On Tue, Aug 8, 2023 at 11:24 AM Peter Löwe  wrote:
> >
> > Hi Markus, all,
> >
> > would it be feasible for the maintainers to do a manual Zenodo-check-in for 
> > GRASS GIS 8.3 similar  to GRASS GIS 7.8.8 ?
> 
> Well, the Zenodo part of 7.8.8 was automated.
> 
> > Alternatively I can contact the Zenodo helpdesk to get this fixed.
> 
> Hold on - I just checked it here:
> 
> https://zenodo.org/account/settings/github/repository/OSGeo/grass
> 
> 7.8.8 OSGeo/grass: GRASS GIS 7.8.8
> DOI: 10.5281/zenodo.8219486
> GRASS GIS 7.8.8
> Published
> a day ago
> 
> 
> 8.3.0 OSGeo/grass: GRASS GIS 8.3.0
> GRASS GIS 8.3.0
> Failed<<<<- !
> a month ago
> 
> 
> 8.3.0RC1 OSGeo/grass: GRASS GIS 8.3.0RC1
> GRASS GIS 8.3.0RC1
> Failed
> 2 months ago
> 
> 
> 8.2.1 OSGeo/grass: GRASS GIS 8.2.1
> DOI: 10.5281/zenodo.7764250
> GRASS GIS 8.2.1
> Published
> 4 months ago
> 
> 
> ...
> 
> In detail:
> 
> 8.3.0 OSGeo/grass: GRASS GIS 8.3.0
> GRASS GIS 8.3.0
> Failed
> 
> {
> "errors": "The license ID you have selected is not present in our
> system. For the available licenses please check in the following URL
> https://developers.zenodo.org/#licenses;
> }
> 
> https://github.com/OSGeo/grass/blob/4428fae82aba5e9033bae7ea4ba84da914949602/CITATION.cff#L109
> --> license: GNU General Public License v2 or later
> 
> I guess it dislikes the "... or later" part. How to write it properly?
> 
> Best,
> Markus
> 
> -- 
> Markus Neteler, PhD
> https://www.mundialis.de - free data with free software
> https://grass.osgeo.org
> https://courses.neteler.org/blog
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev


Re: [GRASS-dev] Version DOI missing for GRASS 8.3.0

2023-08-08 Thread Peter Löwe
Hi Markus, all,

would it be feasible for the maintainers to do a manual Zenodo-check-in for 
GRASS GIS 8.3 similar  to GRASS GIS 7.8.8 ?

Alternatively I can contact the Zenodo helpdesk to get this fixed.

Best,
Peter




> Gesendet: Dienstag, 08. August 2023 um 09:40 Uhr
> Von: "Markus Neteler" 
> An: "Peter Löwe" 
> Cc: "GRASS developers list" 
> Betreff: Re: Re: [GRASS-dev] Version DOI missing for GRASS 8.3.0
>
> Hi Peter, all,
> 
> On Tue, Aug 8, 2023 at 9:37 AM Peter Löwe  wrote:
> >
> > Hi Markus, all,
> >
> > FWIW; the DOI minting _did_ work as expected for GRASS 7.8.8 on August 6: 
> > https://zenodo.org/record/8219486
> 
> Ok, that's good. I released it using the manual way of doing things.
> 
> > > On Mon, Aug 7, 2023 at 4:47 PM Peter Löwe  wrote:
> > > > I just noticed that GRASS 8.3. (https://github.com/OSGeo/grass) hasn't 
> > > > received a version DOI in Zenodo yet.
> ...
> > > > This is weird since the Zenodo - GitHub hookup used to be / is 
> > > > automated.
> 
> For GRASS GIS 8 we use the scripted/semi-automated way. However, I
> don't see why this should behave differently towards Zenodo.
> 
> Best,
> Markus
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev


Re: [GRASS-dev] Version DOI missing for GRASS 8.3.0

2023-08-08 Thread Peter Löwe
Hi Markus, all,

FWIW; the DOI minting _did_ work as expected for GRASS 7.8.8 on August 6: 
https://zenodo.org/record/8219486



Best.
Peter





> Gesendet: Montag, 07. August 2023 um 17:25 Uhr
> Von: "Markus Neteler" 
> An: "Peter Löwe" 
> Cc: "GRASS developers list" 
> Betreff: Re: [GRASS-dev] Version DOI missing for GRASS 8.3.0
>
> On Mon, Aug 7, 2023 at 4:47 PM Peter Löwe  wrote:
> >
> > Hello List,
> >
> > I just noticed that GRASS 8.3. (https://github.com/OSGeo/grass) hasn't 
> > received a version DOI in Zenodo yet.
> > The latest version DOIs were minted for 7.8.8. and 8.2.1:
> > https://zenodo.org/search?page=1=20=conceptrecid:%225176030%22=mostrecent_versions=True
> >
> > This is weird since the Zenodo - GitHub hookup used to be / is automated.
> 
> Oh, too bad.
> 
> > Ideas, anyone ?
> 
> Maybe the "bridge" is broken again?
> Does it still work for others, e.g. GDAL?
> 
> Best,
> Markus
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev


Re: [GRASS-dev] Version DOI missing for GRASS 8.3.0

2023-08-08 Thread Peter Löwe
Hi Markus, all,

GDAL minted its latest version DOI on July 13:
https://zenodo.org/record/8144520

Have there been any changes in the release process (GRASS-sided) ?

Best,
Peter




> Gesendet: Montag, 07. August 2023 um 17:25 Uhr
> Von: "Markus Neteler" 
> An: "Peter Löwe" 
> Cc: "GRASS developers list" 
> Betreff: Re: [GRASS-dev] Version DOI missing for GRASS 8.3.0
>
> On Mon, Aug 7, 2023 at 4:47 PM Peter Löwe  wrote:
> >
> > Hello List,
> >
> > I just noticed that GRASS 8.3. (https://github.com/OSGeo/grass) hasn't 
> > received a version DOI in Zenodo yet.
> > The latest version DOIs were minted for 7.8.8. and 8.2.1:
> > https://zenodo.org/search?page=1=20=conceptrecid:%225176030%22=mostrecent_versions=True
> >
> > This is weird since the Zenodo - GitHub hookup used to be / is automated.
> 
> Oh, too bad.
> 
> > Ideas, anyone ?
> 
> Maybe the "bridge" is broken again?
> Does it still work for others, e.g. GDAL?
> 
> Best,
> Markus
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev


[GRASS-dev] Version DOI missing for GRASS 8.3.0

2023-08-07 Thread Peter Löwe
Hello List,

I just noticed that GRASS 8.3. (https://github.com/OSGeo/grass) hasn't received 
a version DOI in Zenodo yet.
The latest version DOIs were minted for 7.8.8. and 8.2.1:
https://zenodo.org/search?page=1=20=conceptrecid:%225176030%22=mostrecent_versions=True

This is weird since the Zenodo - GitHub hookup used to be / is automated.

Ideas, anyone ?

Best,
Peter





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


Re: [GRASS-dev] [release planning] Enable Zenodo before 7.8.6 and 8.0.0

2021-08-11 Thread Peter Löwe
Hi Vaclav, GRASS devs,

 

the MOSS project has successfully adopted a new Zenodo-related feature, which might simplify also the open access publishing of GRASS 7.8.6 and 8.0.0 via Zenodo.

 

- An additional file called ".zenodo.json" was added to the top level directory of the github repo of MOSS.

- This file (https://github.com/OSGeo/MOSS/blob/main/.zenodo.json) contains structured information about the project author and the developer team, but also maintainers with their specific roles. Individual ORCID IDs can be included.

- The general description how to set the webhooks connecting github and Zenodo (https://guides.github.com/activities/citable-code/) remains the same.

- New: Once a new release is done in github, Zenodo will harvest all metadata provided in .zenodo.json and will update the "cite as" section of the Zenodo landing page accordingly (https://doi.org/10.5281/zenodo.5140319)

- This is a significant improvement. Until now, only the names of the owners of the github repo and the Zenodo account were shown, which is inaccurate in most cases.

 

- Technical information about the JSON Schema followed by the ".zenodo.json" file is at https://zenodo.org/schemas/deposits/records/legacyrecord.json and is documented in the Zenodo developer docs at https://developers.zenodo.org/?python#deposit-metadata.

 

Best,

Peter
 



 
 

Gesendet: Sonntag, 06. Juni 2021 um 05:33 Uhr
Von: "Vaclav Petras" 
An: "Peter Löwe" 
Cc: "grass-dev@lists.osgeo.org" 
Betreff: Re: Re: [release planning] Enable Zenodo before 7.8.6 and 8.0.0



Hi Peter, all, thanks for the answers. I have more questions assuming that's okay.
 


On Fri, Jun 4, 2021 at 2:57 AM Peter Löwe <peter.lo...@gmx.de> wrote:








==> the CodeMeta-Project is currenlty pushing software citation standards: https://codemeta.github.io/








 

Thanks. The roles there seem to be more clear. Any opinion on CodeMata versus CFF (see also below)?

 








 


BTW, ways to retro-provide DOI versioning for previous GRASS releases would be an rewarding topic to discuss with Data Cite (the DOI infrastructure community).




 

Any opinions on how useful this is? We want a good archive of old versions, but does someone need DOIs for old releases?

 

==> This depends on wether the community wants to give due credit by citation to the persons which were involved in the previous releases.








 

Currently, the author list maintained in the source code is cumulative as far as I know, so old authors are still included as authors, so only use cases for that would be citing old releases in paper or by the new versions of software software. None seem likely to me. What do you think?

 











 




Any suggestions on includings DOI into source code? It seems to me that you can only use the generic/concept one and tell people to get the recent one. I didn't figure out the DOI reservation for GitHub repos.








 

Rather than where to put it - although that's important, too - my question is about which DOI? The main one everywhere or somehow try to put there the version specific one if that's even possible. It seems to me that the main DOI is the only feasible option.

 








==> A JSON file could be included. This way, the information is both readable for humans and automated access: https://codemeta.github.io/codemeta-generator/ 








 

I was thinking about the Citation File Format as I have seen it used quite a bit. Any opinions on that?

 






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


Re: [GRASS-dev] [release planning] Enable Zenodo before 7.8.6 and 8.0.0

2021-06-08 Thread Peter Löwe
Hi Vaclav, all,

 

maybe helpful:

 

The transient MOSS repo has been updated for CFF and codemeta.json:

 

https://github.com/ploewe/MOSS

 

The online CFF-generator didn't accept some of the attributes. Doublechecking of the output is recommended.

Further, we hijacked the CFF affiliation tag to include MARC relator/ role terms (https://www.loc.gov/marc/relators/relaterm.html), like the R community has done:

 

https://r-pkgs.org/description.html


"... A three letter code specifying the role. There are four important roles:


	
	cre: the creator or maintainer, the person you should bother if you have problems.
	
	
	aut: authors, those who have made significant contributions to the package.
	
	
	ctb: contributors, those who have made smaller contributions, like patches.
	
	
	cph: copyright holder. This is used if the copyright is held by someone other than the author, typically a company (i.e. the author’s employer).
	

..."

 

I will talk to the software citation folks to see how this is perceived.

 

Best,

Peter

 



 
 

Gesendet: Sonntag, 06. Juni 2021 um 05:33 Uhr
Von: "Vaclav Petras" 
An: "Peter Löwe" 
Cc: "grass-dev@lists.osgeo.org" 
Betreff: Re: Re: [release planning] Enable Zenodo before 7.8.6 and 8.0.0



Hi Peter, all, thanks for the answers. I have more questions assuming that's okay.
 


On Fri, Jun 4, 2021 at 2:57 AM Peter Löwe <peter.lo...@gmx.de> wrote:








==> the CodeMeta-Project is currenlty pushing software citation standards: https://codemeta.github.io/








 

Thanks. The roles there seem to be more clear. Any opinion on CodeMata versus CFF (see also below)?

 








 


BTW, ways to retro-provide DOI versioning for previous GRASS releases would be an rewarding topic to discuss with Data Cite (the DOI infrastructure community).




 

Any opinions on how useful this is? We want a good archive of old versions, but does someone need DOIs for old releases?

 

==> This depends on wether the community wants to give due credit by citation to the persons which were involved in the previous releases.








 

Currently, the author list maintained in the source code is cumulative as far as I know, so old authors are still included as authors, so only use cases for that would be citing old releases in paper or by the new versions of software software. None seem likely to me. What do you think?

 











 




Any suggestions on includings DOI into source code? It seems to me that you can only use the generic/concept one and tell people to get the recent one. I didn't figure out the DOI reservation for GitHub repos.








 

Rather than where to put it - although that's important, too - my question is about which DOI? The main one everywhere or somehow try to put there the version specific one if that's even possible. It seems to me that the main DOI is the only feasible option.

 








==> A JSON file could be included. This way, the information is both readable for humans and automated access: https://codemeta.github.io/codemeta-generator/ 








 

I was thinking about the Citation File Format as I have seen it used quite a bit. Any opinions on that?

 






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


Re: [GRASS-dev] [release planning] Enable Zenodo before 7.8.6 and 8.0.0

2021-06-07 Thread Peter Löwe
Hi Vaclav, all,

 

I would advise to include both a CFF _and_ a Codemeta linked data json file.

 

Reason: CFF is a front-end format, while codemeta-json is a back-end format. The linked data file can be automatically created from the initial CFF.

 

CFF is the right format for the initial provision of the software citation metadata. In a follow up-step its content should be included as a codemeta.json file as linked data into the machine-actioned downstream citation workflow. This allows to translate the metadata into multiple software metadata dialects (https://codemeta.github.io/crosswalk/).

The codemeta.json will also be recognized and used by the Zenodo hooks as part of the DOI-publication process.

 

The CFF should be created first (generator here: https://citation-file-format.github.io/cff-initializer-_javascript_/).

A codemeta.json file can be derived from the CCF by a converter: https://github.com/citation-file-format/cff-converter-python or https://pypi.org/project/cffconvert/

 

For the DOI, I believe there should be (at least) one central DOI for the "general concept" of GRASS GIS. There can be additional GRASS-GIS-releated DOIs (later) for specific releases/versions. 

 

Best,

peter

 

 



 
 

Gesendet: Sonntag, 06. Juni 2021 um 05:33 Uhr
Von: "Vaclav Petras" 
An: "Peter Löwe" 
Cc: "grass-dev@lists.osgeo.org" 
Betreff: Re: Re: [release planning] Enable Zenodo before 7.8.6 and 8.0.0



Hi Peter, all, thanks for the answers. I have more questions assuming that's okay.
 


On Fri, Jun 4, 2021 at 2:57 AM Peter Löwe <peter.lo...@gmx.de> wrote:








==> the CodeMeta-Project is currenlty pushing software citation standards: https://codemeta.github.io/








 

Thanks. The roles there seem to be more clear. Any opinion on CodeMata versus CFF (see also below)?

 








 


BTW, ways to retro-provide DOI versioning for previous GRASS releases would be an rewarding topic to discuss with Data Cite (the DOI infrastructure community).




 

Any opinions on how useful this is? We want a good archive of old versions, but does someone need DOIs for old releases?

 

==> This depends on wether the community wants to give due credit by citation to the persons which were involved in the previous releases.








 

Currently, the author list maintained in the source code is cumulative as far as I know, so old authors are still included as authors, so only use cases for that would be citing old releases in paper or by the new versions of software software. None seem likely to me. What do you think?

 











 




Any suggestions on includings DOI into source code? It seems to me that you can only use the generic/concept one and tell people to get the recent one. I didn't figure out the DOI reservation for GitHub repos.








 

Rather than where to put it - although that's important, too - my question is about which DOI? The main one everywhere or somehow try to put there the version specific one if that's even possible. It seems to me that the main DOI is the only feasible option.

 








==> A JSON file could be included. This way, the information is both readable for humans and automated access: https://codemeta.github.io/codemeta-generator/ 








 

I was thinking about the Citation File Format as I have seen it used quite a bit. Any opinions on that?

 






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


Re: [GRASS-dev] [release planning] Enable Zenodo before 7.8.6 and 8.0.0

2021-06-04 Thread Peter Löwe
Hi Vaclav, all,

 

answers are included below.

 

Best,

Peter



Gesendet: Montag, 31. Mai 2021 um 21:23 Uhr
Von: "Vaclav Petras" 
An: "grass-dev@lists.osgeo.org" , "Peter Löwe" 
Betreff: Re: [release planning] Enable Zenodo before 7.8.6 and 8.0.0


Peter,

 


On Tue, May 25, 2021 at 8:30 AM Peter Löwe <peter.lo...@gmx.de> wrote:




 

 

The MOSS project minted its first DOI as a proof concept in the process of becoming a OSGeo heritage project (https://zenodo.org/record/4719685#.YKzpGKgzaUk). For this, we used stakeholders roles according to MARC21 like the R project does: https://journal.r-project.org/archive/2012-1/RJournal_2012-1_Hornik~et~al.pdf




 

Are there any good alternatives or more recent documents for that?

 

 

==> the CodeMeta-Project is currenlty pushing software citation standards: https://codemeta.github.io/

 

 




 

BTW, ways to retro-provide DOI versioning for previous GRASS releases would be an rewarding topic to discuss with Data Cite (the DOI infrastructure community).




 

Any opinions on how useful this is? We want a good archive of old versions, but does someone need DOIs for old releases?

 

==> This depends on wether the community wants to give due credit by citation to the persons which were involved in the previous releases.

 

 




DOI for software versioning is is still a developing topic. Feedback from the GRASS community would be valuable to push this forward.




 

Right. Any suggestions on includings DOI into source code? It seems to me that you can only use the generic/concept one and tell people to get the recent one. I didn't figure out the DOI reservation for GitHub repos.

 

==> A JSON file could be included. This way, the information is both readable for humans and automated access: https://codemeta.github.io/codemeta-generator/ 

 

Vaclav




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


Re: [GRASS-dev] [release planning] Enable Zenodo before 7.8.6 and 8.0.0

2021-05-25 Thread Peter Löwe
Hi Vaclav, all,

 

it's great to hear that the GRASS project is about to embrace DOI and long term archiving by Zenodo.
 

The MOSS project minted its first DOI as a proof concept in the process of becoming a OSGeo heritage project (https://zenodo.org/record/4719685#.YKzpGKgzaUk). For this, we used stakeholders roles according to MARC21 like the R project does: https://journal.r-project.org/archive/2012-1/RJournal_2012-1_Hornik~et~al.pdf

 

BTW, ways to retro-provide DOI versioning for previous GRASS releases would be an rewarding topic to discuss with Data Cite (the DOI infrastructure community). DOI for software versioning is is still a developing topic. Feedback from the GRASS community would be valuable to push this forward.

 

Best,

Peter

 



 
 

Gesendet: Montag, 24. Mai 2021 um 04:08 Uhr
Von: "Vaclav Petras" 
An: "grass-dev@lists.osgeo.org" 
Cc: "Peter Löwe" 
Betreff: [release planning] Enable Zenodo before 7.8.6 and 8.0.0



Hi all,

 

Let's enable the Zenodo link before 7.8.6 and 8.0(.0?) releases to get DOIs and Zenodo records.

 

Solving the whole DOI linking and Zenodo archiving for the old versions may be complex [1], but enabling the link between GitHub and Zenodo is trivial (one click) and every newly created GitHub release (we do those) will be automatically registered and receive DOI.

 

Zenodo uses a system of DOI versions and a main DOI (Concept DOI). Whether it is an ideal system, that's a question, but it is currently the expected one since it is the same for everything on Zenodo. It is used automatically when using the GitHub-Zenodo integration.

 

It seems I have the permissions to enable it for GRASS GIS. The one who enables that becomes a maintainer of it. I'm fine with that, but I won't be uploading any older versions. The maintainer can be changed later by contacting Zenodo support [2].

 

Although there are things to figure out in terms of next steps, I don't see much risk in enabling it. There are no choices available in the setup or in terms of alternatives. DOI and some kind of registration are expected more and more.

 

Thoughts?

 

Vaclav

 

[1] https://grasswiki.osgeo.org/wiki/GitHub-Zenodo_linkage

[2] https://github.com/zenodo/zenodo/issues/826





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


[GRASS-dev] Statement Peter Loewe

2021-01-15 Thread Peter Löwe

Hello GRASS community,

 

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

 

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

 

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

 

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

 

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

 

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

 

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


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

 

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

 

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

 

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

 

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

 

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

 

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

 

Best,

Peter

 

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

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

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

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

 




 

 


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


[GRASS-dev] Compiling GRASS 7.4.2: Issues with FFTW3 / gmath and shared|static libraries

2018-08-07 Thread Peter Löwe
Hello list,

I have run into a problem when compiling GRASS GIS 7.4. on a Cluster (SUSE 
Linux Enterprise Server-based) as a user (non-root): The issue is connected to 
FFTW for gmath when building GRASS with shared libraries. It disappears when 
using static libraries, which causes other side effects.  

Several required tools were successfully built and installed locally (gdal, 
geos, netcdf, sqlite and fftw).

This is the current configuration - for shared libraries


GRASS is now configured for:  x86_64-pc-linux-gnu

  Source directory:   
/projekte/ploewe/projects/localgrass/grass74_release
  Build directory:
/projekte/ploewe/projects/localgrass/grass74_release
  Installation directory: ${prefix}/grass-7.4.2svn
  Startup script in directory:${exec_prefix}/bin
  C compiler: gcc -g -O2
  C++ compiler:   c++ -g -O2
  Building shared libraries:  yes
  OpenGL platform:none

  MacOSX application: no
  MacOSX architectures:
  MacOSX SDK:

  BLAS support:   yes
  BZIP2 support:  no
  C++ support:yes
  Cairo support:  no
  DWG support:no
  FFTW support:   yes
  FreeType support:   no
  GDAL support:   yes
  GEOS support:   yes
  LAPACK support: no
  Large File support (LFS):   yes
  libLAS support: no
  MySQL support:  no
  NetCDF support: yes
  NLS support:no
  ODBC support:   no
  OGR support:yes
  OpenCL support: no
  OpenGL support: no
  OpenMP support: no
  PDAL support:   no
  PNG support:no
  POSIX thread support:   no
  PostgreSQL support: no
  Readline support:   yes
  Regex support:  yes
  SQLite support: yes
  TIFF support:   yes
  X11 support:no


Make fails on this configuration as gmath breaks. Running make in the gmath 
director fails with this error: "relocation R_X86_64_32S against `.rodata' can 
not be used when making a shared object; recompile with -fPIC" 

Running make CFLAGS="-fPIC" in the gmath directory didn't help.

Strangely, changing the GRASS configure script to static libaries fixes the 
issue, while new issues seem to appear (CTYPES can't be created).

Any advice on the initial FFTW-related issue would be much appreciated.

best,
Peter L.


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

Re: [GRASS-dev] grass gis story movie

2014-07-15 Thread Peter Löwe
Hi Martin,

the GRASS GIS Story has already been uploaded by someone to Youtube 
(https://www.youtube.com/watch?v=U3Hf0qI4JLc). Uploading it a second time won't 
do harm, but neither will solve some Youtube-related issues:

Youtube does not allow for advanced search queries on the movies' content: The 
version already available on Youtube can _not_ be found by the search queries 
like GRASS GIS William Shatner. Further, there is no proper way to _cite_ the 
movie in a publication. In my feeling the movie has already become a historical 
document for the OSGeo community. In the sense of information preservation it 
would be good to have a version which long time preserved, citable and fully 
searchable.

In this vein, an upcoming presentation at FOSS4G 2014 in Portland (Scientific 
Track) will be of interest: GRASS GIS, Star Trek and old Video Tape – a 
reference case on audiovisual preservation for the OSGeo communities :-)

Best,
Peter




Hi,

any obstacle to upload GRASS GIS Story movie [1] (takes to much time
to load and play) to youtube?

Martin

[1] 
http://grass.osgeo.org/HostedVideoAlbums/video/GRASS-History-The-GRASS-Story/15/



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

Re: [GRASS-dev] v.in.ogr: how to force sqlite instead of dbf for output location ? SEG-Y input (Geology/Seismic Data)

2013-09-26 Thread Peter Löwe
Hamish,

  When trying to ingest SEG-Y data (geology/seismics) into a
  new location via v.in.ogr (GDAL 1.9.0) this error is thrown
 
 can I ask what part of it you are trying to load? The actual trace
 data (time vs amplitude) or to extract the navigation data for
 source, receiver, or CDP?

Thanks for your advice!

I'm evaluating the SEG-Y formate to exchange data between software packages 
from the exploration industry like Petrel and Gocad and GRASS. So far only demo 
data sets are used. I will inquire wether P1/90 is also available. 

Peter
peter.lo...@gmx.de

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


[GRASS-dev] v.in.ogr: how to force sqlite instead of dbf for output location ? SEG-Y input (Geology/Seismic Data)

2013-09-25 Thread Peter Löwe
Hi list,

I'm using GRASS6.4.2 on a Suse-based HPC Cluster.

When trying to ingest SEG-Y data (geology/seismics) into a new location via 
v.in.ogr (GDAL 1.9.0) this error is thrown since the new location is set by 
default (?) to dbf:

GRASS 6.4.2 (startup_sqlite):~/geodata/petrel/SEG_Y_Demo  v.in.ogr 
dsn=demo20071121142735_CH1_35P.seg output=seg_y_test location=segy_sqlite
Layer: demo20071121142735_CH1_35P
WARNING: Default driver / database set to:
 driver: dbf
 database: $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/
WARNING: Column type not supported (SAMPLE_ARRAY)
WARNING: DBMI-DBF driver: column name 'TRACE_NUMBER_WITHIN_LINE' truncated
 to 'TRACE_NUMB'
WARNING: DBMI-DBF driver: column name 'TRACE_NUMBER_WITHIN_FILE' truncated
 to 'TRACE_NUMB'
DBMI-DBF driver error:
Column 'TRACE_NUMB' already exists (duplicate name)
Cannot create table.
Error in db_execute_immediate()

ERROR: Unable to create table: 'create table seg_y_test_1 (cat integer,
   TRACE_NUMBER_WITHIN_LINE integer, TRACE_NUMBER_WITHIN_FILE integer,
   ORIGINAL_FIELD_RECORD_NUMBER integer,
   TRACE_NUMBER_WITHIN_ORIGINAL_FIELD_RECORD integer,
   TRACE_IDENTIFICATION_CODE integer, ENSEMBLE_NUMBER integer,
   TRACE_NUMBER_WITHIN_ENSEMBLE integer, NUMBER_VERTICAL_SUMMED_TRACES
   integer, NUMBER_HORIZONTAL_STACKED_TRACES integer, DATA_USE integer,
   DISTANCE_SOURCE_GROUP integer, RECEIVER_GROUP_ELEVATION integer,
   SURFACE_ELEVATION_AT_SOURCE integer, SOURCE_DEPTH_BELOW_SURFACE
   integer, DATUM_ELEVATION_AT_RECEIVER_GROUP integer,
   DATUM_ELEVATION_AT_SOURCE integer, WATER_DEPTH_AT_SOURCE integer,
   WATER_DEPTH_AT_GROUP integer, VERTICAL_SCALAR integer,
   HORIZONTAL_SCALAR integer, SOURCE_X integer, SOURCE_Y integer,
   GROUP_X integer, GROUP_Y integer, COORDINATE_UNITS integer,
   WEATHERING_VELOCITY integer, SUB_WEATHERING_VELOCITY integer,
   UPHOLE_TIME_AT_SOURCE integer, UPHOLE_TIME_AT_GROUP integer,
   SOURCE_STATIC_CORRECTION integer, GROUP_STATIC_CORRECTION integer,
   TOTAL_STATIC_CORRECTION integer, LAG_TIME_A integer, LAG_TIME_B
   integer, DELAY_RECORDING_TIME integer, MUTE_TIME_START integer,
   MUTE_TIME_END integer, SAMPLES integer, SAMPLE_INTERVAL integer,
   GAIN_TYPE integer, INSTRUMENT_GAIN_CONSTANT integer,
   INSTRUMENT_INITIAL_GAIN integer, CORRELATED integer,
   SWEEP_FREQUENCY_AT_START integer, SWEEP_FREQUENCY_AT_END integer,
   SWEEP_LENGTH integer, SWEEP_TYPE integer,
   SWEEP_TRACE_TAPER_LENGTH_AT_START integer,
   SWEEP_TRACE_TAPER_LENGTH_AT_END integer, TAPER_TYPE integer,
   ALIAS_FILTER_FREQUENCY integer, ALIAS_FILTER_SLOPE integer,
   NOTCH_FILTER_FREQUENCY integer, NOTCH_FILTER_SLOPE integer,
   LOW_CUT_FREQUENCY integer, HIGH_CUT_FREQUENCY integer, LOW_CUT_SLOPE
   integer, HIGH_CUT_SLOPE integer, YEAR integer, DAY_OF_YEAR integer,
   HOUR integer, MINUTE integer, SECOND integer, TIME_BASIC_CODE
   integer, TRACE_WEIGHTING_FACTOR integer,
   GEOPHONE_GROUP_NUMBER_OF_ROLL_SWITH integer,
   GEOPHONE_GROUP_NUMBER_OF_TRACE_NUMBER_ONE integer,
   GEOPHONE_GROUP_NUMBER_OF_LAST_TRACE integer, GAP_SIZE integer,
   OVER_TRAVEL integer)'

The initial location from which v.in.ogr was invoked was already switched to a 
sqlite-backend. How can this issue be overcome ?

- I'm no SEG Y guru, so having v.in.ogr infer the settings for the resulting 
target location would be required. 

Cheers,
Peter 

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


[GRASS-dev] Applying map projections for layer rendering

2013-01-08 Thread Peter Löwe
Hi,

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

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

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


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





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

[GRASS-dev] i.atcorr @ GRASS6.4 using RapidEye: strange output

2012-08-14 Thread Peter Löwe
Hi,

I'm reporting again on the mixed performance of i.atcorr for RapidEye satellite 
data in GRASS6.4.2 on SuSE.

In a test case RapidEye satellite data for the Spearfish,SD demo site is used.

Rapideye data comes in 16bit. 

The value ranges (digital numbers) for the first three bands are:
red: [1286 - 58603]
green: [2464 - 54248]
blue: [4069-56975]

So two variants were tried:

Variant A) Using r.rescale to scale the data down to 8 bit

Example [red band]:
i.atcorr iimg=spearfish_3.255.rad iscl=0,255 oscl=0,255 
icnd=re_20100509_3.atcorr_20120814 oimg=spearfish_3.255.rad.atcorr_20120814 --o

The output map consists mostly of zeroes and NULLs with a few 1s and 2s for 
both red and blue band. i.atcorr-ing the green band returns just NULLs.

Variant B) i.atcorrs iscl-option is used to provide the 16bit data range for 
each band.

Example [red band]:
i.atcorr iimg=spearfish_3 iscl=1286,58603 oscl=0,255 
icnd=re_20100509_3.atcorr_20120814 
oimg=spearfish_3.atcorr_test1_1286-58603_0-255 --o

Now the results for the red band seem reasonable, the results for the blue band 
look like a salt and pepper pattern and the green band again goes NULL.

Ideas, anyone ? Does this kind of behaviour also occur for other sensors ?

Best,
Peter
 


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





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

Re: [GRASS-dev] Please update: List of new features in GRASS 7 (trac Wiki)

2012-08-13 Thread Peter Löwe
List of new features in GRASS 7
http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures

Luckily we have tons of news :)

Do we yet have a comparison table on those GRASS modules whose options/flags 
were renamed or extended between G6.4 and G7.0, in an previously - now - 
fashion ?

Such a chart would be *really* useful for people having to port scripted 
GRASS-workflows from G6.4 to G7.0 !

Best,
Peter


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





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

Re: [GRASS-dev] NVIZ Error: Error of failed request: BadWindow

2011-03-22 Thread Peter Löwe
Hi Maris,


export LIBGL_ALWAYS_INDIRECT=1

did the trick.

Thanks,
Peter

 Original-Nachricht 
 Datum: Fri, 18 Mar 2011 17:41:24 +0200
 Von: Maris Nartiss maris@gmail.com
 An: peter.lo...@gmx.de
 CC: grass-dev@lists.osgeo.org
 Betreff: Re: [GRASS-dev] NVIZ Error: Error of failed request: BadWindow

 glxgears working fine?
 OpenGL system vs NVIZ/OGSF compiled in OpenGL system?
 export LIBGL_ALWAYS_INDIRECT=1  nviz ?
 
 Maris.
 
 
 2011/3/18, peter.lo...@gmx.de peter.lo...@gmx.de:
  Hi all,
  I am building GRASS6.4 from source on a computation cluster. GRASS
 itself is
  up and running, but NVIZ causes trouble:
 
  When invoking NVIZ from the GRASS command line (nviz -q), the NVIZ
 command
  window pops up and throws this error message:
 
  Error of failed request:  BadWindow (invalid Window parameter)
Major opcode of failed request:  3 (X_GetWindowAttributes)
Resource id in failed request:  0x
Serial number of failed request:  237
Current serial number in output stream:  238
 
  Any help/comment/advice would be much appreciated.

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





NEU: FreePhone - kostenlos mobil telefonieren und surfen!   
Jetzt informieren: http://www.gmx.net/de/go/freephone
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev


[GRASS-dev] Re: [GRASS GIS] #377: gis.m/Map Display fails to handle vector layers with multiple databse layers

2008-11-24 Thread Peter Löwe
 Original-Nachricht 
 Datum: Fri, 21 Nov 2008 15:35:45 -
 Von: GRASS GIS [EMAIL PROTECTED]
 An: 
 Betreff: Re: [GRASS GIS] #377: gis.m/Map Display fails to handle vector 
 layers with multiple databse layers

 #377: gis.m/Map Display fails to handle vector layers with multiple
 databse
 layers
 -+--
   Reporter:  ploewe  |   Owner:  grass-dev@lists.osgeo.org
   Type:  defect  |  Status:  new  
   Priority:  major   |   Milestone:  6.4.0
  Component:  Tcl | Version:  6.3.0
 Resolution:  |Keywords:  gis.m database query 
   Platform:  Linux   | Cpu:  x86-32   
 -+--
 Comment (by mlennert):
 
  Replying to [ticket:377 ploewe]:
   GRASS 6.3 gives strange effects when one is attempting to query or
  display data from database layers greater than 1. This can be reproduced.
  
   Example:
  
   A polygon layer has been connected (in postgres) to two tables in layer
  1 and layer 2:
  
   GRASS 6.3.0 (meteo):~  v.db.connect -p map=counties_pie01
   Vector map counties_pie01 is connected by:
   layer 1 table counties_pie01 in database
  host=localhost,dbname=meteo through driver pg with key cat
   layer 2 table counties_pie01_a in database
  host=localhost,dbname=meteo through driver pg with key cat
 
  Could you give us the output of v.category option=report ?

v.category input=counties_pie01 option=report layer=1
Layer / table: 1 / counties_pie01
type   countminmax
point  0  0  0
line   0  0  0
boundary   0  0  0
centroid 558  1439
area   0  0  0
all  558  1439

v.category input=counties_pie01 option=report layer=2
type   countminmax
point  0  0  0
line   0  0  0
boundary   0  0  0
centroid 558  1439
area   0  0  0
all  558  1439


HTH,
Peter

 
  Moritz
 
 -- 
 Ticket URL: http://trac.osgeo.org/grass/ticket/377#comment:1
 GRASS GIS http://grass.osgeo.org

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





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