Re: [GRASS-dev] An applicant for GSoC 2024
Chung-Yuan, Please check my comment in the PR. Thanks, Huidae On Fri, Apr 12, 2024 at 11:11 PM Chung-Yuan Liang wrote: > Hello Prof. Cho, > > I just submitted a pull request to address issue #2644 > <https://github.com/OSGeo/grass/issues/2644>. I spent some time > familiarizing myself with the source code of Grass GIS. I hope I am on the > right track. If you have any comments or suggestions, please feel free to > let me know. Thanks a lot! > > Best, > > Chung-Yuan > > On Mon, Apr 1, 2024 at 10:20 PM Huidae Cho wrote: > >> Hi Chung-Yuan, >> >> I'm glad that you're interested in this parallelization project. FYI, the >> deadline for your application is April 2, 18:00 UTC (2pm tomorrow your time >> in EDT). Please check this feature request at >> https://github.com/OSGeo/grass/issues/2644 for testing your skills and >> let me know if you have any questions. >> >> Thanks, >> Huidae >> >> On Mon, Apr 1, 2024 at 8:07 PM Chung-Yuan Liang via grass-dev < >> grass-dev@lists.osgeo.org> wrote: >> >>> Dear OSGeo Community, >>> >>> My name is Chung-Yuan Liang. I am a Ph.D. candidate working with Prof. >>> Venkatesh Merwade in Civil Engineering at Purdue University. Concurrently, >>> I am also studying for a Master's degree in Computer Engineering. My >>> research focuses on processing geospatial data and developing deep learning >>> models for hydraulic and hydrologic modeling. I am particularly interested >>> in employing high-performance computing and machine learning to advance >>> geospatial applications and research. >>> >>> Last week, at the AWRA 2024 GWTC conference, I met Prof. Huidae Cho, who >>> introduced me to the Google Summer of Code (GSoC) program. Inspired by our >>> conversation, I am writing to express my interest in contributing to the >>> OSGeo community through the GSoC project. I am particularly drawn to the >>> project titled "Parallelization of Existing Tools," which Prof. Cho is >>> mentoring. >>> >>> Upon reviewing the issues and repositories of GRASS GIS, I had some >>> preliminary ideas on parallelizing tools. My project proposal outlines the >>> concepts and details of these ideas. I am sharing my proposal and would >>> greatly appreciate any feedback or suggestions. >>> >>> Here is this link to my proposal: >>> https://docs.google.com/document/d/13u0VCHXv8E_KCaDZgKPZHUC8wLe6lSpP/edit?usp=sharing&ouid=102824000057712244948&rtpof=true&sd=true >>> >>> I look forward to contributing to the OSGeo community. Thank you very >>> much for your time and assistance. >>> >>> Sincerely, >>> >>> Chung-Yuan Liang >>> ___ >>> grass-dev mailing list >>> grass-dev@lists.osgeo.org >>> https://lists.osgeo.org/mailman/listinfo/grass-dev >>> >> >> >> -- >> Huidae Cho, Ph.D., GISP, /hidɛ <http://ipa-reader.xyz/?text=hid%C9%9B> >> t͡ɕo/, 조희대, 曺喜大 >> GRASS GIS Developer >> https://idea.isnew.info/ >> > -- Huidae Cho, Ph.D., GISP, /hidɛ <http://ipa-reader.xyz/?text=hid%C9%9B> t͡ɕo/, 조희대, 曺喜大 GRASS GIS Developer https://idea.isnew.info/ ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] An applicant for GSoC 2024
Hi Chung-Yuan, I'm glad that you're interested in this parallelization project. FYI, the deadline for your application is April 2, 18:00 UTC (2pm tomorrow your time in EDT). Please check this feature request at https://github.com/OSGeo/grass/issues/2644 for testing your skills and let me know if you have any questions. Thanks, Huidae On Mon, Apr 1, 2024 at 8:07 PM Chung-Yuan Liang via grass-dev < grass-dev@lists.osgeo.org> wrote: > Dear OSGeo Community, > > My name is Chung-Yuan Liang. I am a Ph.D. candidate working with Prof. > Venkatesh Merwade in Civil Engineering at Purdue University. Concurrently, > I am also studying for a Master's degree in Computer Engineering. My > research focuses on processing geospatial data and developing deep learning > models for hydraulic and hydrologic modeling. I am particularly interested > in employing high-performance computing and machine learning to advance > geospatial applications and research. > > Last week, at the AWRA 2024 GWTC conference, I met Prof. Huidae Cho, who > introduced me to the Google Summer of Code (GSoC) program. Inspired by our > conversation, I am writing to express my interest in contributing to the > OSGeo community through the GSoC project. I am particularly drawn to the > project titled "Parallelization of Existing Tools," which Prof. Cho is > mentoring. > > Upon reviewing the issues and repositories of GRASS GIS, I had some > preliminary ideas on parallelizing tools. My project proposal outlines the > concepts and details of these ideas. I am sharing my proposal and would > greatly appreciate any feedback or suggestions. > > Here is this link to my proposal: > https://docs.google.com/document/d/13u0VCHXv8E_KCaDZgKPZHUC8wLe6lSpP/edit?usp=sharing&ouid=10282457712244948&rtpof=true&sd=true > > I look forward to contributing to the OSGeo community. Thank you very much > for your time and assistance. > > Sincerely, > > Chung-Yuan Liang > ___________ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev > -- Huidae Cho, Ph.D., GISP, /hidɛ <http://ipa-reader.xyz/?text=hid%C9%9B> t͡ɕo/, 조희대, 曺喜大 GRASS GIS Developer https://idea.isnew.info/ ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] [EXTERNAL] vector patching frustration
All, Please review https://github.com/OSGeo/grass/pull/3508. It should fix non-continuous cats. Thanks, Huidae On Fri, Mar 15, 2024 at 10:37 AM Vincent Bain via grass-user < grass-u...@lists.osgeo.org> wrote: > Michael, Huidae > > thats's what I was just about to post... you need to care cats > intervals don't overlap before patching. > > With the attached set of 2 vector maps you can have a try, typing : > > v.in.ogr input=/your/path/to/map1.gpkg output=map1 > v.in.ogr input=/your/path/to/map2.gpkg output=map2 > v.category input=map1 type=centroid option=report > v.category input=map2 type=centroid option=report > # Cats overlap, so : > v.category --overwrite input=map2 type=centroid output=map200 > option=sum cat=100 > v.patch --overwrite input=map1,map200 output=map12 > v.patch -e --overwrite input=map1,map200 output=map12 > > Yours, > V. > > Le vendredi 15 mars 2024 à 09:51 -0600, Huidae Cho a écrit : > > Michael, > > > > Just confirmed your issue. > > > > v.random tmp100 npoints=100 seed=100 > > v.db.addtable tmp100 col="id varchar(20)" > > v.db.update tmp100 col=id qcol="'tmp100_' || cat" > > > > v.random tmp10 npoints=10 seed=10 > > v.db.addtable tmp10 col="id varchar(20)" > > v.db.update tmp10 col=id qcol="'tmp10_' || cat" > > > > v.patch tmp100,tmp10 out=tmp110 -e > > > > v.category tmp110 op=report > > Layer/table: 1/tmp110 > > type countminmax > > point110 2112 > > line 0 0 0 > > boundary 0 0 0 > > centroid 0 0 0 > > area 0 0 0 > > face 0 0 0 > > kernel 0 0 0 > > all 110 2112 > > > > In my case, all features in tmp10 are linked in tmp110. > > > > You can recategorize it. > > > > v.category tmp110 out=tmp110_nocats op=del cat=-1 > > v.category tmp110_nocats out=tmp110_recats op=add > > > > npnts100=$(v.info tmp100 -t | sed '/points=/!d; s/points=//') > > npnts10=$(v.info tmp10 -t | sed '/points=/!d; s/points=//') > > > > v.db.update tmp110_recats col=cat qcol=cat-1 where="cat<=$npnts100+1" > > v.db.update tmp110_recats col=cat qcol=cat-2 where="cat>$npnts100+1" > > > > Yeah... I know what you may think... Please create an issue on > > GitHub. > > > > Regards, > > Huidae > > > > On Thu, Mar 14, 2024 at 4:42 PM Michael Barton via grass-dev > > wrote: > > > Thanks Doug and Vincent. > > > > > > None of this works. I vaguely remember having this same kind of > > > road block several years back. > > > > > > Nothing in v.category lets you change an existing cat value to a > > > different value > > > v.in.ogr MUST add a column that MUST be named cat (all else causes > > > an error--this is a bug) that is a series of consecutive integers > > > from 1-n. So I cannot create a file with a cat field that matches > > > my vector areas. > > > > > > v.edit won't let you change an existing cat number AFAICT. No error > > > but nothing changes. > > > > > > Once I've imported a table using v.in.ogr, I cannot use > > > db.drop.column to delete the cat column--even if it is not being > > > used as a key field. This raises an error. > > > > > > No way to rename a column from cat to something else (or something > > > else to cat) unless you've already connected it to a vector map > > > even if cat is not the key field. So I can't create an integer > > > column to link up my lost vector area with a record in my csv > > > file. > > > > > > This simple task is just not possible in GRASS AFAICT. Or if it is > > > possible, it can only be done by such non-obvious and convoluted > > > means that I've yet to find a method that works in spite of asking > > > a large number of very skilled GRASS users. > > > > > > Michael > > > _ > > > C. Michael Barton > > > Associate Director, School of Complex Adaptive > > > Systems (https://scas.asu.edu) > > > Professor, School of Human Evolution & Social > > > Change (https://shesc.asu.edu) > > > Director, Center for Social Dynamics & > > > Complexity (https://complexity.asu.edu) > > &g
Re: [GRASS-dev] [EXTERNAL] vector patching frustration
ribute table, I indeed see line and cat 155. But it is > not linked with the patched area--which has been assigned a cat=183 for > reasons I cannot fathom. The patch also renumbers my cat field to cat=2-155 > from the original 1-154. > > This has been made more complicated by the fact that v.in.ogr imports all > columns of a *.csv as text, regardless of what is in them and assigns cat > numbers starting at 1. So I can't specify an integer key field of 155 to > try the linking. Nor can I change the assigned cat of the single area I am > trying to patch from 1 to 155 using v.category (or anything else I can > find). > > I'm hoping that someone has a clever solution that I've not seen or I'll > just have to do this fairly simple and straightforward vector operation in > QGIS. > > Michael > _ > C. Michael Barton > Associate Director, School of Complex Adaptive Systems ( > https://scas.asu.edu) > Professor, School of Human Evolution & Social Change ( > https://shesc.asu.edu) > Director, Center for Social Dynamics & Complexity ( > https://complexity.asu.edu) > Arizona State University > Tempe, AZ 85287-2701 > USA > > Executive Director, Open Modeling Foundation ( > https://openmodelingfoundation.github.io > <https://urldefense.com/v3/__https://openmodelingfoundation.github.io/__;!!IKRxdwAv5BmarQ!dv7XjZX6-VnNpFbpXP6R1XYWkuaA4Y-gDR4RvL3bWazWUkLfURuKDMWqiBFqBS6jlNSHDKZCo02GJKjauaAJ-pCVvuAToIA$> > ) > Director, Network for Computational Modeling in Social & Ecological > Sciences (https://comses.net > <https://urldefense.com/v3/__https://comses.net/__;!!IKRxdwAv5BmarQ!dv7XjZX6-VnNpFbpXP6R1XYWkuaA4Y-gDR4RvL3bWazWUkLfURuKDMWqiBFqBS6jlNSHDKZCo02GJKjauaAJ-pCVdW6V-z8$> > ) > > personal website: http://www.public.asu.edu/~cmbarton > > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev > -- Huidae Cho, Ph.D., GISP, /hidɛ <http://ipa-reader.xyz/?text=hid%C9%9B> t͡ɕo/, 조희대, 曺喜大 GRASS GIS Developer https://idea.isnew.info/ ___ 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
+1 Huidae -- Huidae Cho, Ph.D., GISP GRASS GIS Developer https://idea.isnew.info/ Sent from my phone On Wed, Mar 6, 2024, 8:17 AM Anna Petrášová via grass-dev < grass-dev@lists.osgeo.org> wrote: > +1 > > Anna > > On Wed, Mar 6, 2024 at 9:54 AM Martin Landa > wrote: > >> Hi Markus, >> >> I'd now move on and publish GRASS GIS 8.3.2 unless there are objections >>> >> >> +1 >> >> Martin >> >> Markus >>> >>> -- >>> Markus Neteler, PhD >>> https://www.mundialis.de - company >>> https://grass.osgeo.org - FOSS >>> https://neteler.org - freelancing & blog >>> ___ >>> grass-dev mailing list >>> grass-dev@lists.osgeo.org >>> https://lists.osgeo.org/mailman/listinfo/grass-dev >>> >> ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev > ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS Teams on GitHub
Ondrej, I agree with you that there are too many teams for GRASS [1] and they should be consolidated (or not, but at least moved) as child teams. Do we still need these subversion teams? * grass-subversion-committers <https://github.com/orgs/OSGeo/teams/grass-subversion-committers> GRASS GIS Subversion committers * grass-addons-subversion-committers <https://github.com/orgs/OSGeo/teams/grass-addons-subversion-committers> GRASS GIS Addons Subversion committers How is this team different from the above grass-addons-subversion-committers? * grass-addons-write <https://github.com/orgs/OSGeo/teams/grass-addons-write> Maintainers of tools in GRASS GIS Addons with write access to the repository How are these three teams different? * grass-admin <https://github.com/orgs/OSGeo/teams/grass-admin> GRASS GIS repo administration team * grass-maintain <https://github.com/orgs/OSGeo/teams/grass-maintain> GRASS GIS repo settings maintenance team * grass-write <https://github.com/orgs/OSGeo/teams/grass-write> Maintainers of GRASS GIS with write access to the main repository I think we need this team. * grass-docker-homebrew-users <https://github.com/orgs/OSGeo/teams/grass-docker-homebrew-users> Users for automated dockerhub and homebrew builds I believe we can consolidate these two teams. * grass-promo-write <https://github.com/orgs/OSGeo/teams/grass-promo-write> Contributors to GRASS GIS promo repo with write access * grass-website-write <https://github.com/orgs/OSGeo/teams/grass-website-write> Maintainers of GRASS GIS website What about these two? * grass-discussion-moderators <https://github.com/orgs/OSGeo/teams/grass-discussion-moderators> Discussion moderators with general Triage access * grass-triage <https://github.com/orgs/OSGeo/teams/grass-triage> Contributors with PR and issue triage power Best, Huidae [1] https://github.com/orgs/OSGeo/teams On Thu, Feb 22, 2024 at 1:35 AM Ondřej Pešek via grass-dev < grass-dev@lists.osgeo.org> wrote: > Sweet devs, > > Looking at the GitHub teams within the OSGeo organisation [1], it is > impossible not to notice the fact that the GRASS people are very good > in making themselves visible through visual weed infestation. On one > side, it is nice to see GRASS all over the dance floor; on the other > one, I don't find it particularly polite to storm the org and see that > GRASS owns 11 OSGEO's teams out of 24 in the overview (11 out of 26 in > total). > > Wouldn't it be better to follow the example of GDAL instead? Creating > only one master team (grass) and then 11 child teams (grass-write, > grass-addons-write, ...)? It would make the org team overview much > cleaner. Also, you could see all grass child teams' members in one > place. > > In the name of New GitHub Order, > Ondrej > > PS: I also believe that we should reduce the number of GRASS teams and > consolidate some (grass-addons-subversion-committers -> > grass-addons-write) but I guess this is for another and much more > contentious discussion. > _______ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev > -- Huidae Cho, Ph.D., GISP, /hidɛ <http://ipa-reader.xyz/?text=hid%C9%9B> t͡ɕo/, 조희대, 曺喜大 GRASS GIS Developer https://idea.isnew.info/ ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Contents for FOSS4G Asia 2023
Dear All, I'm currently working on slides for FOSS4G Asia 2023 next week. If I missed any important things, please let me know or feel free to create PRs. Any help would be appreciated! https://github.com/HuidaeCho/grass-gis-talk-foss4g-asia-2023 Best, Huidae -- Huidae Cho, Ph.D., GISP, /hidɛ <http://ipa-reader.xyz/?text=hid%C9%9B> t͡ɕo/, 조희대, 曺喜大 GRASS GIS Developer https://idea.isnew.info/ ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Candidate modules for OpenMP parallelization
Hi Anna, I'm not sure if these modules are "low hanging fruit" and even fairly parallelizable, but r.stats and r.watershed might be good candidates because r.stats is generic with no output rasters, and may be used a lot in different fields, and r.watershed calculates several important hydrologic rasters that are often used as input to other modules (i.e., as a first step for most hydrologic analyses based on my experience). Maybe, r.statistics as well? Since I now have access to HPC, I can help mentor him with some testing. Best, Huidae On Thu, Mar 30, 2023 at 9:42 AM Anna Petrášová wrote: > Hi devs, > > We have a GSoC candidate who would like to do OpenMP parallelization. I > could mentor, anybody else is interested? > > At this point, we need to figure out (at least tentatively) which modules > he could work on. After Aaron's work in GSoC 2021, there are not that many > modules left that could be described as "low hanging fruit". Do you have > any suggestions? > > The proposal is due very soon. > > Thanks, > Anna > -- Huidae Cho, Ph.D., GISP, /hidɛ <http://ipa-reader.xyz/?text=hid%C9%9B> t͡ɕo/, 조희대, 曺喜大 GRASS GIS Developer https://idea.isnew.info/ ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] Fwd: [OSGeo-Discuss] GSoC 2023: OSGeo Accepted as Mentor Organization | Form for Mentors
This is great news! Thanks for sharing it. Best, Huidae On Mon, Feb 27, 2023 at 4:47 AM Veronica Andreo wrote: > FYI :) > > -- Forwarded message - > De: Rahul Chauhan via Discuss > Date: dom, 26 feb 2023 a las 2:18 > Subject: [OSGeo-Discuss] GSoC 2023: OSGeo Accepted as Mentor Organization > | Form for Mentors > To: > Cc: , gsoc-adminosgeo.org , > Ashish Kumar > > > Dear All, > > We are happy and elated to announce that OSGeo has been accepted once > again as a mentor organization for GSoC 2023. > >1. The list of accepted organizations is at [0]. >Our OSGeo GSoC 2023 application is available at [1]. >2. Please note the Potential GSoC contributors (Student + >Professional) discuss application >ideas with the mentoring organizations from Feb 22 - March 19, 2023. So, be >ready to be flooded with queries by potential contributors in the coming >period. :-) >3. GSoC contributors will be able to register and submit their >applications from March 20 - April 4, 2023. All proposals must be >submitted by April 4, 2023, at 18:00 UTC. >4. *Mentors of the projects who have already updated their ideas in >the OSGeo GSoC 2023 ideas list, kindly fill out the Google Form [2] so that >we can start sending the invitations.* > > We still have time for more projects to participate with ideas [3]. > It is a good opportunity to: > • Add functionality to your projects. > • Attract more contributors participating in the projects, times they > become long-term contributors. > > OSGeo projects, Incubating projects, and community projects are welcome. > > *Note -* > If you are interested in joining the Organization Administration team and > have been involved with the OSGeo GSoC initiative in the past with rich > experience, please reach out to us. > > [0] https://summerofcode.withgoogle.com/programs/2023/organizations > [1] https://wiki.osgeo.org/wiki/Google_Summer_of_Code_Application_2023 > [2] https://forms.gle/LWBMgA8ToL3RyL5v6 > [3] https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2023_Ideas > > Stay tuned for further instructions on the next steps and be > prepared for another geospatial GSoC with OSGeo! > > Yours, > OSGeo GSoC Admins > ___ > Discuss mailing list > disc...@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/discuss > ___ > grass-user mailing list > grass-u...@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-user > -- Huidae Cho, Ph.D., GISP, /hidɛ <http://ipa-reader.xyz/?text=hid%C9%9B> t͡ɕo/, 조희대, 曺喜大 GRASS GIS Developer https://idea.isnew.info/ ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Transifex Migration to OSGeo Weblate for GRASS Translation
Dear GRASS GIS Translators, The GRASS GIS PSC decided to migrate our translation platform to OSGeo Weblate (https://weblate.osgeo.org/projects/grass-gis/) because this open-source (GPLv3+) tool provides a seamless integration with GitHub (e.g., aggregated auto-PR, auto-pull new messages, etc.) and is also sponsored and backed up daily by our mother organization, OSGeo. We already started using this platform (https://github.com/OSGeo/grass/pull/2271) and it is our best interest to avoid any merge conflicts in our future translation efforts. If you don't already have an OSGeo account, please follow these steps to get started: 1. Go to https://id.osgeo.org/ldap/create 2. Check Translate project and type GRASS GIS 3. Fill out your affiliation 4. Enter mantra: PLEASE CHECK https://www.transifex.com/grass-gis/teams/45198/discussions/2/ for this *secret* key (I guess ;-). Once your OSGeo account is set up, go to https://weblate.osgeo.org/projects/grass-gis/ to start translating on the new platform. Please let us know if you have any questions about this migration: https://lists.osgeo.org/mailman/listinfo/grass-translations Best Regards, Huidae -- Huidae Cho, Ph.D., GISP, /hidɛ <http://ipa-reader.xyz/?text=hid%C9%9B> t͡ɕo/, 조희대, 曺喜大 GRASS GIS Developer https://idea.isnew.info/ ___ 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.0.1
+1 Huidae On Thu, Feb 24, 2022 at 4:45 AM Martin Landa wrote: > Hi, > > čt 24. 2. 2022 v 10:36 odesílatel Markus Neteler > napsal: > > If there are no objectives, I'll prepare 8.0.1 final tonight. > > +1 Martin > > -- > Martin Landa > http://geo.fsv.cvut.cz/gwiki/Landa > http://gismentors.cz/mentors/landa > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev > -- Huidae Cho, Ph.D., GISP, /hidɛ <http://ipa-reader.xyz/?text=hid%C9%9B> t͡ɕo/, 조희대, 曺喜大 GRASS GIS Developer https://idea.isnew.info/ ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS + WSL
Hi Brad, I'm using GRASS under WSLackware (https://github.com/Mohsens22/WSLackware). For me, ximgview compiles fine. Maybe, it's a distribution issue? Best, Huidae On Wed, Feb 2, 2022 at 2:57 PM Brad ReDacted wrote: > Hello, > > It was suggested to me that I report to the list that GRASS almost fully > compiles and runs under Windows Subsystem for Linux (WSL). Everything > compiles except ximgview. > > For those who do not know what WSL is, it is sort of a hidden VM layer > addon for Windows with a custom kernel that allows Linux to run on Windows. > > I am using the Ubuntu WSL Preview on Windows 11 with WSL2. This > combination gives me full GUI without needing to run a separate X Server. > Graphics are accelerated (nvidia, in my case). I have not had a chance to > test everything, yet, but it does look promising. > > On Windows 10, you will need to run a separate middleware X Server to get > the GUI working until the next release of WSL. > > This may eventually replace the need for MinGW for the most recent > releases of Windows. I look forward to running performance benchmarks. > > It's linux, but it's on my Windows desktop! It's a bit surreal. > > Best Regards, > -Brad > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev > -- Huidae Cho, Ph.D., GISP, /hidɛ <http://ipa-reader.xyz/?text=hid%C9%9B> t͡ɕo/, 조희대, 曺喜大 GRASS GIS Developer https://idea.isnew.info/ ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-PSC] difficult to get GRASS source code package
+1 for ZIP links. Huidae On Mon, Feb 14, 2022 at 3:24 PM Jeff McKenna wrote: > On 2022-02-14 4:01 p.m., Veronica Andreo wrote: > > > > El lun, 14 feb 2022 a las 20:29, Vaclav Petras ( > <mailto:wenzesl...@gmail.com>>) escribió: > > > > > > On Mon, 14 Feb 2022 at 14:22, Veronica Andreo > <mailto:veroand...@gmail.com>> wrote: > > > > > > Currently, there's a link to releases in the first entry of > > https://grass.osgeo.org/download/ > > <https://grass.osgeo.org/download/> that points to > > https://github.com/OSGeo/grass/releases > > <https://github.com/OSGeo/grass/releases>. I agree that esp for > > 8.0.0 the link to the tarball means a lot of browsing down. > > > > > > Or instead of the releases page to that tags page I linked above. > > The links (both .tar.gz and .zip) are more readily available there. > > The target audience is technical anyway, so perhaps this is a > > preferred view at this point in the workflow. > > > > https://github.com/OSGeo/grass/tags > > <https://github.com/OSGeo/grass/tags> > > > > > > Here's the PR: https://github.com/OSGeo/grass-website/pull/284 > > <https://github.com/OSGeo/grass-website/pull/284> > > > > > > +1 to that change. > > By the way, one of my last interactions with Martin Isenburg (may his > soul rest in peace) he gave me a strong lecture when I tried to send him > a tarball "jeff it is 2021 please send me something useful like a ZIP". > He is totally right of course, and we should all remember to post > links to zip as well as .tar.gz etc on our main download pages. > > -jeff > > > > > > -- > Jeff McKenna > GatewayGeo: Developers of MS4W, MapServer Consulting and Training > co-founder of FOSS4G > http://gatewaygeo.com/ > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev > -- Huidae Cho, Ph.D., GISP, /hidɛ <http://ipa-reader.xyz/?text=hid%C9%9B> t͡ɕo/, 조희대, 曺喜大 GRASS GIS Developer https://idea.isnew.info/ ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] strange problem using v.out.ogr
Michael, I get the same error when trying to export a vector map to shapefile using v.out.ogr. I daily build the main branch myself for OSGeo4W v1 (GDAL 3.1.4) on Windows [1]. It used to work fine before (cannot remember exactly when). My daily cross-compiled version using GDAL 2.2.4 still works fine [2]. It could be a GDAL 3 issue or a GRASS-GDAL 3 compatibility issue? Maybe, it's worth trying our official Windows release... [1] https://idea.isnew.info/how-to-compile-grass-gis-on-ms-windows.html [2] https://idea.isnew.info/how-to-cross-compile-grass-gis-for-ms-windows.html Best, Huidae On Mon, May 24, 2021 at 7:23 PM Michael Barton wrote: > Using a very recently compiled GRASS 7.9 > > I imported a gpkg vector area. This went fine AFAICT. It imported into the > correct location. (ETRS89 Zone 30) > > I want to export it to shapefile format. > > When I try to export it to *any* format, I get the following error: > > ERROR 10: Pointer 'hSRS' is NULL in 'OSRImportFromWkt'. > ERROR: Unable to create OGR spatial reference > > I've checked the projection info and it seems fine and does not raise any > error or warning. I tried exporting a map from the NC demo data and it > exported fine. > > Any idea what is wrong? > > Michael > _ > C. Michael Barton > Director, Center for Social Dynamics & Complexity > Director, Network for Computational Modeling in Social & Ecological > Sciences > Associate Director, School of Complex Adaptive Systems > Professor, School of Human Evolution & Social Change > Arizona State University > Tempe, AZ 85287-2402 > USA > > voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) > fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) > www: http://shesc.asu.edu, https://complexity.asu.edu, > http://www.public.asu.edu/~cmbarton > > _______ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev > -- Huidae Cho, Ph.D., GISP, /hidɛ t͡ɕo/, 조희대, 曺喜大 GRASS GIS Developer https://idea.isnew.info/ ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Python and script header definitions for modules
wever, the parser is currently quite line-oriented and > the cost-benefit ratio may be low. > > 5. We change the script header definition format to some existing format > that can break lines, i.e. allowing multi-line values. A clear candidate > for the format is YAML or rather its simpler subset. This would have > additional benefits of making the format a standard format. Which in turn > would be beneficial for other things, e.g., for easier learning of the > syntax. Combining this with option 3, we could drop the `# %` part to make > the YAML more readily readable. > > Let me know what you think, what option you like, what you would add, and > what you can help with. > > Thank you, > Vaclav > > > > * Clearly, we should do something about the naming here, too! > > > Example for option 3: > > """ > # %module > # % description: Imports raster data into a GRASS raster map using GDAL > library and reprojects on the fly. > ... > # %option > # % key: resample > # % type: string > # % required: no > # % multiple: no > # % options: > nearest,bilinear,bicubic,lanczos,bilinear_f,bicubic_f,lanczos_f > # % description: Resampling method to use for reprojection > # % descriptions: nearest;nearest neighbor;bilinear;bilinear > interpolation;bicubic;bicubic interpolation;lanczos;lanczos > filter;bilinear_f;bilinear interpolation with fallback;bicubic_f;bicubic > interpolation with fallback;lanczos_f;lanczos filter with fallback > # % answer: nearest > # % guisection: Output > # %end > ... > # %rules > # % required: output,-e > # %end > """ # noqa: E501 > > Links: > > https://github.com/OSGeo/grass/pull/1446 > https://www.flake8rules.com/rules/E265.html > https://www.flake8rules.com/rules/E501.html > http://pylint-messages.wikidot.com/messages:c0111 > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev > -- Huidae Cho, Ph.D., GISP, /hidɛ t͡ɕo/, 조희대, 曺喜大 GRASS GIS Developer https://idea.isnew.info/ ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Parallelization of existing modules for GRASS GIS
Aaron, Thanks for the update. Please take a look at r.mapcalc if it's feasible to parallelize it. It is probably one of the most frequently used raster modules. Best, Huidae On Mon, Jun 7, 2021 at 5:56 AM Aaron Saw Min Sern wrote: > Hi everyone, > > The bonding period has just ended. Here's a short summary of what I have > completed so far. > > 1) What did I get done during this period? > >- I have set up a wiki page detailing my project and its progress. [1] >- I have set up my development environment. Here's the link to my >repository. [2] >- I have gotten in touch with my mentors, and we are arranging a >meeting this week. > > 2) What do I plan on doing next week? > > I will be working on parallelizing 3 modules: *r.proj, r.neighbor, > r.univar*. Based on the results, I will adjust my plans in the future > weeks. > > > 3) Am I blocked on anything? > > No, it has been good so far. > > > Cheers, > Aaron > > [1] https://trac.osgeo.org/grass/wiki/GSoC/2021/RasterParallelization > [2] https://github.com/aaronsms/grass > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev > -- Huidae Cho, Ph.D., GISP, /hidɛ t͡ɕo/, 조희대, 曺喜大 GRASS GIS Developer https://idea.isnew.info/ ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS GIS single layout (GSoC 2021)
Linda, Would it be feasible to implement both single and multi-window modes just like GIMP? I'm not sure how GIMP maintains both, but I can clearly see the pros of multi-windows when you have multiple monitors. Maybe, docking panes? Best, Huidae On Fri, Apr 16, 2021 at 3:10 PM Denis Ovsienko wrote: > On Sun, 11 Apr 2021 11:51:32 +0200 (CEST) > "L.Kladivova" wrote: > > > Idea: > > > > https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/SingleWindow > > I trust you mean well. Let me provide some input. > > My own GUI arrangement for GRASS work was on two monitors (same size, > same DPI). The first monitor with the two smaller GRASS windows plus > non-GRASS windows of the project was in in horizontal orientation. The > second monitor with the GRASS map display was in vertical orientation > to fit the region of interest. And I was running out of screen space > all the time, so if this was a commercial project, there would be at > least one more monitor to provide more space for the multiple > independent windows. Clearly, for a single window UI it would not make > as much sense. > > One other interesting arrangement is a more or less ordinary monitor to > display some GUI in normal usable size plus another "high DPI" monitor > to display some other GUI that needs to show as many physical pixels at > once as possible. Of course, neither the physical size nor the pixel > count match between the monitors, so when a window spans more than one > monitor it becomes difficult to use. > > Finally, GIMP has been using multiple window UI for many years, and the > users figure the GUI out just fine. > > So a multiple window GUI makes a sound use case and it would be nice > to keep it reasonably accessible. > > -- > Denis Ovsienko > ___________ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev > -- Huidae Cho, Ph.D., GISP, /hidɛ t͡ɕo/, 조희대, 曺喜大 GRASS GIS Developer https://idea.isnew.info ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Google Summer of Code (GSoC) 2021
Hi all and, most of all, students, The Google Summer of Code (GSoC) 2021 is now open for student applications until April 13, 2021 at 14:00 EDT [1]. The GRASS GIS community is happy to be part of this great event and you can check proposed ideas for GRASS GIS at [2]. If you have your own ideas, please feel free to discuss those with your potential mentors. Please check [3] and let us [4] know if you have any questions. Looking forward to your applications! Best Regards, Huidae Cho [1] https://summerofcode.withgoogle.com/ [2] https://trac.osgeo.org/grass/wiki/GSoC/2021 [3] https://trac.osgeo.org/grass/wiki/GSoC/2021#Tipsforstudents [4] https://lists.osgeo.org/listinfo/grass-dev -- Huidae Cho, Ph.D., GISP, /hidɛ t͡ɕo/, 조희대, 曺喜大 GRASS GIS Developer https://idea.isnew.info ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Next Tasks For The GSoC Project
On Wed, Mar 24, 2021 at 9:28 PM Vaclav Petras wrote: > > > On Wed, Mar 24, 2021 at 4:03 PM Sunveer Singh > wrote: > >> >> What are some next tasks on which I can work to familiarize myself more >> with the project and demonstrate my skills. >> > > First, let me extend the question to other potential mentors to see if > they have other things they would like to see for the test of skills. > Sunveer, I think it depends on what you want to achieve for GSoC. Are you interested in a project that only requires Python or C or both, or even C++? What is your level of skills in either language? How will you be able to show your skill level? Do you want to take one of these ideas from https://trac.osgeo.org/grass/wiki/GSoC/2021 or want to propose your own project? These are some questions you may want to think about. I'm going to solicit applications for https://trac.osgeo.org/grass/wiki/GSoC/2021#Parallelizationofexistingmodules soon. Best, Huidae > As for myself, although I already fixed the most needed pieces [1, 2] of > the other testing-related GSoC idea [3], the test of skills still applies: > > *Fix failing tests and/or write new tests (more is better). Alternatively, > addressing a smaller problem in the testing framework is a good task, too.* > > Adding new tests is something you are familiar with from the past, so you > can make a new submission which matches your current level of skills. > Fixing existing tests has a value for the documentation-based test project > you are planning to submit as some of the tasks might be similar. Tests in > both grass and grass-addons repos count. I don't see any "smaller problem > in the testing framework" at this point but if you do, you can try to fix > it. > > [1] https://github.com/OSGeo/grass/pull/1290 > [2] https://github.com/OSGeo/grass/pull/1362 > [3] > https://trac.osgeo.org/grass/wiki/GSoC/2021#IntegratetestingframeworkwithGitHubActions > > >> Also, should I start building my GSoC Proposal? >> > > Yes, although that's really up to you. However, we want to see a draft of > your proposal at the beginning of the submission window so that we can > comment and you can incorporate the feedback before the submission period > ends. > > My suggestion is to send another email to the mailing list, not focusing > on GSoC, but really for general discussion, to see what people expect from > this and how they think your idea would work. This can help you define for > the proposal what you are aiming at in your project. Then, for the > proposal, you should also try to match your design with your skill level. > >> -- Huidae Cho, Ph.D., GISP, /hidɛ t͡ɕo/, 조희대, 曺喜大 GRASS GIS Developer https://idea.isnew.info ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Need a mentor for GSoC parallelization topic
Thanks. I'm not familiar with the process. The deadline for mentoring organization applications is approaching. Have we already applied with all those project ideas in the wiki (one application per organization I guess, not per project idea)? Best, Huidae On Wed, Feb 17, 2021 at 11:49 PM Anna Petrášová wrote: > > > On Wed, Feb 17, 2021 at 11:51 AM Huidae Cho wrote: > >> Anna, >> >> Thanks! I just updated the wiki and filled out the form. Will I receive >> further communications from OSGeo (e.g., rejected, accepted, how to >> proceed...)? >> > > I believe they will inform us about the OSGeo application status on OSGeo > discuss and soc mailing lists. Here is the timeline: > https://developers.google.com/open-source/gsoc/timeline > > Best, > Anna > >> >> Regards, >> Huidae >> >> On Wed, Feb 17, 2021 at 11:29 AM Anna Petrášová >> wrote: >> >>> >>> >>> On Tue, Feb 16, 2021 at 2:37 PM Huidae Cho wrote: >>> >>>> Anna, >>>> >>>> It sounds like an interesting topic and I'm open to mentoring him even >>>> though I have limited experience with OpenMP. If anyone else has more >>>> experience with it and is interested in mentoring, that will be even >>>> better. >>>> >>> >>> Thanks Huidae, I think you are more than qualified for being a mentor >>> for this topic. Please put your name on the wiki page and fill out the >>> form. If others would be interested in helping out (e.g. testing, reviews), >>> that would be great, we need a co-mentor and ideally it wouldn't be me, >>> since I may be a mentor elsewhere. >>> >>> Thanks again! >>> Anna >>> >>>> >>>> Best, >>>> Huidae >>>> >>>> On Tue, Feb 16, 2021 at 10:14 AM Anna Petrášová >>>> wrote: >>>> >>>>> Hi devs, >>>>> >>>>> would you consider being a GSoC mentor for this topic [1]? I suggested >>>>> this topic in hope this could be impactful for GRASS and fairly accessible >>>>> for students with CS background. >>>>> >>>>> We need somebody with C experience, ideally also OpenMP experience. I >>>>> have only limited experience, and I would probably be mentoring a >>>>> different >>>>> project, so I can't be the main mentor here. >>>>> >>>>> There is already a student who would be interested in that, so we need >>>>> to make sure there is somebody who can mentor him. >>>>> >>>>> This is all theoretical so far, OSGeo is not even accepted yet. If you >>>>> are interested, please also fill this form [2]. >>>>> >>>>> Thank you for considering this, >>>>> >>>>> Anna >>>>> >>>>> [1] >>>>> https://trac.osgeo.org/grass/wiki/GSoC/2021#Parallelizationofexistingmodules >>>>> [2] https://forms.gle/9Na1vzGX3ESxqgpj9 >>>>> >>>> >>>> >>>> -- >>>> Huidae Cho, Ph.D., GISP, /hidɛ t͡ɕo/, 조희대, 曺喜大 >>>> GRASS GIS Developer >>>> https://idea.isnew.info >>>> >>> >> >> -- >> Huidae Cho, Ph.D., GISP, /hidɛ t͡ɕo/, 조희대, 曺喜大 >> GRASS GIS Developer >> https://idea.isnew.info >> > -- Huidae Cho, Ph.D., GISP, /hidɛ t͡ɕo/, 조희대, 曺喜大 GRASS GIS Developer https://idea.isnew.info ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Need a mentor for GSoC parallelization topic
Anna, Thanks! I just updated the wiki and filled out the form. Will I receive further communications from OSGeo (e.g., rejected, accepted, how to proceed...)? Regards, Huidae On Wed, Feb 17, 2021 at 11:29 AM Anna Petrášová wrote: > > > On Tue, Feb 16, 2021 at 2:37 PM Huidae Cho wrote: > >> Anna, >> >> It sounds like an interesting topic and I'm open to mentoring him even >> though I have limited experience with OpenMP. If anyone else has more >> experience with it and is interested in mentoring, that will be even better. >> > > Thanks Huidae, I think you are more than qualified for being a mentor for > this topic. Please put your name on the wiki page and fill out the form. If > others would be interested in helping out (e.g. testing, reviews), that > would be great, we need a co-mentor and ideally it wouldn't be me, since I > may be a mentor elsewhere. > > Thanks again! > Anna > >> >> Best, >> Huidae >> >> On Tue, Feb 16, 2021 at 10:14 AM Anna Petrášová >> wrote: >> >>> Hi devs, >>> >>> would you consider being a GSoC mentor for this topic [1]? I suggested >>> this topic in hope this could be impactful for GRASS and fairly accessible >>> for students with CS background. >>> >>> We need somebody with C experience, ideally also OpenMP experience. I >>> have only limited experience, and I would probably be mentoring a different >>> project, so I can't be the main mentor here. >>> >>> There is already a student who would be interested in that, so we need >>> to make sure there is somebody who can mentor him. >>> >>> This is all theoretical so far, OSGeo is not even accepted yet. If you >>> are interested, please also fill this form [2]. >>> >>> Thank you for considering this, >>> >>> Anna >>> >>> [1] >>> https://trac.osgeo.org/grass/wiki/GSoC/2021#Parallelizationofexistingmodules >>> [2] https://forms.gle/9Na1vzGX3ESxqgpj9 >>> >> >> >> -- >> Huidae Cho, Ph.D., GISP, /hidɛ t͡ɕo/, 조희대, 曺喜大 >> GRASS GIS Developer >> https://idea.isnew.info >> > -- Huidae Cho, Ph.D., GISP, /hidɛ t͡ɕo/, 조희대, 曺喜大 GRASS GIS Developer https://idea.isnew.info ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Need a mentor for GSoC parallelization topic
Anna, It sounds like an interesting topic and I'm open to mentoring him even though I have limited experience with OpenMP. If anyone else has more experience with it and is interested in mentoring, that will be even better. Best, Huidae On Tue, Feb 16, 2021 at 10:14 AM Anna Petrášová wrote: > Hi devs, > > would you consider being a GSoC mentor for this topic [1]? I suggested > this topic in hope this could be impactful for GRASS and fairly accessible > for students with CS background. > > We need somebody with C experience, ideally also OpenMP experience. I have > only limited experience, and I would probably be mentoring a different > project, so I can't be the main mentor here. > > There is already a student who would be interested in that, so we need to > make sure there is somebody who can mentor him. > > This is all theoretical so far, OSGeo is not even accepted yet. If you are > interested, please also fill this form [2]. > > Thank you for considering this, > > Anna > > [1] > https://trac.osgeo.org/grass/wiki/GSoC/2021#Parallelizationofexistingmodules > [2] https://forms.gle/9Na1vzGX3ESxqgpj9 > -- Huidae Cho, Ph.D., GISP, /hidɛ t͡ɕo/, 조희대, 曺喜大 GRASS GIS Developer https://idea.isnew.info ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Min. req. of programming language standard support, GRASS GIS 8
Thanks Nicklas for the great summary! That helped a lot. I was wondering if we have a list of all supported platforms somewhere? We have official downloads for Linux, Mac, and Windows. Are these three only "officially" supported platforms? I know GRASS is compilable on FreeBSD [1] and maybe (Open|Net)BSD. Is that it? Minix3 supports GDAL 1.11.3, PROJ 4.9.2, GEOS 3.5.0, and GCC 6.2.0 [2]. I know... they are a little behind. Since we cannot (or will be difficult to) go back once we move to a newer C standard, I think we need to discuss what platforms we want to support officially or unofficially (?) first. Is [3] or [4] (GRASS 6.3) still valid? Has anyone tried all or some of those platforms recently (Sun Solaris (SPARC/Intel), Silicon Graphics Irix, HP-UX, DEC-Alpha, AIX, BSD, iPAQ/Linux and other UNIX compliant platforms)? I think at some point this list was removed from a release announcement. Maybe, we are being more realistic because many of these platforms are now irrelevant or we just don't have enough resources or interest to maintain such a list of supported platforms anymore? Best, Huidae [1] https://www.freebsd.org/cgi/man.cgi?query=index§ion=3 [2] http://www.minix3.org/pkgsrc/distfiles/local/3.4.0-2016Q3/ [3] https://old.grass.osgeo.org/screenshots/platforms/ [4] https://grass.osgeo.org/news/2008_04_23_announce_grass630/ On Mon, Feb 1, 2021 at 4:25 PM Markus Metz wrote: > A pity that Nicklas did not answer in this thread, see his answer in > https://lists.osgeo.org/pipermail/grass-dev/2021-February/094913.html > > I have not studied the different C standards and the state of their > implementation in different compilers and their different versions in > depth, and thus appreciate very much the summary of Nicklas! > > IIUC, Nicklas recommends to allow C11 standard features in GRASS C code, > with no need to change the current code base, and all compilers in all > supported platforms apparently support C11. > > +1 from me, as long as all stock compilers on all supported platforms > support C11 > > Markus M > > > On Mon, Feb 1, 2021 at 8:56 AM Moritz Lennert < > mlenn...@club.worldonline.be> wrote: > > > > > > > > Am 31. Januar 2021 22:15:53 MEZ schrieb Markus Metz < > markus.metz.gisw...@gmail.com>: > > >On Fri, Jan 29, 2021 at 11:19 PM Moritz Lennert < > > >mlenn...@club.worldonline.be> wrote: > > >> > > >> > > >> > > >> Am 29. Januar 2021 20:54:06 GMT+00:00 schrieb Markus Metz < > > >markus.metz.gisw...@gmail.com>: > > >> >Hi Huidae, > > >> > > > >> >On Thu, Jan 28, 2021 at 6:30 PM Huidae Cho > wrote: > > >> >> > > >> >> Markus, > > >> >> > > >> >> I think we have to think about what benefits it would bring to us > by > > >> >modernizing C code. Probably, not much at all. Personally, I would > keep > > >it > > >> >as is because the minimum set of anything (e.g., ANSI C with no new > > >> >features) would probably be more portable, I believe. In other words, > > >what > > >> >are we missing from C99? > > >> > > > >> >as I mentioned, there is no need to modernize the GRASS C code. The > > >> >question is if we officially allow C99 features. > > >> > > > >> >For example a number of useful math-related functions and macros are > only > > >> >available with C99. See /usr/include/math.h on your system and > search for > > >> >C99. Also a number of features related to data types, particularly > for > > >> >various int datatypes (stdint.h), become available with C99. And the > > >> >geographic lib in PROJ with src/geodesic.c wants C99. For new PROJ > > >> >versions, C99 is a requirement. > > >> > > >> > > >> If proj requires it, doesn't it automatically become a requirement for > > >GRASS as well ? > > > > > >No, because the code base of other libs might have completely different > > >compile requirements. A software can use functions and libs of other > > >software packages, but does not need to follow the compile standards of > > >those other software packages, because they are compiled independently. > > > > > > > Thanks for the clarification. > > > > In light of that I agree that we should choose the oldest standard > possible, unless we _really_ need something only present in a more recent > version. > > > > @those who want to use more recent standards: what are your reasons for > that ? > > > > Moritz > -- Huidae Cho, Ph.D., GISP, /hidɛ t͡ɕo/, 조희대, 曺喜大 GRASS GIS Developer https://idea.isnew.info ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Min. req. of programming language standard support, GRASS GIS 8
Markus, I think we have to think about what benefits it would bring to us by modernizing C code. Probably, not much at all. Personally, I would keep it as is because the minimum set of anything (e.g., ANSI C with no new features) would probably be more portable, I believe. In other words, what are we missing from C99? Regards, Huidae On Thu, Jan 28, 2021 at 12:19 PM Markus Metz wrote: > Hi all, > > regarding C, there is no need to modernize the code base because the > current C code written for C89 compiles just fine with newer standards > which are backwards compatible it seems. The question is if we allow > features from a newer C standard, say C99, to be included in the code base. > In fact, a few C99 features (supported by gnu89) have already sneaked into > the GRASS C code base. I am opting to allow C99 features. > > Regarding C++, it's a bit more difficult because apparently C++ standards > are not fully backwards compatible. We had corresponding problems with C++ > code in GRASS previously and fixed these problems when they arose. > > Markus M > > > On Thu, Jan 28, 2021 at 3:33 PM Huidae Cho wrote: > >> Nicklas, >> >> Thanks for your suggestions. As far as I know, C code "is written in >> portable ANSI-C and is fully POSIX compliant" [1] (C89 or C90?, rather old >> standards, I know, but GRASS itself is old and predates both standards) and >> the minimum "recommended" version of Python going forward is 3.5 [2]. I >> don't know about C++, but there are not many modules written in it. >> Modernizing the current code base to a newer C standard would be great >> though. >> >> Best, >> Huidae >> >> [1] https://old.grass.osgeo.org/screenshots/platforms/ >> [2] https://github.com/OSGeo/grass/blob/master/REQUIREMENTS.html >> >> >> On Thu, Jan 28, 2021 at 4:28 AM Nicklas Larsson via grass-dev < >> grass-dev@lists.osgeo.org> wrote: >> >>> Dear Devs! >>> >>> As a relatively new member of the GRASS GIS dev community, I have had to >>> search for information on mailing lists, old trac comments etc. regarding >>> coding practice and in particular minimum programming language standard >>> support. Ending up in not entirely conclusive understanding. Up until now, >>> I have been mostly involved in Python development and I’m still not >>> absolutely certain, although I assume 3.5 is minimum version. And I’m not >>> alone, see e.g. [1]. >>> >>> Now, I’ve encountered a similar dilemma with C standard support, >>> attempting to address compiler warnings [2], in particular with the PR >>> #1256 [3]. >>> >>> I would be great if there were a (one) place where the min support of >>> Python version, C (C89, C99, C11, C17…) and C++ (C++03, C++11, C++14 …) >>> standard is stated -- loud and clear. Obviously, there has to be a >>> consensus in the community on these matters for that to happen. Such a >>> statement will also have to be revised now and then. (A related question is >>> also whether or not to support 32 bit, which I know have been raised >>> recently). >>> >>> I’d appreciate your opinion is on this issue! >>> Let me put up a a suggestion for min. req. for coming GRASS GIS 8 as a >>> starting point of discussion: >>> - Python 3.7 >>> - C11 >>> - C++11 >>> >>> >>> Best regards, >>> Nicklas >>> >>> >>> >>> [1] https://github.com/OSGeo/grass/issues/1241 >>> [2] https://github.com/OSGeo/grass/issues/1247 >>> [3] https://github.com/OSGeo/grass/pull/1256 >>> ___ >>> grass-dev mailing list >>> grass-dev@lists.osgeo.org >>> https://lists.osgeo.org/mailman/listinfo/grass-dev >>> >> >> >> -- >> Huidae Cho, Ph.D., GISP, /hidɛ t͡ɕo/, 조희대, 曺喜大 >> GRASS GIS Developer >> https://idea.isnew.info >> ___ >> grass-dev mailing list >> grass-dev@lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/grass-dev >> > -- Huidae Cho, Ph.D., GISP, /hidɛ t͡ɕo/, 조희대, 曺喜大 GRASS GIS Developer https://idea.isnew.info ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Min. req. of programming language standard support, GRASS GIS 8
Nicklas, Thanks for your suggestions. As far as I know, C code "is written in portable ANSI-C and is fully POSIX compliant" [1] (C89 or C90?, rather old standards, I know, but GRASS itself is old and predates both standards) and the minimum "recommended" version of Python going forward is 3.5 [2]. I don't know about C++, but there are not many modules written in it. Modernizing the current code base to a newer C standard would be great though. Best, Huidae [1] https://old.grass.osgeo.org/screenshots/platforms/ [2] https://github.com/OSGeo/grass/blob/master/REQUIREMENTS.html On Thu, Jan 28, 2021 at 4:28 AM Nicklas Larsson via grass-dev < grass-dev@lists.osgeo.org> wrote: > Dear Devs! > > As a relatively new member of the GRASS GIS dev community, I have had to > search for information on mailing lists, old trac comments etc. regarding > coding practice and in particular minimum programming language standard > support. Ending up in not entirely conclusive understanding. Up until now, > I have been mostly involved in Python development and I’m still not > absolutely certain, although I assume 3.5 is minimum version. And I’m not > alone, see e.g. [1]. > > Now, I’ve encountered a similar dilemma with C standard support, > attempting to address compiler warnings [2], in particular with the PR > #1256 [3]. > > I would be great if there were a (one) place where the min support of > Python version, C (C89, C99, C11, C17…) and C++ (C++03, C++11, C++14 …) > standard is stated -- loud and clear. Obviously, there has to be a > consensus in the community on these matters for that to happen. Such a > statement will also have to be revised now and then. (A related question is > also whether or not to support 32 bit, which I know have been raised > recently). > > I’d appreciate your opinion is on this issue! > Let me put up a a suggestion for min. req. for coming GRASS GIS 8 as a > starting point of discussion: > - Python 3.7 > - C11 > - C++11 > > > Best regards, > Nicklas > > > > [1] https://github.com/OSGeo/grass/issues/1241 > [2] https://github.com/OSGeo/grass/issues/1247 > [3] https://github.com/OSGeo/grass/pull/1256 > ___________ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev > -- Huidae Cho, Ph.D., GISP, /hidɛ t͡ɕo/, 조희대, 曺喜大 GRASS GIS Developer https://idea.isnew.info ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS Elections 2020] Voting phase closed, presentation of results
Dear the GRASS community, Thank you for your support and I am honored to be elected for the PSC. I am excited that I can contribute to the community in a different way. We will all make GRASS a better GIS! Best Regards, Huidae Cho On Mon, Jan 25, 2021 at 7:31 AM Chief Return Officer (CRO) - GRASS GIS election 2020 wrote: > Dear members of the GRASS GIS community, > > The voting phase of the GRASS GIS Election 2020 is now finished. Out of > 245 registered voters, 98 completed the survey. The results are shown below > and are now available in the Trac Wiki. > > > Voting result (ranking, name, number of votes): > > 1. Markus Neteler 95 > 2. Anna Petrášová 88 > 3. Helena Mitasova 86 > 4. Martin Landa 83 > 5. Verónica Andreo76 > 6. Moritz Lennert 74 > 7. Vaclav Petras 68 > 8. Michael Barton 58 > 9. Huidae Cho 56 > 10. Helmut Kudrnovsky 55 > 11. Peter Löwe 52 > 12. Māris Nartišs 47 > 13. Stefan Blumentrath 44 > > > > The new PSC is then composed of the following 9 members: > > 1. Markus Neteler 95 > 2. Anna Petrášová 88 > 3. Helena Mitasova 86 > 4. Martin Landa 83 > 5. Verónica Andreo76 > 6. Moritz Lennert 74 > 7. Vaclav Petras 68 > 8. Michael Barton 58 > 9. Huidae Cho 56 > > > > Regards, > > Hernán > > Chief Return Officer (CRO) > > > > > > > _______ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev > -- Huidae Cho, Ph.D., GISP, /hidɛ t͡ɕo/, 조희대, 曺喜大 GRASS GIS Developer https://idea.isnew.info ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Statement Huidae Cho
Dear All, I feel very honored to be nominated for the PSC and really appreciate this opportunity. I started using GRASS in June 2000 for my Master's thesis, optimization of a hydrologic model. I was using FreeBSD as my main operating system at that time and had to go through a lot of hurdles to be able to use GRASS on my machine. I remember I sent a lot of emails to the GRASS mailing list and Markus Neteler asking for help and started creating my own patches to make GRASS compilable on FreeBSD. Since I joined the GRASS development team in 2000, I have ported the Fortran 77 source code of TOPMODEL to GRASS ( r.topmodel <https://grass.osgeo.org/grass79/manuals/r.topmodel.html> and r.topidx <https://grass.osgeo.org/grass79/manuals/r.topidx.html>), updated the earlier 3D GUI (NVIZ), and improved the usability of various modules. Recently, I developed a new hydrologic module (r.accumulate <https://grass.osgeo.org/grass78/manuals/addons/r.accumulate.html>). As a non-Western user and developer of GRASS, I have also been working on I18N including FreeType support, wide-character (CJK) formatting libraries ( libaprintf <https://github.com/HuidaeCho/libaprintf> and cjkformat <https://github.com/HuidaeCho/cjkformat> incorporated into GRASS), and Korean translations. I was fortunate enough to get familiar with a decent amount of the extensive codebase of GRASS for the past two decades. I use GRASS on Linux mainly for hydrologic modeling and analysis for my research, but I am trying to introduce GRASS to my geospatial science and computing students. My school labs still have GRASS 7.4.4, but I wanted to use the latest stable release or daily builds. Since most, if not all, of these students do not have admin rights on lab computers, they are stuck with the older version with some bugs that are already fixed. For this reason, I am very interested in making GRASS as portable as possible without requiring admin rights. Part of that effort was to package it as extractable ZIP files (grass-mingw-scripts <https://github.com/HuidaeCho/grass-mingw-scripts> and grass-build-scripts <https://github.com/HuidaeCho/grass-build-scripts>) so they can simply extract a ZIP file onto their choice of a folder with no installation process at all. As a PCS member if elected, I would like to focus on the portability and usability of GRASS for non-admin Windows users to attract more young geospatial students to GRASS in educational settings. I would also like to see the growth of GRASS into the non-Western world, so I will continue to work on the code for multi-character and translation supports. In terms of new functionalities, I would like to see a web frontend of GRASS and a server-client data model to save CPU time loading heavy data into the memory repeatedly. As a relatively old member of the GRASS community, I will support new developers and users by providing historical perspectives and sharing what I have learned so far. For example, I hope to support and mentor GSoC developers. I am very excited about the future of GRASS. Best Regards, Huidae -- Huidae Cho, Ph.D., GISP, /hidɛ t͡ɕo/, 조희대, 曺喜大 GRASS GIS Developer https://idea.isnew.info ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Bugs in r.stream.extract
Ming, The discrepancy in flow accumulation between the two modules is explained in the r.accumulate manual at https://grass.osgeo.org/grass78/manuals/addons/r.accumulate.html. See Examples => Flow accumulation. Most likely, this is because of r.watershed's handling of border cells. Thanks, Huidae On Wed, Nov 25, 2020 at 7:17 AM ming han wrote: > And another problem I got is that the flow accumulation I got from > r.accumulate and r.watershed is different when r.accumulate using flow > direction from r.watershed. Again is there anyway r.watershed supports > using flow direction, so we can get the consistent result. > > We need this when we need to adjust the flow direction from r.watershed > or r.stream.extract. and then we need to determine new flow accumulation > with an adjusted flow direction dataset. If the result is inconsistent, > not sure what is the solution is. > > Cheers > Ming > > ming han 于2020年11月25日周三 上午6:38写道： > >> Hi Ken >> >>Many thanks for your reply, I think I made a mistake, the flow >> accumulation I provided to r.stream.extract did not match the DEM I >> provided in r.stream.extract. The streamline seems based on flow >> accumulation derived from the provided DEM. >> >>But, If I only want to use flow direction to drive streams, which >> function I should use? >> >>Is there any chance that r.stream.extract can use flow direction as >> inputs without DEM? >> >> Thanks >> Ming >> >> >> Ken Mankoff 于2020年11月24日周二 上午7:07写道： >> >>> Hi Ming, >>> >>> On 2020-11-23 at 09:05 -08, ming han wrote... >>> > Hope this email finds you well. I got a weird result when using >>> > r.stream.extract, as shown in the following figure. The back grids is >>> > the flow accumulation layer with a flow accumulation threshold larger >>> > than 1000. while the blue line is the stream generated by >>> > r.stream.extract. Why the stream from r.stream.extract did not follow >>> > flow accumulation results? And how to fix this problem? >>> >>> Is there any chance you can share the raster that includes this region >>> so I can examine it? And the exact command you ran? >>> >>> -k. >>> >>> ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev > -- Huidae Cho, Ph.D., GISP GRASS GIS Developer https://idea.isnew.info ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Error in GRASS GUI startup
Great! Just to make sure. That was the official daily build, right? Thanks for testing. -- Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE Open Source GIS Developer, GRASS GIS Development Team https://idea.isnew.info Sent from my phone On Fri, Dec 27, 2019, 6:05 PM Bergquist, Kiersten L < kiersten.bergqu...@siu.edu> wrote: > Oh, I installed version 7.9 and it works perfectly! Huh, much easier fix > than I was expecting. Thank you for all your help! > -- > *From:* Huidae Cho > *Sent:* Tuesday, December 24, 2019 3:02 PM > *To:* Bergquist, Kiersten L > *Cc:* Maris Nartiss ; GRASS developers list < > grass-dev@lists.osgeo.org> > *Subject:* Re: [GRASS-dev] Error in GRASS GUI startup > > > [EXTERNAL EMAIL ALERT]: Verify sender before opening links or attachments. > OK, you were having trouble with the OSGeo4W package and the standalone > installer version 7.8.2 is giving you this error. To be honest, we don't > have enough information to troubleshoot your problem. **ERROR: Error in GUI > startup. See messages above (if any) and if necessary, please report this > error to the GRASS developers.** We don't have those "messages above". Do > you see more error messages than this? Maybe, you could take a screenshot > of your problem? > > Please try the 7.9 daily build ( > https://wingrass.fsv.cvut.cz/grass77/x86_64).. Hmm.. this link doesn't > work? Here you go. ( > https://wingrass.fsv.cvut.cz/grass79/x86_64/WinGRASS-7.9.dev-54-Setup-x86_64.exe > ). > > If this official daily build doesn't work either, please try my personal > daily builds (latest master branch, don't worry about malicious code here > ;-): > * > https://idea.isnew.info/how-to-compile-grass-gis-on-ms-windows.html#latest-daily-build > (Comes with OSGeo4W and Python 3) > * > https://idea.isnew.info/how-to-cross-compile-grass-gis-for-ms-windows.html#latest-daily-build > (No OSGeo4W dependency and no Python 3; you need to install Python 3) > > Thanks, > Huidae > > On Mon, Dec 23, 2019 at 9:00 PM Bergquist, Kiersten L < > kiersten.bergqu...@siu.edu> wrote: > > Hello everyone, > > Thank you so much for your speedy response! > > I'm using Windows 10, 64-bit. I used the stand-alone installer for GRASS > 7.8, because I was having trouble with the OSGeo4W package. I got 7.8 > because it was the newest stable version. I downloaded 7.8.2, again since > it was the newest version. > > I'll try deleting the grass directory. In the meantime, if there is any > other advice to be offered, please send it my way! I really appreciate all > this. > -- > *From:* Maris Nartiss > *Sent:* Sunday, December 22, 2019 4:41 AM > *To:* Huidae Cho > *Cc:* Bergquist, Kiersten L ; GRASS > developers list > *Subject:* Re: [GRASS-dev] Error in GRASS GUI startup > > [EXTERNAL EMAIL ALERT]: Verify sender before opening links or attachments. > > Also a precise version of GRASS GIS (7.8.1 or 7.8.2). > There where some start-up related issues fixed in 7.8.2 (see 1, 2 & 3). > > One thing you can try out is to completely delete ~/.grass7 directory. > > 1. https://github.com/OSGeo/grass/pull/155 > 2. https://github.com/OSGeo/grass/pull/185 > 3. https://github.com/OSGeo/grass/pull/167 > > Māris. > > sestd., 2019. g. 21. dec., plkst. 09:28 — lietotājs Huidae Cho > () rakstīja: > > > > Hello Kiersten, > > > > First, we need to know which OS you are using. Are you on MS Windows, > Linux, or Mac? How did you install GRASS if it's Windows? OSGeo4W or > stand-alone (https://grass.osgeo.org/download/software/ms-windows)? > > > > Thanks, > > Huidae > > > > On Fri, Dec 20, 2019 at 6:27 PM Kiersten > wrote: > >> > >> Hello devs, > >> > >> I'm very new to GRASS-GIS. Many jobs in my field want some level of > >> familiarity with GIS so, I wanted to get ahead and try seeing if I can > learn > >> a free version of GIS on my own (since I know that non-GRASS GIS > systems can > >> be costly). > >> > >> I followed along the step-by-step tutorial and had GRASS 7.8 installed. > >> Everything was fine until I downloaded the NC dataset (using the > "location > >> wizard"). I tried to then start a GRASS session with that data, and all > of a > >> sudden the program closed out. I tried to re-open GRASS, when I was hit > with > >> the following message: > >> > >> ERROR: Error in GUI startup. See messages above (if any) and if > necessary, > >> please report this error to the GRASS developers. > >> On systems wit
Re: [GRASS-dev] Error in GRASS GUI startup
OK, you were having trouble with the OSGeo4W package and the standalone installer version 7.8.2 is giving you this error. To be honest, we don't have enough information to troubleshoot your problem. **ERROR: Error in GUI startup. See messages above (if any) and if necessary, please report this error to the GRASS developers.** We don't have those "messages above". Do you see more error messages than this? Maybe, you could take a screenshot of your problem? Please try the 7.9 daily build (https://wingrass.fsv.cvut.cz/grass77/x86_64).. Hmm.. this link doesn't work? Here you go. ( https://wingrass.fsv.cvut.cz/grass79/x86_64/WinGRASS-7.9.dev-54-Setup-x86_64.exe ). If this official daily build doesn't work either, please try my personal daily builds (latest master branch, don't worry about malicious code here ;-): * https://idea.isnew.info/how-to-compile-grass-gis-on-ms-windows.html#latest-daily-build (Comes with OSGeo4W and Python 3) * https://idea.isnew.info/how-to-cross-compile-grass-gis-for-ms-windows.html#latest-daily-build (No OSGeo4W dependency and no Python 3; you need to install Python 3) Thanks, Huidae On Mon, Dec 23, 2019 at 9:00 PM Bergquist, Kiersten L < kiersten.bergqu...@siu.edu> wrote: > Hello everyone, > > Thank you so much for your speedy response! > > I'm using Windows 10, 64-bit. I used the stand-alone installer for GRASS > 7.8, because I was having trouble with the OSGeo4W package. I got 7.8 > because it was the newest stable version. I downloaded 7.8.2, again since > it was the newest version. > > I'll try deleting the grass directory. In the meantime, if there is any > other advice to be offered, please send it my way! I really appreciate all > this. > ---------- > *From:* Maris Nartiss > *Sent:* Sunday, December 22, 2019 4:41 AM > *To:* Huidae Cho > *Cc:* Bergquist, Kiersten L ; GRASS > developers list > *Subject:* Re: [GRASS-dev] Error in GRASS GUI startup > > [EXTERNAL EMAIL ALERT]: Verify sender before opening links or attachments. > > Also a precise version of GRASS GIS (7.8.1 or 7.8.2). > There where some start-up related issues fixed in 7.8.2 (see 1, 2 & 3). > > One thing you can try out is to completely delete ~/.grass7 directory. > > 1. https://github.com/OSGeo/grass/pull/155 > 2. https://github.com/OSGeo/grass/pull/185 > 3. https://github.com/OSGeo/grass/pull/167 > > Māris. > > sestd., 2019. g. 21. dec., plkst. 09:28 — lietotājs Huidae Cho > () rakstīja: > > > > Hello Kiersten, > > > > First, we need to know which OS you are using. Are you on MS Windows, > Linux, or Mac? How did you install GRASS if it's Windows? OSGeo4W or > stand-alone (https://grass.osgeo.org/download/software/ms-windows)? > > > > Thanks, > > Huidae > > > > On Fri, Dec 20, 2019 at 6:27 PM Kiersten > wrote: > >> > >> Hello devs, > >> > >> I'm very new to GRASS-GIS. Many jobs in my field want some level of > >> familiarity with GIS so, I wanted to get ahead and try seeing if I can > learn > >> a free version of GIS on my own (since I know that non-GRASS GIS > systems can > >> be costly). > >> > >> I followed along the step-by-step tutorial and had GRASS 7.8 installed. > >> Everything was fine until I downloaded the NC dataset (using the > "location > >> wizard"). I tried to then start a GRASS session with that data, and all > of a > >> sudden the program closed out. I tried to re-open GRASS, when I was hit > with > >> the following message: > >> > >> ERROR: Error in GUI startup. See messages above (if any) and if > necessary, > >> please report this error to the GRASS developers. > >> On systems with package manager, make sure you have the right GUI > package, > >> probably named grass-gui, installed. > >> To run GRASS GIS in text mode use the --text flag. > >> Use '--help' for further options > >> grass78 --help > >> See also: https://grass.osgeo.org/grass78/manuals/helptext.html > >> > >> I tried and tried to download the GUI package, but the websites led me > in > >> circles and nothing was working. I tried the sites recommended, I tried > >> downloading aptitude in case I was doing anything wrong, but nothing. > I'm > >> pulling my hair out! > >> > >> I'm really not sure what to do. Technology is not my strong point (heck, > >> even running R or SAS for classes is still a struggle for me), so I > figured > >> I would turn to asking real people for help, since the websites haven't > been > >>
Re: [GRASS-dev] Error in GRASS GUI startup
Hello Kiersten, First, we need to know which OS you are using. Are you on MS Windows, Linux, or Mac? How did you install GRASS if it's Windows? OSGeo4W or stand-alone (https://grass.osgeo.org/download/software/ms-windows)? Thanks, Huidae On Fri, Dec 20, 2019 at 6:27 PM Kiersten wrote: > Hello devs, > > I'm very new to GRASS-GIS. Many jobs in my field want some level of > familiarity with GIS so, I wanted to get ahead and try seeing if I can > learn > a free version of GIS on my own (since I know that non-GRASS GIS systems > can > be costly). > > I followed along the step-by-step tutorial and had GRASS 7.8 installed. > Everything was fine until I downloaded the NC dataset (using the "location > wizard"). I tried to then start a GRASS session with that data, and all of > a > sudden the program closed out. I tried to re-open GRASS, when I was hit > with > the following message: > > ERROR: Error in GUI startup. See messages above (if any) and if necessary, > please report this error to the GRASS developers. > On systems with package manager, make sure you have the right GUI package, > probably named grass-gui, installed. > To run GRASS GIS in text mode use the --text flag. > Use '--help' for further options > grass78 --help > See also: https://grass.osgeo.org/grass78/manuals/helptext.html > > I tried and tried to download the GUI package, but the websites led me in > circles and nothing was working. I tried the sites recommended, I tried > downloading aptitude in case I was doing anything wrong, but nothing. I'm > pulling my hair out! > > I'm really not sure what to do. Technology is not my strong point (heck, > even running R or SAS for classes is still a struggle for me), so I figured > I would turn to asking real people for help, since the websites haven't > been > much help for me. Please let me know if I should ask this on a different > part of the forum. > > I would really appreciate some help. I've found with computer stuff, there > is no such thing as over-explaining it to me! Thank you very much in > advance. > > > > -- > Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev -- Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE Open Source GIS Developer, GRASS GIS Development Team ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Try GRASS GIS online: rollApp - rollapp.com
Ah! /tmp works. Thanks! On Fri, Dec 20, 2019 at 9:35 PM Vaclav Petras wrote: > > > On Fri, Dec 20, 2019, 3:42 PM Huidae Cho wrote: > >> Vaclav, >> >> rollApp looks good, but it's read-only without a plan. I can start the >> GUI, but I cannot create a new location, which means no GRASS session. Is >> there a sample location there so I can actually try it in a read-only mode? >> > > There is a workaround: Change GRASS database directory to /tmp. Then, you > can download a sample location and work with it. > > Perhaps a state GRASS could detect and switch to /tmp automatically. > > > >> Thanks, >> Huidae >> >> On Fri, Dec 20, 2019 at 10:48 AM Vaclav Petras >> wrote: >> >>> Dear all, >>> >>> Following posts on Binder - mybinder.org [1] and CoCalc - cocalc.com >>> [2, 3], I would like to introduce also rollApp - rollapp.com, another >>> alternative for "Try online" link. It is a freemium service providing >>> access to many (mostly) open source applications through a web browser >>> (i.e., in cloud). You need to log in (e.g., with Google Account) to access >>> it and you can't save data without purchasing a plan, but you can run >>> applications and access the Internet. (With a plan, you can connect >>> different storage such as Drobox or Google Drive.) >>> >>> It can run GRASS GIS for couple years already. You can try it here: >>> >>> https://www.rollapp.com/app/grassgis (page with a Launch button) >>> https://www.rollapp.com/launch/grassgis (direct link with possibly >>> sub-optimal results) >>> >>> [1] https://lists.osgeo.org/pipermail/grass-dev/2019-August/093053.html >>> [2] https://lists.osgeo.org/pipermail/grass-dev/2019-August/093058.html >>> [3] >>> https://lists.osgeo.org/pipermail/grass-dev/2019-December/093910.html >>> >>> Right now, it would not work well as a "try online" tool, but it could. >>> Continue reading if you want to know details. >>> >>> I worked with them in the past I bit and made some fixes in GRASS GIS >>> which helped rollApp to start GRASS GIS. >>> >>> https://trac.osgeo.org/grass/changeset/70461 >>> https://trac.osgeo.org/grass/changeset/70335 >>> https://trac.osgeo.org/grass/changeset/70336 >>> https://trac.osgeo.org/grass/changeset/70450 >>> https://trac.osgeo.org/grass/changeset/70357 >>> >>> Some additional commits since then (for example, removal of tput) also >>> improved start in environments such as rollApp. >>> >>> >>> https://github.com/OSGeo/grass/commit/5c46b130ea50df148ebc73699974c2a621e15e4b >>> >>> One ongoing issue (which is possibly relevant to CoCalc, too) is that >>> GRASS GIS can start only with terminal. You can reproduce the issue locally >>> on Linux using `nohup grass` or, at least on Ubuntu with Unity, by pressing >>> Ctrl+F2 and typing "grass". >>> >>> https://trac.osgeo.org/grass/ticket/3295 >>> >>> Nevertheless, you can start GRASS GIS even with free account, in the >>> startup screen change the database directory to /tmp, download a sample >>> location, and start GRASS GIS. I think the GUI is little bit faster than in >>> CoCalc. The command line is worse than what you have in CoCalc (fixed size >>> xterm versus in-browser one). >>> >>> There is couple things which can be done in GRASS GIS or in rollApp to >>> make this a great "try online" option (even perhaps as a secondary one in >>> case we want to favor an open source platform). In any case, I would like >>> to find a place on the new website to have rollApp listed as one option for >>> using GRASS GIS online. >>> >>> Let me know what you think, >>> Vaclav >>> ___ >>> grass-dev mailing list >>> grass-dev@lists.osgeo.org >>> https://lists.osgeo.org/mailman/listinfo/grass-dev >> >> >> >> -- >> Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE >> Open Source GIS Developer, GRASS GIS Development Team >> > -- Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE Open Source GIS Developer, GRASS GIS Development Team ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Try GRASS GIS online: rollApp - rollapp.com
Vaclav, rollApp looks good, but it's read-only without a plan. I can start the GUI, but I cannot create a new location, which means no GRASS session. Is there a sample location there so I can actually try it in a read-only mode? Thanks, Huidae On Fri, Dec 20, 2019 at 10:48 AM Vaclav Petras wrote: > Dear all, > > Following posts on Binder - mybinder.org [1] and CoCalc - cocalc.com [2, > 3], I would like to introduce also rollApp - rollapp.com, another > alternative for "Try online" link. It is a freemium service providing > access to many (mostly) open source applications through a web browser > (i.e., in cloud). You need to log in (e.g., with Google Account) to access > it and you can't save data without purchasing a plan, but you can run > applications and access the Internet. (With a plan, you can connect > different storage such as Drobox or Google Drive.) > > It can run GRASS GIS for couple years already. You can try it here: > > https://www.rollapp.com/app/grassgis (page with a Launch button) > https://www.rollapp.com/launch/grassgis (direct link with possibly > sub-optimal results) > > [1] https://lists.osgeo.org/pipermail/grass-dev/2019-August/093053.html > [2] https://lists.osgeo.org/pipermail/grass-dev/2019-August/093058.html > [3] https://lists.osgeo.org/pipermail/grass-dev/2019-December/093910.html > > Right now, it would not work well as a "try online" tool, but it could. > Continue reading if you want to know details. > > I worked with them in the past I bit and made some fixes in GRASS GIS > which helped rollApp to start GRASS GIS. > > https://trac.osgeo.org/grass/changeset/70461 > https://trac.osgeo.org/grass/changeset/70335 > https://trac.osgeo.org/grass/changeset/70336 > https://trac.osgeo.org/grass/changeset/70450 > https://trac.osgeo.org/grass/changeset/70357 > > Some additional commits since then (for example, removal of tput) also > improved start in environments such as rollApp. > > > https://github.com/OSGeo/grass/commit/5c46b130ea50df148ebc73699974c2a621e15e4b > > One ongoing issue (which is possibly relevant to CoCalc, too) is that > GRASS GIS can start only with terminal. You can reproduce the issue locally > on Linux using `nohup grass` or, at least on Ubuntu with Unity, by pressing > Ctrl+F2 and typing "grass". > > https://trac.osgeo.org/grass/ticket/3295 > > Nevertheless, you can start GRASS GIS even with free account, in the > startup screen change the database directory to /tmp, download a sample > location, and start GRASS GIS. I think the GUI is little bit faster than in > CoCalc. The command line is worse than what you have in CoCalc (fixed size > xterm versus in-browser one). > > There is couple things which can be done in GRASS GIS or in rollApp to > make this a great "try online" option (even perhaps as a secondary one in > case we want to favor an open source platform). In any case, I would like > to find a place on the new website to have rollApp listed as one option for > using GRASS GIS online. > > Let me know what you think, > Vaclav > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev -- Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE Open Source GIS Developer, GRASS GIS Development Team ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] any special reason why choice of raster compression method is done via environmental variable ?
One workaround may be GRASS_COMPRESSOR=method r.compress, but it won't directly work on MS-Windows without a batch file, I think. Huidae On Tue, Dec 10, 2019 at 12:47 AM Moritz Lennert < mlenn...@club.worldonline.be> wrote: > On 9/12/19 22:50, Markus Metz wrote: > > Hi Moritz, > > > > On Wed, Dec 4, 2019 at 10:28 AM Moritz Lennert > > mailto:mlenn...@club.worldonline.be>> > wrote: > > > > > > Hi Markus, > > > > > > In recent days, I've been confronted several times with the issue of > > > people trying to share data among themselves, but using different > > > versions of GRASS, and so raster data compressed in a more recent > > > version of GRASS was not usable in an older version of GRASS. > > > > > > Now, I agree that generally the solution is to tell people to use the > > > latest and greatest, but this is not always possible / it is not > > > necessarily highest on the list of priorities of people to see how > they > > > can install the latest version of GRASS within their particular > > environment. > > > > > > Obviously, those with the latest version of GRASS can simple > recompress > > > using ZLIB. However, compression method is defined as an environment > > > variable. This is somewhat daunting to many MS Windows users out > there. > > > Is there any specific reason that lead to the choice of not using a > > > parameter to allow the choice of compression method (possibly to > > > override a default that is still defined by an environment variable) ? > > > > Such a parameter would need to be added to every module creating raster > > output. > > My request is more linked to use cases where one would like to share > data (e.g. with r.pack) with other GRASS GIS users who do not > necessarily have access to the same compression method, not necessarily > to changing the default compression method. I was just wondering whether > it might be easily possible to just implement r.compress method= as a > quick way to recompress a specific map with a chosen method, overriding > the default method. Currently, to do that, you have to change the > default method by changing the env variable, run r.compress, then change > the variable back to the value one wishes generally to use as default. > > Obviously, you can always just export as tiff and share that, but that > just feels less elegant. Anyway, this is probably somewhat of a luxury > problem :-) > > Moritz > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev -- Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE Open Source GIS Developer, GRASS GIS Development Team ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] load_env() issues in startup
OK.. Tried to work around this limitation by adding spaces and $HOME is now expanded into the location directory. Hmm... I kind of see why we're doing this. Maybe, better to fix load_env()? Huidae On Tue, Oct 29, 2019 at 8:59 PM Huidae Cho wrote: > Hi, > > Currently, .grass7/bashrc is partially broken. This file is read by two > functions in the startup script: load_env() and *_startup() ( > https://trac.osgeo.org/grass/ticket/3462). Commenting out export lines in > .grass7/bashrc doesn't work because load_env() splits each line twice (once > by space and once more by equal) to create environment variables without > ignoring commented lines. It doesn't matter whether a line is alias or > export, or whatever as long as it contains one space and one equal sign. > Also, load_env() doesn't expand environment variables in each line. For > example, the following two lines: > > alias vi='vim' > #export PATH="$PATH:grass/scripts" > export GDAL_DRIVER_PATH="$HOME/gdalplugins" > > would create three environment variables: > > vi="'vim'" > PATH="...grass paths...:\$PATH:grass/scripts" > GDAL_DRIVER_PATH="\$HOME/gdalplugins" > > The first variable is not meant to be created at all, PATH shouldn't be > modified because it's commented out, and GDAL_DRIVER_PATH is not usable > because $HOME is not expanded. > > Now, my question is why do we need a separate function load_env() to > "manually" create environment variables instead of just writing out all > these lines into .bashrc in the mapset and letting bash handling > everything? Is it by design or a bug? > > Regards, > Huidae > -- > Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE > Open Source GIS Developer, GRASS GIS Development Team > -- Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE Open Source GIS Developer, GRASS GIS Development Team ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] load_env() issues in startup
Hi, Currently, .grass7/bashrc is partially broken. This file is read by two functions in the startup script: load_env() and *_startup() ( https://trac.osgeo.org/grass/ticket/3462). Commenting out export lines in .grass7/bashrc doesn't work because load_env() splits each line twice (once by space and once more by equal) to create environment variables without ignoring commented lines. It doesn't matter whether a line is alias or export, or whatever as long as it contains one space and one equal sign. Also, load_env() doesn't expand environment variables in each line. For example, the following two lines: alias vi='vim' #export PATH="$PATH:grass/scripts" export GDAL_DRIVER_PATH="$HOME/gdalplugins" would create three environment variables: vi="'vim'" PATH="...grass paths...:\$PATH:grass/scripts" GDAL_DRIVER_PATH="\$HOME/gdalplugins" The first variable is not meant to be created at all, PATH shouldn't be modified because it's commented out, and GDAL_DRIVER_PATH is not usable because $HOME is not expanded. Now, my question is why do we need a separate function load_env() to "manually" create environment variables instead of just writing out all these lines into .bashrc in the mapset and letting bash handling everything? Is it by design or a bug? Regards, Huidae -- Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE Open Source GIS Developer, GRASS GIS Development Team ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GitHub: how to fwd pull requests to this list?
Are you sure you did git add? -a just adds "all changes". I remember add & -m only worked for me on Windows (msys2 git). Regards, Huidae -- Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE Open Source GIS Developer, GRASS GIS Development Team https://idea.isnew.info Sent from my phone On Mon, Jul 15, 2019, 7:04 PM Helmut Kudrnovsky wrote: > Markus Neteler wrote > > Hi > > > > Anna Petrášová < > > > kratochanna@ > > > > schrieb am Mo., 15. Juli 2019, 05:57: > > > >> > >> > >> On Fri, Jul 12, 2019 at 12:50 PM Maris Nartiss < > > > maris.gis@ > > > > > >> wrote: > >> > >>> The biggest question is – do we need PR notifications here. I would > >>> vote for no. Better let's keep discussions in one place. > >>> > >> > >> I agree, and I get the notifications: > >> > https://help.github.com/en/articles/watching-and-unwatching-repositories > >> > > > > > > Then please all promise to subscribe to the repo notifications and look > at > > them :) > > already subscribed. > > somekind related > > in https://trac.osgeo.org/grass/wiki/HowToGit there is mentioned: > > > # > vim ... > > # list local changes > git status > git add file1.c file2.py ... > git commit -m 'my change with reasonable explanation...' > > > at least here in the windows world of git I had to use > > > git commit -am 'my change with reasonable explanation...' > > > to add also the -a switch that anything happend :-D > > otherwise I get the message: > > > $ git commit -m 'add missing dependencies libgraphite2.dll and > libpcre-1.dll > - see https://trac.osgeo.org/grass/ticket/3870' > On branch wingrass_fixes > Changes not staged for commit: > modified: mswindows/osgeo4w/package.sh > > no changes added to commit > > > > > - > best regards > Helmut > -- > Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GitHub: how to fwd pull requests to this list?
Hi, The oldest PR is 2 months old. Using git for collaboration is very different from svn, I believe. Unlike with svn, you have to "actively" merge these PRs into your branch for testing (e.g., features interesting to you?) and wait for an approval from reviewers (?). Why did it not happen to these old PRs? Now, a less bigger question is no one cares about them and who is supposed to be responsible for reviewing and approving them? For example, https://github.com/OSGeo/grass/pull/52 fixes a very obvious formatting issue, which still needs to be approved? Tried to approve it myself, but self-nominating myself as a reviewer is pending... Hmm... Can I even merge it? The merge button seems to be activated. Confused... Best, Huidae On Mon, Jul 15, 2019 at 6:53 AM Markus Neteler wrote: > Hi > > Anna Petrášová schrieb am Mo., 15. Juli 2019, > 05:57: > >> >> >> On Fri, Jul 12, 2019 at 12:50 PM Maris Nartiss >> wrote: >> >>> The biggest question is – do we need PR notifications here. I would >>> vote for no. Better let's keep discussions in one place. >>> >> >> I agree, and I get the notifications: >> https://help.github.com/en/articles/watching-and-unwatching-repositories >> > > > Then please all promise to subscribe to the repo notifications and look at > them :) > > Thanks > Markus > > PS: with "lost" I meant that nobody cares/d. Perhaps since many didn't > subscribe to notifications yet... > >> >>> -- Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE Open Source GIS Developer, GRASS GIS Development Team ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Merging PRs
Greetings Developers, In https://trac.osgeo.org/grass/wiki/HowToGit, it is not clear who is responsible for merging PRs when. Are individual core developers encouraged (allowed?) or discouraged to merge them? I'm talking about core, not addons. How does it work? The main reason why I ask this question is because merging PRs into the upstream master takes time and I cannot wait until that happens (who, when?) to compile all my PRs into one build. If you create multiple branches off of master and create PRs, it wouldn't be easy to keep track of all those individual branches in one place and compile the personal "latest" version until the PRs get merged. For example, 1. master => feature1 2. master => feature2 Compiling feature1 and feature2 branches would only give me feature1 and feature2, respectively, but not both. Should I do something like this? 1. master => feature1 2. feature1 => feature2 Then, how can we make sure that there won't be any conflicts between my feature2 (<= feature1) branch and the OSGeo master? Not sure if what I'm doing is "right," but I'm doing this: 1. create a personal master branch "hcho" (yes, my name) 2. master => feature1 3. master => feature2 4. merge feature1 and feature2 into "hcho" 5. compile "hcho" To be honest, it's a lot of work :-(. Any suggestions or hints would be very welcome. Best Regards, Huidae -- Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE Open Source GIS Developer, GRASS GIS Development Team ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GitHub: how to fwd pull requests to this list?
Markus, I don't think that list has PR notifications. That's only for actual merges, not everything, if I'm not wrong. Best, Huidae On Fri, Jul 12, 2019 at 9:58 AM Markus Neteler wrote: > Hi, > > On Fri, Jul 12, 2019 at 6:12 AM Huidae Cho wrote: > > > > Markus, > > > > I think I have a workaround. In the worst case scenario, if GitHub > doesn't support notification forwarding, we could create a dummy GitHub > account just for notifications and set its email address to > grass-dev@lists.osgeo.org. > > Well, we do have this list: > > https://lists.osgeo.org/pipermail/grass-commit/ > > which contains everything from GitHub (I had set it up like this). > > But I would like to see _only_ the PRs also here and not clutter this > list with the other GH emails. > Not sure how to do that... > > Best > Markus > -- Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE Open Source GIS Developer, GRASS GIS Development Team ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GitHub: how to fwd pull requests to this list?
Markus, I think I have a workaround. In the worst case scenario, if GitHub doesn't support notification forwarding, we could create a dummy GitHub account just for notifications and set its email address to grass-dev@lists.osgeo.org. Just my thoughts. Regards, Huidae On Thu, Jul 11, 2019 at 11:39 PM Huidae Cho wrote: > And, maybe, this question is related. I don't receive any notifications > for my own PRs. PRs from other devs are OK. Is that normal? > > Thanks, > Huidae > > > On Thu, Jul 11, 2019 at 6:43 PM Markus Neteler wrote: > >> Hi, >> >> does anyone know how to how to forward GitHub pull requests to this list? >> >> They tend to get lost: >> https://github.com/OSGeo/grass/pulls >> https://github.com/OSGeo/grass-addons/pulls >> >> thanks >> Markus >> ___ >> grass-dev mailing list >> grass-dev@lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/grass-dev > > > > -- > Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE > Open Source GIS Developer, GRASS GIS Development Team > -- Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE Open Source GIS Developer, GRASS GIS Development Team ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GitHub: how to fwd pull requests to this list?
And, maybe, this question is related. I don't receive any notifications for my own PRs. PRs from other devs are OK. Is that normal? Thanks, Huidae On Thu, Jul 11, 2019 at 6:43 PM Markus Neteler wrote: > Hi, > > does anyone know how to how to forward GitHub pull requests to this list? > > They tend to get lost: > https://github.com/OSGeo/grass/pulls > https://github.com/OSGeo/grass-addons/pulls > > thanks > Markus > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev -- Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE Open Source GIS Developer, GRASS GIS Development Team ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wingrass builds status (git recover)
It's #48 (https://github.com/OSGeo/grass/pull/48). It fixes find_program. On Thu, Jul 11, 2019 at 4:05 PM Helmut Kudrnovsky wrote: > > >Hello, I experienced the exact same issue on Windows. One of my PRs should > fix it. > > thanks for your effort. > > which of your PR? > > next week I'll be able to test it locally in my winGRASS build environment. > > > > - > best regards > Helmut > -- > Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev -- Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE Open Source GIS Developer, GRASS GIS Development Team ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wingrass builds status (git recover)
Hello, I experienced the exact same issue on Windows. One of my PRs should fix it. Regards, Huidae -- Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE Open Source GIS Developer, GRASS GIS Development Team https://idea.isnew.info Sent from my phone On Sun, Jul 7, 2019, 3:53 PM Helmut Kudrnovsky wrote: > Hi Martin, > > > Martin Landa wrote > > Hi, > > > > I have recovered (at least partially) wingrass builds: > > > > * daily builds (GRASS 7.6 & 7.7: only 64bit builds) [standalone [1] & > > osgeo4w/grass-daily) are operational > > > > Up-to-date maintenance scripts available at [2]. > > > > In next days I will re-cover grass74 daily builds and more importantly > > release addons builds (7.4.4 & 7.6.1). > > thanks for your effort to bring winGRASS daily builds back > > tested here with the OSGeo4W 64bit dailys. > > following issue when downloading OSGeo4W grass-daily-7.7.dev-f79c3568d-1: > > ° g.mkfontcap.exe - system error because libgraphite2.dll and libpcre-1.dll > can't be found > ° "inflateValidate" in the dll > C:\OSGeo4W\apps\grass\grass77\bin\libpng16-16.dll can't be found > > regarding the last issue item, in C:\OSGeo4W\apps\grass\grass77\bin\ there > shouldn't be any foreign dll, right? > > looking into it > > C:\OSGeo4W64\apps\grass\grass77\bin>ls | grep lib > libbz2-1.dll > libexpat-1.dll > libfontconfig-1.dll > libfreetype-6.dll > libgcc_s_seh-1.dll > libglib-2.0-0.dll > libharfbuzz-0.dll > libiconv-2.dll > libintl-8.dll > libpng16-16.dll > libstdc++-6.dll > libsystre-0.dll > libtre-5.dll > libwinpthread-1.dll > test.raster3d.lib.exe > zlib1.dll > > downloading > > https://wingrass.fsv.cvut.cz/grass77/x86_64/osgeo4w/grass-daily-7.7.dev-f79c3568d-1.tar.bz2 > > > D:\temp\wwf\grass-daily-7.7.dev-f79c3568d-1.tar\grass-daily-7.7.dev-f79c3568d-1\apps\grass\grass77\bin>ls > | grep lib > libbz2-1.dll > libexpat-1.dll > libfontconfig-1.dll > libfreetype-6.dll > libgcc_s_seh-1.dll > libglib-2.0-0.dll > libharfbuzz-0.dll > libiconv-2.dll > libintl-8.dll > libpng16-16.dll > libstdc++-6.dll > libsystre-0.dll > libtre-5.dll > libwinpthread-1.dll > test.raster3d.lib.exe > zlib1.dll > > these dlls are in > > grass-daily-7.7.dev-f79c3568d-1.tar\grass-daily-7.7.dev-f79c3568d-1\apps\grass\grass77\bin > > any idea about that? > > these dlls maybe are the reason for > > Starting GRASS GIS... > WARNUNG: Sperren gleichzeitiger Zugriffe auf ein Mapset ist unter Windows > nicht möglich. > Cleaning up temporary files... > > __ ___ _____ > / / __ \/ | / ___/ ___/ / / _/ ___/ > / / __/ /_/ / /| | \__ \\_ \ / / __ / / \__ \ >/ /_/ / _, _/ ___ |___/ /__/ / / /_/ // / ___/ / >\/_/ |_/_/ |_/// \/___/// > > Welcome to GRASS GIS 7.7.dev > GRASS GIS homepage: https://grass.osgeo.org > This version running through:Command Prompt > (C:\WINDOWS\system32\cmd.exe) > Help is available with the command: g.manual -i > See the licence terms with: g.version -c > See citation options with: g.version -x > If required, restart the GUI with: g.gui wxpython > When ready to quit enter:exit > > Launching GUI in the background, please wait... > Microsoft Windows [Version 10.0.18362.175] > (c) 2019 Microsoft Corporation. Alle Rechte vorbehalten. > > C:\>C:\OSGEO4~1\apps\grass\grass77\gui\wxpython\wxgui.py:101: > DeprecationWarning: Yield() is deprecated > wx.Yield() > GRASS Modul 'g.proj' nicht gefunden. Kann Kartenfenster nicht starten. > Error in atexit._run_exitfuncs: > wx._core.wxAssertionError: C++ assertion "GetEventHandler() == this" failed > at ..\..\src\common\wincmn.cpp(478) in wxWindowBase::~wxWindowBase(): any > pushed event handlers must have been removed > > > > > > > > > > - > best regards > Helmut > -- > Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Switching addon manual pages to point to grass76 ?
Markus, Maybe, it's related. That URL has only a few addon manuals. Do you have any idea what happened to other manuals? Thanks, Huidae On Mon, Mar 4, 2019 at 11:27 AM Markus Neteler wrote: > On Wed, Feb 20, 2019 at 10:39 AM Markus Neteler wrote: > > On Fri, Feb 15, 2019 at 10:18 PM Markus Neteler > wrote: > > > so far the addons still point to > > > https://grass.osgeo.org/grass74/manuals/addons/ > > > > > > Besides an Apache server rule change I have to do server-side, what > > > else needs to be done? > > > > ping > > ping again ... > > I can easily switch it on the server but I am not sure if that would be > enough? > > Markus > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev -- Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE Open Source GIS Developer, GRASS GIS Development Team ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r73995 - grass/trunk/scripts/v.db.addtable
r74043 works. Thanks, Huidae On Wed, Jan 30, 2019 at 4:20 AM Markus Metz wrote: > > > On Wed, Jan 30, 2019 at 9:42 AM Markus Metz > wrote: > > > > > > > > On Tue, Jan 29, 2019 at 11:37 PM Huidae Cho wrote: > > > > > > Just for our records, actually, PostgreSQL 9.5+ supports CREATE INDEX > IF NOT EXISTS, which the grass sqlite driver already does (this is why we > didn't have this warning with sqlite before). Not sure if we want to > enforce the minimum version for a specific database though. > > > > We can use "if not exists" for PostgreSQL 9.5+, otherwise not, please > try trunk r74042. > > trunk r74043 > > > > Markus M > > > > > > Best, > > > Huidae > > > > > > On Tue, Jan 29, 2019 at 5:16 PM Huidae Cho wrote: > > >> > > >> I just did a quick search and found that these modules > (i.segment.stats, r.mwprecip, v.in.geopaparazzi, v.link.precip, v.out.gps, > v.ply.rectify, v.unpack) create/copy new tables themselves without the > index and invoke v.db.connect. For now, we cannot move index creation to > v.db.addtable. > > >> > > >> Huidae > > >> > > >> On Tue, Jan 29, 2019 at 4:12 PM Huidae Cho wrote: > > >>> > > >>> Yes. Like you said, v.db.connect followed by v.db.connect -d gives > me the same pg errors and grass warning. I agree with you that the > preferred solution would be to create the index in v.db.addtable, not in > v.db.connect "if" no modules rely on v.db.connect for creating the unique > index. > > >>> > > >>> Huidae > > >>> > > >>> > > >>> > > >>> > > >>> On Tue, Jan 29, 2019 at 3:51 PM Markus Metz < > markus.metz.gisw...@gmail.com> wrote: > > >>>> > > >>>> > > >>>> > > >>>> On Tue, Jan 29, 2019 at 4:12 PM Huidae Cho > wrote: > > >>>> > > > >>>> > You're right. It was a warning with PostgresSQL error messages > (attached below), not a fatal error. But I don't think there should be any > warning (or PostgreSQL errors) because the user didn't do anything wrong > here (v.edit map tool=create; v.db.addtable). > > >>>> > > >>>> Hmm yes I agree. At least for v.db.addtable the index can be > created by v.db.connect when the new table is actually linked to the vector > map. > > >>>> > > >>>> You might still get these PG errors when you try to connect an > already existing table, but this is probably not happening very often, and > v.db.connect finishes anyway. > > >>>> > > >>>> Markus M > > >>>> > > >>>> > > > >>>> > DBMI-PostgreSQL driver error: > > >>>> > Unable to create index: create unique index tmp2_cat on tmp2 ( > cat ) > > >>>> > ERROR: relation "tmp2_cat" already exists > > >>>> > > > >>>> > > > >>>> > DBMI-PostgreSQL driver error: > > >>>> > Unable to create index: create unique index tmp2_cat on tmp2 ( > cat ) > > >>>> > ERROR: relation "tmp2_cat" already exists > > >>>> > > > >>>> > > > >>>> > WARNING: Cannot create index > > >>>> > here > > >>>> > WARNING: Values in column will be overwritten > > >>>> > Reading features... > > >>>> > 100% > > >>>> > Updating database... > > >>>> > 100% > > >>>> > > > >>>> > Huidae > > >>>> > > > >>>> > On Tue, Jan 29, 2019 at 9:37 AM Markus Metz < > markus.metz.gisw...@gmail.com> wrote: > > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> On Sun, Jan 27, 2019 at 11:21 AM Markus Metz < > markus.metz.gisw...@gmail.com> wrote: > > >>>> >> > > > >>>> >> > > > >>>> >> > > > >>>> >> > On Sat, Jan 26, 2019 at 2:50 PM Huidae Cho > wrote: > > >>>> >> > > > > >>>> >> > > Markus, > > >>>> >> > > > > >>>> >> > > If there is a linked table, v.db.addtable stops in line
Re: [GRASS-dev] [GRASS-SVN] r73995 - grass/trunk/scripts/v.db.addtable
Just for our records, actually, PostgreSQL 9.5+ supports CREATE INDEX IF NOT EXISTS, which the grass sqlite driver already does (this is why we didn't have this warning with sqlite before). Not sure if we want to enforce the minimum version for a specific database though. Best, Huidae On Tue, Jan 29, 2019 at 5:16 PM Huidae Cho wrote: > I just did a quick search and found that these modules (i.segment.stats, > r.mwprecip, v.in.geopaparazzi, v.link.precip, v.out.gps, v.ply.rectify, > v.unpack) create/copy new tables themselves without the index and invoke > v.db.connect. For now, we cannot move index creation to v.db.addtable. > > Huidae > > On Tue, Jan 29, 2019 at 4:12 PM Huidae Cho wrote: > >> Yes. Like you said, v.db.connect followed by v.db.connect -d gives me the >> same pg errors and grass warning. I agree with you that the preferred >> solution would be to create the index in v.db.addtable, not in v.db.connect >> "if" no modules rely on v.db.connect for creating the unique index. >> >> Huidae >> >> >> >> >> On Tue, Jan 29, 2019 at 3:51 PM Markus Metz < >> markus.metz.gisw...@gmail.com> wrote: >> >>> >>> >>> On Tue, Jan 29, 2019 at 4:12 PM Huidae Cho wrote: >>> > >>> > You're right. It was a warning with PostgresSQL error messages >>> (attached below), not a fatal error. But I don't think there should be any >>> warning (or PostgreSQL errors) because the user didn't do anything wrong >>> here (v.edit map tool=create; v.db.addtable). >>> >>> Hmm yes I agree. At least for v.db.addtable the index can be created by >>> v.db.connect when the new table is actually linked to the vector map. >>> >>> You might still get these PG errors when you try to connect an already >>> existing table, but this is probably not happening very often, and >>> v.db.connect finishes anyway. >>> >>> Markus M >>> >>> > >>> > DBMI-PostgreSQL driver error: >>> > Unable to create index: create unique index tmp2_cat on tmp2 ( cat ) >>> > ERROR: relation "tmp2_cat" already exists >>> > >>> > >>> > DBMI-PostgreSQL driver error: >>> > Unable to create index: create unique index tmp2_cat on tmp2 ( cat ) >>> > ERROR: relation "tmp2_cat" already exists >>> > >>> > >>> > WARNING: Cannot create index >>> > here >>> > WARNING: Values in column will be overwritten >>> > Reading features... >>> > 100% >>> > Updating database... >>> > 100% >>> > >>> > Huidae >>> > >>> > On Tue, Jan 29, 2019 at 9:37 AM Markus Metz < >>> markus.metz.gisw...@gmail.com> wrote: >>> >> >>> >> >>> >> >>> >> On Sun, Jan 27, 2019 at 11:21 AM Markus Metz < >>> markus.metz.gisw...@gmail.com> wrote: >>> >> > >>> >> > >>> >> > >>> >> > On Sat, Jan 26, 2019 at 2:50 PM Huidae Cho >>> wrote: >>> >> > > >>> >> > > Markus, >>> >> > > >>> >> > > If there is a linked table, v.db.addtable stops in line 106. If >>> not, this script doesn't create a unique index and calls v.db.connect. >>> v.db.connect adds a db link in line 317 and creates a unique index >>> (db_create_index2) in line 334 if linking was successful. SQLite didn't >>> complain when both modules created the same unique index, but PostgreSQL >>> failed in v.db.connect (2nd time creating the same unique index). >>> >> >>> >> What do you mean with "failed"? v.db.connect will issue a warning if >>> it can not create an index but finish successfully. >>> >> >>> >> Markus M >>> >> >>> >> >> Not sure which code was added first/later. I think it's more of >>> how we design both modules. v.db.connect will fail if we try to link a >>> table with a unique index. Isn't v.db.connect supposed to "just" connect a >>> table to a layer (without creating any database objects like index)? Which >>> module should be responsible for creating unique indices? >>> >> > > >>> >> > > Before this commit: >>> >> > > 1. v.db.addtable creates unique index >>> >> > > 2. v.db.connect tries to cre
Re: [GRASS-dev] [GRASS-SVN] r73995 - grass/trunk/scripts/v.db.addtable
I just did a quick search and found that these modules (i.segment.stats, r.mwprecip, v.in.geopaparazzi, v.link.precip, v.out.gps, v.ply.rectify, v.unpack) create/copy new tables themselves without the index and invoke v.db.connect. For now, we cannot move index creation to v.db.addtable. Huidae On Tue, Jan 29, 2019 at 4:12 PM Huidae Cho wrote: > Yes. Like you said, v.db.connect followed by v.db.connect -d gives me the > same pg errors and grass warning. I agree with you that the preferred > solution would be to create the index in v.db.addtable, not in v.db.connect > "if" no modules rely on v.db.connect for creating the unique index. > > Huidae > > > > > On Tue, Jan 29, 2019 at 3:51 PM Markus Metz > wrote: > >> >> >> On Tue, Jan 29, 2019 at 4:12 PM Huidae Cho wrote: >> > >> > You're right. It was a warning with PostgresSQL error messages >> (attached below), not a fatal error. But I don't think there should be any >> warning (or PostgreSQL errors) because the user didn't do anything wrong >> here (v.edit map tool=create; v.db.addtable). >> >> Hmm yes I agree. At least for v.db.addtable the index can be created by >> v.db.connect when the new table is actually linked to the vector map. >> >> You might still get these PG errors when you try to connect an already >> existing table, but this is probably not happening very often, and >> v.db.connect finishes anyway. >> >> Markus M >> >> > >> > DBMI-PostgreSQL driver error: >> > Unable to create index: create unique index tmp2_cat on tmp2 ( cat ) >> > ERROR: relation "tmp2_cat" already exists >> > >> > >> > DBMI-PostgreSQL driver error: >> > Unable to create index: create unique index tmp2_cat on tmp2 ( cat ) >> > ERROR: relation "tmp2_cat" already exists >> > >> > >> > WARNING: Cannot create index >> > here >> > WARNING: Values in column will be overwritten >> > Reading features... >> > 100% >> > Updating database... >> > 100% >> > >> > Huidae >> > >> > On Tue, Jan 29, 2019 at 9:37 AM Markus Metz < >> markus.metz.gisw...@gmail.com> wrote: >> >> >> >> >> >> >> >> On Sun, Jan 27, 2019 at 11:21 AM Markus Metz < >> markus.metz.gisw...@gmail.com> wrote: >> >> > >> >> > >> >> > >> >> > On Sat, Jan 26, 2019 at 2:50 PM Huidae Cho >> wrote: >> >> > > >> >> > > Markus, >> >> > > >> >> > > If there is a linked table, v.db.addtable stops in line 106. If >> not, this script doesn't create a unique index and calls v.db.connect. >> v.db.connect adds a db link in line 317 and creates a unique index >> (db_create_index2) in line 334 if linking was successful. SQLite didn't >> complain when both modules created the same unique index, but PostgreSQL >> failed in v.db.connect (2nd time creating the same unique index). >> >> >> >> What do you mean with "failed"? v.db.connect will issue a warning if >> it can not create an index but finish successfully. >> >> >> >> Markus M >> >> >> >> >> Not sure which code was added first/later. I think it's more of how >> we design both modules. v.db.connect will fail if we try to link a table >> with a unique index. Isn't v.db.connect supposed to "just" connect a table >> to a layer (without creating any database objects like index)? Which module >> should be responsible for creating unique indices? >> >> > > >> >> > > Before this commit: >> >> > > 1. v.db.addtable creates unique index >> >> > > 2. v.db.connect tries to create unique index again ==> fatal error >> >> > > >> >> > > After this commit: >> >> > > 1. v.db.addtable doesn't create unique index >> >> > > 2. v.db.connect creates unique index >> >> > > >> >> > > Probably, it should be: >> >> > > 1. v.db.addtable should create unique index >> >> > > 2. v.db.connect shouldn't try to create unique index? Just >> "connect"... >> >> > >> >> > Yes, this is the preferred solution. Consider v.db.connect -d >> followed by v.db.connect, i.e. disconnecting a table and then reconnecting >> the same table: in this case v.db.connect sh
Re: [GRASS-dev] [GRASS-SVN] r73995 - grass/trunk/scripts/v.db.addtable
Yes. Like you said, v.db.connect followed by v.db.connect -d gives me the same pg errors and grass warning. I agree with you that the preferred solution would be to create the index in v.db.addtable, not in v.db.connect "if" no modules rely on v.db.connect for creating the unique index. Huidae On Tue, Jan 29, 2019 at 3:51 PM Markus Metz wrote: > > > On Tue, Jan 29, 2019 at 4:12 PM Huidae Cho wrote: > > > > You're right. It was a warning with PostgresSQL error messages (attached > below), not a fatal error. But I don't think there should be any warning > (or PostgreSQL errors) because the user didn't do anything wrong here > (v.edit map tool=create; v.db.addtable). > > Hmm yes I agree. At least for v.db.addtable the index can be created by > v.db.connect when the new table is actually linked to the vector map. > > You might still get these PG errors when you try to connect an already > existing table, but this is probably not happening very often, and > v.db.connect finishes anyway. > > Markus M > > > > > DBMI-PostgreSQL driver error: > > Unable to create index: create unique index tmp2_cat on tmp2 ( cat ) > > ERROR: relation "tmp2_cat" already exists > > > > > > DBMI-PostgreSQL driver error: > > Unable to create index: create unique index tmp2_cat on tmp2 ( cat ) > > ERROR: relation "tmp2_cat" already exists > > > > > > WARNING: Cannot create index > > here > > WARNING: Values in column will be overwritten > > Reading features... > > 100% > > Updating database... > > 100% > > > > Huidae > > > > On Tue, Jan 29, 2019 at 9:37 AM Markus Metz < > markus.metz.gisw...@gmail.com> wrote: > >> > >> > >> > >> On Sun, Jan 27, 2019 at 11:21 AM Markus Metz < > markus.metz.gisw...@gmail.com> wrote: > >> > > >> > > >> > > >> > On Sat, Jan 26, 2019 at 2:50 PM Huidae Cho wrote: > >> > > > >> > > Markus, > >> > > > >> > > If there is a linked table, v.db.addtable stops in line 106. If > not, this script doesn't create a unique index and calls v.db.connect. > v.db.connect adds a db link in line 317 and creates a unique index > (db_create_index2) in line 334 if linking was successful. SQLite didn't > complain when both modules created the same unique index, but PostgreSQL > failed in v.db.connect (2nd time creating the same unique index). > >> > >> What do you mean with "failed"? v.db.connect will issue a warning if it > can not create an index but finish successfully. > >> > >> Markus M > >> > >> >> Not sure which code was added first/later. I think it's more of how > we design both modules. v.db.connect will fail if we try to link a table > with a unique index. Isn't v.db.connect supposed to "just" connect a table > to a layer (without creating any database objects like index)? Which module > should be responsible for creating unique indices? > >> > > > >> > > Before this commit: > >> > > 1. v.db.addtable creates unique index > >> > > 2. v.db.connect tries to create unique index again ==> fatal error > >> > > > >> > > After this commit: > >> > > 1. v.db.addtable doesn't create unique index > >> > > 2. v.db.connect creates unique index > >> > > > >> > > Probably, it should be: > >> > > 1. v.db.addtable should create unique index > >> > > 2. v.db.connect shouldn't try to create unique index? Just > "connect"... > >> > > >> > Yes, this is the preferred solution. Consider v.db.connect -d > followed by v.db.connect, i.e. disconnecting a table and then reconnecting > the same table: in this case v.db.connect should also fail with PostgreSQL. > IMHO, a unique index should only be created when the table is created. > >> > > >> > Markus M > >> > > >> > > > >> > > Regards, > >> > > Huidae > >> > > > >> > > On Sat, Jan 26, 2019 at 7:39 AM Markus Neteler > wrote: > >> > >> > >> > >> Hi, > >> > >> > >> > >> On Tue, Jan 22, 2019 at 3:51 AM wrote: > >> > >> > > >> > >> > Author: hcho > >> > >> > Date: 2019-01-21 18:51:33 -0800 (Mon, 21 Jan 2019) > >> > >> > New Revision: 73995 > >> >
Re: [GRASS-dev] [GRASS-SVN] r73995 - grass/trunk/scripts/v.db.addtable
You're right. It was a warning with PostgresSQL error messages (attached
below), not a fatal error. But I don't think there should be any warning
(or PostgreSQL errors) because the user didn't do anything wrong here
(v.edit map tool=create; v.db.addtable).
DBMI-PostgreSQL driver error:
Unable to create index: create unique index tmp2_cat on tmp2 ( cat )
ERROR: relation "tmp2_cat" already exists
DBMI-PostgreSQL driver error:
Unable to create index: create unique index tmp2_cat on tmp2 ( cat )
ERROR: relation "tmp2_cat" already exists
WARNING: Cannot create index
here
WARNING: Values in column will be overwritten
Reading features...
100%
Updating database...
100%
Huidae
On Tue, Jan 29, 2019 at 9:37 AM Markus Metz
wrote:
>
>
> On Sun, Jan 27, 2019 at 11:21 AM Markus Metz <
> markus.metz.gisw...@gmail.com> wrote:
> >
> >
> >
> > On Sat, Jan 26, 2019 at 2:50 PM Huidae Cho wrote:
> > >
> > > Markus,
> > >
> > > If there is a linked table, v.db.addtable stops in line 106. If not,
> this script doesn't create a unique index and calls v.db.connect.
> v.db.connect adds a db link in line 317 and creates a unique index
> (db_create_index2) in line 334 if linking was successful. SQLite didn't
> complain when both modules created the same unique index, but PostgreSQL
> failed in v.db.connect (2nd time creating the same unique index).
>
> What do you mean with "failed"? v.db.connect will issue a warning if it
> can not create an index but finish successfully.
>
> Markus M
>
> >> Not sure which code was added first/later. I think it's more of how we
> design both modules. v.db.connect will fail if we try to link a table with
> a unique index. Isn't v.db.connect supposed to "just" connect a table to a
> layer (without creating any database objects like index)? Which module
> should be responsible for creating unique indices?
> > >
> > > Before this commit:
> > > 1. v.db.addtable creates unique index
> > > 2. v.db.connect tries to create unique index again ==> fatal error
> > >
> > > After this commit:
> > > 1. v.db.addtable doesn't create unique index
> > > 2. v.db.connect creates unique index
> > >
> > > Probably, it should be:
> > > 1. v.db.addtable should create unique index
> > > 2. v.db.connect shouldn't try to create unique index? Just "connect"...
> >
> > Yes, this is the preferred solution. Consider v.db.connect -d followed
> by v.db.connect, i.e. disconnecting a table and then reconnecting the same
> table: in this case v.db.connect should also fail with PostgreSQL. IMHO, a
> unique index should only be created when the table is created.
> >
> > Markus M
> >
> > >
> > > Regards,
> > > Huidae
> > >
> > > On Sat, Jan 26, 2019 at 7:39 AM Markus Neteler
> wrote:
> > >>
> > >> Hi,
> > >>
> > >> On Tue, Jan 22, 2019 at 3:51 AM wrote:
> > >> >
> > >> > Author: hcho
> > >> > Date: 2019-01-21 18:51:33 -0800 (Mon, 21 Jan 2019)
> > >> > New Revision: 73995
> > >> >
> > >> > Modified:
> > >> >grass/trunk/scripts/v.db.addtable/v.db.addtable.py
> > >> > Log:
> > >> > v.db.addtable: Do not create unique index from this script;
> v.db.connect will try to create it again causing some drivers to fail
> (PostgreSQL)
> > >> >
> > >> > Modified: grass/trunk/scripts/v.db.addtable/v.db.addtable.py
> > >> > ===
> > >> > --- grass/trunk/scripts/v.db.addtable/v.db.addtable.py 2019-01-21
> 22:37:59 UTC (rev 73994)
> > >> > +++ grass/trunk/scripts/v.db.addtable/v.db.addtable.py 2019-01-22
> 02:51:33 UTC (rev 73995)
> > >> > @@ -139,16 +139,6 @@
> > >> > except CalledModuleError:
> > >> > grass.fatal(_("Unable to create table <%s>") % table)
> > >> >
> > >> > -# create index, see db/driver/*/index.c
> > >> > -if driver != "dbf":
> > >> > -sql = "CREATE UNIQUE INDEX %s_%s ON %s (%s)" % (table,
> key, table, key)
> > >> > -try:
> > >> > -grass.run_command('db.execute',
> > >> > - database=database,
> driver=driver, sql=sql)
Re: [GRASS-dev] [GRASS-SVN] r73995 - grass/trunk/scripts/v.db.addtable
Or maybe, to be more flexible...
1. v.db.addtable doesn't create unique index
2. v.db.connect creates unique index "only if" there is no unique index
Just my 2 cents
On Sat, Jan 26, 2019 at 8:50 AM Huidae Cho wrote:
> Markus,
>
> If there is a linked table, v.db.addtable stops in line 106. If not, this
> script doesn't create a unique index and calls v.db.connect. v.db.connect
> adds a db link in line 317 and creates a unique index (db_create_index2) in
> line 334 if linking was successful. SQLite didn't complain when both
> modules created the same unique index, but PostgreSQL failed in
> v.db.connect (2nd time creating the same unique index). Not sure which code
> was added first/later. I think it's more of how we design both modules.
> v.db.connect will fail if we try to link a table with a unique index. Isn't
> v.db.connect supposed to "just" connect a table to a layer (without
> creating any database objects like index)? Which module should be
> responsible for creating unique indices?
>
> Before this commit:
> 1. v.db.addtable creates unique index
> 2. v.db.connect tries to create unique index again ==> fatal error
>
> After this commit:
> 1. v.db.addtable doesn't create unique index
> 2. v.db.connect creates unique index
>
> Probably, it should be:
> 1. v.db.addtable should create unique index
> 2. v.db.connect shouldn't try to create unique index? Just "connect"...
>
> Regards,
> Huidae
>
> On Sat, Jan 26, 2019 at 7:39 AM Markus Neteler wrote:
>
>> Hi,
>>
>> On Tue, Jan 22, 2019 at 3:51 AM wrote:
>> >
>> > Author: hcho
>> > Date: 2019-01-21 18:51:33 -0800 (Mon, 21 Jan 2019)
>> > New Revision: 73995
>> >
>> > Modified:
>> >grass/trunk/scripts/v.db.addtable/v.db.addtable.py
>> > Log:
>> > v.db.addtable: Do not create unique index from this script;
>> v.db.connect will try to create it again causing some drivers to fail
>> (PostgreSQL)
>> >
>> > Modified: grass/trunk/scripts/v.db.addtable/v.db.addtable.py
>> > ===
>> > --- grass/trunk/scripts/v.db.addtable/v.db.addtable.py 2019-01-21
>> 22:37:59 UTC (rev 73994)
>> > +++ grass/trunk/scripts/v.db.addtable/v.db.addtable.py 2019-01-22
>> 02:51:33 UTC (rev 73995)
>> > @@ -139,16 +139,6 @@
>> > except CalledModuleError:
>> > grass.fatal(_("Unable to create table <%s>") % table)
>> >
>> > -# create index, see db/driver/*/index.c
>> > -if driver != "dbf":
>> > -sql = "CREATE UNIQUE INDEX %s_%s ON %s (%s)" % (table,
>> key, table, key)
>> > -try:
>> > -grass.run_command('db.execute',
>> > - database=database, driver=driver,
>> sql=sql)
>> > -except:
>> > -grass.warning(_("Unable to create index on table
>> <%s>") % table)
>> > -pass
>> > -
>> > # connect the map to the DB:
>> > if schema:
>> > table = '{schema}.{table}'.format(schema=schema, table=table)
>>
>> just a conceptual question:
>> ... are we sure that this index creation removal never leads to a
>> table without index?
>>
>> Markus
>>
>
>
> --
> Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE
> Open Source GIS Developer, GRASS GIS Development Team
>
--
Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE
Open Source GIS Developer, GRASS GIS Development Team
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r73995 - grass/trunk/scripts/v.db.addtable
Markus,
If there is a linked table, v.db.addtable stops in line 106. If not, this
script doesn't create a unique index and calls v.db.connect. v.db.connect
adds a db link in line 317 and creates a unique index (db_create_index2) in
line 334 if linking was successful. SQLite didn't complain when both
modules created the same unique index, but PostgreSQL failed in
v.db.connect (2nd time creating the same unique index). Not sure which code
was added first/later. I think it's more of how we design both modules.
v.db.connect will fail if we try to link a table with a unique index. Isn't
v.db.connect supposed to "just" connect a table to a layer (without
creating any database objects like index)? Which module should be
responsible for creating unique indices?
Before this commit:
1. v.db.addtable creates unique index
2. v.db.connect tries to create unique index again ==> fatal error
After this commit:
1. v.db.addtable doesn't create unique index
2. v.db.connect creates unique index
Probably, it should be:
1. v.db.addtable should create unique index
2. v.db.connect shouldn't try to create unique index? Just "connect"...
Regards,
Huidae
On Sat, Jan 26, 2019 at 7:39 AM Markus Neteler wrote:
> Hi,
>
> On Tue, Jan 22, 2019 at 3:51 AM wrote:
> >
> > Author: hcho
> > Date: 2019-01-21 18:51:33 -0800 (Mon, 21 Jan 2019)
> > New Revision: 73995
> >
> > Modified:
> >grass/trunk/scripts/v.db.addtable/v.db.addtable.py
> > Log:
> > v.db.addtable: Do not create unique index from this script; v.db.connect
> will try to create it again causing some drivers to fail (PostgreSQL)
> >
> > Modified: grass/trunk/scripts/v.db.addtable/v.db.addtable.py
> > ===
> > --- grass/trunk/scripts/v.db.addtable/v.db.addtable.py 2019-01-21
> 22:37:59 UTC (rev 73994)
> > +++ grass/trunk/scripts/v.db.addtable/v.db.addtable.py 2019-01-22
> 02:51:33 UTC (rev 73995)
> > @@ -139,16 +139,6 @@
> > except CalledModuleError:
> > grass.fatal(_("Unable to create table <%s>") % table)
> >
> > -# create index, see db/driver/*/index.c
> > -if driver != "dbf":
> > -sql = "CREATE UNIQUE INDEX %s_%s ON %s (%s)" % (table, key,
> table, key)
> > -try:
> > -grass.run_command('db.execute',
> > - database=database, driver=driver,
> sql=sql)
> > -except:
> > -grass.warning(_("Unable to create index on table <%s>")
> % table)
> > - pass
> > -
> > # connect the map to the DB:
> > if schema:
> > table = '{schema}.{table}'.format(schema=schema, table=table)
>
> just a conceptual question:
> ... are we sure that this index creation removal never leads to a
> table without index?
>
> Markus
>
--
Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE
Open Source GIS Developer, GRASS GIS Development Team
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] difference between r.drain and r.path
Hello, I had the same question before. These two modules are almost the same. Actually, r.drain is a wrapper for r.path and creates input directions internally, then just runs r.path. Not sure if it's worth keeping it just for that extra step. Best, Huidae On Thu, Jan 24, 2019 at 3:29 AM Moritz Lennert wrote: > Hi, > > In GRASS 7.6 we have both r.drain and r.path. What is the difference > between the two ? Should r.drain be declared as deprecated and replaced > by r.path ? > > Moritz > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev -- Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE Open Source GIS Developer, GRASS GIS Development Team ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.delaunay3d error
I tried static_cast, but it didn't work (not sure why). C-style casting and
reinterpret_cast worked though.
Huidae
On Tue, Dec 25, 2018 at 5:16 PM Markus Neteler wrote:
> On Thu, Dec 20, 2018 at 6:39 PM Huidae Cho wrote:
> > Hello Martin,
> >
> > I'm getting this error when compiling your v.delaunay3d addon with CGAL
> 4.13:
> >
> > main.cpp:106:11: error: cannot convert 'DelaunayTriangulation* {aka
> CGAL::Delaunay_triangulation_3*}' to 'Triangulation* {ask
> CGAL::Triangulation_3*}' in assignment
> > T = new DelaunayTriangulation(points.begin(), points.end());
> >
> > Maybe, simple type casting, but I'm not a C++ expert. Any idea?
>
> Perhaps you can get some ideas from this example?
>
>
> https://github.com/CGAL/cgal/blob/master/Triangulation_3/examples/Triangulation_3/simple_triangulation_3.cpp
>
> Markus
>
--
Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE
Open Source GIS Developer, GRASS GIS Development Team
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] v.delaunay3d error
Hello Martin,
I'm getting this error when compiling your v.delaunay3d addon with CGAL
4.13:
main.cpp:106:11: error: cannot convert 'DelaunayTriangulation* {aka
CGAL::Delaunay_triangulation_3*}' to 'Triangulation* {ask
CGAL::Triangulation_3*}' in assignment
T = new DelaunayTriangulation(points.begin(), points.end());
Maybe, simple type casting, but I'm not a C++ expert. Any idea?
Regards,
Huidae
--
Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE
Open Source GIS Developer, GRASS GIS Development Team
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Exclusive rule between '--o' and another custom flag
Nikos, I don't think that's possible. parser_dependencies.c only supports user-defined options and flags, but you can use grass.overwrite() to implement your own rules. Thanks, Huidae On Thu, Dec 13, 2018 at 8:56 AM Nikos Alexandris wrote: > > Dears, > > is it possible to define an exclusive rule between the 'overwrite' flag > and any other custom flag, in a GRASS GIS script? > > The following is, of course, not possible: > > #%rules > #% exclusive: --o, -s > #%end > > Thank you, Nikos > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev -- Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE Open Source GIS Developer, GRASS GIS Development Team ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r73769 - grass/trunk/locale/po
Sure, no problem. It was just faster to do Korean only for testing. Huidae On Sat, Dec 8, 2018 at 7:10 AM Markus Neteler wrote: > On Fri, Dec 7, 2018 at 5:14 PM Huidae Cho wrote: > > > > Yes, I did use the transifex_merge script (changed -a to -l ko). > > Feel free to just update all language files at the same time :-) > > Markus > -- Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE Open Source GIS Developer, GRASS GIS Development Team ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r73769 - grass/trunk/locale/po
Yes, I did use the transifex_merge script (changed -a to -l ko). Huidae On Thu, Dec 6, 2018 at 2:53 AM Markus Neteler wrote: > Hi Huidae, > > On Wed, Dec 5, 2018 at 1:39 PM wrote: > > > > Author: hcho > > Date: 2018-12-05 04:39:10 -0800 (Wed, 05 Dec 2018) > > New Revision: 73769 > > > > Modified: > >grass/trunk/locale/po/grasslibs_ko.po > >grass/trunk/locale/po/grassmods_ko.po > >grass/trunk/locale/po/grasswxpy_ko.po > > Log: > > i18n: Update Korean POs > > > > just a question: did you update this using the transifex_merge script? > > Otherwise the work may get lost until we have "tx push" working. > > Markus > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev -- Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE Open Source GIS Developer, GRASS GIS Development Team ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PO file error?
Great, Thanks! On Tue, Dec 4, 2018 at 4:50 AM Markus Neteler wrote: > Hi, > > On Tue, Dec 4, 2018 at 9:42 AM Maris Nartiss wrote: > > > > Hello, > > there was a bug in the original source code. It was fixed on Oct 10, > > 2018 by mmetz in r73517. PO files in SVN have not been updated for 2 > > months thus contain the old message. It should be just fine in > > Transifex. > > I have updated the .po files accordingly in r73756. Like this existing > translations do not get lost when updating the .po files from the > source code next time. > > Note: since r73517 has not been backported so far I also didn't touch > relbranch76. > > Markus > -- Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE Open Source GIS Developer, GRASS GIS Development Team ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] PO file error?
Hi,
I just found this weird issue in the PO files. This message is in
raster/r.spreadpath/main.c line 161. The file itself looks fine, but all PO
files miss the first character "R".
G_verbose_message(_("Reading the input map -%s- and -%s- and creating some
temporary files..."), backrow_layer, backcol_layer);
#: ../raster/r.spreadpath/main.c:161
#, fuzzy, c-format
msgid "eading the input map -%s- and -%s- and creating some temporary
files..."
I have no idea what happened? A bug in any of our scripts?
Best,
Huidae
--
Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE
Open Source GIS Developer, GRASS GIS Development Team
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r73627 - grass/trunk/raster/r.stream.extract
Thanks Markus! Regarding merging messages from transifex, do we have a designated developer who does that or can anyone merge and check in translations to svn? Best, Huidae -- Huidae Cho, Ph.D., P.E., M.ASCE, CFM, GISP Open Source GIS Developer, GRASS GIS Development Team https://idea.isnew.info Sent from my phone On Thu, Nov 1, 2018, 1:56 PM Markus Neteler On Wed, Oct 31, 2018 at 6:56 PM Huidae Cho wrote: > > > > Markus, > > > > What is the best way to test my translation? I know we have the > transifex merge script, but that will overwrite the SVN version of the > files, which can be accidentally checked in. > > Update for both trunk and relbranch76: > - po files updated for r73627, r73628 > - transifex merge done > > After local update, you can test translations. > > Markus > ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r73627 - grass/trunk/raster/r.stream.extract
Markus,
What is the best way to test my translation? I know we have the transifex
merge script, but that will overwrite the SVN version of the files, which
can be accidentally checked in.
Regards,
Huidae
On Wed, Oct 31, 2018 at 1:38 PM Markus Neteler wrote:
> Please wait.
> First also the .po files need that update add I have done last time as
> well.
> Then no translation will be broken.
>
> Markus
>
> Huidae Cho schrieb am Mi., 31. Okt. 2018, 15:06:
>
>> Hmm... I never thought about backporting these changes... So just G76
>> should be fine then?
>>
>> Huidae /hidɛ/
>>
>> On Wed, Oct 31, 2018 at 5:29 AM Martin Landa
>> wrote:
>>
>>> Hi,
>>>
>>> st 31. 10. 2018 v 10:05 odesílatel Maris Nartiss
>>> napsal:
>>> > ... and by doing so marking all translated strings as untranslated.
>>> > This exactly is a type of change that should NOT be backported – the
>>> > meaning of this string can be understood also when it is misspelled
>>> > and backporting would thus harm translations.
>>>
>>> it can be right for G74 release branch but for for G76 where typos
>>> should be simply fixed. Ma
>>>
>>> > > > --- grass/trunk/raster/r.stream.extract/cseg.c 2018-10-30
>>> 21:00:49 UTC (rev 73626)
>>> > > > +++ grass/trunk/raster/r.stream.extract/cseg.c 2018-10-31
>>> 01:54:09 UTC (rev 73627)
>>> > > > @@ -83,7 +83,7 @@
>>> > > > int cseg_get(CSEG *cseg, CELL *value, GW_LARGE_INT row,
>>> GW_LARGE_INT col)
>>> > > > {
>>> > > > if (Segment_get(&(cseg->seg), value, row, col) < 0) {
>>> > > > - G_warning(_("Unabel to read segment file"));
>>> > > > + G_warning(_("Unable to read segment file"));
>>> > > > return -1;
>>> > > > }
>>> > > > return 0;
>>> > > >
>>> > > > ___
>>> > > > grass-commit mailing list
>>> > > > grass-com...@lists.osgeo.org
>>> > > > https://lists.osgeo.org/mailman/listinfo/grass-commit
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > > Martin Landa
>>> > > http://geo.fsv.cvut.cz/gwiki/Landa
>>> > > http://gismentors.cz/mentors/landa
>>> > > ___
>>> > > grass-dev mailing list
>>> > > grass-dev@lists.osgeo.org
>>> > > https://lists.osgeo.org/mailman/listinfo/grass-dev
>>>
>>>
>>>
>>> --
>>> Martin Landa
>>> http://geo.fsv.cvut.cz/gwiki/Landa
>>> http://gismentors.cz/mentors/landa
>>>
>>
>>
>> --
>> Huidae Cho, Ph.D., PE, M.ASCE, CFM, GISP
>> Open Source GIS Developer, GRASS GIS Development Team
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
>
--
Huidae Cho, Ph.D., PE, M.ASCE, CFM, GISP
Open Source GIS Developer, GRASS GIS Development Team
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r73627 - grass/trunk/raster/r.stream.extract
Hmm... I never thought about backporting these changes... So just G76
should be fine then?
Huidae /hidɛ/
On Wed, Oct 31, 2018 at 5:29 AM Martin Landa wrote:
> Hi,
>
> st 31. 10. 2018 v 10:05 odesílatel Maris Nartiss
> napsal:
> > ... and by doing so marking all translated strings as untranslated.
> > This exactly is a type of change that should NOT be backported – the
> > meaning of this string can be understood also when it is misspelled
> > and backporting would thus harm translations.
>
> it can be right for G74 release branch but for for G76 where typos
> should be simply fixed. Ma
>
> > > > --- grass/trunk/raster/r.stream.extract/cseg.c 2018-10-30 21:00:49
> UTC (rev 73626)
> > > > +++ grass/trunk/raster/r.stream.extract/cseg.c 2018-10-31 01:54:09
> UTC (rev 73627)
> > > > @@ -83,7 +83,7 @@
> > > > int cseg_get(CSEG *cseg, CELL *value, GW_LARGE_INT row,
> GW_LARGE_INT col)
> > > > {
> > > > if (Segment_get(&(cseg->seg), value, row, col) < 0) {
> > > > - G_warning(_("Unabel to read segment file"));
> > > > + G_warning(_("Unable to read segment file"));
> > > > return -1;
> > > > }
> > > > return 0;
> > > >
> > > > ___
> > > > grass-commit mailing list
> > > > grass-com...@lists.osgeo.org
> > > > https://lists.osgeo.org/mailman/listinfo/grass-commit
> > >
> > >
> > >
> > > --
> > > Martin Landa
> > > http://geo.fsv.cvut.cz/gwiki/Landa
> > > http://gismentors.cz/mentors/landa
> > > ___
> > > grass-dev mailing list
> > > grass-dev@lists.osgeo.org
> > > https://lists.osgeo.org/mailman/listinfo/grass-dev
>
>
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
>
--
Huidae Cho, Ph.D., PE, M.ASCE, CFM, GISP
Open Source GIS Developer, GRASS GIS Development Team
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Mixing vector and Raster input maps for a module
Nikos, I would personally keep modules simpler and make them do one task really well (Unix philosophy ;-) unless there are multiple related tasks that share a significant portion of the procedure. I would assume that rasterization is a pre-processing step that needs to be done before using your module, and it may not need to be done every time you run the module. If this pre-processing doesn't require any special treatments to the input raster, I would leave it out and just add some notes in the manual. Best, Huidae On Fri, Jul 27, 2018 at 6:29 AM, Nikos Alexandris wrote: > Dear all, > > I am concerned about mixing Vector and Raster maps as inputs in a > module. I think it's less of a complication if a module considers either > only Vector or Raster maps as inputs. > > Should I just not worry and mix these? The question is about > user-friendliness. > > If tha add-on is exposed to QGIS, non-experienced users will be able to > use it. Should they be forced to think about doing some rasterisation > themselves? Or should the module do this job for them? > > This is a generic question. I much appreciate your thoughts. > > Nikos > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev > -- Huidae Cho, Ph.D., PE, M.ASCE, CFM, GISP Open Source GIS Developer, GRASS GIS Development Team ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #3600: m.nviz.image doesn't produce any output
Test run for the NC sample dataset. g.region rast=elevation m.nviz.image elevmap=elevation output=elev format=tif persp=10 --o On Sun, Jul 22, 2018 at 1:43 AM, Huidae Cho wrote: > For anyone who wants to try this patch on macOS. > > -- Forwarded message -- > From: Huidae Cho > Date: Sun, Jul 22, 2018 at 1:41 AM > Subject: Re: [GRASS-dev] [GRASS GIS] #3600: m.nviz.image doesn't produce > any output > To: Michael Barton > > > Michael, > > Please try this patch. > > cd grass_trunk > for i in ~/*.diff; do > patch -p0 < $i > done > cp include/nviz.h dist.x86_64-apple-darwin17.0.0/include/grass/nviz.h > echo "#define OPENGL_FBO 1" > > dist.x86_64-apple-darwin17.0.0/include/grass/config.h > # case 4 below > (cd lib/nviz; make) > (cd lib/ogsf; make) > > I tried AGL and CGL with/without framebuffer objects (FBO). AGL works with > and without FBO, but CGL only works with FBO, again, on my VM. We know AGL > without FBO doesn't work on your mac. > > 1. AGL, no FBO: OPENGL_AGL, no OPENGL_FBO in config.h works for me, but > not for you. > 2. AGL, FBO: OPENGL_AGL, OPENGL_FBO in config.h works for me. > 3. CGL, no FBO: no OPENGL_AGL, no OPENGL_FBO in config.h doesn't work for > me. > 4. CGL, FBO: OPENGL_FBO, no OPENGL_AGL in config.h works for me. > > If you don't mind, please try cases 2-4. > > Best, > Huidae > -- > Huidae Cho, Ph.D., PE, M.ASCE, CFM, GISP > Senior Geospatial Engineer, MapAnything > Open Source GIS Developer, GRASS GIS Development Team > -- Huidae Cho, Ph.D., PE, M.ASCE, CFM, GISP Senior Geospatial Engineer, MapAnything Open Source GIS Developer, GRASS GIS Development Team ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Fwd: [GRASS GIS] #3600: m.nviz.image doesn't produce any output
For anyone who wants to try this patch on macOS.
-- Forwarded message --
From: Huidae Cho
Date: Sun, Jul 22, 2018 at 1:41 AM
Subject: Re: [GRASS-dev] [GRASS GIS] #3600: m.nviz.image doesn't produce
any output
To: Michael Barton
Michael,
Please try this patch.
cd grass_trunk
for i in ~/*.diff; do
patch -p0 < $i
done
cp include/nviz.h dist.x86_64-apple-darwin17.0.0/include/grass/nviz.h
echo "#define OPENGL_FBO 1" >
dist.x86_64-apple-darwin17.0.0/include/grass/config.h
# case 4 below
(cd lib/nviz; make)
(cd lib/ogsf; make)
I tried AGL and CGL with/without framebuffer objects (FBO). AGL works with
and without FBO, but CGL only works with FBO, again, on my VM. We know AGL
without FBO doesn't work on your mac.
1. AGL, no FBO: OPENGL_AGL, no OPENGL_FBO in config.h works for me, but not
for you.
2. AGL, FBO: OPENGL_AGL, OPENGL_FBO in config.h works for me.
3. CGL, no FBO: no OPENGL_AGL, no OPENGL_FBO in config.h doesn't work for
me.
4. CGL, FBO: OPENGL_FBO, no OPENGL_AGL in config.h works for me.
If you don't mind, please try cases 2-4.
Best,
Huidae
--
Huidae Cho, Ph.D., PE, M.ASCE, CFM, GISP
Senior Geospatial Engineer, MapAnything
Open Source GIS Developer, GRASS GIS Development Team
--- include/nviz.h.orig 2018-07-21 23:14:08.971581793 -0400
+++ include/nviz.h 2018-07-22 01:18:39.349478491 -0400
@@ -15,13 +15,20 @@
# include
# include
# include /* for XA_RGB_DEFAULT_MAP atom */
+# define GL_GLEXT_PROTOTYPES
# include
/*** Mac headers ***/
#elif defined(OPENGL_AQUA)
-# define Cursor QDCursor
-# include
-# undef Cursor
+# if defined(OPENGL_AGL)
+#define Cursor QDCursor
+#include
+#undef Cursor
+# else
+#include
+#include
+#include
+# endif
# include
#else /* make sure only one platform defined */
@@ -125,12 +132,16 @@
#if defined(OPENGL_X11)
Display *displayId; /* display connection */
GLXContext contextId; /* GLX rendering context */
-GLXPixmap windowId;
Pixmap pixmap;
+GLXPixmap windowId;
#elif defined(OPENGL_AQUA)
+#if defined(OPENGL_AGL)
AGLPixelFormat pixelFmtId;
AGLContext contextId;
AGLPbuffer windowId;
+#else
+CGLContextObj contextId;
+#endif
#elif defined(OPENGL_WINDOWS)
HDC displayId; /* display context */
HGLRC contextId; /* rendering context */
--- lib/nviz/render.c.orig 2018-07-21 23:13:55.728581977 -0400
+++ lib/nviz/render.c 2018-07-22 01:18:24.919478690 -0400
@@ -4,7 +4,7 @@
\brief Nviz library -- GLX context manipulation
Based on visualization/nviz/src/togl.c
-
+
(C) 2008, 2010 by the GRASS Development Team
This program is free software under the GNU General Public License
(>=v2). Read the file COPYING that comes with GRASS for details.
@@ -44,9 +44,13 @@
rwin->pixmap = 0;
rwin->windowId = 0;
#elif defined(OPENGL_AQUA)
+#if defined(OPENGL_AGL)
rwin->pixelFmtId = NULL;
rwin->contextId = NULL;
rwin->windowId = NULL;
+#else
+rwin->contextId = NULL;
+#endif
#elif defined(OPENGL_WINDOWS)
rwin->displayId = NULL;
rwin->contextId = NULL;
@@ -69,10 +73,13 @@
glXDestroyContext(rwin->displayId, rwin->contextId);
XCloseDisplay(rwin->displayId);
#elif defined(OPENGL_AQUA)
+#if defined(OPENGL_AGL)
aglDestroyPixelFormat(rwin->pixelFmtId);
aglDestroyContext(rwin->contextId);
aglDestroyPBuffer(rwin->windowId);
-/* TODO FreePixMap */
+#else
+CGLDestroyContext(rwin->contextId);
+#endif
#elif defined(OPENGL_WINDOWS)
wglDeleteContext(rwin->contextId);
DeleteDC(rwin->displayId);
@@ -96,9 +103,16 @@
int width, int height)
{
#if defined(OPENGL_X11)
-int attributeList[] = { GLX_RGBA, GLX_RED_SIZE, 1,
- GLX_GREEN_SIZE, 1, GLX_BLUE_SIZE, 1,
- GLX_DEPTH_SIZE, 1, GLX_DOUBLEBUFFER, None
+int attributeList[] = {
+ GLX_RGBA,
+ GLX_RED_SIZE, 1,
+ GLX_GREEN_SIZE, 1,
+ GLX_BLUE_SIZE, 1,
+ GLX_DEPTH_SIZE, 1,
+#if !defined(OPENGL_FBO)
+ GLX_DOUBLEBUFFER,
+#endif
+ None
};
XVisualInfo *v;
@@ -113,7 +127,7 @@
G_warning(_("Unable to get visual info"));
return -1;
}
-
+
rwin->contextId = glXCreateContext(rwin->displayId, v, NULL, GL_TRUE);
if (!rwin->contextId) {
@@ -131,10 +145,21 @@
XFree(v);
#elif defined(OPENGL_AQUA)
-int attributeList[] = { AGL_RGBA, AGL_RED_SIZE, 1,
- AGL_GREEN_SIZE, 1, AGL_BLUE_SIZE, 1,
- AGL_DEPTH_SIZE, 1, AGL_DOUBLEBUFFER, AGL_NONE
+#if defined(OPENGL_AGL)
+int attributeList[] = {
+ AGL_RGBA,
+ AGL_RED_SIZE, 1,
+ AGL_GREEN_SIZE, 1,
+ AGL_BLUE_SIZE, 1,
+ AGL_DEPTH_SIZE, 1,
+#if !defined(OPENGL_FBO)
+ AGL_DOUBLEBUFFER,
+#endif
+ AGL_NONE
};
+
+fprintf(stderr, "AGL enabled\n");
+
/* TODO: open mac display */
/* TODO: dev = NULL, ndev = 0 ? */
@@ -145,11 +170,34 @@
/* create an off-screen AGL rendering area */
aglCreatePBuffer
Re: [GRASS-dev] [GRASS GIS] #3600: m.nviz.image doesn't produce any output
Maybe, we can try the same thing I did for Windows. Create and hide a real window and draw to it? -- Huidae Cho, Ph.D., P.E. (MD), M.ASCE, CFM, GISP Sent from my phone On Fri, Jul 20, 2018, 1:15 PM Huidae Cho wrote: > Michael, one thing weird is with no changes to the Mac code, it worked on > my 10.12 Sierra VM yesterday. Maybe, VM vs. real hardware? > > Regards, > Huidae > -- > Huidae Cho, Ph.D., P.E. (MD), M.ASCE, CFM, GISP > Sent from my phone > > On Fri, Jul 20, 2018, 1:07 PM Michael Barton > wrote: > >> Unfortunately it didn’t seem to fix the Mac, since r72998 produces a >> black image. >> >> >> >> Michael >> >> >> >> __ >> >> C. Michael Barton >> >> Director, Center for Social Dynamics & Complexity >> >> Professor of Anthropology, School of Human Evolution & Social Change >> >> Head, Graduate Faculty in Complex Adaptive Systems Science >> >> Arizona State University >> >> Tempe, AZ 85287-2402 >> >> USA >> >> >> >> voice:480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) >> >> fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) >> >> www: http://csdc.asu.edu, http://shesc.asu.edu >> >> http://www.public.asu.edu/~cmbarton >> >> >> >> *From: *Huidae Cho >> *Date: *Thursday, July 19, 2018 at 8:17 PM >> *To: *Vaclav Petras >> *Cc: *Michael Barton , GRASS developers list < >> grass-dev@lists.osgeo.org> >> *Subject: *Re: [GRASS-dev] [GRASS GIS] #3600: m.nviz.image doesn't >> produce any output >> >> >> >> >> >> >> >> On Thu, Jul 19, 2018 at 10:12 PM, Vaclav Petras >> wrote: >> >> >> >> >> >> On Thu, Jul 12, 2018 at 5:48 PM, Michael Barton >> wrote: >> >> Here is a question to the memory of the dev group. Does anyone know if >> m.nviz.image has *ever* worked for Mac or Windows? >> >> If it has, any idea when it last worked? We could do a diff of the last >> working code and the current code to see what has changed. >> >> >> >> Just for the record: m.nviz.image (most probably) never worked on >> Windows. On Mac (and Linux) it worked, but since certain version of >> operating system(s) and/or hardware it stopped working. It was reported to >> work even now (before the fixes) on an old (not updated) Mac. (In other >> words, the code was not broken on the way, but still needed/needs to be >> fixed.) >> >> >> >> r72997 fixed m.nviz.image on Windows 10 64-bit. The off-screen bitmap >> buffer never seemed to work, so I changed it to an invisible window DC, >> which also supports hardware acceleration unlike a memory DC. >> >> >> >> >> >> >> If not, it may take considerable effort to make this work. >> >> Trying to figure out an efficient way forward >> >> >> >> For the future readers of this: >> >> >> >> https://trac.osgeo.org/grass/ticket/2114 >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.osgeo.org_grass_ticket_2114&d=DwMFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=ZnnPXW0twcYUOWXFNZdYsRvSZXOMp_rO1CfFCOFSRK4&s=nRsNivIboXPGHTrDGF31STph8_zOnKGRzOouxFfoUYc&e=> >> https://trac.osgeo.org/grass/ticket/2998 >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.osgeo.org_grass_ticket_2998&d=DwMFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=ZnnPXW0twcYUOWXFNZdYsRvSZXOMp_rO1CfFCOFSRK4&s=Zxy30tbTNgdvkXostj6_moCEYJBbkpjvTDYJgwdXiXw&e=> >> https://trac.osgeo.org/grass/ticket/3600 >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.osgeo.org_grass_ticket_3600&d=DwMFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=ZnnPXW0twcYUOWXFNZdYsRvSZXOMp_rO1CfFCOFSRK4&s=kEGItiiIu8ARkFXv6eg23Nt22iJbidrCAYXfUlZ4qto&e=> >> https://trac.osgeo.org/grass/ticket/3606 >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.osgeo.org_grass_ticket_3606&d=DwMFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=ZnnPXW0twcYUOWXFNZdYsRvSZXOMp_rO1CfFCOFSRK4&s=OK6s9jG8OjEMu2ScCHln3ANPQqY4SyUI_AwD05UgJ4w&e=> >> >> >> >> https://trac.osgeo.org/grass/changeset/72939 >> <https://urldefense.proofpoint.com/v2/u
Re: [GRASS-dev] [GRASS GIS] #3600: m.nviz.image doesn't produce any output
Michael, one thing weird is with no changes to the Mac code, it worked on my 10.12 Sierra VM yesterday. Maybe, VM vs. real hardware? Regards, Huidae -- Huidae Cho, Ph.D., P.E. (MD), M.ASCE, CFM, GISP Sent from my phone On Fri, Jul 20, 2018, 1:07 PM Michael Barton wrote: > Unfortunately it didn’t seem to fix the Mac, since r72998 produces a black > image. > > > > Michael > > > > __ > > C. Michael Barton > > Director, Center for Social Dynamics & Complexity > > Professor of Anthropology, School of Human Evolution & Social Change > > Head, Graduate Faculty in Complex Adaptive Systems Science > > Arizona State University > > Tempe, AZ 85287-2402 > > USA > > > > voice:480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) > > fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) > > www: http://csdc.asu.edu, http://shesc.asu.edu > > http://www.public.asu.edu/~cmbarton > > > > *From: *Huidae Cho > *Date: *Thursday, July 19, 2018 at 8:17 PM > *To: *Vaclav Petras > *Cc: *Michael Barton , GRASS developers list < > grass-dev@lists.osgeo.org> > *Subject: *Re: [GRASS-dev] [GRASS GIS] #3600: m.nviz.image doesn't > produce any output > > > > > > > > On Thu, Jul 19, 2018 at 10:12 PM, Vaclav Petras > wrote: > > > > > > On Thu, Jul 12, 2018 at 5:48 PM, Michael Barton > wrote: > > Here is a question to the memory of the dev group. Does anyone know if > m.nviz.image has *ever* worked for Mac or Windows? > > If it has, any idea when it last worked? We could do a diff of the last > working code and the current code to see what has changed. > > > > Just for the record: m.nviz.image (most probably) never worked on Windows. > On Mac (and Linux) it worked, but since certain version of operating > system(s) and/or hardware it stopped working. It was reported to work even > now (before the fixes) on an old (not updated) Mac. (In other words, the > code was not broken on the way, but still needed/needs to be fixed.) > > > > r72997 fixed m.nviz.image on Windows 10 64-bit. The off-screen bitmap > buffer never seemed to work, so I changed it to an invisible window DC, > which also supports hardware acceleration unlike a memory DC. > > > > > > > If not, it may take considerable effort to make this work. > > Trying to figure out an efficient way forward > > > > For the future readers of this: > > > > https://trac.osgeo.org/grass/ticket/2114 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.osgeo.org_grass_ticket_2114&d=DwMFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=ZnnPXW0twcYUOWXFNZdYsRvSZXOMp_rO1CfFCOFSRK4&s=nRsNivIboXPGHTrDGF31STph8_zOnKGRzOouxFfoUYc&e=> > https://trac.osgeo.org/grass/ticket/2998 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.osgeo.org_grass_ticket_2998&d=DwMFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=ZnnPXW0twcYUOWXFNZdYsRvSZXOMp_rO1CfFCOFSRK4&s=Zxy30tbTNgdvkXostj6_moCEYJBbkpjvTDYJgwdXiXw&e=> > https://trac.osgeo.org/grass/ticket/3600 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.osgeo.org_grass_ticket_3600&d=DwMFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=ZnnPXW0twcYUOWXFNZdYsRvSZXOMp_rO1CfFCOFSRK4&s=kEGItiiIu8ARkFXv6eg23Nt22iJbidrCAYXfUlZ4qto&e=> > https://trac.osgeo.org/grass/ticket/3606 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.osgeo.org_grass_ticket_3606&d=DwMFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=ZnnPXW0twcYUOWXFNZdYsRvSZXOMp_rO1CfFCOFSRK4&s=OK6s9jG8OjEMu2ScCHln3ANPQqY4SyUI_AwD05UgJ4w&e=> > > > > https://trac.osgeo.org/grass/changeset/72939 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.osgeo.org_grass_changeset_72939&d=DwMFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=ZnnPXW0twcYUOWXFNZdYsRvSZXOMp_rO1CfFCOFSRK4&s=lUB4AnO2XyQLENDhcAA3xQoghGoc7LMH8NdiCrZOCI0&e=> > > https://trac.osgeo.org/grass/changeset/72948 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.osgeo.org_grass_changeset_72948&d=DwMFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=ZnnPXW0twcYUOWXFNZdYsRvSZXOMp_rO1CfFCOFSRK4&s=C9YbVWu_5cyRn93BAD3u3WoyGpTdcGGoL95wfQllRQ0&e=> > > https://trac.osgeo.org/grass/changeset
Re: [GRASS-dev] [GRASS GIS] #3600: m.nviz.image doesn't produce any output
On Thu, Jul 19, 2018 at 10:12 PM, Vaclav Petras wrote: > > > On Thu, Jul 12, 2018 at 5:48 PM, Michael Barton > wrote: > >> Here is a question to the memory of the dev group. Does anyone know if >> m.nviz.image has *ever* worked for Mac or Windows? >> >> If it has, any idea when it last worked? We could do a diff of the last >> working code and the current code to see what has changed. >> > > Just for the record: m.nviz.image (most probably) never worked on Windows. > On Mac (and Linux) it worked, but since certain version of operating > system(s) and/or hardware it stopped working. It was reported to work even > now (before the fixes) on an old (not updated) Mac. (In other words, the > code was not broken on the way, but still needed/needs to be fixed.) > r72997 fixed m.nviz.image on Windows 10 64-bit. The off-screen bitmap buffer never seemed to work, so I changed it to an invisible window DC, which also supports hardware acceleration unlike a memory DC. > >> >> If not, it may take considerable effort to make this work. >> >> Trying to figure out an efficient way forward >> > > For the future readers of this: > > https://trac.osgeo.org/grass/ticket/2114 > https://trac.osgeo.org/grass/ticket/2998 > https://trac.osgeo.org/grass/ticket/3600 > https://trac.osgeo.org/grass/ticket/3606 > > https://trac.osgeo.org/grass/changeset/72939 > https://trac.osgeo.org/grass/changeset/72948 > https://trac.osgeo.org/grass/changeset/72970 > https://trac.osgeo.org/grass/changeset/72972 > https://trac.osgeo.org/grass/changeset/72974 > https://trac.osgeo.org/grass/changeset/72980 > https://trac.osgeo.org/grass/changeset/72986 > https://trac.osgeo.org/grass/changeset/72987 > https://trac.osgeo.org/grass/changeset/72990 > https://trac.osgeo.org/grass/changeset/72997 > > > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev > -- Huidae Cho, Ph.D., PE, M.ASCE, CFM, GISP Senior Geospatial Engineer, MapAnything Open Source GIS Developer, GRASS GIS Development Team ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r72948 - grass/trunk/misc/m.nviz.image
Anna,
You're right! Good catch. I switched 0 & 1 for write_img once again. It was
my holiday brain... Sorry about that. Fixed in r72951.
Thanks for catching the mistake.
Huidae
On Wed, Jul 4, 2018 at 8:15 PM, Anna Petrášová
wrote:
>
>
> On Wed, Jul 4, 2018 at 3:11 PM wrote:
>
>> Author: hcho
>> Date: 2018-07-04 12:11:33 -0700 (Wed, 04 Jul 2018)
>> New Revision: 72948
>>
>> Modified:
>>grass/trunk/misc/m.nviz.image/main.c
>>grass/trunk/misc/m.nviz.image/write_img.c
>> Log:
>> m.nviz.image: Check return value from GS_write_(ppm|tif)
>>
>> Modified: grass/trunk/misc/m.nviz.image/main.c
>> ===
>> --- grass/trunk/misc/m.nviz.image/main.c2018-07-03 19:44:31 UTC
>> (rev 72947)
>> +++ grass/trunk/misc/m.nviz.image/main.c2018-07-04 19:11:33 UTC
>> (rev 72948)
>> @@ -236,7 +236,9 @@
>> if (strcmp(params->format->answer, "tif") == 0)
>> ret = write_img(output_name, FORMAT_TIF);
>>
>> -if (!ret)
>> +if (ret == 1)
>> + G_fatal_error(_("Failed to write image"));
>> +else if (ret == 2)
>> G_fatal_error(_("Unsupported output format"));
>>
>> G_done_msg(_("File <%s> created."), output_name);
>>
>> Modified: grass/trunk/misc/m.nviz.image/write_img.c
>> ===
>> --- grass/trunk/misc/m.nviz.image/write_img.c 2018-07-03 19:44:31 UTC
>> (rev 72947)
>> +++ grass/trunk/misc/m.nviz.image/write_img.c 2018-07-04 19:11:33 UTC
>> (rev 72948)
>> @@ -23,19 +23,20 @@
>>
>> \param name filename
>>
>> - \return 1 on success
>> - \return 0 on failure (unsupported format)
>> + \return 0 on success
>> + \return 1 on failure (failed to write image)
>> + \return 2 on failure (unsupported format)
>> */
>> int write_img(const char *name, int format)
>> {
>> if (format == FORMAT_PPM)
>> - GS_write_ppm(name);
>> + return !GS_write_ppm(name);
>> #ifdef HAVE_TIFFIO_H
>> else if (format == FORMAT_TIF)
>> - GS_write_tif(name);
>> + return !GS_write_tif(name);
>> #endif
>> else
>> - return 0;
>> + return 2;
>>
>> -return 1;
>> +return 0;
>> }
>>
>>
> Shouldn't it be
>
> return GS_write_ppm(name);
>
> the return code of GS_write_ppm is 1 when it fails, so there shouldn't be
> the negation?
>
> Anna
>
>
>> ___
>> grass-commit mailing list
>> grass-com...@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-commit
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
--
Huidae Cho, Ph.D., PE, M.ASCE, CFM, GISP
Senior Geospatial Engineer, MapAnything
Open Source GIS Developer, GRASS GIS Development Team
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] New addon r.accumulate calculates weighted flow accumulation using a flow direction map
Hi All, I just committed a new addon r.accumulate ( https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.accumulate). Unlike r.watershed, this module calculates weighted flow accumulation directly from the flow direction map and does not require the original elevation data. I wrote this module many years ago for GRASS 6, but I almost forgot about it until I read this question: https://gis.stackexchange.com/questions/280813/compute-flow-accumulation-only-from-flow-direction Thanks. Huidae -- Huidae Cho, Ph.D., PE, M.ASCE, CFM, GISP Senior Geospatial Engineer, MapAnything Open Source GIS Developer, GRASS GIS Development Team ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] a proposal to rename "location"
NENT Mapset) concept, > > I start with: > " > Think of a big box. Inside it, you can keep all items related to > your (specific) project. Now, let use create this box, it's a directory > (or folder). What will be its name? Name it the way you think is best, > for your needs, so you know that its content is for one project. > > Next, you can place inside this box every spatial and non-spatial data > related to the project. Raster and vector maps, data bases (like > sqlite) or CSV files. And more. > > This is a/the GRASS GIS data base. You will need to know the full path > name to this data base, sometimes, as an option to modules. > > Before "placing" actually any data inside the data base, let's > understand more of it. > > Inside this box, we can and will need to create smaller boxes. Each of > the small boxes, will be defined by one and only (spatial) reference > system. > > In GRASS GIS' terminology, these are Locations. Why so? Your data may show > the > same locations on earth, yet defined in different coordinate systems. > You can make use of the Locations to group your data based on their spatial > reference system definition. And, of course, you can move data and maps, > between the different Locations. That will be a re-projection action. > > Using Locations helps you in _not_ mixing different coordinate systems, > as it can and does happen often with other GISes (especially with ESRI > Shapefiles). > > Next... > " > > I think the GRASS GIS data base, or project, or name it the way you > like, deserves equally, or perhaps more, attention. > > > In general, I think descriptions, whether they refer to a module or its > flags and options, or to a concept, should be kept to the minimum > "length" (as in number or words used) possible. Yet, they should be > fully spelled out--no shortcuts here (as in how long a word for an > option, a module name or a concept term is). > > Perhaps CS as in Coordinate System, which is shorter, would be a better > candidate than either of CRS or SRS, since it includes unprojected > locations, which GRASS GIS supports. > > > In texts related to GRASS GIS, I write Location, with "L". Never location. > If I have done the latter, it's a mistake of mine. I tend to avoid > LOCATION (variable names in scripts excluded), simply because CAPITAL > LETTERS ARE NOT MORE legible than simply capitalising the first letter > of a word (or maybe using CamelCase or small caps if available). > > > The "characteristic" property, or name it attribute, of a Location, in > GRASS GIS, is the coordinate system. I think the > word Location is a good choice. The coordinate system in GRASS GIS > (excluded the unprojcted) means to locate information in space. Right? > > The problem, as Michael well explains, arises from the many different > things that the common word location can point to. > The text in https://grass.osgeo.org/grass75/manuals/grass_database.html > does well in trying to explain what a Location is. > > What about very definition of the Location concept in the programmer's > manual? This could help in re-naming, perhaps, the Location? > > > Coming back in organising a project, grouping many Locations under the > same GRASS GIS data base directory (or folder), is common. What is the > best way, then, to name the different Locations? > > I work with data for Europe. So, the data "show" Europe. Yet, the > data are defined in, say, geographic or projected coordinates. How can I > reflect this difference between "files" that actually depict exactly the > same area? My answer to this has been always the spatial reference > system. > > I.e. a "Europe/" GRASS GIS data base with the following locations: > etrs89, wgs84, unprojected, et.c. > > This is, mostly, the way I try to explain the concept in others who ask > me about it. How do you name your Locations? > > > The part of the description in > "https://trac.osgeo.org/grass/attachment/wiki/wxGUIDevelopme > nt/New_Startup/startup_grass_7.5.png" > "One Location can be one project" is not wrong. But I feel it can be > easily misunderstood. Language barriers might lead someone into > thinkgin that a Location "should" be one project. > > > Nikos, learning through mistakes > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev > -- Huidae Cho, Ph.D., PE, M.ASCE, CFM, GISP Senior Geospatial Engineer, MapAnything Open Source GIS Developer, GRASS GIS Development Team ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] New dev team on github for initial tests
On Wed, Jun 13, 2018 at 7:16 PM, Luca Delucchi wrote: > On 13 June 2018 at 22:07, Markus Neteler wrote: > > > > As I said: the OSGeo git services are IMHO under-staffed and would > > require a dedicated budget. Could be a nice idea but the board needs > > to support that. > > > > I don't think so, git on OSGeo server is working [0], and the board > also use it [1]. I don't see any problem, it is like trac or svn > I also used it for an OSGeo code [2] > I agree. Also remember that git is a distributed repository, so individual developers would have their own "complete" repository. I assume less maintenance compared to SVN. Huidae > > Markus > > > > PS > Probably I will move most of my github repositories to OSGeo one and > gitlab according the code topic > > [0] https://git.osgeo.org/gitea/ > [1] https://git.osgeo.org/gitea/osgeo/todo/issues > [2] https://git.osgeo.org/gitea/lucadelu/gci_analyst > > -- > ciao > Luca > > www.lucadelu.org > _______ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev > -- Huidae Cho, Ph.D., PE, M.ASCE, CFM, GISP Senior Geospatial Engineer, MapAnything Open Source GIS Developer, GRASS GIS Development Team ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] New dev team on github for initial tests
Yeah, that acquisition is bad news. Why can we just not use the OSGeo one? Just curious. Huidae On Mon, Jun 4, 2018 at 5:00 PM, Markus Neteler wrote: > On Mon, Jun 4, 2018 at 10:50 PM, Martin Landa > wrote: > [...] > > Migration to *git* is planned in any > > case :-) A host platform is not decided yet. > > We simply need to decide between own hosting (incl. git repo by OSGeo) > and effectively commercial providers (github, gitlab, bitbucket, ...). > > As long as we do not depend on highly specific features of such a > platform, migration to another git based platform will remain "easy". > > We should carefully try to identify potential single points of failure > like service unstable, unmaintained in the long run, pay-only traps > and the like. But unless we use the standard features of git along > with maybe CI we are relatively flexible in choosing the platform. > > Just my 0.02 cents, > Markus > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev > -- Huidae Cho, Ph.D., PE, M.ASCE, CFM, GISP Adjunct Faculty, Kennesaw State University Senior Geospatial Engineer, MapAnything Open Source GIS Developer, GRASS GIS Development Team ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] New dev team on github for initial tests
Great! Thanks, Markus! -- Huidae Cho, Ph.D., P.E., M.ASCE, CFM, GISP Sent from my phone On Thu, Apr 12, 2018, 4:51 PM Markus Neteler wrote: > Huidae, > > On Wed, Mar 28, 2018 at 2:57 PM, Huidae Cho wrote: > > Markus, > > > > You can add me: https://github.com/HuidaeCho > > Happily done. Sorry for the delay due to travelling and inbox overflow :) > > Markus > > > On Mon, Mar 19, 2018 at 10:48 AM, Markus Neteler > wrote: > >> > >> On Mon, Mar 19, 2018 at 11:01 AM, Pietro wrote: > >> > On Sat, Mar 17, 2018 at 6:27 PM, Markus Neteler > >> > wrote: > >> >> > >> >> Hi, > >> >> > >> >> as per > >> >> > >> >> > >> >> > https://grasswiki.osgeo.org/wiki/GRASS_GIS_Community_Sprint_Bonn_2018#Move_to_Git > >> >> > >> >> I have created a "GRASS GIS dev" team here: > >> >> https://github.com/orgs/OSGeo/teams/grass-gis/members > >> >> > >> >> ... who wants to join, please speak up (and send your account name). > >> > >> [...] > >> > >> ... all who requested so far have been added. > >> > >> Markus > >> ___ > >> grass-dev mailing list > >> grass-dev@lists.osgeo.org > >> https://lists.osgeo.org/mailman/listinfo/grass-dev > > > > > > > > -- > Markus Neteler, PhD > http://www.mundialis.de - free data with free software > http://grass.osgeo.org > http://courses.neteler.org/blog > ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] New dev team on github for initial tests
Markus, You can add me: https://github.com/HuidaeCho Thanks. Huidae On Mon, Mar 19, 2018 at 10:48 AM, Markus Neteler wrote: > On Mon, Mar 19, 2018 at 11:01 AM, Pietro wrote: > > On Sat, Mar 17, 2018 at 6:27 PM, Markus Neteler > wrote: > >> > >> Hi, > >> > >> as per > >> > >> https://grasswiki.osgeo.org/wiki/GRASS_GIS_Community_ > Sprint_Bonn_2018#Move_to_Git > >> > >> I have created a "GRASS GIS dev" team here: > >> https://github.com/orgs/OSGeo/teams/grass-gis/members > >> > >> ... who wants to join, please speak up (and send your account name). > > [...] > > ... all who requested so far have been added. > > Markus > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev > ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] lib/python/ctypes compilation errors
sr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avxintrin.h:1318:
Syntax error at '{'
Error:
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avx512fintrin.h:65:
Syntax error at '{'
Error:
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avx512fintrin.h:77:
Syntax error at '{'
Error:
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avx512fintrin.h:87:
Syntax error at '{'
Error:
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avx512fintrin.h:98:
Syntax error at '{'
Error:
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avx512fintrin.h:144:
Syntax error at '{'
Error:
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avx512fintrin.h:159:
Syntax error at '{'
Error:
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avx512fintrin.h:170:
Syntax error at '{'
Error:
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avx512fintrin.h:172:
Syntax error at ','
Error:
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avx512fintrin.h:181:
Syntax error at '{'
Error:
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avx512fintrin.h:183:
Syntax error at ','
Error:
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avx512fintrin.h:193:
Syntax error at '{'
Error:
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avx512fintrin.h:203:
Syntax error at '{'
Error:
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avx512fintrin.h:211:
Syntax error at '{'
Error:
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avx512fintrin.h:219:
Syntax error at '{'
Error:
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avx512fintrin.h:239:
Syntax error at '{'
Error:
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avx512fintrin.h:247:
Syntax error at '{'
Error:
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avx512fintrin.h:254:
Syntax error at '{'
Error:
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avx512fintrin.h:261:
Syntax error at '{'
Error:
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avx512vlintrin.h:36:
Syntax error at '{'
Error:
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avx512vlintrin.h:437:
Syntax error at '{'
Error:
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avx512bwintrin.h:47:
Syntax error at '{'
Error:
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avx512bwintrin.h:61:
Syntax error at '{'
Error: /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/bmi2intrin.h:86:
Syntax error at '__res'
Error: /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/f16cintrin.h:40:
Syntax error at '{'
Error: /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/f16cintrin.h:42:
Syntax error at 'return'
Error: /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/f16cintrin.h:42:
Syntax error at 'i0'
Error: /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/mm3dnow.h:168:
Syntax error at '{'
Status: Processing description list.
Warning: Member "def" of Struct "Option" has been renamed to "_def" because
it has the same name as a Python keyword.
Status: Writing to OBJ.x86_64-pc-linux-gnu/vector.py.
Status: Wrapping complete.
Thanks.
Huidae
On Sun, Jan 28, 2018 at 12:17 PM, Markus Neteler wrote:
> On Sun, Jan 28, 2018 at 4:54 PM, Huidae Cho wrote:
> > Hello,
> >
> > I'm trying to compile the trunk on a new machine and getting these errors
> > when compiling lib/python/ctypes.
>
> Could you please include the ctypes error message?
>
> > I searched this mailing list and found
> > that /usr/include/GL/gl.h.. Syntax error at '\n' is normal (?),
>
> Apparently yes, it happens also on Fedora and elsewhere.
>
> > but what
> > about the others? Regardless of these errors, make reports No errors
> > detected, so can I assume there will be no harm?
> >
> > Error: /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/
> xmmintrin.h:117:
> > Syntax error at '{'
>
> Could you please add more context of the error?
>
> best
> Markus
>
> > These headers have a similar errors with different line numbers:
> > /usr/include/GL/gl.h
> > /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avx512bwintrin.h
> > /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avx512fintrin.h
> > /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avx512vlintrin.h
> > /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avxintrin.h
> > /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/bmi2intrin.h
> > /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/emmintrin.h
> > /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/f16cintrin.h
> > /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/mm3dnow.h
> > /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/xmmintrin.h
> >
> > GRASS SVN: Trunk as of Jan 28, 2018
> > Linux: Slackware64 14.2
> > Kernel: 4.14.14
> > GCC: 5.3.0
> >
> > Any ideas what's going on?
> >
> > Thanks!
> > Huidae
> >
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] lib/python/ctypes compilation errors
Hello,
I'm trying to compile the trunk on a new machine and getting these errors
when compiling lib/python/ctypes. I searched this mailing list and found
that /usr/include/GL/gl.h.. Syntax error at '\n' is normal (?), but what
about the others? Regardless of these errors, make reports No errors
detected, so can I assume there will be no harm?
Error: /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/xmmintrin.h:117:
Syntax error at '{'
These headers have a similar errors with different line numbers:
/usr/include/GL/gl.h
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avx512bwintrin.h
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avx512fintrin.h
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avx512vlintrin.h
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/avxintrin.h
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/bmi2intrin.h
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/emmintrin.h
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/f16cintrin.h
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/mm3dnow.h
/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/xmmintrin.h
GRASS SVN: Trunk as of Jan 28, 2018
Linux: Slackware64 14.2
Kernel: 4.14.14
GCC: 5.3.0
Any ideas what's going on?
Thanks!
Huidae
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r70710 - in grass/branches/releasebranch_7_2: lib/vector/vedit raster/r.timestamp raster/r.to.vect raster/r.topidx raster/r.topmodel scripts/v.db.addtable vector/v.build.po
I wish I could add a log message to that commit. Since I have no admin rights to SVN... hopefully, this log message will help you prepare release news (used new tools/svnlog.sh from r70714): r.timestamp: typo in the manual (backport r70666) v.what: Fix the default distance threshold (backport r70637) v.patch: build topology after appending (backport r70636) v.edit: Fix the default threshold distance (backport r70635) v.db.addtable: Check for duplicate column names (backport r70634) v.to.db: Don't throw a fatal error when there are no features (backport r70633) v.to.db: Fix r70633; Don't throw a fatal error when there are no features (backport r70706) v.to.db: better check for Vect_cidx_get_num_cats_by_index (backport r70707) v.to.db: findex > -1 (backport r70708) v.distance: Fix separator in the manual (backport r70611) v.distance: Update the manual; column= & -p are mutually exclusive (backport r70612) v.distance: Define default column names for -p; Suppress compiler warnings (backport r70613) v.distance: Don't create (0,0) points where no nearest points are found (backport r70614) v.build.polylines: Activate the cats=same option; Remove compile warnings (backport r70599) v.to.points: Don't interpolate for use=node according to the manual (backport r70589) vedit: Remove a compile warning (backport r70586) v.select: Avoid database warnings when no features are selected and copy an empty table (backport r70582) vedit: Fix snapping to BgMap (backport r70537) r.to.vect: Fix a couple of compile errors/warnings (backport r70509) r.to.vect: Call the DB error handler before the vector handler to avoid busy database warnings Reproduce this issue in the North Carolina sample dataset: r.to.vect input=aspect output=aspect type=line Any unthinned input raster will produce the same issue. (backport r70506) r.to.vect: copyright year (backport r70709) r.to.vect: Remove unnecessary parentheses (backport r70507) r.topmodel, r.topidx: Fix links (backport r69139) On Wed, Mar 1, 2017 at 8:16 AM, Huidae Cho wrote: > Ah! Sorry for the huge comment and I forgot to copy log messages. > Backporting is always difficult for me ;) > > On Wed, Mar 1, 2017 at 7:51 AM, Martin Landa > wrote: > >> 2017-03-01 13:31 GMT+01:00 Martin Landa : >> > please *explain* your changes in log message next time. It's >> > flustrating for those who are preparing news page about release to dig >> > into such commits. Log message should help to understand what is >> > purpose of the commit. >> >> Also spliting such huge commit into small commits would be good idea. Ma >> >> >>grass/branches/releasebranch_7_2/raster/r.to.vect/areas_io.c >> >>grass/branches/releasebranch_7_2/raster/r.to.vect/global.h >> >>grass/branches/releasebranch_7_2/raster/r.to.vect/main.c >> >>grass/branches/releasebranch_7_2/raster/r.topidx/r.topidx.html >> >>grass/branches/releasebranch_7_2/raster/r.topmodel/r.topmodel.html >> >>grass/branches/releasebranch_7_2/scripts/v.db.addtable/v.db. >> addtable.py >> >>grass/branches/releasebranch_7_2/vector/v.build.polylines/main.c >> >>grass/branches/releasebranch_7_2/vector/v.build.polylines/walk.c >> >>grass/branches/releasebranch_7_2/vector/v.distance/main.c >> >>grass/branches/releasebranch_7_2/vector/v.distance/v.distance.html >> >>grass/branches/releasebranch_7_2/vector/v.edit/main.c >> >>grass/branches/releasebranch_7_2/vector/v.edit/max_distance.c >> >>grass/branches/releasebranch_7_2/vector/v.patch/main.c >> >>grass/branches/releasebranch_7_2/vector/v.select/copy_tabs.c >> >>grass/branches/releasebranch_7_2/vector/v.select/main.c >> >>grass/branches/releasebranch_7_2/vector/v.to.db/main.c >> >>grass/branches/releasebranch_7_2/vector/v.to.points/write.c >> >>grass/branches/releasebranch_7_2/vector/v.what/main.c >> >> Log: >> >> Backport r70666, r70637, r70636, r70635, r70634, r70633, r70706, >> r70707, r70708, r70611, r70612, r70613, r70614, r70599, r70589, r70586, >> r70582, r70537, r70509, r70506, r70709, r70507, r69139 >> >> >> >> >> >> >> >> Modified: grass/branches/releasebranch_7_2/lib/vector/vedit/break.c >> >> === >> >> --- grass/branches/releasebranch_7_2/lib/vector/vedit/break.c >> 2017-03-01 11:35:50 UTC (rev 70709) >> >> +++ grass/branches/releasebranch_7_2/lib/vector/vedit/break.c >> 2017-03-01 11:45:44 UT
Re: [GRASS-dev] [GRASS-SVN] r70710 - in grass/branches/releasebranch_7_2: lib/vector/vedit raster/r.timestamp raster/r.to.vect raster/r.topidx raster/r.topmodel scripts/v.db.addtable vector/v.build.po
Ah! Sorry for the huge comment and I forgot to copy log messages.
Backporting is always difficult for me ;)
On Wed, Mar 1, 2017 at 7:51 AM, Martin Landa wrote:
> 2017-03-01 13:31 GMT+01:00 Martin Landa :
> > please *explain* your changes in log message next time. It's
> > flustrating for those who are preparing news page about release to dig
> > into such commits. Log message should help to understand what is
> > purpose of the commit.
>
> Also spliting such huge commit into small commits would be good idea. Ma
>
> >>grass/branches/releasebranch_7_2/raster/r.to.vect/areas_io.c
> >>grass/branches/releasebranch_7_2/raster/r.to.vect/global.h
> >>grass/branches/releasebranch_7_2/raster/r.to.vect/main.c
> >>grass/branches/releasebranch_7_2/raster/r.topidx/r.topidx.html
> >>grass/branches/releasebranch_7_2/raster/r.topmodel/r.topmodel.html
> >>grass/branches/releasebranch_7_2/scripts/v.db.addtable/v.
> db.addtable.py
> >>grass/branches/releasebranch_7_2/vector/v.build.polylines/main.c
> >>grass/branches/releasebranch_7_2/vector/v.build.polylines/walk.c
> >>grass/branches/releasebranch_7_2/vector/v.distance/main.c
> >>grass/branches/releasebranch_7_2/vector/v.distance/v.distance.html
> >>grass/branches/releasebranch_7_2/vector/v.edit/main.c
> >>grass/branches/releasebranch_7_2/vector/v.edit/max_distance.c
> >>grass/branches/releasebranch_7_2/vector/v.patch/main.c
> >>grass/branches/releasebranch_7_2/vector/v.select/copy_tabs.c
> >>grass/branches/releasebranch_7_2/vector/v.select/main.c
> >>grass/branches/releasebranch_7_2/vector/v.to.db/main.c
> >>grass/branches/releasebranch_7_2/vector/v.to.points/write.c
> >>grass/branches/releasebranch_7_2/vector/v.what/main.c
> >> Log:
> >> Backport r70666, r70637, r70636, r70635, r70634, r70633, r70706,
> r70707, r70708, r70611, r70612, r70613, r70614, r70599, r70589, r70586,
> r70582, r70537, r70509, r70506, r70709, r70507, r69139
> >>
> >>
> >>
> >> Modified: grass/branches/releasebranch_7_2/lib/vector/vedit/break.c
> >> ===
> >> --- grass/branches/releasebranch_7_2/lib/vector/vedit/break.c
> 2017-03-01 11:35:50 UTC (rev 70709)
> >> +++ grass/branches/releasebranch_7_2/lib/vector/vedit/break.c
> 2017-03-01 11:45:44 UTC (rev 70710)
> >> @@ -247,12 +247,13 @@
> >> line_new = -1;
> >>
> >> if (line_new > -1) {
> >> + n_points = Points_from->n_points - 1;
> >> +
> >> if (first) {
> >> x = Points_from->x[0];
> >> y = Points_from->y[0];
> >> }
> >> else {
> >> - n_points = Points_from->n_points - 1;
> >> x = Points_from->x[n_points];
> >> y = Points_from->y[n_points];
> >> }
> >>
> >> Modified: grass/branches/releasebranch_7_2/lib/vector/vedit/move.c
> >> ===
> >> --- grass/branches/releasebranch_7_2/lib/vector/vedit/move.c
> 2017-03-01 11:35:50 UTC (rev 70709)
> >> +++ grass/branches/releasebranch_7_2/lib/vector/vedit/move.c
> 2017-03-01 11:45:44 UTC (rev 70710)
> >> @@ -71,7 +71,7 @@
> >>
> >> for (bgi = 0; bgi < nbgmaps; bgi++) {
> >> if (Vedit_snap_point
> >> - (BgMap[bgi], line, &x[j], &y[j], &z[j],
> thresh,
> >> + (BgMap[bgi], -1, &x[j], &y[j], &z[j],
> thresh,
> >> (snap == SNAPVERTEX) ? 1 : 0))
> >> break; /* snapped, don't continue */
> >> }
> >>
> >> Modified: grass/branches/releasebranch_7_2/lib/vector/vedit/vertex.c
> >> ===
> >> --- grass/branches/releasebranch_7_2/lib/vector/vedit/vertex.c
> 2017-03-01 11:35:50 UTC (rev 70709)
> >> +++ grass/branches/releasebranch_7_2/lib/vector/vedit/vertex.c
> 2017-03-01 11:45:44 UTC (rev 70710)
> >> @@ -115,7 +115,7 @@
> >>
> >> for (bgi = 0; bgi < nbgmaps; bgi++) {
> >> if (Vedit_snap_point
> >> - (BgMap[bgi], line, &x[k], &y[k],
> >> + (BgMap[bgi], -1, &x[k], &y[k],
> >> &z[k], thresh_snap,
> >> (snap == SNAPVERTEX) ? 1 : 0))
> >> moved[k] = 2;
> >>
> >> Modified: grass/branches/releasebranch_7_2/raster/r.timestamp/r.
> timestamp.html
> >> ===
> >> --- grass/branches/releasebranch_7_2/raster/r.timestamp/r.timestamp.html
> 2017-03-01 11:35:50 UTC (rev 70709)
> >> +++ grass/branches/releasebranch_7_2/raster/r.timestamp/r.timestamp.html
> 2017-03-01 11:45:44 UTC (rev 70710)
> >> @@ -15,7 +15,7 @@
> >>
> >> The timestamp values must use the format
Re: [GRASS-dev] [GRASS-SVN] r70632 - grass/trunk/scripts/v.report
sure. usually, I don't backport, but I'll check the wiki. Thanks.
On Mon, Feb 20, 2017 at 3:11 AM, Martin Landa
wrote:
> Hi,
>
> 2017-02-20 8:58 GMT+01:00 Huidae Cho :
> > no problem, I'll backport it.
>
> ok, thanks for taking care about it. Note that only bugfixes or
> cosmetics issues (we are close to freeze period) should be backported
> to relb72. After releasing 7.2.1 also non-bug (minor new
> functionality) issues can be backported. It's good to note such
> waiting backports on wiki [1]. Ma
>
> [1] https://trac.osgeo.org/grass/wiki/Grass7Planning#a7.2.2tobebackported
>
> >> > if cols[catcol] == '-1' or cols[catcol] == '0':
> >> > continue
> >> > @@ -115,7 +116,6 @@
> >> >
> >> > if len(records1) == 0:
> >> > try:
> >> > -f = grass.vector_db(map=mapname)[int(layer)]
> >> > grass.fatal(_("There is a table connected to input
> >> > vector map '%s', but "
> >> >"there are no categories present in the
> >> > key column '%s'. Consider using "
> >> >"v.to.db to correct this.") % (mapname,
> >> > f['key']))
> >> > @@ -142,6 +142,7 @@
> >> > for r2 in records2:
> >> > records3.append(filter(lambda r1: r1[catcol] == r2[0],
> >> > records1)[0] + r2[1:])
> >> > else:
> >> > +catcol = 0
> >> > records1 = []
> >> > p = grass.pipe_command('v.category', inp=mapname,
> layer=layer,
> >> > option='print')
> >> > for line in p.stdout:
> >> > @@ -172,15 +173,18 @@
> >> > numcols = len(colnames) + len(extracolnames)
> >> >
> >> > # calculate percents if requested
> >> > -if units != '' and units in ['p', 'percent']:
> >> > -# calculate total area value
> >> > -areatot = 0
> >> > +if units == 'percent' and option != 'coor':
> >> > +# calculate total value
> >> > +total = 0
> >> > for r in records3:
> >> > -areatot += float(r[-1])
> >> > +total += float(r[-1])
> >> >
> >> > -# calculate area percentages
> >> > -records4 = [float(r[-1]) * 100 / areatot for r in records3]
> >> > -records3 = [r1 + [r4] for r1, r4 in zip(records1, records4)]
> >> > +# calculate percentages
> >> > +records4 = [float(r[-1]) * 100 / total for r in records3]
> >> > +if type(records1[0]) == int:
> >> > +records3 = [[r1] + [r4] for r1, r4 in zip(records1,
> >> > records4)]
> >> > +else:
> >> > +records3 = [r1 + [r4] for r1, r4 in zip(records1,
> >> > records4)]
> >> >
> >> > # sort results
> >> > if options['sort']:
> >> >
> >> > ___
> >> > grass-commit mailing list
> >> > grass-com...@lists.osgeo.org
> >> > https://lists.osgeo.org/mailman/listinfo/grass-commit
> >>
> >>
> >>
> >> --
> >> Martin Landa
> >> http://geo.fsv.cvut.cz/gwiki/Landa
> >> http://gismentors.cz/mentors/landa
> >
> >
>
>
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r70632 - grass/trunk/scripts/v.report
no problem, I'll backport it.
Thanks.
On Mon, Feb 20, 2017 at 2:39 AM, Martin Landa
wrote:
> Hi,
>
> are you planning to backport bugfixes to relb72? Thanks, Ma
>
> 2017-02-20 1:15 GMT+01:00 :
> > Author: hcho
> > Date: 2017-02-19 16:15:14 -0800 (Sun, 19 Feb 2017)
> > New Revision: 70632
> >
> > Modified:
> >grass/trunk/scripts/v.report/v.report.py
> > Log:
> > v.report: Fix unit=percent
> >
> > Modified: grass/trunk/scripts/v.report/v.report.py
> > ===
> > --- grass/trunk/scripts/v.report/v.report.py2017-02-19 23:40:29 UTC
> (rev 70631)
> > +++ grass/trunk/scripts/v.report/v.report.py2017-02-20 00:15:14 UTC
> (rev 70632)
> > @@ -81,7 +81,7 @@
> > else:
> > extracolnames = [option]
> >
> > -if units in ['p', 'percent']:
> > +if units == 'percent':
> > unitsp = 'meters'
> > elif units:
> > unitsp = units
> > @@ -90,6 +90,7 @@
> >
> > # NOTE: we suppress -1 cat and 0 cat
> > if isConnection:
> > +f = grass.vector_db(map=mapname)[int(layer)]
> > p = grass.pipe_command('v.db.select', quiet=True, map=mapname,
> layer=layer)
> > records1 = []
> > catcol = -1
> > @@ -97,12 +98,12 @@
> > cols = line.rstrip('\r\n').split('|')
> > if catcol == -1:
> > for i in range(0, len(cols)):
> > -if cols[i] == 'cat':
> > +if cols[i] == f['key']:
> > catcol = i
> > break
> > if catcol == -1:
> > -# shouldn't happen, but let's do this
> > -catcol = 0
> > +grass.fatal(_("There is a table connected to input
> vector map '%s', but "
> > + "there is no key column '%s'.") %
> (mapname, f['key']))
> > continue
> > if cols[catcol] == '-1' or cols[catcol] == '0':
> > continue
> > @@ -115,7 +116,6 @@
> >
> > if len(records1) == 0:
> > try:
> > -f = grass.vector_db(map=mapname)[int(layer)]
> > grass.fatal(_("There is a table connected to input
> vector map '%s', but "
> >"there are no categories present in the
> key column '%s'. Consider using "
> >"v.to.db to correct this.") % (mapname,
> f['key']))
> > @@ -142,6 +142,7 @@
> > for r2 in records2:
> > records3.append(filter(lambda r1: r1[catcol] == r2[0],
> records1)[0] + r2[1:])
> > else:
> > +catcol = 0
> > records1 = []
> > p = grass.pipe_command('v.category', inp=mapname, layer=layer,
> option='print')
> > for line in p.stdout:
> > @@ -172,15 +173,18 @@
> > numcols = len(colnames) + len(extracolnames)
> >
> > # calculate percents if requested
> > -if units != '' and units in ['p', 'percent']:
> > -# calculate total area value
> > -areatot = 0
> > +if units == 'percent' and option != 'coor':
> > +# calculate total value
> > +total = 0
> > for r in records3:
> > -areatot += float(r[-1])
> > +total += float(r[-1])
> >
> > -# calculate area percentages
> > -records4 = [float(r[-1]) * 100 / areatot for r in records3]
> > -records3 = [r1 + [r4] for r1, r4 in zip(records1, records4)]
> > +# calculate percentages
> > +records4 = [float(r[-1]) * 100 / total for r in records3]
> > +if type(records1[0]) == int:
> > +records3 = [[r1] + [r4] for r1, r4 in zip(records1,
> records4)]
> > +else:
> > +records3 = [r1 + [r4] for r1, r4 in zip(records1, records4)]
> >
> > # sort results
> > if options['sort']:
> >
> > ___
> > grass-commit mailing list
> > grass-com...@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-commit
>
>
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r68061 - grass/trunk/lib/gis
Hi Martin, This fix only affects the history, not its behavior. "v.info -h n" gives you: COMMAND: v.edit map="n" layer="1" type="point,line,boundary,centroid" tool="delete" threshold=-1,0,0 where="" snap="no" Without this fix, you'll see: COMMAND: v.edit map="n" layer="1" type="point,line,boundary,centroid" tool="delete" threshold=-1,0,0 snap="no" and cannot reuse this command without manually adding where="". BTW, I think v.edit n tool=delete where="" should delete all features because you're selecting all records by "select * from n" without any where conditions. So your results look OK. Huidae On Sun, May 1, 2016 at 4:51 PM, Martin Landa wrote: > Hi, > > 2016-03-15 9:56 GMT+01:00 : > > Author: hcho > > Date: 2016-03-15 01:56:28 -0700 (Tue, 15 Mar 2016) > > New Revision: 68061 > > > > Modified: > >grass/trunk/lib/gis/parser.c > > Log: > > G_recreate_command: Add empty answers. > > Fix the command history for e.g., v.edit where="". Without this fix, > where="" is not included, which makes an invalid command. > > I tried to backport this commit to relbr70. My quick test: > > v.random out=n n=100 --o > v.db.addtable n > > leads to the all features removed. > > v.edit n tool=delete where="" > Selecting features... > 100 of 100 features selected from vector map > 100 features deleted > > I thought that this should be fixed by this commit, right? So no > features removed (?) > > Thanks for explanation. Martin > > -- > Martin Landa > http://geo.fsv.cvut.cz/gwiki/Landa > http://gismentors.cz/mentors/landa > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Fwd: Re: [GRASS-SVN] r68240 - grass/trunk/scripts/v.report
I don't think we have a consensus yet... -- Sent from my phone On Apr 12, 2016 11:01 AM, "Markus Neteler" wrote: > On Mon, Apr 11, 2016 at 3:57 PM, Huidae Cho wrote: > ... > > 11 scripts use \r\n and 5 use os.linesep. g.extension uses \r\n for > reading > > and os.linesep for printing. > > Any volunteer to homogenize that? > > thanks > Markus > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] usage of os.linesep (was: Re: [GRASS-SVN] r68240 - grass/trunk/scripts/v.report_
What about this then? For reading text files, use \r\n. For reading
outputs from GRASS modules and writing, use os.linesep.
I think this makes sense because it can handle cross platform files safely
and it's very unlikely to have mixed newlines from modules compiled on the
same platform.
Or simply just use \r\n for reading and os.linesep for writing?
--
Sent from my phone
On Apr 11, 2016 10:58 AM, "Martin Landa" wrote:
> Hi Huidae,
>
> {I took liberty to move discussion to ML}
>
> 2016-04-11 15:54 GMT+02:00 Huidae Cho :
> > That was a copy+paste from the same script, but I think \r\n is safer
> than
> > os.linesep just in case v.to.db prints out \r for whatever reason. But I
> > know that won't happen in non-Windows anyway, so os.linesep should be
> fine?
>
> hm, you are right, but still I would prefer to use os.linesep over
> '\r\n'. The only problem can happen when the user will ship generated
> files between Unix and Windows OS.
>
> Any comments from others?
>
> Thanks, Martin
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Fwd: Re: [GRASS-SVN] r68240 - grass/trunk/scripts/v.report
Forgot to reply all...
--
Sent from my phone
-- Forwarded message --
From: "Huidae Cho"
Date: Apr 11, 2016 9:54 AM
Subject: Re: [GRASS-dev] [GRASS-SVN] r68240 - grass/trunk/scripts/v.report
To: "Martin Landa"
Cc:
That was a copy+paste from the same script, but I think \r\n is safer than
os.linesep just in case v.to.db prints out \r for whatever reason. But I
know that won't happen in non-Windows anyway, so os.linesep should be fine?
11 scripts use \r\n and 5 use os.linesep. g.extension uses \r\n for reading
and os.linesep for printing.
Huidae
--
Sent from my phone
On Apr 10, 2016 7:49 AM, "Martin Landa" wrote:
> 2016-04-10 13:44 GMT+02:00 :
> > +fields = line.rstrip('\r\n').split('|')
>
> really '\r\n' ? Why not os.linesep? Ma
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r68127 - grass/trunk/lib/gis
I partly agree with you, but I think at least there should be consistency in the same file. Those two options had 4 spaces, but others have tabs or 8 spaces. Well, there is still inconsistency... Why don't we use the indent script for all files? On Wed, Mar 23, 2016 at 11:52 PM, Vaclav Petras wrote: > > On Wed, Mar 23, 2016 at 11:29 PM, Huidae Cho wrote: > >> Vaclav, that script completely removes tabs and I didn't want to >> introduce a big revision for no reason other than changing those two >> options to match the rest of the file. > > > > I think there is no need to do that. There is a lot of files in the source > code which do not comply with any (!) version of the indent script. If you > want the file to be consistent, why not to be consistent with the script > and actually use it? If inconsistencies with Submitting guidelines are OK, > why change anything? Perhaps it will turn into the new style itself in time > if we won't be reverting it back. We can also say that we actually want > everything to be consistent and do that big change. > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r68127 - grass/trunk/lib/gis
Vaclav, that script completely removes tabs and I didn't want to introduce
a big revision for no reason other than changing those two options to match
the rest of the file.
On Wed, Mar 23, 2016 at 10:59 PM, Vaclav Petras
wrote:
>
> On Wed, Mar 23, 2016 at 5:29 PM, wrote:
>
>> Author: hcho
>> Date: 2016-03-23 14:29:40 -0700 (Wed, 23 Mar 2016)
>> New Revision: 68127
>>
>> Modified:
>>grass/trunk/lib/gis/parser_standard_options.c
>> Log:
>> parser: Fix indentation
>>
>>
> Please, see:
>
> https://trac.osgeo.org/grass/browser/grass/trunk/tools/grass_indent.sh
> https://trac.osgeo.org/grass/wiki/Submitting/C#Indentation
>
>
>> Modified: grass/trunk/lib/gis/parser_standard_options.c
>> ===
>> --- grass/trunk/lib/gis/parser_standard_options.c 2016-03-23
>> 19:54:16 UTC (rev 68126)
>> +++ grass/trunk/lib/gis/parser_standard_options.c 2016-03-23
>> 21:29:40 UTC (rev 68127)
>> @@ -659,26 +659,26 @@
>> break;
>>
>> case G_OPT_M_LOCATION:
>> -Opt->key = "location";
>> -Opt->type = TYPE_STRING;
>> -Opt->required = NO;
>> -Opt->multiple = NO;
>> -Opt->label = _("Location name");
>> -Opt->description = _("Location name (not location path)");
>> -Opt->gisprompt = "old,location,location";
>> -Opt->key_desc = "name";
>> -break;
>> + Opt->key = "location";
>> + Opt->type = TYPE_STRING;
>> + Opt->required = NO;
>> + Opt->multiple = NO;
>> + Opt->label = _("Location name");
>> + Opt->description = _("Location name (not location path)");
>> + Opt->gisprompt = "old,location,location";
>> + Opt->key_desc = "name";
>> + break;
>>
>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r66772 - in grass/trunk: db/drivers db/drivers/dbf db/drivers/mysql db/drivers/odbc db/drivers/ogr db/drivers/postgres db/drivers/sqlite lib/db/dbmi_driver lib/db/stubs
I can also confirm this. I had to copy dbstubs.h to dist.../include/grass, but I'm not sure what brought those changes in the above revision. If we have to keep this revision, adding dbstubs.h in include/ should address this issue... On Wed, Nov 11, 2015 at 11:54 AM, Vaclav Petras wrote: > > On Wed, Nov 11, 2015 at 11:14 AM, Martin Landa > wrote: > > > > 2015-11-11 16:52 GMT+01:00 Martin Landa : > > > fyi, it seems that it broke travis builds [1]. Ma > > > > > > add_col.c:2:27: fatal error: grass/dbstubs.h: No such file or directory > > > compilation terminated. > > > > > > [1] > https://s3.amazonaws.com/archive.travis-ci.org/jobs/90543352/log.txt > > > > it's also broken on my pc, can anybody confirm it? > > I can confirm it but I was not able to figure out what is wrong. > > https://lists.osgeo.org/pipermail/grass-dev/2015-November/077266.html > https://lists.osgeo.org/pipermail/grass-dev/2015-November/077278.html > > > execute.c:2:27: fatal error: grass/dbstubs.h: No such file or directory > > compilation terminated. > > ../../../include/Make/Compile.make:32: recipe for target > > 'OBJ.x86_64-unknown-linux-gnu/execute.o' failed > > make[4]: *** [OBJ.x86_64-unknown-linux-gnu/execute.o] Error 1 > > make[4]: Leaving directory '/opt/src/grass_trunk/lib/db/stubs' > > > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Return value from g.copy is one when --overwrite - bug or feature?
r66775 adds a warning for non-vector elements as well. On Mon, Nov 9, 2015 at 6:20 AM, Glynn Clements wrote: > > Markus Neteler wrote: > > > It should probably not silently fail. > > > > The code in question is in > > lib/manage/do_copy.c > > M_do_copy() returns a status. g.copy's main() checks that and uses it > to set the exit status, but it doesn't generate an error or warning if > the status is non-zero. > > If G_recursive_copy() or M_do_copy() raised an error, that would > result in the program aborting on the first error; at present, it > copies as much as it can. > > Realistically, g.copy() should be generating the error at the bottom > of main() if result is non-zero. E.g. > > -exit(result); > +if (result) > +G_fatal_error(...); > +return 0; > > > and potentially there to be added strerror(errno) as for example in > > lib/gis/mapset_msc.c > > That would require G_recursive_copy() to call G_warning() (with the > appropriate strerror(errno)) for each failed system call. Either that, > or G_recursive_copy() would have to generate a "log" of failures so > that the caller can report them. > > -- > Glynn Clements > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Return value from g.copy is one when --overwrite - bug or feature?
Rainer, I cannot seem to replicate your issue: G srorg6630/tmp ~> g.version GRASS 7.1.svn (2015) G srorg6630/tmp ~> g.list region tmp tmp.d.rast.edit.6753 tmp1 G srorg6630/tmp ~> g.copy region=tmp,tmp1 --overwrite Copy region definition to current mapset as G srorg6630/tmp ~> echo $? 0 g.copy returns 1 when it cannot either read the source or write to the target. Please check your permissions on your region files in LOCATION/MAPSET/windows/. Regards, Huidae On Fri, Nov 6, 2015 at 8:21 AM, Rainer M Krug wrote: > When copying via g.copy and specifying --overwrite and the target object > already exists, the return value is 1 but no error message is returned: > > , > | simASM:grassAnalysis> g.copy --overwrite region=region1,region2 > | simASM:grassAnalysis> echo $? > | 1 > | simASM:grassAnalysis> g.version > | GRASS 7.0.1 (2015) > | simASM:grassAnalysis> > ` > > From http://tldp.org/LDP/abs/html/exit-status.html: > > , > | A successful command returns a 0, while an unsuccessful one returns a > | non-zero value that usually can be interpreted as an error code. > ` > > So shouldn't the return value be 0 in this case, as the command did what > it was told? > > Cheers, > > Rainer > > -- > Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation > Biology, UCT), Dipl. Phys. (Germany) > > Centre of Excellence for Invasion Biology > Stellenbosch University > South Africa > > Tel : +33 - (0)9 53 10 27 44 > Cell: +33 - (0)6 85 62 59 98 > Fax : +33 - (0)9 58 10 27 44 > > Fax (D):+49 - (0)3 21 21 25 22 44 > > email: rai...@krugs.de > > Skype: RMkrug > > PGP: 0x0F52F982 > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r65981 - grass-addons/grass7/raster/r.wateroutlet.lessmem
Markus, Yes, it does work. I had to do the following: svn propset svn:keywords "Date" r.wateroutlet.lessmem.html Thanks. Huidae On Mon, Aug 24, 2015 at 6:22 PM, Markus Neteler wrote: > Just FYI > > On Fri, Aug 21, 2015 at 9:04 AM, wrote: > > Author: hcho > > Date: 2015-08-21 00:04:44 -0700 (Fri, 21 Aug 2015) > > New Revision: 65981 > > > > Modified: > > > grass-addons/grass7/raster/r.wateroutlet.lessmem/r.wateroutlet.lessmem.html > > Log: > > r.wateroutlet.lessmem: Reformat author; Date tag not working? > > It does: > cat > grass-addons/grass7/raster/r.wateroutlet.lessmem/r.wateroutlet.lessmem.html > ... > Last changed: $Date: 2015-08-21 09:10:56 +0200 (Fri, 21 Aug 2015) $ > > as soon as it got submitted (and > grass-addons/tools/module_svn_propset.sh being used) > > Markus > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r65307 - grass/trunk/lib/init
Thanks, Martin. Is there any good reason why grass.py imports environment variables in load_env() and writes non-/^export/ lines (r65585 does not strip out whitespaces) into MAPSET/.bashrc in bash_startup() instead of simply sourcing or fully writing .grass7/bashrc? I see a couple of problems with this two step approach. 1. /^export/ lines in .grass.bashrc don't work anymore with r65585. This file used to be "fully" written into MAPSET/.bashrc. 2. Conditional constructs like the following are not supported in .grass7/bashrc: case $TERM in xterm*) export PS1=xterm # no space before export ;; screen) export PS1=screen ;; esac because load_env() would overwrite PS1 and bash_startup() won't write out the /^export PS1/ lines. It will work if there are whitespaces before export, but I would say that was not intended by you... Regards, Huidae On Tue, Jul 14, 2015 at 8:51 AM, Martin Landa wrote: > Hi, > > 2015-07-08 18:31 GMT+02:00 Huidae Cho : > > I think the following change has to be reverted because it breaks aliases > > and custom prompts defined in ~/.grass7/bashrc. Currently, only > "NAME=VALUE" > > lines are parsed from this file in load_env(). > > sorry for delay, I took liberty to partly re-introduce r65307 in > r65585. It should work with aliases now. > > Martin > > -- > Martin Landa > http://geo.fsv.cvut.cz/gwiki/Landa > http://gismentors.cz/mentors/landa > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r65307 - grass/trunk/lib/init
Martin,
I think the following change has to be reverted because it breaks aliases
and custom prompts defined in ~/.grass7/bashrc. Currently, only
"NAME=VALUE" lines are parsed from this file in load_env().
Regards,
Huidae
On Thu, May 21, 2015 at 5:45 PM, wrote:
> Author: martinl
> Date: 2015-05-21 14:45:19 -0700 (Thu, 21 May 2015)
> New Revision: 65307
>
> Modified:
>grass/trunk/lib/init/grass.py
> Log:
> grass.py: don't overwrite environmental variables in bash_startup()
>
>
> Modified: grass/trunk/lib/init/grass.py
> ===
> --- grass/trunk/lib/init/grass.py 2015-05-21 21:01:15 UTC (rev 65306)
> +++ grass/trunk/lib/init/grass.py 2015-05-21 21:45:19 UTC (rev 65307)
>
...
> @@ -1443,9 +1449,7 @@
> path = os.path.join(userhome, ".grass.bashrc") # left for backward
> compatibility
> if os.access(path, os.R_OK):
> f.write(readfile(path) + '\n')
> -if os.access(grass_env_file, os.R_OK):
> -f.write(readfile(grass_env_file) + '\n')
> -
> +
> f.write("export PATH=\"%s\"\n" % os.getenv('PATH'))
> f.write("export HOME=\"%s\"\n" % userhome) # restore user home path
>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] inconsistency between G_OPT_V_INPUT and G_OPT_R_INPUT
I think we still need to fix it. On Thu, May 21, 2015 at 11:15 AM, Vaclav Petras wrote: > > > On Wed, May 13, 2015 at 10:14 AM, Vaclav Petras > wrote: > > > > On Wed, May 13, 2015 at 9:47 AM, Pietro wrote: > > > > > > On Wed, May 13, 2015 at 11:08 AM, Martin Landa > wrote: > > > > > > > > 2015-05-13 8:03 GMT+02:00 Pietro : > > > > > > > >> As you can see the description of the parameter add the default > > > >> description set in G_OPT_V_INPUT and in a new line the description > > > >> added manually in the definition of the module parameters. Instead > the > > > >> G_OPT_R_INPUT shows only the description set manually. > > > > > > > > right, G_OPT_V_INPUT has defined both label and description [1]. This > > > > the source of inconsistency. There are more standard options which > > > > defines both label and description. > > > > > > Do you think this inconsistency should be fix, or just reported > > > somewhere on a Wiki page? > > > > Perhaps all standard options should define both label and description > and you can then modify whatever suits you. (I often end up setting both.) > > > > In the future, we should revise this anyway, like move from description > to label as the primary one or making both mandatory. > > See also *Standard options label vs description* from Huidae Cho: > > http://lists.osgeo.org/pipermail/grass-dev/2014-June/069313.html > > http://osgeo-org.1560.x6.nabble.com/Standard-options-label-vs-description-td5144023.html > > Vaclav > > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r65249 - grass/trunk/raster/r.topidx
Hi, Thanks for pointing me to the script. I just manually adjusted several
lines to make them 80 columns. Based on the script, it looks like couple
options were dropped (-ts8, -ut) and new ones were added (-npro, --no-tabs).
On Fri, May 15, 2015 at 1:22 PM, Vaclav Petras wrote:
> Hi, I see that you are making the indent in a file consistent but I just
> wanted to make sure you know that I recently updated the script
> ./tools/grass_indent.sh.
>
> On Fri, May 15, 2015 at 11:42 AM, wrote:
>
>> Author: hcho
>> Date: 2015-05-15 08:42:52 -0700 (Fri, 15 May 2015)
>> New Revision: 65249
>>
>> Modified:
>>grass/trunk/raster/r.topidx/main.c
>>grass/trunk/raster/r.topidx/topidx.c
>> Log:
>> r.topidx: indent
>>
>> Modified: grass/trunk/raster/r.topidx/main.c
>> ===
>> --- grass/trunk/raster/r.topidx/main.c 2015-05-15 14:45:57 UTC (rev
>> 65248)
>> +++ grass/trunk/raster/r.topidx/main.c 2015-05-15 15:42:52 UTC (rev
>> 65249)
>> @@ -51,7 +51,7 @@
>> exit(EXIT_FAILURE);
>>
>> /* Make sure that the current projection is not lat/long */
>> -if ((G_projection() == PROJECTION_LL))
>> +if (G_projection() == PROJECTION_LL)
>> G_fatal_error(_("Lat/Long location is not supported by %s. Please
>> reproject map first."),
>> G_program_name());
>>
>>
>> Modified: grass/trunk/raster/r.topidx/topidx.c
>> ===
>> --- grass/trunk/raster/r.topidx/topidx.c2015-05-15 14:45:57 UTC
>> (rev 65248)
>> +++ grass/trunk/raster/r.topidx/topidx.c2015-05-15 15:42:52 UTC
>> (rev 65249)
>> @@ -125,7 +125,8 @@
>> sum += route[0];
>> nroute++;
>> }
>> - if (!is_cv_null(i - 1, j) && cv(i, j) - cv(i - 1, j)
>> > ZERO) {
>> + if (!is_cv_null(i - 1, j) &&
>> + cv(i, j) - cv(i - 1, j) > ZERO) {
>> tanB[1] = (cv(i, j) - cv(i - 1, j)) * dx1;
>> route[1] = 0.5 * dx * tanB[1];
>> sum += route[1];
>> @@ -148,7 +149,8 @@
>> nroute++;
>> }
>> if (j + 1 < window.cols) {
>> - if (!is_cv_null(i, j + 1) && cv(i, j) - cv(i, j + 1)
>> > ZERO) {
>> + if (!is_cv_null(i, j + 1) &&
>> + cv(i, j) - cv(i, j + 1) > ZERO) {
>> tanB[5] = (cv(i, j) - cv(i, j + 1)) * dx1;
>> route[5] = 0.5 * dx * tanB[5];
>> sum += route[5];
>> @@ -164,7 +166,8 @@
>> sum += route[6];
>> nroute++;
>> }
>> - if (!is_cv_null(i + 1, j) && cv(i, j) - cv(i + 1, j)
>> > ZERO) {
>> + if (!is_cv_null(i + 1, j) &&
>> + cv(i, j) - cv(i + 1, j) > ZERO) {
>> tanB[7] = (cv(i, j) - cv(i + 1, j)) * dx1;
>> route[7] = 0.5 * dx * tanB[7];
>> sum += route[7];
>> @@ -187,46 +190,38 @@
>> nslp = 0;
>> if (i > 0) {
>> if (j > 0 && !is_cv_null(i - 1, j - 1)) {
>> - sumtb += (cv(i - 1, j - 1)
>> - - cv(i, j)) * dx2;
>> + sumtb += (cv(i - 1, j - 1) - cv(i, j)) * dx2;
>> nslp++;
>> }
>> if (!is_cv_null(i - 1, j)) {
>> - sumtb += (cv(i - 1, j)
>> - - cv(i, j)) * dx1;
>> + sumtb += (cv(i - 1, j) - cv(i, j)) * dx1;
>> nslp++;
>> }
>> if (j + 1 < window.cols && !is_cv_null(i - 1, j +
>> 1)) {
>> - sumtb += (cv(i - 1, j + 1)
>> - - cv(i, j)) * dx2;
>> + sumtb += (cv(i - 1, j + 1) - cv(i, j)) * dx2;
>> nslp++;
>> }
>> }
>>
>> if (j > 0 && !is_cv_null(i, j - 1)) {
>> - sumtb += (cv(i, j - 1)
>> - - cv(i, j)) * dx1;
>> + sumtb += (cv(i, j - 1) - cv(i, j)) * dx1;
>> nslp++;
>> }
>> if (j + 1 < window.cols && !is_cv_null(i, j + 1)) {
>> - sumtb += (cv(i, j + 1)
>> - - cv(i, j)) * dx1;
>> + sumtb += (cv(i, j + 1) - cv(i, j)) * dx1;
>> nslp++;
>> }
>> if (i + 1 < window.rows) {
>> if (j > 0 && !is_cv_nu
Re: [GRASS-dev] module header definitions add: text/multiline and latex support?
On Thu, Jan 15, 2015 at 2:46 AM, Glynn Clements wrote: > > > Requiring raster OR vector is possible already. > > > > #%rules > > #% requires: raster, vector > > #%end > > This should be "required" (at least one of the options must be given). > If you want exactly one option to be given, you need both "required" > and "exclusive", e.g. > > #%rules > #% required: raster, vector > #% exclusive: raster, vector > #%end > > A "requires" rule indicates that if the first option is given, at > least one of the other options must be given. > > You're right. I was thinking about "required", but my hands typed "requires" :-( > -- > Glynn Clements > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] module header definitions add: text/multiline and latex support?
On Wed, Jan 14, 2015 at 3:42 AM, Pietro wrote:
> Dear devs,
>
> sometimes I would like to add some multiline text on the module GUI to
> help to understand the meaning of the parameter, and/or understand the
> logic of the module.
>
> Do you think that would be possible to have a description option that
> it does not take any input but allow us to be more descriptive inside
> the module interface?
>
> for instance if I have two mutual exclusive options like:
>
> {{{
> #%module
> #% description: test script
> #%end
> ...
> #%option
> #% key: raster
> #% type: string
> #% gisprompt: old,cell,raster
> #% description: Raster input map:
> #% required : no
> #%end
> #%option
> #% type: description
> #% answer: OR
> #%end
> #%option
> #% key: vector
> #% type: string
> #% gisprompt: old,vector,vector
> #% description: Vector input map
> #% required : no
> #%end
> }}}
>
> So in the gui of the module I will have:
>
> Raster input map:
> -> raster menu
>
> OR
>
> Vector input map:
> -> vector menu
>
> or add a relation, to do something like:
>
> {{{
> #%module
> #% description: test script
> #%end
> ...
> #%option
> #% key: raster
> #% type: string
> #% gisprompt: old,cell,raster
> #% description: Raster input map:
> #% required : yes
> #%end
> #%option
> #% key: vector
> #% type: string
> #% gisprompt: old,vector,vector
> #% description: Vector input map
> #% required : yes
> #%end
> #%keyrelation: raster OR vector
> }}}
>
> Is it this possible already? If yes how? Do you have some links?
>
Requiring raster OR vector is possible already.
#%rules
#% requires: raster, vector
#%end
> Do you think that would be feasible add also a LaTex option?
> To do something like:
>
> {{{
> #%module
> #% description: test script
> #%end
> ...
> #%option
> #% guisection: Costs
> #% type: description
> #% answer: This option is used to compute the total
> #% cost of using this formula:
> #%end
> #%option
> #%option
> #% guisection: Costs
> #% type: latex
> #% answer: \rho = \frac{\gamma}{\pi}
> #%end
> #%option
> #% guisection: Costs
> #% key: gamma
> #% type: double
> #% description: $\gamma$ value
> #% required : no
> #% answer: 12.45
> #%end
> #%option
> #% guisection: Costs
> #% key: currency
> #% type: string
> #% description: the currency
> #% required : no
> #% answer: €
> #%end
> }}}
>
> In this way the GUI could be more descriptive and clearer.
>
> I have not idea if this could be feasible or not... What do you think?
>
> Best regards
>
> Pietro
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] group does not update REF file upon g.remove raster file
Yann, Please be more specific. What is the group REF file and how can I replicate your issue? And what do you expect to happen? Regards, Huidae -- Sent from my phone On Dec 15, 2014 3:49 AM, "Yann Chemin" wrote: > Hi, > > did g.remove a raster, and the group REF file referencing the raster did > not update accordingly. > > Is this a known behaviour? > Yann > > -- > > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Custom GRASS command line prompt
That's cool. I'll try it tonight. Thanks.
--
Sent from my phone
On Dec 15, 2014 5:12 PM, "Martin Landa" wrote:
> Hi,
>
> 2014-12-15 22:34 GMT+01:00 Huidae Cho :
> > Mine looks like this (bash shell):
> >
> > grass_ps(){
> > echo "G `g.gisenv LOCATION_NAME`/`g.gisenv MAPSET`"
>
> btw, in trunk you can avoid calling `g.gisenv` twice
>
> g.gisenv get=LOCATION_NAME,MAPSET sep='/'
>
> Martin
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.eu/mentors/landa
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
