Re: [GRASS-dev] [release planning] GRASS GIS 8.3.2
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
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
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
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
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
+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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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)
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
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
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)
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
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
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