Re: [GRASS-dev] Send GRASS news to mailing list

[Helena Mitasova via grass-dev]

I think this is a great idea - +1,

Helena

Helena Mitasova
Professor, Department of Marine, Earth and Atmospheric Sciences
Associate Director and Faculty Fellow, Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu


"All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.”




> On Sep 1, 2023, at 8:52 AM, Vaclav Petras  wrote:
> 
> Dear all,
> 
> Having the very nice post about the meeting in Prague and others at the GRASS 
> website, I was thinking we should send this to the grass-user mailing list 
> too and maybe grass-dev.
> 
> Given the mailing list emails have size limitations and may end up 
> potentially ASCII, I'm suggesting sending an email with a link to the new 
> item and the first paragraph of the news item to the grass-user mailing list. 
> So, the one for Prague, would look like this:
> 
> """"
> Report of the GRASS GIS Community Meeting in Prague
> 
> The GRASS GIS Community Meeting was held in the Czech Republic from June 2 to 
> 6 at the Faculty of Civil Engineering of the Czech Technical University in 
> Prague. The meeting was a milestone event to celebrate the 40th birthday of 
> GRASS GIS and brought together users, supporters, contributors, power users 
> and developers to celebrate, collaborate and chart the future of GRASS GIS.
> 
> Read more at:
> 
> https://grass.osgeo.org/news/2023_08_13_grass_community_meeting_prague_june_2023_report/
>  
> <https://grass.osgeo.org/news/2023_08_13_grass_community_meeting_prague_june_2023_report/>
> """
> 
> What do you think?
> 
> Vaclav
> ___
> 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] Fwd: [OSGeo AGM 2021] [Action required] GRASS GIS upload link please upload your video till August 30

[Helena Mitasova]

I am not sure whether this was discussed already or anybody from PSC knows 
about this but we need to prepare 
a short 1 minute video about GRASS updates for FOSS4G AGM - see more details 
below and here
https://wiki.osgeo.org/wiki/Annual_General_Meeting_2021 
<https://wiki.osgeo.org/wiki/Annual_General_Meeting_2021>

I checked the slides and GRASS project is updated (thanks Vasek?) so that is 
done, now we need the video.
I think that adding 2 narrated slides with some nice images/photos/animations 
would be great and we will
need a volunteer to record. 

I shared google slides with you - it has the AGM slide and 2 additional as 
template - feel free to add material keeping
in mind that it should be 1 minute.

Thanks a lot, Helena

> Begin forwarded message:
> 
> From: "Astrid Emde (OSGeo Secretary)" 
> Subject: [OSGeo AGM 2021] [Action required] GRASS GIS upload link please 
> upload your video till August 30
> Date: August 16, 2021 at 11:56:17 AM EDT
> To: Markus Neteler , hmit...@ncsu.edu
> Reply-To: secret...@osgeo.org
> 
> Hello Markus, hello Helena,
> 
> we invite you and your team to present the GRASS GIS project at the OSGeo AGM 
> 2021.
> 
> This year we will publish the OSGeo AGM video in advance of FOSS4G [1].
> 
> You find all important information about the AGM at [5].
> 
> 
> Video upload link
> ---
> Please use the following upload link to upload your video (Deadline 
> 2021-08-30)
> 
> https://vortraege.fossgis.de/u/d/b87f9e4fef7b434a839a/
> 
> Timeline
> ---
> - 2021-08-30: upload your video and update the AGM slides [2]
> - 2021-09-10: AGM 2021 complete video will be published
> - 2021-10-01: 11h Argentinian Time Zone (14:00 UTC) Join the OSGeo AGM 2021 
> meeting at FOSS4G [3] [4]
> 
> If you have questions or problems with the upload of your video please let us 
> know secretary (at) osgeo (dot) org.
> 
> Stay safe,
> 
> Astrid Emde
> OSGeo Secretary
> 
> [1] https://www.youtube.com/channel/UCDvJEf8hXbyeVqaYaS8sLvw
> [2] 
> https://docs.google.com/presentation/d/1brbBb7-sKRI6U4dZ7LKnBT_-NnWzyS2TaZqVXzy8RDo/edit#slide=id.p4
> [3] https://callforpapers.2021.foss4g.org/foss4g2021/talk/WDEW3P/
> [4] 
> https://www.timeanddate.com/worldclock/meetingdetails.html?year=2021=10=1=14=0=0=51=26=49=155=217=312=250=71=248=240
> [5] https://wiki.osgeo.org/wiki/Annual_General_Meeting_2021
> 
> -- 
> 
> -----
> Astrid Emde
> OSGeo Board Member and OSGeo Secretary
> Open Source Geospatial Foundation
> https://www.osgeo.org/member/astrid-emde/
> astrid_e...@osgeo.org
> 

Helena Mitasova
Professor, Department of Marine, Earth and Atmospheric Sciences
Faculty Fellow,
Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu



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

Re: [GRASS-dev] [OSGeo-Discuss] FOSS4G 2021: Community vote is open!

[Helena Mitasova]

I already went through all 303 abstracts - there is a lot of interesting 
contributions 
so it is well worth the time to paticipate and vote!

Helena

> On Apr 25, 2021, at 5:55 PM, Markus Neteler  wrote:
> 
> Dear GRASS community,
> 
> Please consider to participate in the community voting.
> Hint: there are many GRASS GIS related talks and workshops :-)
> 
> Cheers,
> Markus
> 
> -- Forwarded message -
> From: Veronica Andreo 
> Date: Fri, Apr 23, 2021 at 1:04 PM
> Subject: [OSGeo-Discuss] FOSS4G 2021: Community vote is open!
> To: OSGeo-discuss 
> 
> Dear all,
> 
> The traditional community vote is open!!
> 
> https://callforpapers.2021.foss4g.org/foss4g2021/p/voting/signup/
> 
> To be able to vote, you need to type in your email there (that's
> required only once), search for the automatic email in your inbox to
> confirm the address and done, you are ready to go! The votes are
> anonymous
> 
> You can use the weekend to go through all ~300 proposed talks and tell
> us what you think :)
> 
> Voting options are: Does not fit in a FOSS4G, Looks acceptable, Looks
> interesting and A FOSS4G must-see
> 
> Have fun!
> The FOSS4G 2021 LOC
> 
> ps: There's time until May 15th to cast your vote :)
> ___
> Discuss mailing list
> disc...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/discuss
> _______
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev

Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
Associate director and faculty fellow at the Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

"All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

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

Re: [GRASS-dev] minor tweak to new website

[Helena Mitasova]

I agree with Michael’s suggestion too, Helena

> On Jan 15, 2021, at 2:10 PM, Paulo van Breugel  wrote:
> 
> 
> 
> On Fri, Jan 15, 2021 at 5:49 PM Michael Barton  wrote:
> On the new download pages, I just noticed that the dev versions are 
> referenced like this:
> 
>  
> 
> GRASS GIS 7.9 devel (unstable)
> 
>  
> 
> This implies that GRASS 7.9 is risky and perhaps minimally useable. The 
> reality is that it works very well but has some new features that might be 
> buggy or might change. While we want to indicate these differences from the 
> current stable version, we don’t want to discourage people from trying it 
> (and reporting any issues).
> 
>  
> 
> I suggest that we reference it as
> 
>  
> 
> GRASS GIS 7.9 devel (development)
> 
>  
> 
> Or
> 
>  
> 
> GRASS GIS 7.9 devel (preview)
> 
> 
> 
> 
> +1 good point, it indeed works well, and is in my experience more stable than 
> many other software tools I use(d).
> 
>  
>  
> 
> 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
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev

Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
Associate director and faculty fellow at the Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

"All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

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

[GRASS-dev] Statement Helena Mitasova

[Helena Mitasova]

 Dear GRASS community,

I am  honored to be nominated - thank you.  

As most of you probably know I am faculty at the Center for Geospatial 
Analytics at North Carolina State University. 
I have participated in GRASS GIS development since 1991, working at USA CERL in 
90s and I have been on GRASS PSC
since it was established. I have collaborated with Markus on the GRASSbook and 
co-authored many papers and two
additional books with GRASS-related topics. I have promoted GRASS in academic 
communities and at conferences through
presentations of our research developing innovative tools and applications. 
  

I am currently on the board of directors for OSGeo and as GRASS PSC member I 
try to make sure that the views and needs
from GRASS project are well represented. I am rather quiet on the lists as I 
try to minimize sending emails, writing only when I feel
that it is absolutely necessary. But I closely follow GRASS development and 
follow up with any  issues that arise with Anna and Vasek.
I developed and teach courses where we use GRASS and my current and former 
graduate students use GRASS in their research.
I was fortunate to have Anna and Vasek as my grad students  bringing GRASS 
development into our lab at NCSU.

As a PSC member I see my role as guarding the continuity while supporting new 
ideas -I am excited about the new developments 
which may change how people use GRASS and make it more accessible. I am 
committed to working with GRASS community to further develop open access 
educational material  for courses and workshops.
I would also strive to keep the admin and procedures as simple as possible to 
focus the resources (time and effort)
on development, documentation and education, while dividing the work as 
suggested by Markus - perhaps bringing 
in some experience from currently well functioning OSGeo board.

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

[GRASS-dev] Fwd: [Board] upcoming OSGeo/OGC/Apache code sprint

[Helena Mitasova]

This is just to make sure ithat this message reaches evenrybody in the 
grass-dev community as I am not sure who is on the projects list
as this is a new opportunity for collaboration between major projects and 
initiatives, Helena

> Begin forwarded message:
> 
> From: Tom Kralidis 
> Subject: [Board] upcoming OSGeo/OGC/Apache code sprint
> Date: December 10, 2020 at 8:05:43 AM EST
> To: proje...@lists.osgeo.org
> Cc: osgeo-board List 
> 
> Hi everyone: as part of our ongoing collaboration with OGC, and given
> the synergy of FOSS4G projects and OGC standards, we are working with
> OGC and the Apache Software Foundation to coordinate an OSGeo/OGC/ASF
> virtual code sprint in Q1 2021 (~February 2021).
> 
> As with previous OSGeo presence at OGC Hackathons, we will document and
> report on OSGeo participation at the event.  This will provide
> value in terms of having a sense of FOSS4G projects involvement as part
> of our OGC collaboration.  This will also help coordinate involvement
> at future hackathons / code sprints at both OSGeo code sprints (i.e. perhaps
> a dedicated interoperability theme), OGC Hackathons, or related ASF events.
> 
> We are working with OGC and ASF to coordinate dates for the events, as well
> as a joint announcement to help advertise the event details in the coming 
> weeks.
> 
> Given the synergy of FOSS4G projects and OGC standards, we kindly ask
> that projects
> consider participation in this important upcoming event.  This event with also
> will be a first between OSGeo/OGC and ASF, and provides the opportunity
> for cross-pollination with ASF geospatial projects (see [1] as an example of
> geospatial projects presented at ApacheCon 2020 as an example).
> 
> Thanks
> 
> ..Tom
> 
> [1] https://apachecon.com/acah2020/tracks/geospatial.html
> ___
> Board mailing list
> bo...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/board

Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
Associate director and faculty fellow at the Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

"All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

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

Re: [GRASS-dev] GRASS code spring slide for OSGeo AGM

[Helena Mitasova]

I can present it, if nobody else would like to. 

Helena

> On Sep 9, 2020, at 5:03 PM, Markus Neteler  wrote:
> 
> Hi PSC, devs,
> 
> On Wed, Sep 9, 2020 at 6:42 PM Helena Mitasova  wrote:
>> 
>> Hi, we are going through the slides for 2020 OSGeo AGM (scheduled for 
>> tomorrow
>> https://wiki.osgeo.org/wiki/Annual_General_Meeting_2020
> 
> btw: who is willing to present our project slide?
> 
> It is tomorrow at 13:00UTC:
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSGeo+AGM=20200910T13=1440=2
> 
> best
> Markus
> 
> ...
>> We are, like all OSGeo projects, requested to provide one slide
> ...
>> https://docs.google.com/presentation/d/1C6llSnWZ28c2aWQgttPiOnoo6dttdqKg07ugU_yr6Uc/edit#slide=id.g233aae6a05_0_0

Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
Associate director and faculty fellow at the Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

"All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

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

Re: [GRASS-dev] GRASS code spring slide for OSGeo AGM

[Helena Mitasova]

we can remove it then - the general GRASS report will be enough,

thanks a lot for quick answer

Helena

> On Sep 9, 2020, at 12:52 PM, Vaclav Petras  wrote:
> 
> AFAIK, in the summer 2019 - summer 2020 period, we had only the small one in 
> Prague in Dec 2019. Is that you want to report on?
> 
> https://grasswiki.osgeo.org/wiki/GRASS_GIS_Community_Sprint_Prague_2019
> 
> On Wed, Sep 9, 2020 at 12:42 PM Helena Mitasova  wrote:
> Hi, we are going through the slides for 2020 OSGeo AGM (scheduled for 
> tomorrow 
> https://wiki.osgeo.org/wiki/Annual_General_Meeting_2020
> 
> and there is no text for the code spring - Vashek (or somebody else) can you 
> please add some info if there was a code spring
> (we had some meetings but I am not sure about the code sprint)?
> https://docs.google.com/presentation/d/1C6llSnWZ28c2aWQgttPiOnoo6dttdqKg07ugU_yr6Uc/edit#slide=id.g33e7b00af0_3_73
> Also we need somebody to present the slide (1 minute or so).
> 
> Thank you, Helena
> 
> 
> 
>> On Sep 3, 2020, at 5:23 PM, Veronica Andreo  wrote:
>> 
>> Hi, 
>> 
>> I just added some content to it as items. Other ideas?
>> 
>> best, 
>> Vero
>> 
>> El jue., 3 sept. 2020 a las 20:56, Markus Neteler () 
>> escribió:
>>  Hi,
>> (sorry for cross-posting)
>> 
>> The OSGeo Annual General Meeting (AGM) will take place on 10th Sep
>> 2020 from 6 pm to 8pm UTC
>> (https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSGeo+AGM=20200910T18=1440=2)
>> as a virtual meeting.
>> 
>> AGM 2020 announcement:
>> - https://lists.osgeo.org/pipermail/discuss/2020-August/039019.html
>> 
>> AGM 2020 Wiki page:
>> - https://wiki.osgeo.org/wiki/Annual_General_Meeting_2020
>> 
>> 
>> We are, like all OSGeo projects, requested to provide one slide with
>> the development and community news of the last year.
>> Our draft slide is at p. 40:
>> 
>> https://docs.google.com/presentation/d/1C6llSnWZ28c2aWQgttPiOnoo6dttdqKg07ugU_yr6Uc/edit#slide=id.g233aae6a05_0_0
>> 
>> Please contribute to the content!
>> 
>> Markus
>> 
>> PS: content suggestions from the board list:
>> 
>> - key accomplishments
>> - releases
>> - infrastructure or process changes
>> - community health and happiness
>> - areas for improvements
>> - these are challenges faced by the project
>> - opportunities to help
>> - anything for members to help with?
>> - requests and communication
>> - any formal request from the board, marketing or other committees?
>> - did you make a budget request for 2020? How did it go ...
>> - external correspondence? letter of recommendation for a GSOC
>> student? code donation? etc…
>> - outlook for 2020
>> - any roadmap items to share with our members?
>>     - let the board know if there is anything to plan for in 2020
>> ___
>> 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
> 
> Helena Mitasova
> Professor at the Department of Marine, 
> Earth, and Atmospheric Sciences
> Associate director and faculty fellow at the Center for Geospatial Analytics
> North Carolina State University
> Raleigh, NC 27695-8208
> hmit...@ncsu.edu
> 
> "All electronic mail messages in connection with State business which are 
> sent to or received by this account are subject to the NC Public Records Law 
> and may be disclosed to third parties.” 
> 
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev

Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
Associate director and faculty fellow at the Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

"All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

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

[GRASS-dev] GRASS code spring slide for OSGeo AGM

[Helena Mitasova]

Hi, we are going through the slides for 2020 OSGeo AGM (scheduled for tomorrow 
https://wiki.osgeo.org/wiki/Annual_General_Meeting_2020 
<https://wiki.osgeo.org/wiki/Annual_General_Meeting_2020>

and there is no text for the code spring - Vashek (or somebody else) can you 
please add some info if there was a code spring
(we had some meetings but I am not sure about the code sprint)?
https://docs.google.com/presentation/d/1C6llSnWZ28c2aWQgttPiOnoo6dttdqKg07ugU_yr6Uc/edit#slide=id.g33e7b00af0_3_73
 
<https://docs.google.com/presentation/d/1C6llSnWZ28c2aWQgttPiOnoo6dttdqKg07ugU_yr6Uc/edit#slide=id.g33e7b00af0_3_73>
Also we need somebody to present the slide (1 minute or so).

Thank you, Helena



> On Sep 3, 2020, at 5:23 PM, Veronica Andreo  wrote:
> 
> Hi, 
> 
> I just added some content to it as items. Other ideas?
> 
> best, 
> Vero
> 
> El jue., 3 sept. 2020 a las 20:56, Markus Neteler () 
> escribió:
>  Hi,
> (sorry for cross-posting)
> 
> The OSGeo Annual General Meeting (AGM) will take place on 10th Sep
> 2020 from 6 pm to 8pm UTC
> (https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSGeo+AGM=20200910T18=1440=2)
> as a virtual meeting.
> 
> AGM 2020 announcement:
> - https://lists.osgeo.org/pipermail/discuss/2020-August/039019.html
> 
> AGM 2020 Wiki page:
> - https://wiki.osgeo.org/wiki/Annual_General_Meeting_2020
> 
> 
> We are, like all OSGeo projects, requested to provide one slide with
> the development and community news of the last year.
> Our draft slide is at p. 40:
> 
> https://docs.google.com/presentation/d/1C6llSnWZ28c2aWQgttPiOnoo6dttdqKg07ugU_yr6Uc/edit#slide=id.g233aae6a05_0_0
> 
> Please contribute to the content!
> 
> Markus
> 
> PS: content suggestions from the board list:
> 
> - key accomplishments
> - releases
> - infrastructure or process changes
> - community health and happiness
> - areas for improvements
> - these are challenges faced by the project
> - opportunities to help
> - anything for members to help with?
> - requests and communication
> - any formal request from the board, marketing or other committees?
> - did you make a budget request for 2020? How did it go ...
> - external correspondence? letter of recommendation for a GSOC
> student? code donation? etc…
> - outlook for 2020
> - any roadmap items to share with our members?
> - let the board know if there is anything to plan for in 2020
> ___
> 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

Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
Associate director and faculty fellow at the Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

"All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

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

Re: [GRASS-dev] Release policy: towards an urgent GRASS GIS release with Python3 support

[Helena Mitasova]

I agree that we need tp release GRASS with python 3 support as soon as possible 
and 7.8 seems more feasible 
than 8.0. I would like to hear from Anna on how much much is needed and whether 
she or Vashek need to spend
some significant time on it (which would be OK with me as this is a critical 
need). They are on vacation at this time
so I am not sure whether they will respond (Martin may have talked to them 
recently).

Helena

> On Dec 27, 2018, at 6:26 AM, Markus Neteler  wrote:
> 
> On Thu, Dec 27, 2018 at 12:18 PM Luca Delucchi  wrote:
>> Il giorno gio 27 dic 2018, 10:38 Markus Neteler  ha 
>> scritto:
> ...
>> Are we sure that a so big change does not require a major release, moving 
>> forward to 8.0?
>> 
>> I remember already some discussion about it but I don't remember if we 
>> arrive to a conclusion.
> 
> AFAIK there was no conclusion.
> 
> Keep in mind that changing to grass80 will break most of the existing
> interfaces (QGIS, R, ...) which rely on grass7x for startup. It will
> take a long time for them to catch up and propagate their needed
> changes through their update channels.
> And Python3 support is rather a "must" nowadays, rather a big bugfix
> than a new feature.
> 
> My suggestion would be to see it in a rather pragmatic way and use V8
> to roll out e.g. a new raster format.
> 
> my2cents,
> Markus
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev

Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
Associate director and faculty fellow at the Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/publications.html

"All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

___
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"

[Helena Mitasova]

Michael,

we are all aware of this issue and I think that this should be part of the 
discussion 
of how to make the GRASS startup more friendly for newcomers.
Here is a summary of some ideas from the recent discussion on the list and in 
our lab:
https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/New_Startup 
<https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/New_Startup>

as you can see the proposals refer to a project (it was also called "project 
location"), 
but as we discussed it this week in our lab it can get complicated. CRS may be 
confusing 
to new users as well because there can be many different locations with the 
same CRS for
different projects.

Feel free to add summary of your ideas to the trac linked above,

Helena


> On Jun 1, 2018, at 6:51 PM, Michael Barton  wrote:
> 
> As one of the most venerable desktop GIS packages and perhaps THE most 
> venerable still in existence, GRASS has some quirks that harken back to its 
> origins long ago. Most are simply quirky. But the folder hierarchy called a 
> “location” is very confusing in today’s GIS world. Originally, it did 
> primarily refer to maps referencing a geographic location in the world. 
> Although that meaning still exists in the ‘default region’, GRASS locations 
> primarily refer to a coordinate reference system (CRS). In fact, while the 
> CRS of a location cannot be changed (unless you manually alter some of the 
> files in the directory, at the risk of making maps unuseable), the default 
> region can be. So a location now refers to a fixed CRS and a changeable 
> geographic extent.
>  
> Use of the anachronistic term “location” to refer to a CRS is a quirk that 
> makes GRASS more confusing to initial users. I suggest we consider beginning 
> to migrate the term “location” to “CRS”. The term “location” does not occur 
> in a large number of module interfaces: those (like g.mapset) for changing to 
> a new working directory on the fly, vector and raster reprojection modules, 
> and maybe a couple of others. It occurs in the GUI at startup, in the 
> location wizard of course, and in some tools for georeferencing.
>  
> We could initially maintain backward compatibility and increase 
> understandability by simply referring to “location” as something like 
> “location/CRS” where ever it shows up in the GUI, but leave module arguments 
> alone. A next step would be to have modules that require “location=” as an 
> argument accept either “location=” or “CRS=”. And maybe that is enough. We 
> could keep “location” where it currently occurs in existing command modules 
> and scripts as a legacy option. Likewise, we could keep it in current code, 
> only changing during code rewrites. Any new modules that need to refer to 
> this file hierarchy would use “CRS”.
>  
> Thoughts?
>  
> 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
>  
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev

Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
Associate director and faculty fellow at the Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/publications.html 
<http://geospatial.ncsu.edu/osgeorel/publications.html>

"All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

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

Re: [GRASS-dev] [OSGeo-Discuss] [GRASS-user] Helena Mitasova awarded 2018 Waldo-Tobler GIScience Prize

[Helena Mitasova]

Thank you all - this is very special for me because Professor Tobler has been a 
great inspiration for our work early on.
And big thanks to the GRASS GIS community for creating an environment where all 
developers can thrive, 
and to big OSGeo family for support, 

best wishes, Helena


> On Apr 4, 2018, at 8:28 PM, Venkatesh Raghavan 
> <ragha...@media.osaka-cu.ac.jp> wrote:
> 
> Congratulations Helena!!
> 
> Venka
> 
> On 4/5/2018 7:23 AM, Massimiliano Cannata wrote:
>> Congratulations
>> 
>> Il gio 5 apr 2018, 08:11 Helmut Kudrnovsky <hel...@web.de> 
>> <mailto:hel...@web.de> ha scritto:
>> 
>>> forwarding:
>>> https://lists.osgeo.org/pipermail/grass-user/2018-April/078052.html 
>>> <https://lists.osgeo.org/pipermail/grass-user/2018-April/078052.html>
>>> 
>>> -
>>> 
>>> https://gi-science.blogspot.com/2018/04/helena-mitasova-awarded-2018-waldo.html
>>>  
>>> <https://gi-science.blogspot.com/2018/04/helena-mitasova-awarded-2018-waldo.html>
>>> 
>>> "The Austrian Academy of Sciences through its Commission for GIScience is
>>> awarding the GIScience Prize named after Prof Waldo Tobler to a scientist
>>> having demonstrated outstanding and sustained contributions to the
>>> discipline worthy of inspiring young scientists in Geoinformatics and
>>> Geographic Information Science, and having accomplished significant
>>> advances in research and education.
>>> 
>>> The received nominations were reviewed and assessed by an external panel of
>>> peers, who unanimously recommended to award the 2018 prize to Prof Helena
>>> Mitasova (North Carolina State University)."
>>> 
>>> 
>>> congratulations!
>>> 
>>> kind regards
>>> Helmut
>>> 
>>> OSGeo charter member
>>> ___
>>> Discuss mailing list
>>> disc...@lists.osgeo.org <mailto:disc...@lists.osgeo.org>
>>> https://lists.osgeo.org/mailman/listinfo/discuss 
>>> <https://lists.osgeo.org/mailman/listinfo/discuss>
>> 
>> 
>> ___
>> Discuss mailing list
>> disc...@lists.osgeo.org <mailto:disc...@lists.osgeo.org>
>> https://lists.osgeo.org/mailman/listinfo/discuss 
>> <https://lists.osgeo.org/mailman/listinfo/discuss>
> ___
> Discuss mailing list
> disc...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/discuss

Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
Associate director and faculty fellow at the Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/publications.html 
<http://geospatial.ncsu.edu/osgeorel/publications.html>

"All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

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

Re: [GRASS-dev] [GRASS-user] Grass on MacOS (Ken Mankoff)

[Helena Mitasova]

I also looked at the links that Jurgen Fisher has sent a while ago so the next 
step is to request SAC to buy it for GRASS. Markus, are you on SAC - if yes, 
can you please make a request there? I missed the start of the last board 
meeting but I put it on agenda and this is how I think board handles it 
(through SAC)

Helena

Board motion: https://lists.osgeo.org/pipermail/board/2015-October/008514.html 
<https://lists.osgeo.org/pipermail/board/2015-October/008514.html>


> On Feb 12, 2018, at 4:30 AM, Markus Neteler <nete...@osgeo.org> wrote:
> 
> On Fri, Jan 19, 2018 at 1:26 AM, Helena Mitasova <hmit...@ncsu.edu> wrote:
>> I believe OSGeo covers this for projects (but I may be mixing it up with
>> something else) - if not, GRASS has a budget from OSGeo which can be used to
>> cover it (we can give up some stickers for this). I thought we already had
>> it.
>> Let me know whether I should check with board/Michael the best way to handle
>> this.
> 
> 
> I found an older email from your side, see below.
> 
> Best, Markus
> 
> 
> -- Forwarded message --
> From: Helena Mitasova <hmit...@ncsu.edu>
> Date: Sun, Oct 18, 2015 at 1:22 AM
> Subject: [GRASS-PSC] OSGeo signing certificates
> To: GRASS-PSC <grass-...@lists.osgeo.org>
> 
> 
> This is just FYI, that board has just voted for OSGeo to obtain
> signing certificates for OSGeo projects -
> see more details in the follwing threads below:
> 
> motion:
> https://lists.osgeo.org/pipermail/board/2015-October/013364.html
> 
> discussion:
> https://lists.osgeo.org/pipermail/board/2015-October/013321.html
> 
> It was requested by QGIS but it should help GRASS as well,
> 
> Helena
> ___
> grass-psc mailing list
> grass-...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-psc

Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
Associate director and faculty fellow at the Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/publications.html 
<http://geospatial.ncsu.edu/osgeorel/publications.html>

"All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

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

Re: [GRASS-dev] [GRASS-user] Grass on MacOS (Ken Mankoff)

[Helena Mitasova]

I believe OSGeo covers this for projects (but I may be mixing it up with 
something else) - if not, GRASS has a budget from OSGeo which can be used to 
cover it (we can give up some stickers for this). I thought we already had it.
Let me know whether I should check with board/Michael the best way to handle 
this.

Helena

> On Jan 18, 2018, at 7:12 PM, Michael Barton <michael.bar...@asu.edu> wrote:
> 
> It would make life easier for people using GRASS. I'm not sure how that would 
> be implemented, but if the QGIS folks do it, we should be able to do it too.
> 
> 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
> 
> voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
> fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
> www: http://www.public.asu.edu/~cmbarton 
> <http://www.public.asu.edu/~cmbarton>, http://csdc.asu.edu 
> <http://csdc.asu.edu/>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> On Jan 17, 2018, at 11:24 PM, Markus Neteler <nete...@osgeo.org 
>> <mailto:nete...@osgeo.org>> wrote:
>> 
>> 
>> Am 18.01.2018 12:29 vorm. schrieb "Michael Barton" <michael.bar...@asu.edu 
>> <mailto:michael.bar...@asu.edu>>:
>> Thanks Carlos,
>> 
>> Many recent versions seem to take a long time to initialize the first time 
>> opened. And of course this needs to be opened with a Ctrl-click because I 
>> have not paid Apple $100/year to be able to sign packages. 
>> 
>> As far as I know the QGIS project pays this license fee (through OSGeo?).
>> Should we do that as well?
>> 
>> Markus
>> 
>> 
> 
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev

Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
Associate director and faculty fellow at the Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/publications.html 
<http://geospatial.ncsu.edu/osgeorel/publications.html>

"All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

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

Re: [GRASS-dev] Grass on MacOS (Ken Mankoff)

[Helena Mitasova]

t;>> Date: January 14, 2018 at 7:46:27 AM MST
>>>> To: Adam Dershowitz <adershow...@exponent.com 
>>>> <mailto:adershow...@exponent.com>>
>>>> Cc: Carlos Grohmann <carlos.grohm...@gmail.com 
>>>> <mailto:carlos.grohm...@gmail.com>>, "grass-user\@lists.osgeo.org 
>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.osgeo.org=DwMFaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=XA6yReZT2BoAaNeg126zooD8EtmwRkQ-7rwLzxODg7I=yZDoUcNj1d74AFJRYotWx_ewnwtaFx97LQBYr0ErH_s=>"
>>>>  <grass-u...@lists.osgeo.org <mailto:grass-u...@lists.osgeo.org>>
>>>> 
>>>> 
>>>> Hi Adam,
>>>> 
>>>> I'm glad to hear you got GRASS working on OS X w/ MacPorts. That is the 
>>>> system I use too. I recently switched from HomeBrew. I got GRASS working 
>>>> with fink too, but prefer MacPorts, although there are some 
>>>> MacPort-specific issues if you want to use the temporal framework.
>>>> 
>>>> I found it helpful to set GRASS_PYTHON and have it pointing to
>>>> 
>>>> export GRASS_PYTHON=/opt/local/bin/python2.7
>>>> 
>>>> I don't like installing 3rd-party frameworks, so I also have QGIS 
>>>> installed via MacPorts and it works well.
>>>> 
>>>> For GRASS, I had to "sudo port install gdal +netcdf" in order to be able 
>>>> to read in NetCDF files. For QGIS I did "sudo port install QGIS +qt4 
>>>> +grass".
>>>> 
>>>>  -k.
>>>> 
>>>> 
>>>> On 2018-01-14 at 00:37, Adam Dershowitz <adershow...@exponent.com 
>>>> <mailto:adershow...@exponent.com>> wrote:
>>>>> Thanks, but…I use Macports for a bunch of things, and homebrew and
>>>>> maports don’t play well together. So, I can’t easily do that. I did
>>>>> get the macports version to work after I asked the question. It was
>>>>> actually just due to the fact that I have been using the Kyngchoas
>>>>> version for a long time, and that used to require that GRASS_PYTHON be
>>>>> set in .bash_profile. But, I had set it to point to an old directory a
>>>>> while back, and that folder didn’t exist. So, I just had to delete
>>>>> that environmental variable and the macports version now works fine.
>>>>> And, the Kyngchaos version of qgis does seem to work fine.
>>>>> 
>>>>> Thanks for the suggestion. I suppose that it would be useful to have
>>>>> working binaries to avoid these kinds of issues.
>>>> 
>>> 
> 
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev

Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
Associate director and faculty fellow at the Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/publications.html 
<http://geospatial.ncsu.edu/osgeorel/publications.html>

"All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

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

Re: [GRASS-dev] Different CRS matching in 7.2 and trunk

[Helena Mitasova]

> On Nov 10, 2017, at 7:20 PM, Markus Metz <markus.metz.gisw...@gmail.com> 
> wrote:
> 
> 
> 
> On Sat, Nov 11, 2017 at 12:22 AM, Helena Mitasova <hmit...@ncsu.edu 
> <mailto:hmit...@ncsu.edu>> wrote:
> >
> > Please note, that  in spite of the fact that the datum.table shows same 
> > transformation parameters,
> > different nad83 datums are different (it is not just a different name for 
> > the same datum) and there are different EPSG codes associated
> > with the relevant CRS.
> > You can find more about it here (or just google it)
> > https://confluence.qps.nl/pages/viewpage.action?pageId=29855153 
> > <https://confluence.qps.nl/pages/viewpage.action?pageId=29855153>
> >
> > Supposedly, the shift from NAD83(86) to NAD83(HARN) can be done with the 
> > NGS NADCON program (I have not checked it out)
> > (http://www.ngs.noaa.gov/TOOLS/Nadcon/Nadcon.shtml 
> > <http://www.ngs.noaa.gov/TOOLS/Nadcon/Nadcon.shtml>).
> 
> There are 12 (!) different definitions for NAD83. What to do about this? 
> Regard these 12 definitions as different datums? In this case I would need to 
> reinstate the datum check and we need to add more entries to datum.table.

Markus, we absolutely need to have a datum check - although the differences 
between different NAD83 datums are less than a meter, differences between NAD27 
and NAD83 are over hundred meters in some areas. Anything that has a different 
EPSG should be treated as different CRS exactly for the reasons you mentioned 
in your answer to Vasek.

Helena

> 
> Markus M
> 
> >
> > Helena
> >
> > On Nov 10, 2017, at 5:30 PM, Markus Metz <markus.metz.gisw...@gmail.com 
> > <mailto:markus.metz.gisw...@gmail.com>> wrote:
> >
> >
> >
> > On Fri, Nov 10, 2017 at 8:46 PM, Vaclav Petras <wenzesl...@gmail.com 
> > <mailto:wenzesl...@gmail.com>> wrote:
> > >
> > > On Fri, Nov 10, 2017 at 2:21 PM, Markus Metz 
> > > <markus.metz.gisw...@gmail.com <mailto:markus.metz.gisw...@gmail.com>> 
> > > wrote:
> > > >
> > > > > >
> > > > > > 7.2 considers this OK while trunk considers this different. I'm not 
> > > > > > sure which one is correct.
> > > > >
> > > > > In this case, 7.2 is correct, but 7.2 does not compare datums, i.e. 
> > > > > projections would be regarded as matching even with e.g. nad27 and 
> > > > > nad83.
> > > > > The comparison of datums is new in 7.3 and needs some refinement.
> > > > >
> > > > > I will fix the comparison of swapped lat_1 and lat_2.
> > > >
> > > > Fixed in trunk r71656.
> > > >
> > > > The test for different datum names has been disabled again in trunk 
> > > > r71657. There are several different datum names in lib/gis/datum.table 
> > > > that apparently mean the same: same ellipsoid and same transformation 
> > > > parameters. Apparently, GRASS does not provide a datum name when 
> > > > converting projection information from GRASS to proj4 for reprojecting 
> > > > data.
> > >
> > >
> > > Thank you so much, Markus. This saves me a lot of trouble.
> >
> > About avoiding trouble, the motivation of the stricter CRS comparison is to 
> > avoid subsequent geolocation errors. If data have been imported and 
> > differences in the CRS were not detected, it can become very difficult 
> > later on in the processing to figure out the reason for geolocation errors 
> > (different data not matching each other spatially). I'm not sure what to do 
> > about different datum names. The current check relies on the test for 
> > differences in ellipsoids.
> >
> > Markus M
> >
> > >
> > > (I'm working on a Jupyter Notebook where I need trunk.)
> > > https://github.com/wenzeslaus/Notebook-for-processing-point-clouds-in-GRASS-GIS
> > >  
> > > <https://github.com/wenzeslaus/Notebook-for-processing-point-clouds-in-GRASS-GIS>
> > >
> > > >
> > > >
> > > > Markus M
> > > >
> >
> > ___
> > grass-dev mailing list
> > grass-dev@lists.osgeo.org <mailto:grass-dev@lists.osgeo.org>
> > https://lists.osgeo.org/mailman/listinfo/grass-dev 
> > <https://lists.osgeo.org/mailman/listinfo/grass-dev>
> >
> >
> > Helena Mitasova
> > Professor at the Department of Marine, 
> > Earth, and Atmospheric Sciences

Re: [GRASS-dev] Different CRS matching in 7.2 and trunk

[Helena Mitasova]

Please note, that  in spite of the fact that the datum.table shows same 
transformation parameters,
different nad83 datums are different (it is not just a different name for the 
same datum) and there are different EPSG codes associated
with the relevant CRS.
You can find more about it here (or just google it)
https://confluence.qps.nl/pages/viewpage.action?pageId=29855153 
<https://confluence.qps.nl/pages/viewpage.action?pageId=29855153>

Supposedly, the shift from NAD83(86) to NAD83(HARN) can be done with the NGS 
NADCON program (I have not checked it out)
(http://www.ngs.noaa.gov/TOOLS/Nadcon/Nadcon.shtml 
<http://www.ngs.noaa.gov/TOOLS/Nadcon/Nadcon.shtml>).

Helena

> On Nov 10, 2017, at 5:30 PM, Markus Metz <markus.metz.gisw...@gmail.com> 
> wrote:
> 
> 
> 
> On Fri, Nov 10, 2017 at 8:46 PM, Vaclav Petras <wenzesl...@gmail.com> wrote:
> >
> > On Fri, Nov 10, 2017 at 2:21 PM, Markus Metz 
> > <markus.metz.gisw...@gmail.com> wrote:
> > >
> > > > >
> > > > > 7.2 considers this OK while trunk considers this different. I'm not 
> > > > > sure which one is correct.
> > > >
> > > > In this case, 7.2 is correct, but 7.2 does not compare datums, i.e. 
> > > > projections would be regarded as matching even with e.g. nad27 and 
> > > > nad83.
> > > > The comparison of datums is new in 7.3 and needs some refinement.
> > > >
> > > > I will fix the comparison of swapped lat_1 and lat_2.
> > >
> > > Fixed in trunk r71656.
> > >
> > > The test for different datum names has been disabled again in trunk 
> > > r71657. There are several different datum names in lib/gis/datum.table 
> > > that apparently mean the same: same ellipsoid and same transformation 
> > > parameters. Apparently, GRASS does not provide a datum name when 
> > > converting projection information from GRASS to proj4 for reprojecting 
> > > data.
> >
> >
> > Thank you so much, Markus. This saves me a lot of trouble.
> 
> About avoiding trouble, the motivation of the stricter CRS comparison is to 
> avoid subsequent geolocation errors. If data have been imported and 
> differences in the CRS were not detected, it can become very difficult later 
> on in the processing to figure out the reason for geolocation errors 
> (different data not matching each other spatially). I'm not sure what to do 
> about different datum names. The current check relies on the test for 
> differences in ellipsoids.
> 
> Markus M
> 
> >
> > (I'm working on a Jupyter Notebook where I need trunk.)
> > https://github.com/wenzeslaus/Notebook-for-processing-point-clouds-in-GRASS-GIS
> >
> > >
> > >
> > > Markus M
> > >
> 
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev

Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/publications.html

"All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

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

Re: [GRASS-dev] GRASS resources in the new OSGeo website

[Helena Mitasova]

Vashek,

the deadline is only for the demo of the new web site to be shown at FOSS4G - 
the more we have the better, but
there will be the saturday code spring specifically set up to work with the 
site designers to add more content and modify things as needed. We will be able 
to add content after the conference as well.

Thanks for testing,

Helena


> On Aug 10, 2017, at 10:14 AM, Vaclav Petras <wenzesl...@gmail.com> wrote:
> 
> I assume this is replacement for:
> 
> http://www.osgeo.org/educational_content?filter1=GRASS 
> <http://www.osgeo.org/educational_content?filter1=GRASS>
> 
> Did you get where to put software used? I asked that in the feedback field.
> 
> So far I added:
> 
> http://www.osgeo.org/node/1592 <http://www.osgeo.org/node/1592>
> 
> Many more to go.
> 
> https://grass.osgeo.org/documentation/ 
> <https://grass.osgeo.org/documentation/>
> https://grass.osgeo.org/documentation/tutorials/ 
> <https://grass.osgeo.org/documentation/tutorials/>
> https://ncsu-geoforall-lab.github.io/grass-as-a-platform/ncgis2017.html#/56 
> <https://ncsu-geoforall-lab.github.io/grass-as-a-platform/ncgis2017.html#/56>
> 
> I don't know when I can do that. Is tomorrow the deadline? (I remember Friday 
> was mentioned in different context.)
> 
> Vaclav
> 
> 
> 
> On Thu, Aug 10, 2017 at 6:32 AM, Luca Delucchi <lucadel...@gmail.com 
> <mailto:lucadel...@gmail.com>> wrote:
> Hi all,
> 
> it is possible to add resources (tutorial, workshop, ecc) to the new
> OSGeo website, you can fill the form [0], and later this info will be
> added to the website.
> 
> Thanks
> 
> 
> [0] 
> https://docs.google.com/forms/d/e/1FAIpQLSdYn2TxII8nm_1OQ43RWTfVonTkWRa_KH4O-6BL4l4tjH7QTQ/viewform
>  
> <https://docs.google.com/forms/d/e/1FAIpQLSdYn2TxII8nm_1OQ43RWTfVonTkWRa_KH4O-6BL4l4tjH7QTQ/viewform>
> --
> ciao
> Luca
> 
> www.lucadelu.org <http://www.lucadelu.org/>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org <mailto:grass-dev@lists.osgeo.org>
> https://lists.osgeo.org/mailman/listinfo/grass-dev 
> <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

Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/publications.html 
<http://geospatial.ncsu.edu/osgeorel/publications.html>

"All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

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

Re: [GRASS-dev] GRASS flyer for the new osgeo branding

[Helena Mitasova]

Luca,

I agree with Vasek’s comments, especially that including the logo showing that 
this is an OSGeo Project would be useful.
Also you can just say Development and skip the word info. 
On the website and wiki we have Addons, AddOns, Add-ons and add-ons, I don’t 
think it matters too much but perhaps 
the ones with - or O are easier to understand?

thanks a lot for working on this, Helena


> On Jul 24, 2017, at 10:01 PM, Vaclav Petras <wenzesl...@gmail.com> wrote:
> 
> Thank you for working on the flyer, Luca. Please see my comments below.
> 
> On Mon, Jul 24, 2017 at 6:55 PM, Luca Delucchi <lucadel...@gmail.com 
> <mailto:lucadel...@gmail.com>> wrote:
> I worked for the GRASS flyer [0] with the new osgeo branding, the
> content is really similar to the GRASS flyer, just different layout.
> 
> Comments?
> 
> One of the triangles at the bottom is white (the overall background is 
> transparent). Is that an intention?
> 
> A long term endeavor: the whole paragraph shows bold for me.
> 
> Interoperability: I would remove gstat since AFAIU it is retired. There may 
> be better candidates for that place. For example, we are successfully using 
> GRASS with Blender (although the heavy lifting is mostly done on the Blender 
> part thanks to Blender GIS plugin & GDAL). ParaView may be a better candidate.
> 
> G Logo: You have there logo without text with GRASS GIS next to it, so it 
> looks like a logo. We need to be careful with that and keep the brand. I 
> agree that we need a more horizontal logo and that we can have a logo in 
> OSGeo colors (as an alternative). I'm attaching Vincent's version with text 
> but in OSGeo colors (or close to them - there was still some confusion when I 
> was grabbing those).
> 
> OSGeo logo: It is not there, should be?
> 
> URL: Does it need to be a full URL with http://?
> 
> Vaclav
> _______
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev

Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/publications.html 
<http://geospatial.ncsu.edu/osgeorel/publications.html>

"All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

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

[GRASS-dev] update of next event on website needed

[Helena Mitasova]

Assuming that users will visit GRASS GIS website following the GRASS7.2.1 
release 
https://grass.osgeo.org/ 

should the Next event be updated to
 
foss4g europe 
https://europe.foss4g.org/2017/ 

and foss4g global Boston
http://2017.foss4g.org/ 

(I am not sure I have access to do it myself),

Thank you, Helena

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

Re: [GRASS-dev] [release planning] 7.2.0

[Helena Mitasova]

Regarding the release there is also a major issue with v.in.lidar - Vasek is 
this still a problem in 7.2?

Helena

> On Dec 10, 2016, at 11:18 AM, Vaclav Petras <wenzesl...@gmail.com> wrote:
> 
> 
> On Sat, Dec 10, 2016 at 10:57 AM, Martin Landa <landa.mar...@gmail.com> wrote:
> 2016-12-10 16:51 GMT+01:00 Markus Neteler <nete...@osgeo.org>:
> > On Dec 7, 2016 10:02 PM, "Markus Neteler" <nete...@osgeo.org> wrote:
> >> Now the current showstopper is MacOSX it seems...
> >
> > Is this really a GRASS issue?
> > Do we still wait?
> 
> I don't think so. Putting to cpy Anna and Vaclav who knows more. Ma
> 
> The issue is with Mac OS system Python. On Linux, I would say "ask your 
> maintainers," no idea what you do on Mac. The Python version needs to be 
> updated. There is no way around it except for a major code change in GRASS 
> which would workaround a bug in Python on Mac (Mac libs (newly?) behaving 
> differently then other unixes or something like that). The bug is already 
> fixed and fix is released, so Mac needs to update Python.
> 
> I would say, even at the download site, that there are no Mac binaries until 
> Mac Python maintainers update to latest Python 2.7.
> 
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev

Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/publications.html

"All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

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

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Helena Mitasova]

for r.stream* and r.geomorphon (both worth to be included into the core) it 
would be useful 
to contact the developers (Jarek) - 

Vasek, can you please email him to ask about their interest 
in getting the modules included and make the necessary adjustments?
From my discussion with Jarek last year I got an impression that they have 
improved versions
of these modules, but I am not sure how those conform to the GRASS core 
standards in terms
of portability. However, they were interested in having the modules in core 
GRASS.

Helena

> On Jul 5, 2016, at 4:31 AM, Helmut Kudrnovsky <hel...@web.de> wrote:
> 
>> The r.stream* modules have been around for quite awhile and are very useful. 
> 
> regarding the r.stream.*-modules, some tickets may be solved first:
> 
> https://trac.osgeo.org/grass/ticket/2516
> https://trac.osgeo.org/grass/ticket/2356
> https://trac.osgeo.org/grass/ticket/2348
> https://trac.osgeo.org/grass/ticket/2302
> https://trac.osgeo.org/grass/ticket/2301
> https://trac.osgeo.org/grass/ticket/2296
> https://trac.osgeo.org/grass/ticket/2237
> https://trac.osgeo.org/grass/ticket/2218
> 
> 
> 
> -
> best regards
> Helmut
> --
> View this message in context: 
> http://osgeo-org.1560.x6.nabble.com/Upcoming-7-2-0-review-which-addons-to-move-to-core-tp5274533p5274703.html
> Sent from the Grass - Dev mailing list archive at Nabble.com.
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev

Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/publications.html

"All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

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

Re: [GRASS-dev] grass 7.2 planning

[Helena Mitasova]

Michael,

we can look at these issues during our visit at ASU later this month -
Vasek has done quite a bit of work on this and can give you an overview on
what the best approach would be - see here abstract of his talk at FOSS4G
NA

https://2016.foss4g-na.org/session/grass-gis-loves-lidar

Helena

On Sun, May 1, 2016 at 1:21 AM, Michael Barton <michael.bar...@asu.edu>
wrote:

> Unfortunately, the very important "ground" module (filtering for ground
> surface points) requires PCL, but perhaps not VTK which may be mainly for
> the "view"/visualization modules and functions. JSON is only needed for the
> "pipeline" module
>
> 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
>
> voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
> fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>
>
> On Apr 30, 2016, at 4:05 PM, grass-dev-requ...@lists.osgeo.org wrote:
>
> *From: *Sebastiaan Couwenberg <sebas...@xs4all.nl>
> *Subject: **Re: [GRASS-dev] grass 7.2 planning*
> *Date: *April 30, 2016 at 2:41:24 PM MST
> *To: *<grass-dev@lists.osgeo.org>
>
>
> On 04/30/2016 11:22 PM, Markus Neteler wrote:
>
> Note that PDAL needs tons of extra packages including gl2ps, hexer,
> jsoncpp, laszip, netcdf-cxx, nitro, openni, pcl, points2grid, qhull,
> tinyxml, vtk, boost-date-time, boost-system.
>
>
> You only need all those dependencies if need all the PDAL plugins, core
> PDAL only requires GDAL, the other dependencies are optional.
>
> The pdal Debian package only enables the plugins for which the
> dependencies are available (greyhound, icebridge, python & sqlite). The
> PCL plugin pulls in the enormous and problematic VTK dependency chain
> and has been disabled in the Debian package despite the dependencies
> being available.
>
> Kind Regards,
>
> Bas
>
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Helena Mitasova
Professor
Department of Marine, Earth and Atmospheric Sciences
North Carolina State University
1125 Jordan Hall
NCSU Box 8208
Raleigh, NC 27695-8208
http://www4.ncsu.edu/~hmitaso/
http://geospatial.ncsu.edu/

email: hmit...@ncsu.edu
ph: 919-513-1327 (no voicemail)
fax 919 515-7802
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2456: read CSV from GDAL data directory

[Helena Mitasova]

I suggest to treat it as a separate datum, the coordinates would be
different although the differences are for most applications negligible.
With the sub-meter resolution data now quite common it is important to
treat it as different.
 See more info here:
http://www2.arnes.si/~gljsentvid10/datm_faq.html#1.2
https://confluence.qps.nl/pages/viewpage.action?pageId=29855153
http://www.ngs.noaa.gov/faq.shtml#WhatHARN

Just to make things more complicated a committee was set up in NC to decide
how to deal with upcoming dynamic datum with more frequent updates.

Helena

On Mon, Apr 25, 2016 at 10:47 PM, Markus Neteler <nete...@osgeo.org> wrote:

> (cc Helena)
>
> First of all, thanks to Even and Paul to shed some light on this!
>
> On Mon, Apr 25, 2016 at 10:37 PM, Paul Kelly
> <paul-gr...@stjohnspoint.co.uk> wrote:
> ...
> > The problem is actually even simpler (datum simply not recognised in
> GRASS)
> > and there are two possible solutions:
> >
> > 1) If we want NAD83_High_Accuracy_Reference_Network to be treated as a
> > completely separate datum from North_American_Datum_1983, then we add it
> as
> > a new line in lib/gis/datum.table as per the first attached patch.
> >
> > 2) If we want NAD83_High_Accuracy_Reference_Network to be treated as
> > equivalent to North_American_Datum_1983 (this means once the location has
> > been created, 'g.proj -w' will report the datum name as
> > North_American_Datum_1983), then we add two new lines to the equivalent
> > pairs array in lib/proj/convert.c as per the second attached patch.
> >
> > I don't really feel qualified to decide which is the most desirable
> > behaviour, so I'll leave that up to someone else to decide, if that's OK.
>
> I also don't feel too qualified here :) but from a user's point of
> view a change of name is confusing.
>
> So option 1) looks better to me (i.e., " datum.table.patch") which is
> tested ok here.
> Maybe Helena as our NC expert has an opinion here?
>
> Paul, still struggling with "SIRGAS2000"
> https://trac.osgeo.org/grass/ticket/2456#comment:15
> (g.proj versus testepsg output). Needs a different trick?
>
> Markus
>
>
> --
> Markus Neteler
> http://www.mundialis.de - free data with free software
> http://courses.neteler.org/blog/
>



-- 
Helena Mitasova
Professor
Department of Marine, Earth and Atmospheric Sciences
North Carolina State University
1125 Jordan Hall
NCSU Box 8208
Raleigh, NC 27695-8208
http://www4.ncsu.edu/~hmitaso/
http://geospatial.ncsu.edu/

email: hmit...@ncsu.edu
ph: 919-513-1327 (no voicemail)
fax 919 515-7802
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.surf.rst segment boundaries

[Helena Mitasova]

Anna is right, 
but there may be another case if you are interpolating from contours or 
isolines (such as isochrones as you may be doing) 
make sure your optimize the number of points on the contour - click on the two 
last images on the page below
to see the difference
http://www4.ncsu.edu/~hmitaso/grasswork/interpgen.html

Vasek may have a better example for this - we had to use this approach when 
interpolating temporal
surface from time series of contours.

If you see the segments only in some spots that don’t have data (e.g. bare 
ground lidar where buildings were removed)
Anna has written a v.surf.rst wrapper that does two passes interpolation to 
minimize the visible segments.

Perhaps if you could share the data and the command that you have used we can 
suggest a solution.

Helena


> On Nov 18, 2015, at 1:35 PM, Anna Petrášová <kratocha...@gmail.com> wrote:
> 
> 
> 
> On Wed, Nov 18, 2015 at 1:29 PM, Michael Barton <michael.bar...@asu.edu> 
> wrote:
> Helena (or anyone else),
> 
> I really like the amount of control over interpolation that comes with 
> v.surf.rst. But it always gives me artifacts at the segment boundaries 
> (little “cliffs”). Is there some way to prevent that?
> 
> Could you perhaps share the command you use and what type of data (sparse 
> points or dense lidar) you run it for? From my experience, too low tension or 
> low npmin can cause that. Default settings are usually not producing the 
> segments, but it might be time inefficient.
> 
> Anna
> 
> 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
> 
> voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
> fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
> 

Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/publications.html

"All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

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

Re: [GRASS-dev] r.relief

[Helena Mitasova]

I think that user should do the conversion (in most cases it needs to be 
reinterpolated).
I think that the current behavior is right for many reasons,

Helena


 On Apr 30, 2015, at 8:25 AM, Paulo van Breugel p.vanbreu...@gmail.com wrote:
 
 Hi,
 
 When running r.relief (in GRASS7.1) on a integer DEM raster, the output is an 
 integer map. Is this intended behavior? Would it be possible to have r.relief 
 convert the layer to double precision / float automatically if the DEM is of 
 CELL type?
 
 Paulo
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev

Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/
All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

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

Re: [GRASS-dev] r.relief

[Helena Mitasova]

In areas of low relief the integer DEMs have steps (you get alternating flat 
and steep areas, with steep
areas along contours which you may be seeing in your shaded relief map), so 
when you run
r.relief and you get a nice smooth map because the data were converted to float 
using bilinear interpolation
you do not realize that you have the steps (you don’t see them on the 2D 
elevation map).
Then you run some modeling or analysis using slope or flow routing running 
through these flats (which could be quite large) and you get various artificial 
patterns of the modeling results in these flat areas or you run some 
statistical analysis you will get serious bias in the histogram
see the slide #14 here
http://courses.ncsu.edu/mea582/common/GIS_anal_lecture/GIS_Anal_Ltopoanal.ppt

If you convert to float using nearest neighbor you may still get the flats 
depending on the resolution.
Integer DEMs are pretty much a pain to work with if you are doing more than 
just visualizing 
the terrain and the steps along 1m contours
are quite hard to get rid of in areas of low relief - you pretty much have to 
reinterpolate the DEM.
Integer shaded relief output alerts user that the data are integer and they may 
have a problem,
or if it is in mountains that the integers are not an issue.

So what may be a convenience for one user may cause problems for other users, 
so if we want to conversion it should be a flag (similar situation like the -a 
flag in r.watershed).

Helena



 On Apr 30, 2015, at 10:00 AM, Paulo van Breugel p.vanbreu...@gmail.com 
 wrote:
 
 Out of curiosity, what are those reasons? From a user perspective it might 
 not be that obvious (well, it wasn't for me at least). If the current 
 implementation is maintained, perhaps it would be useful to add a note to the 
 manual page?
 
 Paulo
 
 
 
 On 30-04-15 15:15, Helena Mitasova wrote:
 I think that user should do the conversion (in most cases it needs to be 
 reinterpolated).
 I think that the current behavior is right for many reasons,
 
 Helena
 
 
 On Apr 30, 2015, at 8:25 AM, Paulo van Breugel p.vanbreu...@gmail.com 
 wrote:
 
 Hi,
 
 When running r.relief (in GRASS7.1) on a integer DEM raster, the output is 
 an integer map. Is this intended behavior? Would it be possible to have 
 r.relief convert the layer to double precision / float automatically if the 
 DEM is of CELL type?
 
 Paulo
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev
 Helena Mitasova
 Professor at the Department of Marine,
 Earth, and Atmospheric Sciences
 and Center for Geospatial Analytics
 North Carolina State University
 Raleigh, NC 27695-8208
 hmit...@ncsu.edu
 http://geospatial.ncsu.edu/osgeorel/
 All electronic mail messages in connection with State business which are 
 sent to or received by this account are subject to the NC Public Records Law 
 and may be disclosed to third parties.”
 
 

Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/
All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

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

Re: [GRASS-dev] GRASS 7: r.shaded.relief changed name?

[Helena Mitasova]

I agree with Carlos on this , I think r.shaded.relief was pretty clear what
it was doing. As I learned recently, r.relief indeed can be confused with
any of the numerous relief metrics.

Helena

On Wednesday, April 22, 2015, Vaclav Petras wenzesl...@gmail.com wrote:

 Hi Carlos,

 On Wed, Apr 22, 2015 at 8:44 AM, Carlos Grohmann 
 carlos.grohm...@gmail.com
 javascript:_e(%7B%7D,'cvml','carlos.grohm...@gmail.com'); wrote:
 
  Hi
 
  I just installed the latest pkg for GRASS 7 on OSX (nice splash screen
 BTW)
  and r.shaded.relief is now just r.relief
 
  Is it too much if ask why this change? To me, r.shaded.relief is so much
 better, it describes the module.

 I did the rename after discussion with Michael Barton and Markus Neteler.
 We've tried to consider different names for several modules and picked the
 ones which seemed less confusing. See the discussion:

 http://lists.osgeo.org/pipermail/grass-dev/2014-November/071904.html

 http://osgeo-org.1560.x6.nabble.com/Re-GRASS-SVN-r62845-in-grass-trunk-scripts-d-shadedmap-r-shadedmap-td5174184.html

 
  r.relief might be confusing (is it to calculate some rellief-related
 parameter?

 I'm afraid that in case of these modules, basically anything can be
 confusing. Let us know what do you think after reading the discussion, so
 we have some more feedback.

  local relief? other morphometric parameter?).

 BTW, there is r.local.relief in addons.

 Vaclav

 
 
  best
 
  Carlos
 
 
 
  --
  Prof. Carlos Henrique Grohmann
  Institute of Energy and Environment - Univ. of São Paulo, Brazil
  - Digital Terrain Analysis | GIS | Remote Sensing -
 
  http://carlosgrohmann.com
  http://orcid.org/-0001-5073-5572
  
  Can’t stop the signal.
 
  ___
  grass-dev mailing list
  grass-dev@lists.osgeo.org
 javascript:_e(%7B%7D,'cvml','grass-dev@lists.osgeo.org');
  http://lists.osgeo.org/mailman/listinfo/grass-dev



-- 
Helena Mitasova
Associate Professor
Department of Marine, Earth and Atmospheric Sciences
North Carolina State University
1125 Jordan Hall
NCSU Box 8208
Raleigh, NC 27695-8208
http://www4.ncsu.edu/~hmitaso/
http://geospatial.ncsu.edu/

email: hmit...@ncsu.edu
ph: 919-513-1327 (no voicemail)
fax 919 515-7802
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-PSC] RFC 4: Release procedure

[Helena Mitasova]

I agree with the suggested modification by Moritz,

Helena

Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/
All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Mar 3, 2015, at 3:31 AM, Moritz Lennert wrote:

 On 01/03/15 19:02, Markus Neteler wrote:
 Hi,
 
 On Tue, Feb 17, 2015 at 1:54 PM, Markus Neteler nete...@osgeo.org wrote:
 On Fri, Jun 20, 2014 at 3:39 AM, Scott Mitchell smi...@me.com wrote:
 Agreed, and I like Markus’ idea of testing it on an upcoming release.
 
 (just a low priority comment here)
 
 While doing so it turns out that one week between RC2 and final is a bit 
 short.
 And some urgent fixes came in only during the RC procedure. We need to
 [add] a phrase if this requires a new RC (not this time though!) or not
 or depends.
 
 Overall, we got the release out :-)
 Any opinions on above remaining issue?
 
 I think that with time we will get better at this procedure and the one week 
 limit should be ok, but I have no objections to add a phrase to step 6 such as
 
 A final, concerted bug squashing effort by all developers of no more than 
 one week. During that same time the release announcement is drafted. If an 
 important bug is discovered for which a fix needs some more testing, an RC3 
 can exceptionally be published, with another week of testing before final 
 release.
 
 Moritz
 ___
 grass-psc mailing list
 grass-...@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-psc

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

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

[Helena Mitasova]

On Jan 21, 2015, at 2:16 PM, Moritz Lennert wrote:

 On 21/01/15 19:35, Markus Neteler wrote:
 
 On Jan 21, 2015 6:56 PM, Vaclav Petras wenzesl...@gmail.com
 mailto:wenzesl...@gmail.com wrote:
 
  On Wed, Jan 21, 2015 at 12:24 PM, Markus Neteler nete...@osgeo.org
 mailto:nete...@osgeo.org wrote:
   The project has been introduced in the past to de-confuse user
   coming from other GIS.
   Location alone is not quite clear I fear.
 
  I see the motivation but random rename of one thing at one place is
 just adding to confusion. If we need explanation, then we need something
 like explanation in some less prominent color, similarly to what is in
 GUI elsewhere (see attachment). Broad rename is out of question I guess.
 
  Project is very ambiguous, it is location, mapset or GUI workspace?
 For me project is usually mapset, sometimes in combination with GUI
 workspace and this how I explain that to people.
 
 In my opinion we should not have the location selection dialog at all.
 Revolution!
 
 We should start GRASS right away in latlong like most GIS in the world.
 
 Then let the user open the dialog to change projection if desired from
 inside.
 
 This would avoid a lot of questions right away.
 
 Please don't do this ! I find the fact that GRASS does not provide a default 
 projection system, but forces the user to think about projection from the 
 start, one of its strengths, both for work and for teaching.

Moritz - that won't be lost, I agree that it is a very important GRASS feature.

 The concept of location/mapset remains, but they will have to start thinking 
about it once they start GRASS,
not before they even open it. In my class when we go through starting GRASS 
step-by-step, the students are fine (although there is 
still the problem that some unzip apps create an extra directory when unzipping 
the files automatically which people don't notice),
but when in workshops or when on their own I have seen users struggling to get 
GRASS even open because they give it wrong path
(e.g., to the location rather than gis directory) or they don't know what to 
select and whether to create a new location or new mapset.
I am not sure how well the approach of selecting the location from within GRASS 
will work, but I am willing to give it a try.
I have just written the chapter on creating new locations and reprojecting data 
in GRASS for the 4th edition of grassbook so I will have to rewrite it,
but this also made me aware of how cumbersome the startup page may be for new 
users. 

On the other hand I just discovered how easy and elegant is to start GRASS from 
command line and skip the startup screen altogether.

I am not pushing strongly for this change - we can try this first in our lab on 
real-world projects with newcomers and experienced users
and see whether it would help or whether it would cause even more confusion,

Helena


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

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

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

[Helena Mitasova]

On Jan 21, 2015, at 1:35 PM, Markus Neteler wrote:

 
 On Jan 21, 2015 6:56 PM, Vaclav Petras wenzesl...@gmail.com wrote:
 
  On Wed, Jan 21, 2015 at 12:24 PM, Markus Neteler nete...@osgeo.org wrote:
   The project has been introduced in the past to de-confuse user
   coming from other GIS.
   Location alone is not quite clear I fear.
 
  I see the motivation but random rename of one thing at one place is just 
  adding to confusion. If we need explanation, then we need something like 
  explanation in some less prominent color, similarly to what is in GUI 
  elsewhere (see attachment). Broad rename is out of question I guess.
 
  Project is very ambiguous, it is location, mapset or GUI workspace? For me 
  project is usually mapset, sometimes in combination with GUI workspace and 
  this how I explain that to people.
 
 In my opinion we should not have the location selection dialog at all. 
 Revolution!
 
 We should start GRASS right away in latlong like most GIS in the world.
 
 Then let the user open the dialog to change projection if desired from inside.
 
 This would avoid a lot of questions right away.

I agree, Helena

 
 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] New splash screen for GRASS GIS 7?

[Helena Mitasova]

On Jan 21, 2015, at 12:03 PM, Vaclav Petras wrote:

 
 On Wed, Jan 21, 2015 at 9:28 AM, Markus Neteler nete...@osgeo.org wrote:
 On Wed, Jan 21, 2015 at 11:37 AM, Vincent Bain b...@toraval.fr wrote:
  Just for fun, I made a couple of tests there:
  http://www.lesfavrets.fr/telec/grass_splash.tar.gz
 
 Please, have a look at my suggestion in the attachment for welcome/startup 
 screen/window. It contains a graphics but it has small height. Title and 
 whole upper part is changed. Note that it is actually done in code, so it is 
 pretty precise, except for the graphics which was done just quickly. The gray 
 in the background of the image is the one of the window done using 
 transparency so it should always match with the window. Unfortunately, this 
 will fail miserably when somebody has dark window background color or green 
 one (text or logo will be invisible).
 
 I would also like to change some terms used in the startup window. Namely, 
 avoid using ambiguous word project. If it is not clear, use GRASS 
 location, otherwise just location. Same for mapset. We should also let the 
 translators know that location and mapset should not be translated, or 
 translated very carefully. Perhaps also, Start GRASS should be replaced by 
 Start GRASS session which is something we avoid in documentation but it is 
 quite crucial to understand how it works.

as Markus mentioned location and mapset by themselves don't work - users have 
no idea what it means or think that location is name of the place
which they want to study, that is why the additional text was added there. 
It helped a little but it is my observation from the workshop and classes that 
people get lost when defining their GIS data directory - they tend to put there 
the path to the location and then there is nothing to chose for location and 
mapset and they are done with GRASS.
And this happens even after you explain what GIS data directory means. 
I don't have a good solution - it is a long standing issue, but going back to 
just location and mapset won't help,

Helena
 
 I like the splash with grass in the background. Hopefully, there is enough CC 
 BY images out there.
 grass_startup.png___
 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] New splash screen for GRASS GIS 7?

[Helena Mitasova]

On Jan 21, 2015, at 1:13 PM, Vaclav Petras wrote:

 
 On Wed, Jan 21, 2015 at 1:04 PM, Helena Mitasova hmit...@ncsu.edu wrote:
 I don't have a good solution - it is a long standing issue, but going back to 
 just location and mapset won't help,
 
 I'm suggesting to use location and mapset or GRASS location and GRASS 
 mapset and explanation (but not only in manual, it should be in the window 
 directly). I'm against introducing new synonyms or alternative names such as 
 project or directory of GIS files. If the current situation is really 
 bad, we should rename it and not use random alternatives here and there.

Vasek, it was worse when there was just location and mapset.

Helena

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

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

[Helena Mitasova]

I like this one - I think it well represents what GRASS is.  (perhaps GRASS 
GIS?)

 GRASS. Bringing advanced geospatial technologies to the world.

Helena

Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/
All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Jan 19, 2015, at 11:32 AM, Michael Barton wrote:

 Cool idea.
 
 Since GRASS is a global project, how about one of the first truly global like 
 Mercator's of 1569 
 (https://en.m.wikipedia.org/wiki/History_of_cartography#/image/File:Mercator_1569.png)
  or Ortelius' of 1570 
 (https://en.m.wikipedia.org/wiki/History_of_cartography#/image/File:OrteliusWorldMap1570.jpg)?
 
 Better images than these from Wikipedia probably exist.
 
 With such a map, we could have a slightly different message on the splash 
 screen too. Maybe something like
 
 
 
 OR
 
 GRASS. Advanced geospatial technology for everyone.
 
 Anyway. Those are a couple of ideas.
 
 Michael
 
 
 On Jan 17, 2015, at 3:58 AM, Yann Chemin yche...@gmail.com wrote:
 
 I for one, will welcome our new @!SPLASH!@ ...
 
 Yes +1
 
 any wiki page to submit?
 
 On 17 January 2015 at 16:21, Markus Neteler nete...@osgeo.org wrote:
 Hi,
 
 I'd suggest, in order to clearly distinguish G6 from G7, to replace
 the current splash screen for the upcoming G7.0.0 release.
 We may consider to get community contributions for this.
 
 What do you think?
 
 Markus
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev
 
 
 
 -- 
 
 
 
 
 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
 
 voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
 fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
 www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 ___
 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] Planning GRASS GIS 7.0.0RC1

[Helena Mitasova]

On Jan 19, 2015, at 1:13 PM, Vaclav Petras wrote:

 On Mon, Jan 19, 2015 at 12:08 PM, Markus Neteler nete...@osgeo.org wrote:
 On Mon, Jan 19, 2015 at 5:46 PM, Vaclav Petras wenzesl...@gmail.com wrote:
  On Sun, Jan 18, 2015 at 5:49 PM, Markus Neteler nete...@osgeo.org wrote:
   If I turn the tests into a test suite script, I will use a vector from
   the the full version of the North Carolina sample dataset. Is this ok?
  
   This is ok. MarkusN says we should use the new dataset but I think it is
   not
   yet stable.
 
  I would invite everybody to switch to these simplified names:
  http://trac.osgeo.org/grass/wiki/SampleDataset
 
  At page bottom download the dataset (done by Helena).
 
 
  Is it stable enough?
 
 What is stable? The names, the size of the package or the selection of maps?

There is one thing about this data set that I would like to change - the name 
of the location itself.
Given that distribution of data by mapsets does not work well, all data sets 
should be distributed as locations
(or external data) and then we won't need the loc part in the name.
So I suggest to use the name

ncspm_baseline_v1.0
or
ncarolina_baseline_v1.0

instead of loc_ncspm_baseline

and we should have a single place where this data set is stored (on grass 
website under data?)
to avoid creating multiple versions of the data set. I will remove mine and 
replace it by a link.

Then the italian version of this data set would be 

piemonte_baseline

 
 Naming, selection and placement into mapsets.
  
  Anyway, first we have to solve the challenge of having
  the maps in different mapsets. How do you get them in examples and tests?
  Use name of mapset? Or expect everything to be on path?
 
 Probably a simple g.mapsets call would be enough to get it in.
 
 Switching of mapset is not applicable in tests (tests are isolated using 
 GRASS means, i.e. processes and mapsets) but yes, changing path is the way. 
 Do you think we should add it to each example which needs it? For tests it 
 would be quite easy to do something like set up the search path automatically 
 according to existing mapsets or search path set in PERMANENT but it is 
 desired? I don't have a strong opinion, explicit g.mapsets calls sounds as a 
 safe way to go but putting @mapsetname everywhere would also work, am I right?

I suggest to distribute all mapsets with at least the baseline data set in 
PERMANENT. Then you would have to deal with data in different 
mapsets (and in fact in different locations) only for the examples where you 
need to combine data from two or more different
specialized mapsets - for example lidar and networks.
 
  Once we decide to switch (for example in 7.1/trunk) we should do it
  officially, so we avoid the unclear situation caused by full NC and basic NC
  where the locations were incompatible and it was not defined which one to
  use.
 
 I haven't used NC basic at all but would be happy to replace (all) my
 examples from full NC with the simplified names.
 
 It's completely the same for me.

I agree - we should retire all other small data sets and mark them as retired, 
although I expect that nc_spm_08 and nc_spm_08_grass7 will be still used for a 
while.
I will post the relevant notes on my website and in our courses as well. 
  
  Which data you use when running the tests on you computer is your choice, so
  you can experiment with any dataset and develop your tests with the dataset
  which will be used in the future.
 
 Yes but the point is that we need to switch to the simplified names as
 suggested by Helena (maybe with your collaboration in your lab):
 http://trac.osgeo.org/grass/wiki/SampleDataset
 
 At this point I could update the Piemonte location (also on the Web
 site) accordingly.
 
 Replacing the old one by a new one on my server should be quite simple 
 because it is already there. Same if we decide to just use new NC instead of 
 currently used full NC. Adding new location is what is very unpleasant to do 
 now.

I agree.
  
  I might be able to improve location handling in tests next month, or at
  least add the new NC and basic NC locations to my test server to accommodate
  the different tests (before the situation will stabilize).
 
 I am not sure what we are waiting for.
 
 If it is stable enough for trunk (i.e. it is worth to modify examples and 
 tests) and it is clear how to access the maps in other mapsets then we just 
 have to announce the official switch. Will this be the default dataset for 
 7.1 then?

GRASS7.1 would be a good target. I am also working on a new external data set 
and on locations in other coordinate systems with some limited but hopefully 
meaningful
map layers in them.

Helena
 
 Vaclav
 
 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

Re: [GRASS-dev] [GRASS-PSC] RFC4 discussion call

[Helena Mitasova]

On Jan 7, 2015, at 4:20 PM, Markus Neteler wrote:

 On Wed, Jan 7, 2015 at 9:26 AM, Massimiliano Cannata
 massimiliano.cann...@supsi.ch wrote:
 Dear all, I went trough the document and it make perfectly sense to me.
 
 I agree. I updated its date now and expanded RC in the beginning.
 
 http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure
 
 Last doubts:
 
 * Step1:  The Project manager (or if exists the Release manager)
 then collects reactions to decide whether there is sufficient support
 for this proposal. 
 
 -- this sufficient is still a bit elastic. If one developer is
 against it, others in favour, it is fine to start? Leave it to
 democratical debates? Just to be sure.

I changed to decide to and decides so it is more clear that it is at the 
discretion of the Project/Release manager to decide whether there is sufficient 
support.
If Project manager cannot decide by himself (e.g. he/she is not sure), he/she 
can always call for a vote by PSC.
 
 Just a minor comment is that we shall probably clearly specify who is
 responsible for the mentioned actions: call for soft, hard freeze etc.
 
 That's the release manager. But I added that now (looks more dramatic
 than it is, trac doesn't highlight well this time).:
 
 http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure?action=diffversion=16old_version=13
 
 ... makes sense?

I made small language edits which did not change the meaning of the document 
and I agree with the document.

Helena
 
 Markus
 ___
 grass-psc mailing list
 grass-...@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-psc

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

Re: [GRASS-dev] r.slope.aspect: one pixel less in the output at the border shrinks region extent in further calculations

[Helena Mitasova]

Helmut,

you can use r.resamp.rst which computes slope and aspect and does not shrink 
the region. But you may need to adjust the parameters
to make sure it works well.

Another way would be to modify r.slope.aspect to compute the values at the 
edges - a second order polynomial min.square approximation
is used to estimate the derivatives in r.slope.aspect (you get the well known 
differencing function when you do the math) and it can be used
also to compute the values at the edge cells, but I had no luck convincing 
others that it is the right thing to do.
I believe that any reasonable estimate is better than the current shrinking 
region (in r.flow we just propagate the same values to the edges),
but that does not seem to be the consensus. 
Also, implementation  for the edges is not straightforward because of how
GRASS works with rows, but a smart developer could certainly do it (you can 
compute the edge values e.g.in r.mapcalc).

I hope this clarifies it and may be helps a little bit. I am quite interested 
in the flat valley bottoms - here in NC they are often
found as bottoms of abandoned, dried out mill ponds.

Helena






Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/
All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Jan 4, 2015, at 7:54 AM, Helmut Kudrnovsky wrote:

 Hi Pietro,
 
 this is not a bug. 
 
 I unterstand the same. my question is more about how to implemented the
 mentioned iterative algorithm which uses coarser resolution by each step and
 how to avoid an extent shrinking of e.g. about 400m with the coarsest
 resolution.
 
 
 
 -
 best regards
 Helmut
 --
 View this message in context: 
 http://osgeo-org.1560.x6.nabble.com/r-slope-aspect-one-pixel-less-in-the-output-at-the-border-shrinks-region-extent-in-further-calculatis-tp5179874p5179923.html
 Sent from the Grass - Dev mailing list archive at Nabble.com.
 ___
 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] anyone compiled GRASS 7 on Mac Yosemite?

[Helena Mitasova]

Michael,

Anna compiled it for me.

Below is the configure and some notes. We had to run make for wxGUI from within 
GRASS and the vector attribute tables do not work
for me at the moment due to sqlite problems - we ran out of time to solve it.
We also used wxPython carbon 3 to see what kind of problems it would have - so 
some of the GUI panels are cut off so use 2.8

But otherwise it works great so it is worth doing - if you could provide GRASS7 
binaries for yosemite that would be fantastic,
Anna is away but I have the machine with me so I can help or at least test.

Thanks for looking into it,

Helena

here are our notes:

./configure \
--with-proj \
--with-x \
--with-proj-includes=/Library/Frameworks/PROJ.framework/unix/include \
--with-proj-libs=/Library/Frameworks/PROJ.framework/unix/lib \
--with-proj-share=/Library/Frameworks/PROJ.framework/Resources/proj \
--with-gdal=/Library/Frameworks/GDAL.Framework/Programs/gdal-config \
--with-tiff-includes=/Library/Frameworks/UnixImageIO.framework/unix/include \
--with-tiff-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib \
--with-png-includes=/Library/Frameworks/UnixImageIO.framework/unix/include \
--with-png-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib \
--with-opengl=aqua \
--without-fftw \
--with-cairo 
--with-cairo-includes=/Library/Frameworks/cairo.framework/unix/include/cairo \
--with-cairo-libs=/Library/Frameworks/cairo.framework/unix/lib \
--with-cairo-ldflags=-lcairo \
--with-freetype \
--with-freetype-includes=/Library/Frameworks/FreeType.framework/unix/include/freetype2
 /Library/Frameworks/FreeType.framework/unix/include/ /opt/X11/include/ \
--with-freetype-libs=/Library/Frameworks/FreeType.framework/unix/lib \
--with-geos=/Library/Frameworks/GEOS.framework/Versions/3/unix/bin/geos-config \
--with-sqlite \
--with-sqlite-libs=/Library/Frameworks/SQLite3.framework/unix/lib \
--with-sqlite-includes=/Library/Frameworks/SQLite3.framework/unix/include \
--with-macosx-archs=i386 x86_64

# run before compilation: export VERSIONER_PYTHON_PREFER_32_BIT=yes

PATH=/Library/Frameworks/PROJ.framework/Versions/4/Programs:$PATH
export PATH

wxPython carbon 3 has issues - use 2.8
Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/
All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Dec 30, 2014, at 2:51 PM, Michael Barton wrote:

 Has anyone yet tried to compile GRASS 7 on Mac Yosemite (AKA OS X 10.10)? 
 
 I will update soon and try it. It would be nice to know if it compiles 
 without any issues.
 
 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
 
 voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
 fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
 www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 ___
 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-PSC] RFC4 discussion call

[Helena Mitasova]

I agree with Maris that no feedback should be interpreted as agreement. 
A statement : if there are no further comments or feedback for the 7 days, RC1 
will be released on XXX date
may help in case somebody has some issues and was just delaying posting them.

Also for the PSC, it appears that the release procedure is ready to be voted on?
http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure

Helena



On Dec 29, 2014, at 3:11 AM, Maris Nartiss wrote:

 IMHO lack of answer in a transparent procedure with reasonable
 response windows just means carry on, everyone agrees. Having a
 fixed last date for comments might force someone to say something (or
 used as an argument for STFU later).
 
 
 Just my 0.02,
 Māris.
 
 
 2014-12-29 9:50 GMT+02:00 Markus Neteler nete...@osgeo.org:
 On Mon, Nov 24, 2014 at 2:50 PM, Moritz Lennert
 mlenn...@club.worldonline.be wrote:
 On 24/11/14 14:38, Martin Landa wrote:
 
 Dear all,
 
 as we are closer and closer to GRASS 7 release I would like to open
 discussion related to Release procedure - RFC4 [1]. Ideally (I would
 say) it would make sense to find a way how accept such procedure
 before we start with GRASS RCs...
 
 Thanks for your feedback in advance! Martin
 
 [1] http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure
 
 
 Rereading it I found parts that didn't seem clear, so I reordered the
 sentences slightly to make the meaning clearer.
 
 While this is all nice, I am strongly lacking support in the day to
 day release management.
 Again the RC1 feedback is actually 0 (zero).
 
 The General Procedure in the document is lacking answers to what to
 do if no or no reasonable feedback occurs.
 Any ideas? We are in soft freeze for months.
 
 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

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

Re: [GRASS-dev] sample vector temporal data

[Helena Mitasova]

On Nov 26, 2014, at 2:22 PM, Anna Petrášová wrote:
 On Wed, Nov 26, 2014 at 12:10 PM, Luca Delucchi lucadel...@gmail.com wrote:
 On 8 October 2014 at 03:21, Anna Petrášová kratocha...@gmail.com wrote:
 
  as you know we need to decide which data are we going to use for t.vect.*
  examples. One possibility is to use oceanfront shorelines of North Carolina,
  we can get this data easily from here:
 
  http://portal.ncdenr.org/web/cm/download-spatial-data-maps-oceanfront
 
  It includes these years, interval data in case of older data, and instance
  data from the past years:
  1849 - 1873, 1925 - 1946, 1933 - 1952, 1940 - 1962, 1970 - 1988, 1997, 1998,
  2003, 2004, 2009
 
  The advantage is that the data is public and basically ready to use. If we
  decide to use it, should we include the entire NC shoreline or just some
  detail (look at the attachment)?
 
  In addition, we can also create a vector time-series where the geometry is
  not changing, just the attribute changes (derived from the climate data for
  example).
 
  Any thoughts on this?
 
 
 After some weeks without any comments I think we could proceed to
 create the dataset.
 
  By the way, the climate dataset seems to be fine, we got the confirmation we
  can use it, it is not subject to the PRISM licence since it was interpolated
  at NC State Climate Office.
 
 
 I would like to work on it and on temporal documentation in the next
 two days, so what do you think about this plan starting from the
 sample data for the temporal workshop [0]?
 - remove some years from climate_2000_2012 data, for example keep no
 more that 5 years, because right know the location is a little bit
 heavy (about 700MB) and for documentation 5 years should be fine.
 
 I agree.
  
 - create vector for static temporal dataset from towns querying the
 rasters in climate_2000_2012 to create something like virtual weather
 stations
 
 yes, but there are no NC towns as points in the standard dataset. You could 
 use  precip_30ynormals@PERMANENT which are the meteorology stations, which 
 probably doesn't make much sense since but maybe it's still good for the 
 dataset. 

Anna is right - in fact these are the stations which were used to create the 
rasterized climate time series so there is no need to create 
virtual weather stations - we already have the real ones. We can get more 
complete data for these stations if needed 
- all have at least temperature and precipitation on daily basis going back 
several decades. 
 
 - add the shoreline ocean data, maybe in a new mapset
 
 Helena suggests here to select a smaller, dynamic area (some cape for 
 example) and also provide a DEM and ortho for that area (elev_lid792 is not 
 coastal) to get some context. I am not sure about this dataset, if it's 
 really needed, because I don't know what kind of temporal vector analysis we 
 could show in the manual. It could be a good dataset to show how to create 
 animations. If we decide to do it, I can help you with this part.
 
 Another option is to derive contours from the temperature/precipitation 
 dataset. The advantage is that's easier to prepare.
 
 - create at least one temporal dataset for each type (strds, str3ds, stvds)
 
 Do we have any temporal data for 3d raster? I don't think we necessarily have 
 to create this dataset.

we can ask our colleagues for some 3D atmospheric data or the ocean temperature 
or salinity data,
but it would take us some time to get to this. We also have some good 
interpolated 3D/4D soil data but they are not public
at this point.

Helena

 
 Anna 
 
 - update the temporal documentation according the new dataset.
 
 what do you think?
 
 Helena in her answer was speaking about orthophoto and DEM for the
 shoreline ocean data, are this data already inside the location
 (elev_lid792_1m,elev_state_500m,ortho_t792_1m) ?
 
  Anna
 
 
 [0] http://fatra.cnr.ncsu.edu/temporal-grass-workshop/
 
 --
 ciao
 Luca
 
 http://gis.cri.fmach.it/delucchi/
 www.lucadelu.org
 
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev

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

Re: [GRASS-dev] What should d.erase do in the main wxGUI?

[Helena Mitasova]

Vasek,

the main reason we have d.erase in the assignments and in the book is for 
zooming to computational region,
including changing the resolution 

# for d.erase: Zoom to computational region and switch off previous map layers 

the manual page does not say it, probably because it was implied.
If possible it may be useful to have the zoom to region as a flag?
d.erase would just switch off the layers (I am not sure it should remove them - 
let us see what others say)
d.erase -r would remove the layers and zoom the display to computational region.

This would be extremely helpful in the assignments when switching to 3D view

Helena


Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/
All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Oct 16, 2014, at 11:43 PM, Vaclav Petras wrote:

 Hi,
 
 in GRASS 7, the d.erase command is not supported in the main GUI.
 
 For `d.mon wx0` d.erase removes all rasters and shows the backgroud. d.erase 
 bgcolor is ignored.
 
 For `d.mon png` d.erase uses bgcolor as expected.
 
 For the main GUI, the question is if the Layers in Layer Manager should be 
 removed or just unchecked. I'm for removing them.
 
 The second question is if the background should be changed. The same applies 
 to `d.mon wx0`. The settings of background color in GUI is done differently 
 but perhaps d.erase can change the color temporary (I'm not sure how hard 
 this would be to implement).
 
 Is there something else what d.erase is doing? I got the impression that it 
 zooms to computational region but manual page is silent about it.
 
 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] sample vector temporal data

[Helena Mitasova]

Anna,

to put these data into context, the dataset should include also at least one 
ortho (probably for 2009) and perhaps 
also a lidar-based DEM for 2009.
I think that the detail will work better - maybe you can show it on orthophoto 
or a DEM to make it easier to understand what
the lines mean.

To derive vector time series from the climate data where the geometry is 
changing just derive isolines for temperature 
or precipitation from the existing rasters. If the isolines are noisy we can 
smooth them out using v.generalize or reinterpolate some data.
This may be a simpler solution because it will use the same data set. 

But the shoreline may be more interesting.

Helena


Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/
All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Oct 7, 2014, at 9:21 PM, Anna Petrášová wrote:

 Hi,
 
 as you know we need to decide which data are we going to use for t.vect.* 
 examples. One possibility is to use oceanfront shorelines of North Carolina, 
 we can get this data easily from here:
 
 http://portal.ncdenr.org/web/cm/download-spatial-data-maps-oceanfront
 
 It includes these years, interval data in case of older data, and instance 
 data from the past years:
 1849 - 1873, 1925 - 1946, 1933 - 1952, 1940 - 1962, 1970 - 1988, 1997, 1998, 
 2003, 2004, 2009
 
 The advantage is that the data is public and basically ready to use. If we 
 decide to use it, should we include the entire NC shoreline or just some 
 detail (look at the attachment)? 
 
 In addition, we can also create a vector time-series where the geometry is 
 not changing, just the attribute changes (derived from the climate data for 
 example).
 
 Any thoughts on this?
 
 By the way, the climate dataset seems to be fine, we got the confirmation we 
 can use it, it is not subject to the PRISM licence since it was interpolated 
 at NC State Climate Office.
 
 Anna
 
 all.jpgdetail.jpg___
 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] G7 blockers call

[Helena Mitasova]

Martin,

our semester has just started and we have students downloading and installing 
GRASS7.0.0RC3.
So far I had two students reporting the problem with MSVCR.71.dll missing - I 
have added the link to the 
WinGRASS_errors wiki to the course webpage so I hope that will help.
I have a visiting student who had to go through the steps listed there to get 
GRASS7 working, but it seemed to work fine after that. 
We also have it running on several machines in the lab, but I suggest to wait 
few days to see whether 
any serious problems are reported by students (in addition to the WinGRASS 
installer issue which we cannot do anything
about as far as I understand it).

Helena


Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/
All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Aug 22, 2014, at 8:53 AM, Martin Landa wrote:

 Hi all,
 
 we are slowly moving towards GRASS 7 release. Recently 3rd beta has
 been released. It's importnant to know what is still missing before we
 start RC stage. So please report ASAP issues which you feel that they
 need to be solved before GRASS 7 will be released (especially API
 changes, renaming modules, parameters, everything which is impossible
 to change later because of backward compatibility).
 
 Please report this issues as 'blockers'. Other notes can be collected
 on trac wiki page [1].
 
 Thanks for collaboration! Martin
 
 [1] http://trac.osgeo.org/grass/wiki/Grass7Planning
 
 -- 
 Martin Landa * http://geo.fsv.cvut.cz/gwiki/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

[GRASS-dev] updates needed on wingrass webpage?

[Helena Mitasova]

As I am going through the class instructions I am wondering whether the text 
on the page from which the students download WinGRASS needs updates:
http://grass.osgeo.org/grass70/binary/mswindows/native/

specifically - do we still consider WinGRASS an experimental project? We have 
been using it in courses for couple years now.
Also, is the binary still built on Windows Vista as indicated in the text?

There is also a link to 
http://grasswiki.osgeo.org/wiki/WinGRASS_Current_Status
which mostly includes references to 6.4, so this may be confusing to users 
installing GRASS7.
If this wiki page is not maintained perhaps the link should be removed.

Finally, the LOCATION that is provided with WinGRASS is called NORTH_CAROLINA
which is different from nc_spm_08 for GRASS6 and nc_spm_08_grass7 for GRASS7.
This is not a huge issue but users who may already have NORTH_CAROLINA from 
previous installs 
and skip downloading it for WinGRASS7 may be surprised that the vector data 
don't work.
Should the name of this location be changed (preferably to nc_spm_08_grass7) to 
indicate
that this is a different data set in terms of vector data format?

Thank you, Helena  

Helena Mitasova
Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/
All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 ___
 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

[GRASS-dev] update GRASS 6.4.3 to GRASS 6.4.4. on downloads?

[Helena Mitasova]

as I am preparing instructions for the new semester I noticed that the download 
page refers to 6.4.3 stable
but the actual release is 6.4.4 which may be confusing to some users 
http://grass.osgeo.org/download/software/
Should it be just GRASS 6.4 to make it consistent with GRASS7.0 and the binary 
would have the latest 
release number?

Thank you, Helena

Helena Mitasova
Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu
OSGeoREL
http://marinesci.ncsu.edu/
All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Aug 11, 2014, at 6:30 PM, Michael Barton wrote:

 I just posted binaries for GRASS 7.0 beta 3, along with new binaries for 
 GRASS 7.1 dev and GRASS 6.4.4 svn. These use the most current frameworks from 
 William Kyngesburye’s site (also posted on the GRASS for Mac site). 
 
 They can be downloaded at: http://grassmac.wikidot.com/downloads
 
 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
 
 voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
 fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
 www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 ___
 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-PSC] too many branches = retirement GRASS6.5.svn (=develbranch6)

[Helena Mitasova]

I believe that we have a communication problem here rather than a disagreement 
about the GRASS6.5:

Hamish says:
GRASS 6.x is already far along into bugfix maintenance mode.
*Please, just leave it to naturally and quietly make its way into history.*
 I wish to use the bulk of my grass dev time maintaining the grass 6 line. 
To do that properly I need a staging area, and devbr6 is it. 

which is pretty much in agreement with Martin's:
I think we should really stop thinking about GRASS 6 development,
So please bug fix only should go there (relbr64). No new functionality.

So I think that we have a broad agreement on maintenance only mode for grass6 
line,
and if there is a concern that new features will be added to grass6.5, perhaps 
we can keep it
in read-only mode as suggested in one of the initial emails in this discussion 
and have
only Hamish keep write access for testing (staging area).

I think that if Hamish can maintain GRASS6 line this will free the time for all 
other developers to focus on GRASS7.
Regarding GRASS7 - it is in a pretty good shape, we have been using it in 
classes since the fall semester
and I was quite surprised how little changes are needed to update the full 
semester course material for GRASS7.

Helena



Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Apr 6, 2014, at 4:45 PM, Markus Metz wrote:

 On Sun, Apr 6, 2014 at 3:16 PM, Moritz Lennert
 mlenn...@club.worldonline.be wrote:
 On 06/04/14 13:46, Hamish wrote:
 
 
 As mentioned before, I wish to use the bulk of my grass dev time
 maintaining the grass 6 line. To do that properly I need a staging
 area, and devbr6 is it.
 
 I don't see the need for a devbr6 because maintaining the GRASS 6 line
 means backporting bug fixes from trunk. New functionality should be
 implemented in trunk, as in any other project. Bug fixes are then
 backported to the release branch, unfortunately we have now two
 release branches. Apart from addons, there will most probably not be
 any more GRASS 6 development, only GRASS 6 bug fixing, for which a
 GRASS 6 release branch is IMHO sufficient.
 
 I don't think it makes sense to maintain two GRASS major versions if
 development aka adding new functionality should take place in both.
 Some contributors like to implement new functionality in devbr6, but
 most contributors follow the (IMHO logical) way of trunk - relbr. The
 now proposed development way of trunk - relbr_7 - devbr6 - relbr6
 or or also devbr6 - relbr6, skipping trunk, is unrealistic, will slow
 down GRASS development, and might lead to diverging branches.
 
 If GRASS 6, and release branch maintenance in general, is restricted
 to bug fixing, it should be easy to maintain trunk and two release
 branches. Granted that trunk is not abused as addon repository by
 adding untested code.
 
 My 2c,
 
 Markus M
 
 
 Hosting a clone on github for that is too
 ridiculous and broken a situation to begin to contemplate.
 
 If devbr6 is removed I simply can not do the stable grass 6
 maintenance job properly. So without that there is really very little
 for me to contribute in future. It will not translate to me spending
 more time working on grass 7, only drive me away from the project.
 
 
 I think that seen Hamish' continued effort for this project this a serious
 enough situation to demand a solution.
 
 But maybe the idea to actually release a first version of grass7 in a not to
 far future is a way out.
 
 Hamish, maybe you could be the official grass6 maintainer, managing the
 whole grass6 development in the way you propose, i.e. any new development
 and bugfixes first go into grass6dev for a period of testing, before _you_
 make the decision that something can be backported to grass6release. I do
 think however, that for this to work, we would need to regularly publish
 snapshots of grass6dev for easy testing.
 
 All other devs only commit to grass6dev, never to grass6release.
 
 Just my 2¢,
 
 Moritz
 
 ___
 grass-psc mailing list
 grass-...@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-psc
 ___
 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] change linear back to bilinear in grass7 ?

[Helena Mitasova]

Martin I read the discussion post (I should have mentioned it, I did not 
realize that the change has been made until now) 

to all - please read the wikipedia entry linked in my post (read the whole 
thing, not just the first paragraph), 

Contrary to what the name suggests, the bilinear interpolant is not linear; 
nor is it the product of two linear functions.
Alternatively, the interpolant can be written as
inline: 539ce24cab74f38d7c3bc3f59ab0c916.png

so the equation is not linear, the function is a hyperbolic surface

and even if you go with linear, then the examples in all manual pages should be 
updated -
currently it is a mess which could have been avoided just by keeping he 
original names of the parameters.

Helena

I have not checked the code for the bicubic option, but based on the manual 
entries referring to cubic convolution
(see again the wikipedia entry for bicubic interpolation) I am guessing it is 
bicubic. I will look at it - but the easiest 
is to look at the implementation and compare with the equation in wikipedia. 



Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Jan 27, 2014, at 5:29 AM, Hamish wrote:

 Helena wrote:
 As we are going through the class material I have noticed 
 that in GRASS7  in r.resample.interp method bilinear was
 changed to linear and bicubic was changed to cubic.
 
 Martin:
 for the record, there was a discussion about that a while
 ago [1]. So probably we will to open this discussion again.
 ...
 [1] http://lists.osgeo.org/pipermail/grass-dev/2013-May/063855.html
 
 
 Hi all and happy new year.
 
 for my 2c wrt interpolations I seem to come across bilinear in the 
 world-beyond grass more commonly, and to me it makes more sense.
 Is the bicubic truly considering x and y separately? i.e. is it actually 
 correct to use the bi- prefix with it? If it's more of a buffer operation, 
 cubic might be better.
 
 but whatever is chosen, consistency in use is good to help with the learning 
 curves. I wouldn't object to bilinear + cubic though if each was considered 
 best in its class.
 
 
 regards,
 Hamish
 

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

[GRASS-dev] change linear back to bilinear in grass7 ?

[Helena Mitasova]

As we are going through the class material I have noticed that in GRASS7
in r.resample.interp method bilinear was changed to linear and bicubic was 
changed to cubic.

I would like to ask whether it would be OK to change it back for two reasons:
- consistency with 6.4 (minimizes changes required in tutorials, scripts, 
assignments etc.)
- bilinear interpolation is not linear, (see the relevant text in wikipedia  
you need to scroll down to find the relevant section)

Also, the change to linear and cubic has created additional inconsistencies in 
manual pages of
r.resamp.bspline
v.sample
v.drape
which have bicubic or bilinear in the examples and the text, but cubic and 
linear in the command SYNOPSIS parameters.

Helena


Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

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

Re: [GRASS-dev] Handling of Python scripts on MS Windows

[Helena Mitasova]

Just a note, given that most of these problems were caused by conflicts with 
python installed by ArcGIS,
I checked with our GIS support and the latest ArcGIS 10.2 installs python2.7 
which (I guess) should work with GRASS.


On Jan 24, 2014, at 3:03 PM, Glynn Clements wrote:

 
 Markus Metz wrote:
 
 Where it gets problematic is if the user already has a Python
 installation but it's not suitable for whatever reason. In the worst
 case they may be faced with a choice between using GRASS or using
 whatever the existing Python was installed for.
 
 IMHO keeping in mind that many GIS-interested winGRASS-users may already
 have been installed other (GIS-)software including a system-wide python
 installation, that will be the demanding challenge to provide a suitable
 solution ...
 
 How many users will have versions which are:
 
 a) too old for GRASS to use, and
 b) required to be that old by the existing package?
 
 Bear in mind that GRASS won't be the only package affected by an
 outdated system-wide Python installation.
 
 AFAIK, the primary case where another package requires a system-wide
 Python installation is ArcGIS, no? IIRC, ArcGIS requires Python 2.6;
 is there some fundamental reason why this isn't suitable for GRASS? If
 so, does ArcGIS require that exact version, or can it use a later
 version?

yes, given that most of these problems were caused by conflicts with python 
installed by ArcGIS,
I checked with our GIS support and the latest ArcGIS 10.2 installs python2.7 
which should work with GRASS
(correct me if I am wrong).
We had similar situation with ArcGIS9* and GRASS6.3 where you had to use a 
specific winpython2.5 build 212 
to have both of them working on the same machine.
The test suggested by Markus in the related message would be still useful, 
but upgrading to ArcGIS10.2 should solve the problem?

Helena



 Therefore I would suggest to keep using the embedded Python version
 which is known to work
 
 Actually, it known not to work, hence this thread.
 
 The only way you can make execution of Python scripts seamless (i.e.
 works with system(), subprocess.Popen(), etc) is for the .py extension
 to be associated with a suitable interpreter (or launcher) in the
 registry.
 
 Any other approach will trap us into an endless maintenance burden,
 identifying cases where we have to provide special handling for Python
 scripts then implementing that handling.
 
 -- 
 Glynn Clements gl...@gclements.plus.com
 ___
 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] weren't r.stream going to core? was: r.stream.* problems on Ubuntu when installed via g.extensions

[Helena Mitasova]

Maybe it just waits for somebody to put it there, we would like to see it in 
the core as well. 

Do we need for some kind of procedure to decide (e.g. through PSC action, 
verify that it has been thoroughly tested) 
and to designate a developer who moves the code from add-ons to the core?

Helena

Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Jan 19, 2014, at 2:48 PM, Markus Neteler wrote:

 On Thu, Jan 9, 2014 at 2:24 PM, Margherita Di Leo
 dileomargher...@gmail.com wrote:
 On Thu, Jan 9, 2014 at 1:25 PM, Johannes Radinger
 So for the meanwhile I can use the workaround with compiling r.stream.*
 directly with the source for G7, however maybe other users in future are
 also interested in using these add-ons and will face similar problems I did.
 
 
 sorry if OT but did I miss something? I thought r.stream* were going to
 core..?
 
 I thought the same...
 
 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] weren't r.stream going to core? was: r.stream.* problems on Ubuntu when installed via g.extensions

[Helena Mitasova]

On Jan 19, 2014, at 3:01 PM, Martin Landa wrote:

 Hi,
 
 2014/1/19 Helena Mitasova hmit...@ncsu.edu:
 Maybe it just waits for somebody to put it there, we would like to see it in 
 the core as well.
 
 it's not only question of putting it here. The modules need some
 review (code, parameters, manuals). I will be able to help with this
 procedure in some days. There will be hopefully more people
 interested. Martin

If that is the case, that is a completely different issue, I thought they are 
ready.
We can look at how much work it would be.

Then what about v.transects - it has been updated to grass7 and tested in class 
and has a manual and testing report available.
Can this module go to core? How do we make the decision for ready to go 
modules?

Helena



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

Re: [GRASS-dev] xganim: fix compilation or remove completely?

[Helena Mitasova]

Vasek,

I think that if there are no objections xganim can be removed from grass7, the 
new animation tool is much, much better.

It may be worth keeping it in grass6.4*. To test xganim just use any output 
from r.sim.water or r.sun.daily or nags head series.
If you are seeing window larger than your screen check your region settings - 
the size of the xganim window in pixels
is the size of your region (so either change the region to lower resolution or 
smaller spatial extent).

We can go through xganim in the lab (I may have it still running on the mac 
laptop) to make sure 
we have everything in the new animation tool that was in xganim, but I believe 
that we do,

Helena

Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Dec 11, 2013, at 10:38 PM, Vaclav Petras wrote:

 Hi,
 
 when testing the previous problems with C++11/clang/Mavericks, I used the 
 following compilation settings on Ubuntu 12.04:
 
   export CC=clang
   export CXX=clang++
   export CFLAGS=-ggdb -Wall -Wextra -Werror-implicit-function-declaration 
 -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls
   export CXXFLAGS=-ggdb -std=c++11
 
 I get the following errors in `visualization/xganim` directory:
 
 ./bitmaps/rewind.xbm:4:28: error: constant expression evaluates to 128 which 
 cannot be narrowed to type 'char'
0x00, 0x00, 0x00, 0x30, 0x80, 0x01, 0x28, 0x40, 0x01, 0x30, 0xa0, 0x01,
^~~~
 ./bitmaps/rewind.xbm:4:28: note: override this message by inserting an 
 explicit cast
0x00, 0x00, 0x00, 0x30, 0x80, 0x01, 0x28, 0x40, 0x01, 0x30, 0xa0, 0x01,
^~~~
stat)c_castchar(
 
 and a lot of other similar errors.
 
 I'm not getting these errors on Mavericks.
 
 I'm not able to test the xganim tool [1] right now; there is no ready-to-use 
 example and I'm not sure which environment it requires (I'm getting white 
 window bigger than my screen). However, the question is: It is worth keeping 
 the xganim tool in code or should we remove it completely?
 
 Are there any functions which xganim tool does have comparing to 
 g.gui.animation [2]? Or are there some other advantages of xganim? We should 
 avoid loosing functionality as it was with tools such as gm_animate [3]. So 
 these questions shall be answered before removing xganim.
 
 Best,
 Vaclav
 
 [1] http://grass.osgeo.org/grass70/manuals/xganim.html
 [2] http://grass.osgeo.org/grass70/manuals/g.gui.animation.html
 [3] http://grass.osgeo.org/grass64/manuals/gm_animate.html
 
 ___
 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] trying to compile GRASS 7 on Mavericks

[Helena Mitasova]

Michael,

can you please share your configure file that you are using?

thanks, Helena

Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Dec 3, 2013, at 7:12 PM, Michael Barton wrote:

 I got it to compile fine using GDAL 1.10. But the GUI still crashes on 
 startup due to problems in the xml toolbox.
 
 Michael
 __
 C. Michael Barton 
 Director, Center for Social Dynamics  Complexity
 Professor of Anthropology, 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://csdc.asu.edu, http://shesc.asu.edu
 http://www.public.asu.edu/~cmbarton
 
 On Dec 3, 2013, at 12:43 PM, Anna Petrášová kratocha...@gmail.com wrote:
 
 
 Hi all,
 
 I am still having problems to compile GRASS on Maverick, it cannot find 
 GDAL, I already reinstalled the frameworks and Xcode, too. I tried to 
 compile the simple code which seems to be compiled during configure:
 #include gdal.h
 
 int main(int argc, const char* argv[])
 {
 GDALOpen(foo, GA_ReadOnly);
 }
 
 which gives me:
 
 gis-imac:Desktop akratoc$ gcc test.c 
 
 test.c:14:5: warning: ignoring return value of function declared with 
 warn_unused_result attribute [-Wunused-result]
 
 GDALOpen(foo, GA_ReadOnly);
 
 ^~~~ ~~
 
 1 warning generated.
 
 Undefined symbols for architecture x86_64:
 
   _GDALOpen, referenced from:
 
   _main in test-sew0gz.o
 
 ld: symbol(s) not found for architecture x86_64
 
 clang: error: linker command failed with exit code 1 (use -v to see 
 invocation)
 
 I am having the same problem also on another computer. Any help appreciated.
 
 Thanks, 
 Anna
 
 
 
 
 
 On Fri, Nov 29, 2013 at 3:27 PM, Markus Neteler nete...@osgeo.org wrote:
 On Fri, Nov 29, 2013 at 9:02 PM, Michael Barton michael.bar...@asu.edu 
 wrote:
  I've been chilling out after Thanksgiving and thought I'd try compiling
  GRASS on Mavericks.
 
  I had a couple of configure issues.
 
  --with-odbc failed. Is this not included with Mavericks or do I need to
  reference it in some other way?
  --with nls also failed. I wonder if I have to update the version of gettext
  that I compiled on Lion?
 
  When I dropped these out, I got it to compile. But it errors out with the
  following:
 
  Undefined symbols for architecture x86_64:
___sincos_stret, referenced from:
 
 I found these random links:
 
 http://trac.macports.org/ticket/40961
 
 http://stackoverflow.com/questions/19015780/sincos-stret-undefined-symbol-when-linking
 
 Perhaps giving the right idea..
 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] unable to configure GRASS on Mac OSX 10.9 Maverick

[Helena Mitasova]

On Nov 4, 2013, at 11:34 AM, Michael Barton wrote:

 Thanks for this important heads up. We were hoping that compiling in OSX 10.9 
 would just work.
 
 Have you checked to see if my GRASS 6 and 7 binaries run?

Michael your GRASS6 binary runs without any trouble so far. 

Helena
 
 MIchael
 
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity 
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 
 voice:480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
 fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
 www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 
 
 
 
 
 
 
 
 On Nov 4, 2013, at 9:19 AM, Anna Petrášová kratocha...@gmail.com
  wrote:
 
 Hi devs,
 
 I tried to run GRASS 7 configure on new Mac 10.9 but it fails when trying to 
 find GDAL:
 
 configure: error: *** Unable to locate GDAL library.
 
 I tried to reinstall GDAL from Williams' binaries but it didn't help. Any 
 ideas what to check? I am using Mac OS just occasionally so I am not so 
 familiar with it. I tried to look at configure file but I don't really 
 understand what's going on there.
 
 Thanks, 
 Anna 
 
 
 

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

[GRASS-dev] v.kcv enahncement- was Re: How to calculate mean coordinates from big point datasets?

[Helena Mitasova]

Markus,

when you are at it, can you also have a look at v.kcv?
http://grass.osgeo.org/grass70/manuals/v.kcv.html

I am wondering whether it works efficiently with lidar data sets (millions of 
points) - I heard that it takes forever,
but that was about a year ago and I haven't tried it myself.
For example, if I want to partition the data set into 1% test points and 99% 
given data points (for example to test
interpolation) it appears I may need 100 partitions as there is no way to have 
just two partitions with different size. 

One of the problems may be the table - perhaps if this was run without the 
table and the output was written into 
two (or k) separate files, it could be faster? The core of the algorithm which 
is based on finding the closest 
points to the set of random points should allow this.
Creating a subset of points which are farther apart than given threshold (2d or 
3d distance) would be also useful
(it is done internally in v.surf.rst and I have a version which does it with 3D 
distances, but the resulting subset is not
written into output file).

This is not urgent but if it is not too difficult  it would be nice to have,
or let us know if it already works and I just cannot find the right module,

Helena

Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Sep 22, 2013, at 11:06 AM, Markus Metz wrote:

 Markus Neteler wrote:
 Hi,
 
 I came across this question:
 
 http://gis.stackexchange.com/questions/71734/how-to-calculate-mean-coordinates-from-big-point-datasets
 
 Please try the new addon v.centerpoint [0]. It calculates various
 center points for point clouds, lines, and areas. Standard options are
 the geometric mean (center of gravity) and geometric median (more
 robust for outliers). There are additional options to calculate center
 points for points, lines and areas, explained in the manual. The
 geometric medians (points of minimum distance to all other points) are
 approximations, but fairly accurate and very fast. I would be
 surprised if any other GIS software can calculate these center points.
 
 Markus M
 
 [0] http://grasswiki.osgeo.org/wiki/AddOns/GRASS7/vector#v.centerpoint
 ___
 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] Script directory in build GRASS session

[Helena Mitasova]

On Sep 22, 2013, at 11:04 PM, Vaclav Petras wrote:

 I added the script directory into PATH for build session, see r57814.
 
 This makes sense (bin is there too) and moreover it should fix missing 
 descriptions and keywords for modules in wxGUI menu and module tree. Note 
 that you wouldn't saw this problem if gui/wxpython is compiled in (standard) 
 GRASS session. Maybe this change will fix menudata.xml problem for Micheal's 
 compilation, but I'm afraid that it will not.

I just updated grass7 and the problem is still there for MacOSX10.6.
I assume that Michael refers to these

 Errors in:
 /Users/helena/grassdev7/grass_trunk/gui/wxpython/animation
 /Users/helena/grassdev7/grass_trunk/gui/wxpython/mapswipe
 /Users/helena/grassdev7/grass_trunk/gui/wxpython/gmodeler
 /Users/helena/grassdev7/grass_trunk/gui/wxpython/rlisetup
 /Users/helena/grassdev7/grass_trunk/gui/wxpython/psmap
 /Users/helena/grassdev7/grass_trunk/gui/wxpython/dbmgr
 /Users/helena/grassdev7/grass_trunk/gui/wxpython/vdigit
 /Users/helena/grassdev7/grass_trunk/gui/wxpython/iclass
 /Users/helena/grassdev7/grass_trunk/gui/wxpython/gcp
 /Users/helena/grassdev7/grass_trunk/gui/wxpython/timeline

Helena
 
 Vaclav
 
 https://trac.osgeo.org/grass/changeset/57814
 ___
 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] WinGRASS6.4.3 crashing

[Helena Mitasova]

Helmut,

thank you very much for quick advice - for one of the students 
osgeo4w-winGRASS6.4.3 works along ArcGIS10.1 
so we will try this out in the lab as well and report back. Hopefully this will 
solve the problem,

Helena

Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Aug 16, 2013, at 4:50 PM, Helmut Kudrnovsky wrote:

 hi Helena,
 
 After clicking on the GRASS icon the cli window just flashes and the
 startup page
 does not open.
 
 did you activated to download the needed microsoft runtimes? it's on the
 download tab (ms files and sample datasets) during the installation of the
 standalone installer.
 
 It is worrisome that the final release is more problematic than RC2, but I
 am wondering whether the problem is on our side - perhaps the GRASS6.4.3RC2
 should be uninstalled before installing GRASS6.4.3 final?
 
 give it a try.
 
 We have ArcGIS running on these machines and I am aware of the python
 issues I am just wondering whether RC2 had a better solution for the GRASS
 startup than the final release.
 
 RC2 has no better solution, but another python version than ArcGIS. 
 
 if you have ArcGIS 10.1, then the trouble comes in. 
 
 ArcGIS 10.1 and WinGRASS6.4.3 have the same python version (python 2.7.x)
 
 If there is no easy fix, would it be possible to provide GRASS6.4.3RC2 on
 the GRASS website for those who cannot run GRASS6.4.3?
 
 would be osgeo4w-winGRASS6.4.3 an alternative? this works for me having
 ArcGIS 10.1 on my laptop.
 
 Should I submit this a s bug report or is this strictly our problem
 
 ...you are not alone. but there is no easy solution for this python issue, a
 ticket is already opened. but IMHO it is more a general question of
 operating system design made by MS than a winGRASS problem.
 
 
 
 -
 best regards
 Helmut
 --
 View this message in context: 
 http://osgeo-org.1560.x6.nabble.com/WinGRASS6-4-3-crashing-tp5072888p5072913.html
 Sent from the Grass - Dev mailing list archive at Nabble.com.
 ___
 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] GRASS6.4.3RC3 on downloads web site

[Helena Mitasova]

Michael,

I think that you should keep what you have for GRASS6.4.3 - I just
installed it on MacOSX10.8 and it at least opens correctly - I will test it
more in next few days.
William, your binary has similar problem as WinGRASS, it does not open the
wxGUI properly - I can post more info, but Michael can probably explain
what needs to be done.

Helena


On Thu, Aug 15, 2013 at 4:36 PM, Michael Barton michael.bar...@asu.eduwrote:

  Helena,

  Do I need to recompile GRASS 6.4.3? I don't know if I have 6.4.3-1 or
 not.

  Michael
__
  C. Michael Barton
  Director, Center for Social Dynamics  Complexity
  Professor of Anthropology, 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://csdc.asu.edu, http://shesc.asu.edu
  http://www.public.asu.edu/~cmbarton

  On Aug 15, 2013, at 12:00 PM, grass-dev-requ...@lists.osgeo.org
  wrote:

  *From: *Helena Mitasova hmit...@ncsu.edu
  *Subject: **[GRASS-dev] GRASS6.4.3RC3 on downloads web site*
  *Date: *August 14, 2013 7:13:27 PM MST
  *To: *GRASS developers grass-developers grass-dev@lists.osgeo.org


 I just checked the download webpage and it lists GRASS6.4.2 | 6.4.3RC3 as
 stable versions,
 but the news says that GRASS6.4.3 has been released - should the above be
 changed to 6.4.3 too?
 http://grass.osgeo.org/download/software/

 WinGRASS binaries show 6.4.3-1 as the latest stable but the link at
 Installing GRASS points to WinGRASS6.4.2-2,
 should that be changed to 6.4.3-1?
 http://grass.osgeo.org/grass64/binary/mswindows/native/

 the binaries for Mac
 http://grass.osgeo.org/download/software/mac-osx/
 show the link to William's web page first which has 6.4.2 binaries
 (William, any chance for providing 6.4.3?)
 but Michael's web site has GRASS6.4.3 binaries - should it be listed first?

 We haven't tried WinGRASS6.4.3-1 yet, I am wondering whether there are any
 known issues besides
 the ones listed on wiki under WinGRASS errors

 Thank you, Helena

 Helena Mitasova
 Associate Professor
 Department of Marine, Earth, and Atmospheric Sciences
 2800 Faucette Drive, Rm. 1125 Jordan Hall
 North Carolina State University
 Raleigh, NC 27695-8208
 hmit...@ncsu.edu

 All electronic mail messages in connection with State business which are
 sent to or received by this account are subject to the NC Public Records
 Law and may be disclosed to third parties.”







-- 
Helena Mitasova
Associate Professor
Department of Marine, Earth and Atmospheric Sciences
North Carolina State University
1125 Jordan Hall
NCSU Box 8208
Raleigh, NC 27695-8208
http://skagit.meas.ncsu.edu/~helena/

email: hmit...@ncsu.edu
ph: 919-513-1327 (no voicemail)
fax 919 515-7802
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] WinGRASS6.4.3 crashing

[Helena Mitasova]

I am sorry to report that WinGRASS6.4.3-1 does not run on our lab
computers.
After clicking on the GRASS icon the cli window just flashes and the
startup page
does not open. We have GRASS6.4.3RC2 running OK on the same machine.

It is worrisome that the final release is more problematic than RC2, but I
am wondering whether the problem is on our side - perhaps the GRASS6.4.3RC2
should be uninstalled before installing GRASS6.4.3 final? We have ArcGIS
running on these machines and I am aware of the python issues I am just
wondering whether RC2 had a better solution for the GRASS startup than the
final release.

If there is no easy fix, would it be possible to provide GRASS6.4.3RC2 on
the GRASS website for those who cannot run GRASS6.4.3?
Should I submit this a s bug report or is this strictly our problem and
everybody
else runs WinGRASS6.4.3 just fine?

Any advice would be appreciated

Helena

-- 
Helena Mitasova
Associate Professor
Department of Marine, Earth and Atmospheric Sciences
North Carolina State University
1125 Jordan Hall
NCSU Box 8208
Raleigh, NC 27695-8208
http://skagit.meas.ncsu.edu/~helena/

email: hmit...@ncsu.edu
ph: 919-513-1327 (no voicemail)
fax 919 515-7802
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GRASS6.4.3RC3 on downloads web site

[Helena Mitasova]

I just checked the download webpage and it lists GRASS6.4.2 | 6.4.3RC3 as 
stable versions,
but the news says that GRASS6.4.3 has been released - should the above be 
changed to 6.4.3 too?
http://grass.osgeo.org/download/software/

WinGRASS binaries show 6.4.3-1 as the latest stable but the link at Installing 
GRASS points to WinGRASS6.4.2-2,
should that be changed to 6.4.3-1?
http://grass.osgeo.org/grass64/binary/mswindows/native/

the binaries for Mac
http://grass.osgeo.org/download/software/mac-osx/
show the link to William's web page first which has 6.4.2 binaries (William, 
any chance for providing 6.4.3?)
but Michael's web site has GRASS6.4.3 binaries - should it be listed first?

We haven't tried WinGRASS6.4.3-1 yet, I am wondering whether there are any 
known issues besides
the ones listed on wiki under WinGRASS errors

Thank you, Helena

Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

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

Re: [GRASS-dev] GRASS GIS 7 tech-preview release preparations

[Helena Mitasova]

On Jul 13, 2013, at 7:32 PM, Michael Barton wrote:

 It's really a bite that I cannot a working Mac version of GRASS 7 without 
 some post-compilation hacking. While I can create a useable Mac binary with 
 some effort, it could be a problem for others who wish to do so.

I was just trying to compile grass7 on a new airbook that I am taking to 
Prague, and I can confirm
hat there is a problem.

Also, related to the tech preview, the current wingrass6.4.3svn and wingrass7 
binaries from Martin crash on networked windows8 in our lab and for my 
colleague (the startup does not open) but run fine on the windows side of my 
student's Mac. 
I did not have time to look into any of this as we are leaving for Europe on 
Monday (I guess that is today).
Hopefully we will be able to resolve at least some of these issues in Prague,

Helena
 
 Glynn suggests that this is a ctypes issue and Anna thinks it may be 
 something that has consequences for numerous modules (I'm inclined to agree). 
 But so far, we're stuck. 
 
 Michael
 
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity 
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 
 voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
 fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
 www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 
 
 
 
 
 
 
 
 On Jul 13, 2013, at 10:46 AM, grass-dev-requ...@lists.osgeo.org wrote:
 
 From: Moritz Lennert mlenn...@club.worldonline.be
 Subject: Re: [GRASS-dev] GRASS GIS 7 tech-preview release preparations
 Date: July 13, 2013 3:16:12 AM MST
 To: Markus Metz markus.metz.gisw...@gmail.com
 Cc: grass-dev grass-dev@lists.osgeo.org
 
 
 On Fri, July 12, 2013 22:04, Markus Metz wrote:
 On Fri, Jul 12, 2013 at 3:21 PM, Moritz Lennert
 mlenn...@club.worldonline.be wrote:
 
 Main issues I see for grass7 currently to get it preview-release ready:
 
 [...]
 
 - LFS handling in Windows
 
 https://trac.osgeo.org/grass/ticket/1131 (not sure I understand where we
 are
 at with this)
 
 Global LFS is enabled by default and working on all officially
 supported platforms, plus *BSD and some UNIX systems.
 
 
 That means we can close this ticket ?
 
 Moritz
 
 
 
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev

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

Re: [GRASS-dev] GRASS 6.4.3 release planning, mapcalc expressions in wingrass

[Helena Mitasova]

I am happy to report that the expressions with || now work on windows from 
command console when quotes are used.
Thank you Anna and Glynn for solving this long standing problem for wingrass 
users,

Helena

On Jul 4, 2013, at 4:45 PM, Anna Petrášová wrote:

 
 
 
 On Tue, Jul 2, 2013 at 8:57 PM, Anna Petrášová kratocha...@gmail.com wrote:
 Hi,
 
 
 On Fri, Jun 28, 2013 at 2:29 AM, Helena Mitasova hmit...@ncsu.edu wrote:
 regarding the r.mapcalc issue in command console on wingrass -
 (sorry I did not make it clear it was for wingrass - it always worked well on 
 Mac and linux)
 
 It is not critical, windows users can still use the mapcalculator GUI where 
 it runs OK,
 but the r.mapcalc in the command console still does not seem to work - tried 
 by a student
 using June 26 snapshot this is what she says:
 
 Here are examples of the commands run and the errors received:
 r.mapcalc urban2_30m=if(landuse96_28m==1 || 
 landuse96_28m==2,landuse96_28m,null())
 syntax error, unexpected $end, expecting ')'
 Parse error
 'landuse96_28m' is not recognized as an internal or external
 
 command,
 operable program or batch file.
 
 r.mapcalc MASK=if((elevation100  elevation60)  (landuse96_28m==1 || 
 landuse96_28m==2),1,null())
 1 was unexpected at this time.
 
 This is the same we were getting in GRASS6.4.3RC2 and apparently the proposed 
 solutions did not work
 http://lists.osgeo.org/pipermail/grass-dev/2013-February/062047.html
 http://lists.osgeo.org/pipermail/grass-dev/2013-March/062607.html
 
 
 I had the opportunity to test Glynn's patch (the second link above) on 
 Windows and it seems to solve the problems. From the discussion I can see 
 that Markus already tested it but he was not successful, so I applied the 
 patch to 6.5 first.
 All the commands causing problems are now working with both (, ') quotes and 
 without, only the command with || requires quotes.
 
 Anna
 
 Seems to work, I applied it to all branches, please test (using e.g. the 
 commands above).
 
 Anna
 
 
 
 
 if I get this confirmed I will file a bug report (I thought I already did, 
 but it is not there).
 If it is not fixable it should be at least mentioned on the known issues web 
 page
 http://grasswiki.osgeo.org/wiki/WinGRASS_Current_Status#Raster_modules
 
 Helena
 
 
 
 
 
  Helena:
  I am also wondering whether the r.mapcalc expressions with || (or)
  now run from the wxGUI command console.
 
  I just tried on linux 6.4.3svn wxGUI command console:
 
r.mapcalc either = 0 || 1
  and it worked.
 
  In general I wouldn't be surprised if full command line quoting took
  years and huge amounts of effort to (re)perfect. And even then, does
  it try to follow Bash conventions, or python, or DOS, or some mix of
  all those? How much do we try to (re)teach about command line
  techniques in our own docs? Will unquoted input=C:\Users\files\data.txt
  always be parsed to input=C:Usersfilesdata.txt (literal \U, \f, \d)
  in the command console in that case?
 
 
  best,
 
  Hamish
 
  ___
  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
 
 

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

Re: [GRASS-dev] GRASS 6.4.3 release planning

[Helena Mitasova]

I am also wondering whether the r.mapcalc expressions with || (or) now run from 
the wxGUI command console.
Is this the place to get the right binary to try it out?
http://wingrass.fsv.cvut.cz/grass64/

Helena 

On Jun 27, 2013, at 9:33 AM, Markus Neteler wrote:

 On Wed, Jun 26, 2013 at 10:29 PM, Hamish hamis...@yahoo.com wrote:
 I've worked through the changelog and the 6.4.3rc4 release summary page 
 seems in order now,
 
  https://trac.osgeo.org/grass/wiki/Release/6.4.3RC4-News
 
 Thanks.
 
 anything else to add?
 
 It is not clear to me (lost in too many emails):
 - if g.extension is sufficiently ok now
 - if Python scripts run on Windows
 - for both, if it improved in the upcoming RC4
 
 So, perhaps either some related remarks would be good or
 a link to the (to be updated)
 http://grasswiki.osgeo.org/wiki/WinGRASS_Current_Status#Known_Issues
 
 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 6.4.3 release planning

[Helena Mitasova]

regarding the r.mapcalc issue in command console on wingrass -
(sorry I did not make it clear it was for wingrass - it always worked well on 
Mac and linux)

It is not critical, windows users can still use the mapcalculator GUI where it 
runs OK,
but the r.mapcalc in the command console still does not seem to work - tried by 
a student
using June 26 snapshot this is what she says:

Here are examples of the commands run and the errors received: 
r.mapcalc urban2_30m=if(landuse96_28m==1 || 
landuse96_28m==2,landuse96_28m,null())
syntax error, unexpected $end, expecting ')'
Parse error
'landuse96_28m' is not recognized as an internal or external
command,
operable program or batch file.

r.mapcalc MASK=if((elevation100  elevation60)  (landuse96_28m==1 || 
landuse96_28m==2),1,null())
1 was unexpected at this time.

This is the same we were getting in GRASS6.4.3RC2 and apparently the proposed 
solutions did not work
http://lists.osgeo.org/pipermail/grass-dev/2013-February/062047.html
http://lists.osgeo.org/pipermail/grass-dev/2013-March/062607.html

if I get this confirmed I will file a bug report (I thought I already did, but 
it is not there).
If it is not fixable it should be at least mentioned on the known issues web 
page
http://grasswiki.osgeo.org/wiki/WinGRASS_Current_Status#Raster_modules

Helena




 
 Helena:
 I am also wondering whether the r.mapcalc expressions with || (or)
 now run from the wxGUI command console.
 
 I just tried on linux 6.4.3svn wxGUI command console:
   r.mapcalc either = 0 || 1
 and it worked.
 
 In general I wouldn't be surprised if full command line quoting took
 years and huge amounts of effort to (re)perfect. And even then, does
 it try to follow Bash conventions, or python, or DOS, or some mix of
 all those? How much do we try to (re)teach about command line
 techniques in our own docs? Will unquoted input=C:\Users\files\data.txt
 always be parsed to input=C:Usersfilesdata.txt (literal \U, \f, \d)
 in the command console in that case?
 
 
 best,
 Hamish
 
 ___
 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 7 crashes on startup on Mac

[Helena Mitasova]

On Jun 8, 2013, at 7:18 PM, Michael Barton wrote:

 I've been staying with wxPython 2.8.x Perhaps some of the new code only works 
 correctly in 2.9?

that is the message I have been getting, Helena
 
 Michael
 
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity 
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 
 voice:480-965-6262 (SHESC), 480-727-9746 (CSDC)
 fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
 www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 
 
 
 
 
 
 
 On Jun 7, 2013, at 8:39 PM, William Kyngesburye wokl...@kyngchaos.com wrote:
 
 I just compiled trunk, no compile errors, and GUI runs fine.
 
 OSX 10.7 Lion, Xcode 4.6.2 command line tools, wxPython 2.9.4
 
 I'm a bit lost now - what is the status of this, what is the current problem?
 
 On Jun 7, 2013, at 10:28 AM, Michael Barton wrote:
 
 Maybe it is PYTHONPATH
 
 BUT...
 
 Python and the GUI is compiling and working just fine otherwise. And Python 
 runs with no problem in the terminal.
 
 The bogus errors for compiling mapswipe, composer, etc first appeared with 
 what I think was the introduction of a new window class for these modules. 
 I have not seen the toolbox, but it may reuse the same code. If I knew what 
 this new code is, I might be able to troubleshoot it. But I don't have time 
 to try to reverse engineer it without guidance as to where to look. The 
 error on importing wx is misleading as to what the real error is. 
 
 I can't say for sure that these are all related (and the error is indeed 
 somewhat different for the toolbox compilation). But it seems a reasonable 
 place to start.
 
 If it IS a PYTHONPATH problem, then the code for building the toolbox is 
 somehow ignoring PYTHONPATH because this is set properly otherwise.
 
 
 On Thu, Jun 6, 2013 at 7:16 PM, Michael Barton michael.bar...@asu.edu 
 wrote:
 Anna,
 
 This is from the log. It looks to me like a path problem during compilation
 
 Traceback (most recent call last):
 File tools/build_modules_xml.py, line 85, in module
   sys.exit(main())
 File tools/build_modules_xml.py, line 77, in main
   header(fh)
 File tools/build_modules_xml.py, line 58, in header
   import grass.script.core as grass
 ImportError: No module named grass.script.core
 make[1]: *** 
 [/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.3.0/etc/gui/wxpython/xml/module_items.xml]
  Error 1
 make: [default] Error 2 (ignored)
 make xml/menudata.xml
 make[1]: `xml/menudata.xml' is up to date.
 make menustrings.py
 
 The other bogus errors on No module named wx also seems like a path 
 problem.
 
 yes, problem might be in PYTHONPATH. Could you ask about this William? I 
 have currently no time and I am probably not able to solve this.
 
 Regards,
 
 Anna 
 
 On Jun 6, 2013, at 2:39 AM, Anna Petrášová kratocha...@gmail.com wrote:
 
 Hi, Michael,
 
 
 On Wed, Jun 5, 2013 at 11:45 PM, Michael Barton michael.bar...@asu.edu 
 wrote:
 OK. I did this remotely but hopefully it is what you need.
 
 yes, perfect, thanks. Could you try the compilation again with the change 
 William did recently (demolocation probem, [1])? It might be related 
 because from the errors in the log it seems that the virtual grass 
 session is not there. If the problem is still there, please send me 
 updated compilation log.
 
 Thanks,
 Anna
 
 
 [1] https://trac.osgeo.org/grass/changeset/56621 
 
 
 -
 William Kyngesburye kyngchaos*at*kyngchaos*dot*com
 http://www.kyngchaos.com/
 
 The beast is actively interested only in now, and, as it is always now and 
 always shall be, there is an eternity of time for the accomplishment of 
 objects.
 
 - the wisdom of Tarzan
 
 
 
 
 
 
 ___
 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 7 crashes on startup on Mac

[Helena Mitasova]

I haven't been following this very well but grass7 crashes for me with the 
following error:

ERROR: wxGUI requires wxPython = 2.8.10.1. Your wxPython version is 2.8.8.1.

so I guess I need to get wxPython2.9?

Helena

Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Jun 4, 2013, at 7:40 PM, Michael Barton wrote:

 Anna,
 
 Still crashes.
 
 See below.
 __
 C. Michael Barton 
 Director, Center for Social Dynamics  Complexity
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 Tempe, AZ  85287-2402
 USA
 
 voice: 
 480-965-6262 (SHESC), 480-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
 
 On May 20, 2013, at 12:06 AM, Anna Petrášová kratocha...@gmail.com wrote:
 
 Hi Michael,
 
 
 On Tue, May 14, 2013 at 12:32 AM, Anna Petrášová kratocha...@gmail.com 
 wrote:
 
 
 
 On Mon, May 13, 2013 at 11:51 PM, Michael Barton michael.bar...@asu.edu 
 wrote:
 Perhaps I discovered the problem. Both the distribution version (downloaded 
 in the past hour) and (of course) the compiled version of menudata.xml are 
 empty.
 
 Yes, that's what I was thinking. Could you try to run this separately:
 
 python core/toolboxes.py  xml/menudata.xml 
 
 I assumed that you want me to run this from the GRASS terminal prompt???
 
 python core/toolboxes.py  xml/menudata.xml
 bash: xml/menudata.xml: No such file or directory
 
 Michael
 
 
 which should be done during compilation but it seems to fail somehow. It 
 should generate the xml menu file.
 
 any update? I know you announced to be out of office but maybe you can try 
 it anyway?
 
 Anna
 
 
 
 Michael
 
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity 
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 
 voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
 fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
 www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 
 
 
 
 
 
 
 On May 13, 2013, at 2:18 PM, Anna Petrášová kratocha...@gmail.com
  wrote:
 
 There might be a problem with compilation. Is there any error? Could you 
 check file menudata.xml in gui/wxpython/xml/ and the same file in 
 distribution? Is it there and what's inside?
 
 
 On Mon, May 13, 2013 at 10:51 PM, Michael Barton michael.bar...@asu.edu 
 wrote:
 Anna,
 
 I deleted all the GUI code and did a new svn up and make distclean.
 
 Just finished compiling and have the same error on startup. The GUI crashes.
 
 
 Michael
 __
 C. Michael Barton 
 Director, Center for Social Dynamics  Complexity
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 Tempe, AZ  85287-2402
 USA
 
 voice: 
 480-965-6262 (SHESC), 480-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
 
 On May 13, 2013, at 1:23 PM, Anna Petrášová kratocha...@gmail.com
  wrote:
 
 Hi Michael,
 
 
 On Mon, May 13, 2013 at 9:52 PM, Michael Barton michael.bar...@asu.edu 
 wrote:
 I just compiled GRASS 7 Trunk.
 
 It crashes on startup with the following error:
 
 this is related to the new toolboxes and menu customization. I don't know 
 what is wrong because it was tested successfully also on Windows. Could 
 you check what you have in directory toolboxes which should be in the same 
 folder as saved settings file? Also try make distclean or just make clean 
 in gui/wxpython and remove manually the gui files from distribution.
 
 Anna
 
 
 GRASS 7.0.svn (nc_spm_08):~  Traceback (most recent call last):
   File 
 /Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py,
  line 140, in module
 sys.exit(main())
   File 
 /Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py,
  line 133, in main
 app = GMApp(workspaceFile)
   File 
 /Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py,
  line 45, in __init__
 wx.App.__init__(self, False)
   File 
 /Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/python/wx/_core.py,
  line 7981, in __init__
 self._BootstrapApp()
   File 
 /Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/python/wx/_core.py,
  line 7555, in _BootstrapApp
 return _core_.PyApp__BootstrapApp(*args, **kwargs)
   File

Re: [GRASS-dev] wxGUI GRASS 7: how to drape a map over a DEM?

[Helena Mitasova]

I have updated the videos for wxnviz including working with multiple surfaces, 
color draping and adding a constant surface
and cutting planes here:
http://courses.ncsu.edu/mea582/common/GIS_anal_grass/GIS_Anal_grvisual.html
you can see there wxnviz and old nviz side-by-side.

I will re-do the videos once we have a final release of 6.4.3

The only thing that you need to be aware of is that in GRASS6 change in region 
is ignored by wxnviz - it always
uses the region which was set when you first switched to it. You need to quit 
wxgui, change region and restart wxgui.
In GRASS7 region can be changed - one more reason to have GRASS7 pre-release.

Anna please correct me if I am wrong in anything above.

I hope this helps, Helena


Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On May 26, 2013, at 7:16 AM, Markus Metz wrote:

 On Sun, May 26, 2013 at 11:21 AM, Anna Petrášová kratocha...@gmail.com 
 wrote:
 
 
 
 On Sun, May 26, 2013 at 11:08 AM, Markus Metz
 markus.metz.gisw...@gmail.com wrote:
 
 On Sun, May 26, 2013 at 10:32 AM, Anna Petrášová kratocha...@gmail.com
 wrote:
 
 The problem why you don't see anything when you load both maps is that
 flowacc has large extreme values, so the initial view is confused.
 Anyway
 you should be able see something when you adjust the view to some normal
 height.
 
 That means I can not change the raster map to be used as surface?
 Because I see that two different surfaces are used after updating,
 resetting, and changing height to a reasonable value, even though only
 one surface map is given. BTW, nviz in 6.x accepts multiple raster
 maps as surfaces.
 
 Sorry, I don't really understand what you mean. You can display more
 surfaces, you can unload (uncheck or remove) surface and add new.
 
 OK, got it. All active raster maps in the layer manager are loaded as 
 surfaces.
 
 Markus M
 ___
 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] RE : formatting expressions for r.mapcalc in GRASS6.4.3

[Helena Mitasova]

Robert,

I might have missed it but I am wondering whether the mapcalc now works 
reliably in the command console on Windows.

Helena

Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Mar 17, 2013, at 8:09 PM, Robert Lagacé wrote:

 
 I look at the code friday night (the file utils.py) and it seems to contains 
 some functions 
 to deals with Windows/Unix and some 'HACK' as writen in comments. 
 
 What is the purposeof the function split(s)? 
 
 I think that the question/problem is more profond than that this split() 
 funtion.
 
 I am developping an application in Python/wxPython that is working on both 
 Linux and Windows.
 
 Wth that experience I will try come back in a few weeks to make a 
 proposal/suggestions.
 But does not solve the problem in the mean time. With which version of Python 
 and Windows 
 the students are working?
 
 Robert Lagacé
 
 
 De : grass-dev-boun...@lists.osgeo.org [grass-dev-boun...@lists.osgeo.org] de 
 la part de Markus Neteler [nete...@osgeo.org]
 Date d'envoi : 17 mars 2013 18:48
 À : Glynn Clements
 Cc : GRASS developers list
 Objet : Re: [GRASS-dev] formatting expressions for r.mapcalc in GRASS6.4.3
 
 On Sun, Mar 17, 2013 at 12:23 AM, Glynn Clements
 gl...@gclements.plus.com wrote:
 ...
 Replace the split() function in core/utils.py with:
 
def split(s):
!Platform spefic shlex.split
if sys.platform == win32:
return shlex.split(s.replace('\\', r'\\'))
else:
return shlex.split(s)
 
 I have tested attached patch (which I hope is the same as the suggested 
 change),
 it lead to a complete GUI error. I tried to catch it with a screenshot
 but was to
 slow. I can try harder if needed.
 
 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 7: segmax and npmin confused in r.fillnulls / v.surf.rst

[Helena Mitasova]

Stefan,

I think you should file a ticket for this,

Helena 

On Apr 22, 2013, at 4:37 AM, SBL wrote:

 Hi
 
 I am struggeling a bit with r.filnulls on a big raster (60,000 x 50,000
 cells) with lots of NULL areas (ca. 52,000 holes).
 
 In trac I provided a patch for speeding-up r.fillnulls ( #1938
 http://trac.osgeo.org/grass/ticket/1938  ). But it still feels pretty slow
 on such a big raster...
 
 In particular, I was stumbeling upon the following waring message
 
 
 
 If number of points is below 600, then both segmax and npmin are set to
 pointsnumber. So, from r.fillnulls segmax was set to 40 (and not 80, like
 the warning message indicates...). Then I tested in v.surf.rst with a hole
 with 1033 existing data points on the edge, and now I am a little confused:
 
 If I set 
 
 I get the following Warning message:
 
 And interpolation is done within 6 seconds.
 
 I get the same message if I set:
 
 But now processing takes now 16 seconds...
 
 The warning message above changes to 
 
 when I set:
 
 Strange that it is possible because in the GUI it says npmin has to be
 greater than segmax...
 But processing time is down on 6 secs again...
 
 With:
 
 I get the expected error message, that npmin has to greater than segmax.
 
 Finally, I set segmax and npmin to the default in r.fillnulls for holes
 with pointnumber = 600:
 
 Now processing takes 55 seconds!!!
 This is especially confusing because during the tests with npmin = 1033 I
 got the following warning message in addition:
 
 But actually, processing was nearly 10 times faster then with npmin=300!
 
 Sorry for the long post!
 
 Summary:
 Something seems to be confused in the way v.surf.rst handles the user input
 and gives warning/error messages...
 
 
 Shall I file a ticket?
 
 
 Cheers
 Stefan
 
 P.S.: BTW, using the dmin in r.fillnulls could improve the processing
 speed for bigger holes some more. Maybe it is worth giving the user the
 option to set dmi also in r.fillnulls?
 
 
 
 
 --
 View this message in context: 
 http://osgeo-org.1560.x6.nabble.com/Grass-7-segmax-and-npmin-confused-in-r-fillnulls-v-surf-rst-tp5048683.html
 Sent from the Grass - Dev mailing list archive at Nabble.com.
 ___
 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] repeated problem for installing GRASS for windows

[Helena Mitasova]

Michael

has she tried the suggestion that my students found and that worked for them:
http://i.justrealized.com/2009/how-to-fix-missing-msvcr71dll-problem-in-windows/

Helena

Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Mar 7, 2013, at 1:03 PM, Michael Barton wrote:

 Thanks Helmut.
 
 Sadly, it turns out that the solutions on the link now on the download page 
 will help many but not all people who get this error. My student tried all 
 suggestions so far to no avail. 
 
 I suggested (hopefully correctly) to do a search on the dll and see if there 
 are multiple copies, including out of date ones. But I'm not sure what else 
 to have her try.
 
 Michael
 __
 C. Michael Barton 
 Director, Center for Social Dynamics  Complexity
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 Tempe, AZ  85287-2402
 USA
 
 voice: 
 480-965-6262 (SHESC), 480-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
 
 On Mar 7, 2013, at 1:46 AM, grass-dev-requ...@lists.osgeo.org
  wrote:
 
 From: Helmut Kudrnovsky hel...@web.de
 Subject: Re: [GRASS-dev] repeated problem for installing GRASS for windows
 Date: March 6, 2013 1:26:45 PM MST
 To: grass-dev@lists.osgeo.org
 
 
 
 If you can give me the name of the installation script (or the script
 itself),
 I will try to find a way. 
 
 Robert,
 
 I'm afraid I don't know much about Windows compiling or installing (I'm
 more of a Mac person with Linux second). Perhaps others on the dev list
 could help you with this. I'm copying the list.
 
 the installer script for the standalone-wingrass-nsis-installer:
 
 http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/mswindows/GRASS-Installer.nsi.tmpl
 
 
 
 
 -
 best regards
 Helmut
 --
 View this message in context: 
 http://osgeo-org.1560.n6.nabble.com/repeated-problem-for-installing-GRASS-for-windows-tp5038650p5038864.html
 Sent from the Grass - Dev mailing list archive at Nabble.com.
 

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

Re: [GRASS-dev] GRASS GSoC idea: Temporal GIS algebra for raster and vector data

[Helena Mitasova]

I think that is a great project - Soeren thanks for proposing the idea and 
volunteering as a mentor,

Helena 

On Feb 27, 2013, at 5:37 AM, Sören Gebbert wrote:

 Hi all,
 i would like to participate in the GSoC project this year as mentor
 for the Temporal GIS algebra for vector and raster data[1] idea.
 
 I would like to suggest my colleague Thomas Leppelt[2] as GSoC student
 who implements the temporal GIS algebra modules.
 Thomas is a PhD student at our Institute[3] and a GRASS7 power user
 with comprehensive knowledge about the new temporal GIS part of
 GRASS7. He is also a skilled Python and R programmer.
 
 What do you think?
 
 Best regards
 Soeren
 
 [1] http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2013#Temporal_GIS_Algebra
 [2] 
 http://www.ti.bund.de/en/startseite/institutes/climate-smart-agriculture/staff/researchers/leppelt-thomas.html
 [3] 
 http://www.ti.bund.de/en/startseite/institutes/climate-smart-agriculture.html
 ___
 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-user] NViz - problem in the visualization of 3D objects

[Helena Mitasova]

I have seen this problem - it is similar to issues with rendering the box point 
symbols and at some scales
even for spheres.
Carla, have you tried to move around the light - does it change anything?

Helena
 
Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Feb 14, 2013, at 1:15 PM, Anna Kratochvílová wrote:

 On Thu, Feb 14, 2013 at 6:30 PM, Carla Rebelo crreb...@gmail.com wrote:
 Hi,
 
 I have footprint buildings and the height value (type double
 precision) of each footprint.
 
 v.info -t map=buildings@
 nodes=250
 points=0
 lines=0
 boundaries=243
 centroids=88
 areas=89
 islands=8
 faces=0
 kernels=0
 primitives=331
 map3d=1
 
 After the v.extrude step v.extrude --overwrite --verbose
 input=buldings@ output=buildings3D hcolumn=Height type=area
 
 v.info -t map=buildings3D@
 nodes=646
 points=0
 lines=0
 boundaries=0
 centroids=0
 areas=0
 islands=0
 faces=743
 kernels=88
 primitives=831
 map3d=1
 
 When I visualized the file 3D from NViz, I have seen some of the
 buildings with a black filling (it's black inside or the top of
 building is black) 
 
 Is it a problem of rendering? Or a problem with the topology?
 
 Some of the buildings look ok? I've just tried a small example and it
 works for me .
 
 There could be a problem with the normal vectors of the faces.
 Unfortunately I don't know much about the topology of kernels.
 
 Regards,
 Anna
 
 
 Best regards,
 CR
 ___
 grass-user mailing list
 grass-u...@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user
 ___
 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

[GRASS-dev] v.out.ogr browse button for output

[Helena Mitasova]

I noticed that students had hard time finding or defining the path to the file 
exported by v.out.ogr 
(in our case it was a kml file) because there is no browse button - is there a 
reason for the missing 
Browse for this command?
r.out.gdal has such button and it was suggested but Helmut some time ago:
http://lists.osgeo.org/pipermail/grass-user/2009-July/051356.html

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

Re: [GRASS-dev] v.out.ogr browse button for output

[Helena Mitasova]

On Feb 18, 2013, at 11:19 AM, Markus Metz wrote:

 On Mon, Feb 18, 2013 at 4:49 PM, Helena Mitasova hmit...@ncsu.edu wrote:
 I noticed that students had hard time finding or defining the path to the 
 file exported by v.out.ogr
 (in our case it was a kml file) because there is no browse button - is there 
 a reason for the missing
 Browse for this command?
 
 OGR access to vector data requires a data source name (dsn) and a
 layer name. The data source could be a PostGIS database in which case
 a browse button does not make sense. In other cases, e.g. kml or
 shapefiles, the dsn can be a directory or file name, or both. This is
 too much flexibility for an automatically generated gui and the reason
 for the new interfaces for r.in.gdal and v.in.ogr.
 
 You can also set the current working directory in the GUI with
 Settings-GRASS working environment-Change working directory. This
 affects only the GUI, not the shell.

this is actually what I was looking for, I could not find it in GRASS6.4.3 but 
I see that it is in GRASS7.
It could resolve several issues for Windows users.

thanks a lot, Helena
 
 Markus M
 
 r.out.gdal has such button and it was suggested but Helmut some time ago:
 http://lists.osgeo.org/pipermail/grass-user/2009-July/051356.html
 
 Helena
 ___
 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 GIS 6.4.3RC2 released

[Helena Mitasova]

On Feb 14, 2013, at 3:45 AM, Markus Metz wrote:

 On Thu, Feb 14, 2013 at 2:09 AM, Michael Barton michael.bar...@asu.edu 
 wrote:
 The main blocker for the Mac has been partly fixed in trunk: broken volume
 display. Now it displays most of the time and only crashes randomly instead
 all the time.  If Markus Metz has backported this to 6.4.x, I'm happy to
 test and see if it works the same way there.
 
 I have disabled the gvl_align_data() function in 6.5. and 6.4, as
 suggested by you. All it does is reallocating memory to the minimum
 that is needed. Memory consumption might thus be a bit larger in GRASS
 6 than in GRASS 7, but with regard to the ogsf lib it should work
 nevertheless because gvl_align_data() does not touch the actual data.
 Another possible source of bugs is the wxPython part of wxNVIZ because
 it uses ctypes. Does it make sense to test the old Tcl/Tk nviz and see
 if volume display works there?

yes, I should be able to run it with the old tcltk - that would be a good test,

Helena

 
 Markus M
 
 
 Michael
 
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 
 voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
 fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
 www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 
 
 
 
 
 
 
 On Feb 13, 2013, at 2:20 PM, grass-dev-requ...@lists.osgeo.org
 wrote:
 
 From: Martin Landa landa.mar...@gmail.com
 Subject: Re: [GRASS-dev] GRASS GIS 6.4.3RC2 released
 Date: February 13, 2013 1:32:11 PM MST
 To: Helmut Kudrnovsky hel...@web.de
 Cc: grass-dev@lists.osgeo.org
 
 
 Hi,
 
 2013/2/3 Martin Landa landa.mar...@gmail.com:
 
 since it's more than a month ago now, what about another another RC or
 release?
 
 
 agreed. After RC3 should come ideally final release.
 
 
 sorry for bringing this issue back. We have 2 RCs released, RC2 is
 almost 2(!) month old. I don't see any blocker in trac [1], even
 nothing noted on the dev's wiki [2]. Is there any blocker, if so
 please collect them in trac or at least note them on trac page [2].
 Currently I am afraid that we have no clear idea what is the status of
 critical issues which have been reported within various mails in
 various threads by various persons.
 
 Martin
 
 [1]
 http://trac.osgeo.org/grass/query?status=newstatus=assignedstatus=reopenedgroup=typeorder=prioritypriority=blockerpriority=criticalmilestone=6.4.3milestone=6.4.2milestone=6.4.1milestone=6.4.0
 [2] http://trac.osgeo.org/grass/wiki/Grass6Planning#GRASS6.4.3
 
 --
 Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa
 
 
 

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

Re: [GRASS-dev] GRASS GIS 6.4.3RC2 released

[Helena Mitasova]

On Feb 14, 2013, at 10:38 AM, Michael Barton wrote:

 Actually, I already tested that a couple months back. The TclTk volume 
 display works fine even when wxPython display does not.

but does it work with the latest changes? That was my main concern, Helena

 
 Michael
 __
 C. Michael Barton 
 Director, Center for Social Dynamics  Complexity
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 Tempe, AZ  85287-2402
 USA
 
 voice:480-965-6262 (SHESC), 480-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
 
 On Feb 14, 2013, at 7:40 AM, Helena Mitasova hmit...@ncsu.edu
 wrote:
 
 
 On Feb 14, 2013, at 3:45 AM, Markus Metz wrote:
 
 On Thu, Feb 14, 2013 at 2:09 AM, Michael Barton michael.bar...@asu.edu 
 wrote:
 The main blocker for the Mac has been partly fixed in trunk: broken volume
 display. Now it displays most of the time and only crashes randomly instead
 all the time.  If Markus Metz has backported this to 6.4.x, I'm happy to
 test and see if it works the same way there.
 
 I have disabled the gvl_align_data() function in 6.5. and 6.4, as
 suggested by you. All it does is reallocating memory to the minimum
 that is needed. Memory consumption might thus be a bit larger in GRASS
 6 than in GRASS 7, but with regard to the ogsf lib it should work
 nevertheless because gvl_align_data() does not touch the actual data.
 Another possible source of bugs is the wxPython part of wxNVIZ because
 it uses ctypes. Does it make sense to test the old Tcl/Tk nviz and see
 if volume display works there?
 
 yes, I should be able to run it with the old tcltk - that would be a good 
 test,
 
 Helena
 
 
 Markus M
 
 
 Michael
 
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 
 voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
 fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
 www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 
 
 
 
 
 
 
 On Feb 13, 2013, at 2:20 PM, grass-dev-requ...@lists.osgeo.org
 wrote:
 
 From: Martin Landa landa.mar...@gmail.com
 Subject: Re: [GRASS-dev] GRASS GIS 6.4.3RC2 released
 Date: February 13, 2013 1:32:11 PM MST
 To: Helmut Kudrnovsky hel...@web.de
 Cc: grass-dev@lists.osgeo.org
 
 
 Hi,
 
 2013/2/3 Martin Landa landa.mar...@gmail.com:
 
 since it's more than a month ago now, what about another another RC or
 release?
 
 
 agreed. After RC3 should come ideally final release.
 
 
 sorry for bringing this issue back. We have 2 RCs released, RC2 is
 almost 2(!) month old. I don't see any blocker in trac [1], even
 nothing noted on the dev's wiki [2]. Is there any blocker, if so
 please collect them in trac or at least note them on trac page [2].
 Currently I am afraid that we have no clear idea what is the status of
 critical issues which have been reported within various mails in
 various threads by various persons.
 
 Martin
 
 [1]
 http://trac.osgeo.org/grass/query?status=newstatus=assignedstatus=reopenedgroup=typeorder=prioritypriority=blockerpriority=criticalmilestone=6.4.3milestone=6.4.2milestone=6.4.1milestone=6.4.0
 [2] http://trac.osgeo.org/grass/wiki/Grass6Planning#GRASS6.4.3
 
 --
 Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~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] formatting expressions for r.mapcalc in GRASS6.4.3

[Helena Mitasova]

 The wxGUI command line has its own rules (see shlex.split()
 in the Python library documentation).

running mapcalc through the wxGUI command line is where the students have 
problems in winGRASS 
(but it works on Mac)

Helmut - can you please try this commands with data in nc_spm_08 
just pasting them in command console in wingrass?
- I had them originally in double quotes but that did not work for any 
expression,
without quotes this works:

g.region rast=landuse96_28m -p
r.mapcalc 
ndvi3=float(lsat7_2002_40-lsat7_2002_30)/float(lsat7_2002_40+lsat7_2002_30)

but the students complain that the ones with if statements don't
(they say that they tried to put spaces around = and some other modifications 
but they keep getting syntax error):

r.mapcalc urban1_30m=if(landuse96_28m==1,1,0)+if(landuse96_28m==2,2,0)
r.mapcalc urban2_30m=if(landuse96_28m==1 || 
landuse96_28m==2,landuse96_28m,null()
g.region rast=elevation -p
r.mapcalc MASK=if((elevation100  elevation60)  (landuse96_28m==1 || 
landuse96_28m==2),1,null())

so I am trying to figure out how to make r.mapcalc work in wingrass in command 
console
(all of these expressions work if entered through the map calculator GUI)

r.mapcalc is one of the most used commands so I think it is important to have 
it running reliably
and it may be just a matter of special instrcutions for wingrass in the manual 
page,

Thank you, Helena

 
 Map names can be quoted with either single or double quotes, so if the
 expression is quoted with double quotes you can quote map names with
 single quotes and vice-versa.
 
 -- 
 Glynn Clements gl...@gclements.plus.com
 ___
 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] formatting expressions for r.mapcalc in GRASS6.4.3

[Helena Mitasova]

Anna,

you are right - it is the commands that include || that give an error,
I finally had time to go through all of the examples in the lab  - all
the other ones work so far. Is this something that can be fixed?

Helena

On Thu, Feb 14, 2013 at 12:25 PM, Anna Kratochvílová
kratocha...@gmail.com wrote:
 On Thu, Feb 14, 2013 at 5:41 PM, Helena Mitasova hmit...@ncsu.edu wrote:


 The wxGUI command line has its own rules (see shlex.split()
 in the Python library documentation).

 running mapcalc through the wxGUI command line is where the students have 
 problems in winGRASS
 (but it works on Mac)

 Helmut - can you please try this commands with data in nc_spm_08
 just pasting them in command console in wingrass?
 - I had them originally in double quotes but that did not work for any 
 expression,
 without quotes this works:

 g.region rast=landuse96_28m -p
 r.mapcalc 
 ndvi3=float(lsat7_2002_40-lsat7_2002_30)/float(lsat7_2002_40+lsat7_2002_30)

 but the students complain that the ones with if statements don't
 (they say that they tried to put spaces around = and some other 
 modifications but they keep getting syntax error):

 r.mapcalc urban1_30m=if(landuse96_28m==1,1,0)+if(landuse96_28m==2,2,0)
 r.mapcalc urban2_30m=if(landuse96_28m==1 || 
 landuse96_28m==2,landuse96_28m,null()
 g.region rast=elevation -p
 r.mapcalc MASK=if((elevation100  elevation60)  (landuse96_28m==1 || 
 landuse96_28m==2),1,null())

 One problem is caused by the pipe character. It seems that it is taken
 as the end of a command and the rest is evaluated as another command.
 I noticed the same problem when I wanted to execute a command
 (run_command) with option separator = | from gui. It's a general
 problem both in grass 6 and 7.

 Anna


 so I am trying to figure out how to make r.mapcalc work in wingrass in 
 command console
 (all of these expressions work if entered through the map calculator GUI)

 r.mapcalc is one of the most used commands so I think it is important to 
 have it running reliably
 and it may be just a matter of special instrcutions for wingrass in the 
 manual page,

 Thank you, Helena


 Map names can be quoted with either single or double quotes, so if the
 expression is quoted with double quotes you can quote map names with
 single quotes and vice-versa.

 --
 Glynn Clements gl...@gclements.plus.com
 ___
 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



-- 
Helena Mitasova
Associate Professor
Department of Marine, Earth and Atmospheric Sciences
North Carolina State University
1125 Jordan Hall
NCSU Box 8208
Raleigh, NC 27695-8208
http://skagit.meas.ncsu.edu/~helena/

email: hmit...@ncsu.edu
ph: 919-513-1327 (no voicemail)
fax 919 515-7802
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS GIS 6.4.3RC2 released

[Helena Mitasova]

Martin,

I think that #1736 is still unresolved and I am afraid that the latest changes 
might have made it worse, I still have a working version in GRASS6.5 which I 
have not updated for a while but the most recent version in 6.4.3 seems to be 
crashing unpredictably,
similar to what it used to do couple years ago in old nviz (see #803). I will 
try to update and test again to see where it stands
but it may be now crashing on linux as well. 

here is the 2d and 3d raster that I have used for testing, it now crashes for 
isosurface 15 and 16 but works for isosurface 17
(my GRASS6.5 works with it without any trouble for any isosurface)
http://skagit.meas.ncsu.edu/~helena/grasswork/JR_2008_ALL.asci
http://skagit.meas.ncsu.edu/~helena/grasswork/JR_7408MR_2m_t70_nd0.asci
I am doing my testing on Mac OSX10.6 and Mac OSX10.8
(I totally agree with Markus M and Tomas Paudits that ogsf needs to be 
rewritten but so far I did not have much luck 
finding anybody with the right expertise to do it).

I think that #1801was fixed thanks to Markus M, but I did not have time to 
test. here is a 3d raster with nulls that was causing problems if somebody 
wants to test
http://skagit.meas.ncsu.edu/~helena/grasswork/JR_7408MR_2m_t70.asci

I can try #1784 on our Windows machines to see whether we have the same problem.
I am not sure about the rest of the critical bugs. The rest of the issues that 
I posted in emails was not critical,
mostly confusing features and most of them are fixed thanks to Anna,

Helena  





Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Feb 13, 2013, at 3:32 PM, Martin Landa wrote:

 Hi,
 
 2013/2/3 Martin Landa landa.mar...@gmail.com:
 since it's more than a month ago now, what about another another RC or
 release?
 
 agreed. After RC3 should come ideally final release.
 
 sorry for bringing this issue back. We have 2 RCs released, RC2 is
 almost 2(!) month old. I don't see any blocker in trac [1], even
 nothing noted on the dev's wiki [2]. Is there any blocker, if so
 please collect them in trac or at least note them on trac page [2].
 Currently I am afraid that we have no clear idea what is the status of
 critical issues which have been reported within various mails in
 various threads by various persons.
 
 Martin
 
 [1] 
 http://trac.osgeo.org/grass/query?status=newstatus=assignedstatus=reopenedgroup=typeorder=prioritypriority=blockerpriority=criticalmilestone=6.4.3milestone=6.4.2milestone=6.4.1milestone=6.4.0
 [2] http://trac.osgeo.org/grass/wiki/Grass6Planning#GRASS6.4.3
 
 -- 
 Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~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 wiki main page colorbrewer tool

[Helena Mitasova]

 
 
 
 ps- if anyone at the sprint is looking for a nice task, building
 a wxPy color wizard around the ColorBrewer tables might be fun:
  http://colorbrewer2.org/
 I've got their data reduced to some csv text files from a past
 attempt, and AFAIR the licensing on those was compatible w/ GPL.
 (it's worth looking that up again, but I wouldn't have bothered
 starting on it if it wasn't) I think QGIS has something similar
 already?

Hamish, if there is no time or interest to do this at the sprint (fixing the 
bugs for GRASS6.4.3 release are probably 
higher priority) maybe you can add it into the cartography enhancements topic 
for GSoC2013
http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2013.
Given the max. number of classes supported - 12 and less for some color 
schemes, supposedly you cannot distinguish more,
it would be nice to add a button for generating discrete colors for continuous 
data, such as elevation,
for a given number of classes - it can be done now, but as far as I know you 
would have to reclass your raster first.

Helena

 ___
 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 wiki main page colorbrewer tool

[Helena Mitasova]

On Feb 3, 2013, at 11:17 PM, Hamish wrote:

 Hamish wrote:
 ps- if anyone at the sprint is looking for a nice task, building
 a wxPy color wizard around the ColorBrewer tables might be fun:
 http://colorbrewer2.org/
 I've got their data reduced to some csv text files from a past
 attempt, and AFAIR the licensing on those was compatible w/ GPL.
 
 (you can also download the excel spreadsheet from their site directly)
 
 Helena wrote:
 Hamish, if there is no time or interest to do this at the
 sprint (fixing the bugs for GRASS6.4.3 release are probably
 higher priority)
 
 fwiw one of my strong wishes for 6.4.3 is to convert the wxPsMap
 eps symbols into proper grass symbols and use the 'symbol' command
 with them. I don't really want to release the current way and
 have to keep support for the duplicated eps decorations forever.
 
 
 maybe you can add it into the cartography enhancements topic
 for GSoC2013
 http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2013.
 
 that's fine too.
 
 a minor note about one of the suggestions already there: Google
 only accepts projects which are primarily coding in nature to
 SoC. So graphics design, website overhaul, and documentation
 projects while very important and often badly needed for FOSS
 projects are actually beyond the scope of the program.

this topic should cover the programming part, not the design of symbology. We 
need to have
d.rast.leg and d.vect.leg - even if it is just single color for a feature like 
water
(like we have r.colors and v.colors - I was thrilled to discover v.colors, 
thanks a lot for that,
e.g. the streets map with speed limits in the nc data set looks great and I see 
the trick with the legend,
but that is not a solution for vector data in general)
We need better handling of scale bar and everything needs to be more robust.
I looked at the cartographic composer and recommended it to students but 
we are still behind other packages in terms of producing nice maps in a 
convenient way -
everything (or most of it ) is there, it just needs more work. That is the part 
of GRASS I get
most complaints about, although some students produce beautiful maps with GRASS.

 IIUC Google's Code In for high school students allows those
 sorts of things as challenges though. (at perhaps the cost
 of more mentoring time needed)
 
 Given the max. number of classes supported - 12 and less for
 some color schemes, supposedly you cannot distinguish more,
 
 I haven't read the academic paper behind the site (I assume
 there is one based on how they got their funding), so I'm not
 sure if the colors were selected algorithmically, by educated
 eye, or a mix of both. If there's a formula we could tap into
 (like r.watershed has), then all the better for it.
 
 it would be nice to add a button for generating discrete
 colors for continuous data, such as elevation,
 for a given number of classes - it can be done now, but as
 far as I know you would have to reclass your raster first.
 
 Even though it is very popular in other widely used software,
 I've always tried to steer away from applying discrete classes
 to continuous raster data. IMO it deserves it's own chapter
 in How to lie with statistics*, as it is very easy to fool
 both yourself and others about what the data says based on the
 ultimately arbitrary choice (as far as nature is concerned)
 of intervals. I realize that it is also difficult for the human
 eye to follow a constant hue and isolines can be useful, so
 typically what I try to do for those as a compromise is have the
 continuous gradient colors in the back ground with contour lines
 of the same data over the top.

I totally agree with you on this but there is some research that says otherwise
and there are some situations when the discrete maps simply work better.
I can see it when we have the GRASS and ArcGIS maps side-by-side,
our continuous color ramps are certainly better than the grey ramp for 
continuous
data in ArcGIS, but the discrete color ramps produced by some ArcGIS modules
are often more readable although they can hide some detail - I try to deliver 
that 
message all the time and we use relief shading a lot to avoid hiding features. 
It very much depends on the data - it would be a  long discussion. 
The precipitation example in GRASSbook - Fig.6.17 is a good example where the 
continuous
color ramp did not work, even when it was in color you could not see the 
pattern.
 
 [*] actually I think there's already a book on it called How to lie with 
 maps

yes there is famous book about it by Monmonier (#2 on Amazon in Cartography)
 
 If you really want to do it though there's no reason to reclass,
 see the r.colors.stddev script for an example. Just make two
 rules at the same value right next to each other. e.g., from
 r.colors.stddev:
 
 r.colors $GIS_OPT_INPUT color=rules  EOF
   0% black
   $MEAN_MINUS_3STDEV black
   $MEAN_MINUS_3STDEV red
   $MEAN_MINUS_2STDEV red
   $MEAN_MINUS_2STDEV yellow
   

Re: [GRASS-dev] formatting expressions for r.mapcalc in GRASS6.4.3

[Helena Mitasova]

On Feb 2, 2013, at 8:27 AM, Glynn Clements wrote:

 
 Helena Mitasova wrote:
 
 Over the years there have been changes in the formatting of r.mapcalc 
 expressions
 and it appears the currently there is no single way that would work 
 everywhere
 (you either need quotes or it does not work with quotes and in GRASS6.4.3 
 the space around = is not necessary).
 I have tried to summarize our experience on MSWindows, Mac and linux here
 
 http://courses.ncsu.edu/mea582/common/GIS_anal_grass/mapcalcformats.html
 
 My question about the document above - is this how it should work?
 
 From the command line, the most portable approach is to use:
 
   r.mapcalc outmap = whatever
 
 That should work in any version on any platform.

Glynn, Markus,

thanks for your answer - I have used your suggested format for years and that 
is how we have it in the book
and it works in linux shell and on my mac in command console as well - I will 
add it to my little how to run mapcalc document
given that it is still valid. 
But it does not work in command console in windows7, I had to remove the quotes 
to get it run. 
I should get more feedback from students by tuesday and I will try 
it in the lab again and post the error message - last two semesters, I guess 
since GRASS6.4.3svn there were more troubles 
with r.mapcalc than before, although the command console otherwise works really 
great.

BTW when you look at the Notes in the manual, the suggestion there is to put 
single quotes around the expression (right side of the equation), while the 
section about raster map layer names explains that putting your expression in 
double quotes will
interpret it as a raster map name and the floating point section has the quotes 
as used in the book so if somebody is new to GRASS 
it is easy to get confused. 

Helena
 
 GRASS 6 simply concatenates all arguments with a space between each
 one, and uses the result as the expression.
 
 GRASS 7 uses G_parser():
 
   Usage:
r.mapcalc [expression=string] [file=name] [--overwrite] [--verbose]
  [--quiet]
 
 The above example is shorthand for:
 
   r.mapcalc expression=outmap = whatever
 
 For this to work, the expression must be a single argument (i.e. 
 quoted), and there must be a space between the output map and the
 first =. Using:
 
   r.mapcalc outmap=whatever
 
 would result in G_parser() complaining that outmap isn't a
 recognised option name.
 
 -- 
 Glynn Clements gl...@gclements.plus.com

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

Re: [GRASS-dev] does GRASS 7 for Mac compile yet?

[Helena Mitasova]

Anna,

we just started to dig into this with Michael about two days ago. I believe the 
errors started to pop-up with the introduction
of g.gui.* - all of these commands have it and at the time when g.gui.* was 
being added, the list of modules with this error
has been expanding. The error messages below are from Michael, but I get 
exactly the same ones - see the error for mapswipe.
Before g.gui was introduced, mapswipe did not produce an error. And this is on 
MacOSX10.6 and MacOSX10.8.
BUT for me on 10.6, in spite of the error message, most of these modules 
actually run OK - I tried mapswipe, psmap,vdigit,
and wxnviz and m.nviz.image run too. Perhaps others can test the rest of the 
modules.
So it may be just a manual page or something like that.
The only thing that does not run is animation - I will email about it 
separately because it may be a separate issue.

Helena

Errors in:

/Users/Shared/grass_dev/grass70_dev/gui/wxpython/animation
/Users/Shared/grass_dev/grass70_dev/gui/wxpython/mapswipe
/Users/Shared/grass_dev/grass70_dev/gui/wxpython/gmodeler
/Users/Shared/grass_dev/grass70_dev/gui/wxpython/rlisetup
/Users/Shared/grass_dev/grass70_dev/gui/wxpython/psmap
/Users/Shared/grass_dev/grass70_dev/gui/wxpython/dbmgr
/Users/Shared/grass_dev/grass70_dev/gui/wxpython/vdigit
/Users/Shared/grass_dev/grass70_dev/gui/wxpython/iclass

for each of those I get the same error like this

cmb-macbookpro:~ cmbarton$ 
/Users/Shared/grass_dev/grass70_dev/gui/wxpython/animation
-bash: /Users/Shared/grass_dev/grass70_dev/gui/wxpython/animation: is a 
directory
cmb-macbookpro:~ cmbarton$ cd 
/Users/Shared/grass_dev/grass70_dev/gui/wxpython/animation
cmb-macbookpro:animation cmbarton$ 
cmb-macbookpro:animation cmbarton$ make
make 
/Users/Shared/grass_dev/grass70_dev/dist.x86_64-apple-darwin12.2.0/docs/html/g.gui.animation.html
GISRC=/Users/Shared/grass_dev/grass70_dev/dist.x86_64-apple-darwin12.2.0/demolocation/.grassrc70
 GISBASE=/Users/Shared/grass_dev/grass70_dev/dist.x86_64-apple-darwin12.2.0 
PATH=/Users/Shared/grass_dev/grass70_dev/dist.x86_64-apple-darwin12.2.0/bin:/Users/Shared/grass_dev/grass70_dev/dist.x86_64-apple-darwin12.2.0/bin:$PATH
 
PYTHONPATH=/Users/Shared/grass_dev/grass70_dev/dist.x86_64-apple-darwin12.2.0/etc/python:/Users/Shared/grass_dev/grass70_dev/dist.x86_64-apple-darwin12.2.0/etc/python:$PYTHONPATH
 
DYLD_LIBRARY_PATH=/Users/Shared/grass_dev/grass70_dev/dist.x86_64-apple-darwin12.2.0/bin:/Users/Shared/grass_dev/grass70_dev/dist.x86_64-apple-darwin12.2.0/lib:/Users/Shared/grass_dev/grass70_dev/dist.x86_64-apple-darwin12.2.0/lib:
 LC_ALL=C 
/Users/Shared/grass_dev/grass70_dev/dist.x86_64-apple-darwin12.2.0/scripts/g.gui.animation
 --html-description  /dev/null | grep -v '/body\|/html'  
g.gui.animation.tmp.html
Traceback (most recent call last):
 File 
/Users/Shared/grass_dev/grass70_dev/dist.x86_64-apple-darwin12.2.0/scripts/g.gui.animation,
 line 45, in module
   import wx
ImportError: No module named wx
make[1]: *** [g.gui.animation.tmp.html] Error 1
rm g.gui.animation.tmp.html

cpe-098-026-069-175:mapswipe helena$ make
make 
/Users/helena/grassdev7/grass_trunk/dist.x86_64-apple-darwin10.8.0/docs/html/g.gui.mapswipe.html
GISRC=/Users/helena/grassdev7/grass_trunk/dist.x86_64-apple-darwin10.8.0/demolocation/.grassrc70
 GISBASE=/Users/helena/grassdev7/grass_trunk/dist.x86_64-apple-darwin10.8.0 
PATH=/Users/helena/grassdev7/grass_trunk/dist.x86_64-apple-darwin10.8.0/bin:/Users/helena/grassdev7/grass_trunk/dist.x86_64-apple-darwin10.8.0/bin:$PATH
 
PYTHONPATH=/Users/helena/grassdev7/grass_trunk/dist.x86_64-apple-darwin10.8.0/etc/python:/Users/helena/grassdev7/grass_trunk/dist.x86_64-apple-darwin10.8.0/etc/python:$PYTHONPATH
 
DYLD_LIBRARY_PATH=/Users/helena/grassdev7/grass_trunk/dist.x86_64-apple-darwin10.8.0/bin:/Users/helena/grassdev7/grass_trunk/dist.x86_64-apple-darwin10.8.0/lib:/Users/helena/grassdev7/grass_trunk/dist.x86_64-apple-darwin10.8.0/lib:
 LC_ALL=C 
/Users/helena/grassdev7/grass_trunk/dist.x86_64-apple-darwin10.8.0/scripts/g.gui.mapswipe
 --html-description  /dev/null | grep -v '/body\|/html'  
g.gui.mapswipe.tmp.html
Traceback (most recent call last):
  File 
/Users/helena/grassdev7/grass_trunk/dist.x86_64-apple-darwin10.8.0/scripts/g.gui.mapswipe,
 line 51, in module
import  wx
  File 
/var/tmp/wxWidgets/wxWidgets-13~231/2.6/DSTROOT/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode/wx/__init__.py,
 line 45, in module

  File 
/var/tmp/wxWidgets/wxWidgets-13~231/2.6/DSTROOT/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode/wx/_core.py,
 line 4, in module
ImportError: 
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode/wx/_core_.so:
 no appropriate 64-bit architecture (see man python for running in 32-bit 
mode)
make[1]: *** [g.gui.mapswipe.tmp.html] Error 1
rm g.gui.mapswipe.tmp.html
make: *** [guiscript] Error 2

Helena Mitasova
Associate

Re: [GRASS-dev] animations on Mac problem

[Helena Mitasova]

This is the error that I get when I try to run the animation (on MacOSX10.6 - I 
will try on 10.8 as well later on):

Helena

Traceback (most recent call last):
  File /Users/helena/grassdev7/grass_trunk/dist.x86_64
-apple-darwin10.8.0/etc/gui/wxpython/lmgr/frame.py, line
1397, in OnAnimationTool

frame = AnimationFrame(parent = self)
  File /Users/helena/grassdev7/grass_trunk/dist.x86_64
-apple-darwin10.8.0/etc/gui/wxpython/animation/frame.py,
line 54, in __init__

self.animationPanel = AnimationsPanel(self, self.windows,
initialCount = MAX_COUNT)
  File /Users/helena/grassdev7/grass_trunk/dist.x86_64
-apple-darwin10.8.0/etc/gui/wxpython/animation/frame.py,
line 256, in __init__

w = AnimationWindow(self)
  File /Users/helena/grassdev7/grass_trunk/dist.x86_64
-apple-
darwin10.8.0/etc/gui/wxpython/animation/mapwindow.py, line
108, in __init__

self.bitmap = wx.EmptyBitmap(0, 0)
  File /var/tmp/wxWidgets/wxWidgets-13~231/2.6/DSTROOT/Syst
em/Library/Frameworks/Python.framework/Versions/2.6/Extras/l
ib/python/wx-2.8-mac-unicode/wx/_gdi.py, line 726, in
EmptyBitmap
wx._core
.
PyAssertionError
:
C++ assertion m_hBitmap failed at
../src/mac/carbon/bitmap.cpp(242) in Create(): Unable to
create CGBitmapContext context


Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Jan 31, 2013, at 6:15 AM, Anna Kratochvílová wrote:

 On Thu, Jan 31, 2013 at 11:47 AM, Luca Delucchi lucadel...@gmail.com wrote:
 2013/1/31 Thomas Adams - NOAA Federal thomas.ad...@noaa.gov:
 All,
 
 
 Hi Thomas
 
 I'm a Mac user in addition to Linux. I'm going to have more free time
 starting in a few weeks. I'd be happy to step-up my use of GRASS 7 for
 testing. Just let me know what I can do. I'm moving from the U.S. to
 Melbourne, Australia in a couple of weeks!
 
 
 thanks for your support, you could start to read from here [0].
 Michael and William could you update the instructions of this file [1]
 for GRASS7 and move them to the wiki page please?
 
 
 Michael, it would be helpful to summarize all the problems. It is very
 confusing at least for me. It is not clear which problems are related
 to the introduction of g.gui.* modules, wxPython version and so on
 because the information is in many threads.
 
 Thanks,
 Anna
 
 Cheers,
 Tom
 
 
 [0] http://grasswiki.osgeo.org/wiki/Compiling_on_MacOSX
 [1] 
 http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/macosx/ReadMe.rtf?format=raw
 
 
 --
 ciao
 Luca
 
 http://gis.cri.fmach.it/delucchi/
 www.lucadelu.org
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev
 ___
 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] animations on Mac problem

[Helena Mitasova]

I am happy to report that in grass7 on Mac10.8 the animations RUN!
Michael, perhaps you should ignore the error message from the compilation and 
try to run the modules,
they seem to be OK on 10.8, at least those that I tried.

This is before your change Anna,

Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Jan 31, 2013, at 11:58 AM, Anna Kratochvílová wrote:

 On Thu, Jan 31, 2013 at 5:09 PM, Helena Mitasova hmit...@ncsu.edu wrote:
 This is the error that I get when I try to run the animation (on MacOSX10.6 
 - I will try on 10.8 as well later on):
 
 Could you test it again, I've just committed a small change which could help.
 
 Anna
 
 
 Helena
 
 Traceback (most recent call last):
  File /Users/helena/grassdev7/grass_trunk/dist.x86_64
 -apple-darwin10.8.0/etc/gui/wxpython/lmgr/frame.py, line
 1397, in OnAnimationTool
 
 frame = AnimationFrame(parent = self)
  File /Users/helena/grassdev7/grass_trunk/dist.x86_64
 -apple-darwin10.8.0/etc/gui/wxpython/animation/frame.py,
 line 54, in __init__
 
 self.animationPanel = AnimationsPanel(self, self.windows,
 initialCount = MAX_COUNT)
  File /Users/helena/grassdev7/grass_trunk/dist.x86_64
 -apple-darwin10.8.0/etc/gui/wxpython/animation/frame.py,
 line 256, in __init__
 
 w = AnimationWindow(self)
  File /Users/helena/grassdev7/grass_trunk/dist.x86_64
 -apple-
 darwin10.8.0/etc/gui/wxpython/animation/mapwindow.py, line
 108, in __init__
 
 self.bitmap = wx.EmptyBitmap(0, 0)
  File /var/tmp/wxWidgets/wxWidgets-13~231/2.6/DSTROOT/Syst
 em/Library/Frameworks/Python.framework/Versions/2.6/Extras/l
 ib/python/wx-2.8-mac-unicode/wx/_gdi.py, line 726, in
 EmptyBitmap
 wx._core
 .
 PyAssertionError
 :
 C++ assertion m_hBitmap failed at
 ../src/mac/carbon/bitmap.cpp(242) in Create(): Unable to
 create CGBitmapContext context
 
 
 Helena Mitasova
 Associate Professor
 Department of Marine, Earth, and Atmospheric Sciences
 2800 Faucette Drive, Rm. 1125 Jordan Hall
 North Carolina State University
 Raleigh, NC 27695-8208
 hmit...@ncsu.edu
 
 All electronic mail messages in connection with State business which are 
 sent to or received by this account are subject to the NC Public Records Law 
 and may be disclosed to third parties.”
 
 On Jan 31, 2013, at 6:15 AM, Anna Kratochvílová wrote:
 
 On Thu, Jan 31, 2013 at 11:47 AM, Luca Delucchi lucadel...@gmail.com 
 wrote:
 2013/1/31 Thomas Adams - NOAA Federal thomas.ad...@noaa.gov:
 All,
 
 
 Hi Thomas
 
 I'm a Mac user in addition to Linux. I'm going to have more free time
 starting in a few weeks. I'd be happy to step-up my use of GRASS 7 for
 testing. Just let me know what I can do. I'm moving from the U.S. to
 Melbourne, Australia in a couple of weeks!
 
 
 thanks for your support, you could start to read from here [0].
 Michael and William could you update the instructions of this file [1]
 for GRASS7 and move them to the wiki page please?
 
 
 Michael, it would be helpful to summarize all the problems. It is very
 confusing at least for me. It is not clear which problems are related
 to the introduction of g.gui.* modules, wxPython version and so on
 because the information is in many threads.
 
 Thanks,
 Anna
 
 Cheers,
 Tom
 
 
 [0] http://grasswiki.osgeo.org/wiki/Compiling_on_MacOSX
 [1] 
 http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/macosx/ReadMe.rtf?format=raw
 
 
 --
 ciao
 Luca
 
 http://gis.cri.fmach.it/delucchi/
 www.lucadelu.org
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev
 ___
 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

[GRASS-dev] formatting expressions for r.mapcalc in GRASS6.4.3

[Helena Mitasova]

Over the years there have been changes in the formatting of r.mapcalc 
expressions
and it appears the currently there is no single way that would work everywhere
(you either need quotes or it does not work with quotes and in GRASS6.4.3 the 
space around = is not necessary).
I have tried to summarize our experience on MSWindows, Mac and linux here

http://courses.ncsu.edu/mea582/common/GIS_anal_grass/mapcalcformats.html

My question about the document above - is this how it should work?

If yes, should we include something like this in the manual? 

For example, the ndvi example in the manual would not run from the command 
console on MSwindows
and the text talking about running r.mapcalc non-interactively and 
interactively, refers to the old way
of running GRASS before there was any GUI. 
The Note about running r.mapcalc on command line can also cause some confusion 
- this is how that example works in the shell

GRASS 6.4.3RC2 (nc_spm_08):~  r.mapcalc result = 'elevation * 2'
 100%
GRASS 6.4.3RC2 (nc_spm_08):~  r.mapcalc result=elevation*2
 100%
GRASS 6.4.3RC2 (nc_spm_08):~  r.mapcalc
Enter expressions, end when done.
mapcalc result = 'elevation * 2'
Illegal filename. Character   not allowed.
Invalid map elevation * 2
mapcalc result=elevation*2
mapcalc end
100%

GRASS7 is a different story, but examples in the manual for grass7 may need 
testing and revision too.

Helena


Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

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

[GRASS-dev] GRASS6.4.3RC2 issues

[Helena Mitasova]

We are running GRASS6.4.3RC2 on Windows and Mac (50+ students on their own 
computers)
and so far we had few small issues with wxGUI which are causing some confusion.
Please let me know for which it would be useful to file a bug report.

- in wxnviz for draped vector lines after I change the line width e.g. to 0,
the displayed line goes back to wider line each time something else is drawn
(e.g. fringe or view is changed) but the number is still set to 0.
It shows in this video capture (go past minute 1:00, we set line width to 0,
it is drawn as thin line but when we start working with points it goes back to 
default width).
http://courses.ncsu.edu/mea582/common/media/03/sc_wxnviz2_edit2.mov
I am wondering whether this is a bug or I am missing something

- in 2D display legend is now much better than ever before, but
when the d.legend command is run from command line
it appears that the legend parameters are not carried over to the GUI
and need to be entered in GUI again - is this the desired behavior?
For example in the sequence
# Convert from vector to raster
in this assignment
http://courses.ncsu.edu/mea582/common/GIS_anal_grass/GIS_Anal_grdataS2.html
this command does not work properly from the command line
d.legend streets_speed_30m at=5,30,2,5 use=25,35,45,55,65
Also, if there is a legend already present, Add legend opens the legend GUI
behind the map display window (where it is of course hard to find)
I think this issue has already been discussed before
BTW, the legend now runs on Mac in 3d wxnviz well.

- g.remove run from command console thinks I am in PERMANENT rather than the 
current mapset

g.remove rast=elev_lidrural1mr_1m
Removing raster elev_lidrural1mr_1m
WARNING: Raster map elev_lidrural1mr_1m not found
WARNING: elev_lidrural1mr_1m nothing removed

from linux shell it works
GRASS 6.4.3RC2 (nc_spm_08):~  g.remove rast=elev_lidruralmr_1m
Removing raster elev_lidruralmr_1m

- r3.in.ascii needs a fix for handling of input parameters, see bug report
http://trac.osgeo.org/grass/ticket/1801#comment:4

Finally, among the first questions I get about GRASS is how to add legend for 
vector data layer -
is there any? If not, perhaps that is something for GSoC along with numerous
other cartography related capabilities (e.g. expand the symbology)
to add to either display or cartographic composer.

thank you for any response, fixes, assistance, hopefully we will get 
GRASS6.4.3RC2 well tested

Helena


Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Jan 19, 2013, at 3:53 PM, GRASS GIS wrote:

 #1854: d.legend kills wx monitor started with d.mon
 --+-
  Reporter:  huhabla  |   Owner:  grass-dev@…  
  Type:  defect   |  Status:  closed   
  Priority:  major|   Milestone:  7.0.0
 Component:  Display  | Version:  svn-trunk
 Resolution:  fixed|Keywords:  wx, d.mon, d.legend  
  Platform:  Linux| Cpu:  x86-64   
 --+-
 Changes (by huhabla):
 
  * status:  new = closed
  * resolution:  = fixed
 
 
 Comment:
 
 It works!
 Many thanks for the quick fix.
 
 -- 
 Ticket URL: http://trac.osgeo.org/grass/ticket/1854#comment:2
 GRASS GIS http://grass.osgeo.org
 
 ___
 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

[GRASS-dev] GRASS GIS 2012 report

[Helena Mitasova]

I have prepared a draft report about GRASS GIS for the OSGEO report 2012. It is 
based on the report submitted by Markus in 2011,
I just updated it with the 2012 accomplishments and events. Please add your 
activities and whatever I have missed, modify, and fix,
the report is here
http://wiki.osgeo.org/wiki/GRASS_GIS_Report_2012

Thank you,

Helena

Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 


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

Re: [GRASS-dev] release planning and no volume display on Mac - Any info on where crash happens?

[Helena Mitasova]

On Jan 11, 2013, at 2:48 PM, Anna Kratochvílová wrote:

 Hi Michael,
 
 On Mon, Jan 7, 2013 at 7:57 AM, Michael Barton michael.bar...@asu.edu wrote:
 So I found a change that would make volumes visible again a week ago. Anyone 
 have any thoughts about this? Do we need the function/procedure that sets 
 the memory pointer for volume displays? Or can we simply get rid of it? Is 
 it needed for Linux? Windows? Any thoughts about what happens without it?
 
 I can confirm that removing those two lines does no harm for me
 (Linux). However it's clear that we cannot just leave them out without
 understanding why they are there. Can anyone (for example Glynn) think
 of a reason why this code is crashing on Mac and not on Linux (no idea
 about Windows)?

I just tested it on Windows 7 with WinGRASS6.4.3RC2 and I am happy to report 
that it works OK
 - both isosurfaces and crossections.

However, in the same WinGRASS6.4.3.RC2 there is a problem with the path to 
cellheader in G3d_read_window,
so r3.info and g.region rast3d=myvoxel gives an error that the region is 
invalid. 

Also, I finally got a laptop with MacOSX10.8 and I can confirm that in 
GRASS6.4.3RC2 binary
posted Michael isusrfaces crash wxGUI. I will try to compile myself but I 
expect the result
to be the same given that it crashed for William as well.

Helena 

 And why removing of realloc helps?
 
 Regards,
 Anna
 
 
 Cheers
 Michael
 
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 
 voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
 fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
 www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 
 
 
 
 
 
 
 On Jan 2, 2013, at 11:22 PM, Michael Barton michael.bar...@asu.edu wrote:
 
 GREAT NEWS!
 
 Commenting out both gvl_align_data lines (#684 and #1009) in gvl_calc_c 
 makes this work. Both slices and isosurfaces display and do not crash. I 
 don't know if there would be a problem with larger files or not. But this 
 is finally functional again.
 
 BUT the command you sent does NOT work. It gives a segmentation fault error:
 
 m.nviz.image elevation_map=JR_2008_ALL_dem@test3d -a mode=fine 
 resolution_fine=6 color_map=JR_2008_ALL_dem@test3d 
 volume=jr_7408MR_2m_t70@test3d volume_shading=gouraud volume_resolution=1 
 volume_position=0,0,20 isosurf_level=1:18.0 
 isosurf_color_map=jr_7408MR_2m_t70@test3d isosurf_transparency_value=0 
 slice=1:x,1:z 
 slice_position=0.00,1.00,0.52,1.00,0.00,1.00,0.25,0.72,0.08,1.00,0.00,1.00
  slice_transparency=0,0 position=0.84,0.16 height=356 perspective=20 
 twist=0 zexag=5.00 focus=569,593,28 light_position=0.68,0.68,0.80 
 light_brightness=80 light_ambient=20 light_color=255:255:255 
 output=jrvoltest format=tif size=798,545
 Loading raster map JR_2008_ALL_dem@test3d...
 100%
 Loading raster map JR_2008_ALL_dem@test3d...
 100%
 Translating colors from raster map JR_2008_ALL_dem@test3d...
 100%
 Loading 3d raster map jr_7408MR_2m_t70@test3d...
 Segmentation fault: 11
 
 
 Also, somewhere there is a bug somewhere that is sending progress bar text 
 to the screen for any nviz activity (GRASS_INFO_PERCENT: 0...)
 
 So now we have some kind of workaround. I don't know if there are any other 
 down sides to bypassing this memory reallocation, but this is a good start 
 on fixing this finally. Thanks Anna and Helena.
 
 Michael
 
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 
 voice:480-965-6262 (SHESC), 480-727-9746 (CSDC)
 fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
 www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 On Jan 2, 2013, at 10:45 PM, Helena Mitasova hmit...@ncsu.edu
 wrote:
 
 Michael,
 
 what you describe sounds as if you had only one depth layer so let us 
 check first that the 3D region is right.
 If the 3d region is set to the provided 3d raster given here
 http://skagit.meas.ncsu.edu/~helena/grasswork/JR_7408MR_2m_t70.asci
 http://skagit.meas.ncsu.edu/~helena/grasswork/JR_2008_ALL.asci (reference 
 2d raster)
 it should look like this
 
 GRASS 6.4.3svn (nc_spm_05):~  g.region -p3
 projection: 99 (Lambert Conformal Conic)
 zone:   0
 datum:  nad83
 ellipsoid:  a=6378137 es=0.006694380022900787
 north:  250690
 south:  249502
 west:   912791
 east:   913931
 top:64.
 bottom: 0.
 nsres:  2
 nsres3: 2
 ewres:  2
 ewres3: 2
 tbres:  8
 rows:   594
 rows3:  594
 cols:   570
 cols3:  570
 depths: 8
 
 can you then try to run the following command (please adjust the names of 
 the 2d and 3d rasters to your actual names)
 
 m.nviz.image elevation_map=JR_2008_ALL@Baseline_JR -a mode=fine

Re: [GRASS-dev] release planning and no volume display on Mac - Any info on where crash happens?

[Helena Mitasova]

Michael,

what you describe sounds as if you had only one depth layer so let us check 
first that the 3D region is right. 
If the 3d region is set to the provided 3d raster given here
http://skagit.meas.ncsu.edu/~helena/grasswork/JR_7408MR_2m_t70.asci
http://skagit.meas.ncsu.edu/~helena/grasswork/JR_2008_ALL.asci (reference 2d 
raster)
 it should look like this

GRASS 6.4.3svn (nc_spm_05):~  g.region -p3
projection: 99 (Lambert Conformal Conic)
zone:   0
datum:  nad83
ellipsoid:  a=6378137 es=0.006694380022900787
north:  250690
south:  249502
west:   912791
east:   913931
top:64.
bottom: 0.
nsres:  2
nsres3: 2
ewres:  2
ewres3: 2
tbres:  8
rows:   594
rows3:  594
cols:   570
cols3:  570
depths: 8

can you then try to run the following command (please adjust the names of the 
2d and 3d rasters to your actual names)

m.nviz.image elevation_map=JR_2008_ALL@Baseline_JR -a mode=fine 
resolution_fine=6 color_map=JR_2008_ALL@Baseline_JR \
volume=JR_7408MR_2m_t70@Baseline_JR volume_shading=gouraud volume_resolution=1 
volume_position=0,0,20 isosurf_level=1:18.0 
isosurf_color_map=JR_7408MR_2m_t70@Baseline_JR isosurf_transparency_value=0 
slice=1:x,1:z 
slice_position=0.00,1.00,0.52,1.00,0.00,1.00,0.25,0.72,0.08,1.00,0.00,1.00
 slice_transparency=0,0 position=0.84,0.16 height=356 perspective=20 twist=0 
zexag=5.00 focus=569,593,28 \
light_position=0.68,0.68,0.80 light_brightness=80 light_ambient=20 
light_color=255:255:255 \
output=jrvoltest format=tif size=798,545 

it should generate an image with isosurfaces and a tilted crossection - it is 
not quite what I have on the screen, because
it apparently uses some default values instead of actual values (e.g. for 
toggle normal direction and crossection) but it should have some 
isosurfaces. Let us know whether the command line works and we can go from 
there.

Helena

On Jan 3, 2013, at 12:08 AM, Michael Barton wrote:

 When I put in values between 15 and 20 I can see the horizontal outline of a 
 rectangle but not the 3D shape of a box. No isosurfaces display. No crash 
 either.
 
 I un-commented line 684 and commented line 1009 in gvl_calc_c to see what 
 happens to slices
 
 /* gvl_align_data(pos, slice-data); */
 
 A horizontal slice displays and I can manipulate it in the X and Y direction. 
 But I cannot manipulate it in the Z direction. Also, a Z dimension slice 
 shows up only as a line. Also, isosurfaces do not display. But there is no 
 crash for either isosurfaces or slices when I comment out this line. On the 
 face of it, a memory issue related to display in the Z dimension is causing a 
 crash. Commenting out calls to gvl_align_data in gvl_calc_c stops the crash 
 and stops display in the Z dimension. There is also something called 
 gvl_calc2_c in this folder. Its code is very similar to gvl_calc_c
 
 I'm guessing that Martin and Helena know the most about the relevant C code 
 for lib/ogsf/*. Glynn may have some insight into this too. Anyone else is 
 welcome to chime in.
 
 FWIW, the last time gvl_calc_c was touched was by Glynn 4 years ago (glynn: 
 Fix char/char* mismatch (merge from trunk, r32757)).
 
 Volume display worked as recently as fall 2011 AFAIK.
 
 Michael
 
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity 
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 
 voice:480-965-6262 (SHESC), 480-727-9746 (CSDC)
 fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
 www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 On Jan 2, 2013, at 10:21 AM, Helena Mitasova hmit...@ncsu.edu wrote:
 
 
 
 On Jan 2, 2013, at 1:34 AM, Michael Barton wrote:
 
 Testing with GRASS 6.4.3RC2
 
 Rem-ing out line 684 in gvl_calc_c
 
 /* gvl_align_data(dbuff[i].ndx_new, dbuff[i].new); */
 
 prevents crashing. But I don't see an isosurface.
 
 
 
 Helena, 
 
 I'm using your test data (jr_7408MR_2m_t70)
 
 What is a good value to set for an isosurface to see anything?
 
 anything between 15 to 20 should work.
 You can move the volume a little bit above the surface to see the entire 
 isosurface
 Here is an example of settings that I have used (the name of the volume 
 raster is slightly different
 but it is the same data).
 
 m.nviz.image elevation_map=JR_2008_ALL -a mode=fine resolution_fine=1 
 color=243:243:243 volume=JR_7408MR_2m volume_shading=gouraud 
 volume_resolution=1 volume_position=0,0,20 isosurf_level=1:17.0 
 isosurf_color_map=JR_7408MR_2m isosurf_transp_value=0 position=0.11,0.07 
 height=243 perspective=13 twist=0 zexag=6.00 focus=569,593,17 
 light_position=0.26,-0.30,0.61 light_brightness=94 light_ambient=55 
 light_color=255:255:255 output=nviz_output format=ppm size=798,545
 
 This volume includes no-data because the original rasters were masked, I 
 think it would be useful to start

Re: [GRASS-dev] Grass7 GUI compilation failed

[Helena Mitasova]

I can confirm that - I don't think it was the animation, I think it was the 
g.gui.* that started to break down modules for me.
I am still on 10.6.8 but I am trying to set up a machine with 10.8 for testing. 

Currently, the compilation ends with error for the following modules:
/Users/helena/grassdev7/grass_trunk/gui/wxpython/animation
/Users/helena/grassdev7/grass_trunk/gui/wxpython/mapswipe
/Users/helena/grassdev7/grass_trunk/gui/wxpython/gmodeler
/Users/helena/grassdev7/grass_trunk/gui/wxpython/rlisetup
/Users/helena/grassdev7/grass_trunk/gui/wxpython/psmap
/Users/helena/grassdev7/grass_trunk/gui/wxpython/dbmgr
/Users/helena/grassdev7/grass_trunk/gui/wxpython/vdigit
/Users/helena/grassdev7/grass_trunk/gui/wxpython/iclass

but it affects more than the modules above - for example switching to 3d view 
is broken - it has erratic behavior (I can provide
more details - there are too many to list here but the following error shows up
pythonw2.6[69774] Error: CGContextRestoreGState: invalid context 0x0
(this is just with a single DEM, no volumes)

v.digit runs but hangs on rendering

mapswipe works fine except for the manual page which gives
CGContextRestoreGState: invalid context 0x0

animation tool does not start at all giving the following error
CGBitmapContextCreate: invalid data bytes/row: should be at least 4 for 8 
integer bits/component, 3 componen
ts, kCGImageAlphaNoneSkipFirst.
 pythonw2.6[69774] Error: CGContextTranslateCTM: invalid context 0x0
 pythonw2.6[69774] Error: CGContextScaleCTM: invalid context 0x0

Note that  this issue is different from GRASS6.4.3 
crashing gui on OS X 10.7 and 10.8 when drawing isosurfaces - that works OK on 
10.6 but the issues above 
are in GRASS7 only and on Mac OSX 10.6 - 10.8 

Helena 

On Dec 29, 2012, at 3:57 PM, Michael Barton wrote:

 This has been broken since the introduction of the animation module and 
 apparently now is affecting other modules that used to compile fine. So GRASS 
 7 is increasingly broken for the Mac. Volume displays have been broken for 
 many months now. If someone could tell me what has changed with the 
 introduction of these new modules and related changes to the other ones, I 
 might be able to find out what is breaking on the Mac. I'm guessing that it 
 is a new class that calls some wxPython windowing routine that has a problem, 
 but I don't know what it is.
 
 Michael
 
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity 
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 
 voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
 fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
 www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 
 
 
 
 
 
 
 On Dec 29, 2012, at 1:00 PM, grass-dev-requ...@lists.osgeo.org
  wrote:
 
 From: Rashad M mohammedrasha...@gmail.com
 Subject: Re: [GRASS-dev] Grass7 GUI compilation failed
 Date: December 29, 2012 11:25:17 AM MST
 To: grass-dev@lists.osgeo.org
 
 
 here is output from v.digit
 make
 ml
 make[6]: Entering directory `/code/grass/grass70/gui/wxpython/vdigit'
 GISRC=/code/grass/grass70/dist.x86_64-unknown-linux-gnu/demolocation/.grassrc70
  GISBASE=/code/grass/grass70/dist.x86_64-unknown-linux-gnu 
 PATH=/code/grass/grass70/dist.x86_64-unknown-linux-gnu/bin:/code/grass/grass70/dist.x86_64-unknown-linux-gnu/bin:$PATH
  
 PYTHONPATH=/code/grass/grass70/dist.x86_64-unknown-linux-gnu/etc/python:/code/grass/grass70/dist.x86_64-unknown-linux-gnu/etc/python:$PYTHONPATH
  
 LD_LIBRARY_PATH=/code/grass/grass70/dist.x86_64-unknown-linux-gnu/bin:/code/grass/grass70/dist.x86_64-unknown-linux-gnu/lib:/code/grass/grass70/dist.x86_64-unknown-linux-gnu/lib:
   LC_ALL=C 
 /code/grass/grass70/dist.x86_64-unknown-linux-gnu/scripts/g.gui.vdigit 
 --html-description  /dev/null | grep -v '/body\|/html'  
 g.gui.vdigit.tmp.html
 Traceback (most recent call last):
   File 
 /code/grass/grass70/dist.x86_64-unknown-linux-gnu/scripts/g.gui.vdigit, 
 line 39, in module
 import wx
 ImportError: No module named wx
 make[6]: *** [g.gui.vdigit.tmp.html] Error 1
 rm g.gui.vdigit.tmp.html
 make[6]: Leaving directory `/code/grass/grass70/gui/wxpython/vdigit'
 make[5]: *** [guiscript] Error 2
 
 
 On Sat, Dec 29, 2012 at 9:57 PM, Rashad M mohammedrasha...@gmail.com wrote:
 grass7.0 fails compilation at first and continues only after setting 
 PYTHONPATH.
 
 This becomes a routine for recompilation. Is there any work around to 
 automatically pickup wxPython?
 
 Here is my error log:
 
 Started compilation: Sat Dec 29 21:46:17 IST 2012
 --
 Errors in:
 /code/grass/grass70/gui/wxpython/animation
 /code/grass/grass70/gui/wxpython/mapswipe
 /code/grass/grass70/gui/wxpython/gmodeler
 /code/grass/grass70/gui/wxpython/rlisetup
 /code/grass/grass70/gui/wxpython/psmap
 /code/grass/grass70/gui/wxpython/dbmgr
 /code/grass/grass70/gui/wxpython/vdigit
 --
 In case of errors please change into the directory with error and run 'make'.
 

Re: [GRASS-dev] [GRASS-SVN] r54115 - grass/trunk/general/g.version

[Helena Mitasova]

just tested on Mac - this fixes the g.version issue.

Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Nov 30, 2012, at 10:45 AM, svn_gr...@osgeo.org wrote:

 Author: martinl
 Date: 2012-11-30 07:45:47 -0800 (Fri, 30 Nov 2012)
 New Revision: 54115
 
 Modified:
   grass/trunk/general/g.version/Makefile
 Log:
 g.version: missing GEOSCFLAGS
 
 
 Modified: grass/trunk/general/g.version/Makefile
 ===
 --- grass/trunk/general/g.version/Makefile2012-11-30 14:41:33 UTC (rev 
 54114)
 +++ grass/trunk/general/g.version/Makefile2012-11-30 15:45:47 UTC (rev 
 54115)
 @@ -5,7 +5,7 @@
 # cat the COPYING file, add a c line-break \n at each line end
 # and remove the unix newline. 
 
 -EXTRA_CFLAGS = $(PROJINC) \
 +EXTRA_CFLAGS = $(PROJINC) $(GEOSCFLAGS) \
   -DGRASS_VERSION_NUMBER=\'$(GRASS_VERSION_NUMBER)'\ \
   -DGRASS_VERSION_DATE=\'$(GRASS_VERSION_DATE)'\ \
   -DGRASS_VERSION_SVN=\'$(GRASS_VERSION_SVN)'\ \
 
 ___
 grass-commit mailing list
 grass-com...@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-commit

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

Re: [GRASS-dev] compiling animation, mapswipe, etc.

[Helena Mitasova]

Just a note that when compiling trunk on

MacOSX 10.6.8, running python2.6

I get Errors in:
/Users/helena/grassdev7/grass_trunk/general/g.version
/Users/helena/grassdev7/grass_trunk/gui/wxpython/animation
/Users/helena/grassdev7/grass_trunk/gui/wxpython/mapswipe
/Users/helena/grassdev7/grass_trunk/gui/wxpython/gmodeler
/Users/helena/grassdev7/grass_trunk/gui/wxpython/rlisetup

but mapswipe and gmodeler works anyway, 
unfortunately animation does not although they all show the same error (see 
below).

Helena


Traceback (most recent call last):
  File 
/Users/helena/grassdev7/grass_trunk/dist.x86_64-apple-darwin10.8.0/scripts/g.gui.animation,
 line 42, in module
import wx
  File 
/var/tmp/wxWidgets/wxWidgets-13~231/2.6/DSTROOT/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode/wx/__init__.py,
 line 45, in module
  File 
/var/tmp/wxWidgets/wxWidgets-13~231/2.6/DSTROOT/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode/wx/_core.py,
 line 4, in module
ImportError: 
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode/wx/_core_.so:
 no appropriate 64-bit architecture (see man python for running in 32-bit 
mode)
make: *** [g.gui.animation.tmp.html] Error 1

Traceback (most recent call last):
  File 
/Users/helena/grassdev7/grass_trunk/dist.x86_64-apple-darwin10.8.0/scripts/g.gui.mapswipe,
 line 40, in module
import  wx
  File 
/var/tmp/wxWidgets/wxWidgets-13~231/2.6/DSTROOT/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode/wx/__init__.py,
 line 45, in module
  File 
/var/tmp/wxWidgets/wxWidgets-13~231/2.6/DSTROOT/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode/wx/_core.py,
 line 4, in module
ImportError: 
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode/wx/_core_.so:
 no appropriate 64-bit architecture (see man python for running in 32-bit 
mode)
make: *** [g.gui.mapswipe.tmp.html] Error 1

Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Nov 29, 2012, at 3:09 PM, Anna Kratochvílová wrote:

 On Thu, Nov 29, 2012 at 3:12 AM, William Kyngesburye
 wokl...@kyngchaos.com wrote:
 On Nov 28, 2012, at 12:27 PM, Markus Neteler wrote:
 
 On Wed, Nov 28, 2012 at 6:35 PM, Carlos Grohmann
 carlos.grohm...@gmail.com wrote:
 Hi
 
 so, all modules under guy/wxpython that didn't compile show the same error:
 
 
 /usr/local/lib/wxPython-unicode-2.8.12.1/lib/python2.7/site-packages/wx-2.8-mac-unicode/wx/_core_.so:
 no matching architecture in universal wrapper
 make: *** [g.gui.animation.tmp.html] Error 1
 
 and both modules under visualization also have a common problem
 
 _wxEVT_ERASE_BACKGROUND, referenced from:
 __static_initialization_and_destruction_0(int, int)in gui.o
 _wxEVT_IDLE, referenced from:
 __static_initialization_and_destruction_0(int, int)in main.o
 _wxEVT_NULL, referenced from:
 __static_initialization_and_destruction_0(int, int)in gui.o
 __static_initialization_and_destruction_0(int, int)in main.o
 _wxEmptyString, referenced from:
 wxStringBase::Init()  in gui.o
 _wxFrameNameStr, referenced from:
 MyFrame::MyFrame(wxString const, int, int, gui_data*)in gui.o
 MyFrame::MyFrame(wxString const, int, int, gui_data*)in gui.o
 _wxPanelNameStr, referenced from:
 MyCanvas::MyCanvas(wxWindow*, int, wxSize const)in gui.o
 MyCanvas::MyCanvas(wxWindow*, int, wxSize const)in gui.o
 _wxStaticTextNameStr, referenced from:
 MyFrame::MyFrame(wxString const, int, int, gui_data*)in gui.o
 MyFrame::MyFrame(wxString const, int, int, gui_data*)in gui.o
 ld: symbol(s) not found for architecture x86_64
 collect2: ld returned 1 exit status
 lipo: can't open input file:
 /var/folders/gf/8bwpz0412gs7706j57hdyb4hgn/T//ccTJ28Cm.out (No such 
 file
 or directory)
 make: ***
 [/Volumes/HDD/Users/guano/Documents/installs/GIS/grass/grass_trunk/dist.x86_64-apple-darwin12.2.0/bin/xganim]
 Error 1
 
 
 WxPython 2.8 can only be built 32bit (aka Carbon).  GRASS configuration will 
 detect if wxPython is 64bit-ready, and force compilation in 32bits if not, 
 but that only works if you configure GRASS at least 32bit.  ie 32bit only, 
 or 32+64bit.  The default on Mt Lion is 64bit-only if you don't set any arch 
 options.
 
 This is why compilation with WxPython 2.9 works, because it can use 64bit 
 Cocoa.  But then there is the runtime problem that has yet to be solved.
 
 What about the fix r40523 from the discussion mentioned by Markus?
 Could it be helpful in this case?
 
 Anna

Re: [GRASS-dev] MASK indicated on map display even after it was removed in GRASS 6.4.3 release

[Helena Mitasova]

On Nov 15, 2012, at 8:27 AM, Markus Metz wrote:

 On Thu, Nov 15, 2012 at 10:45 AM, Martin Landa landa.mar...@gmail.com wrote:
 Hi Helena,
 
 2012/11/15 Helena Mitasova hmit...@ncsu.edu:
 This is not a serious problem but I just noticed  that the grass6.4.3 
 compiled on oct 18 on mac
 the red word MASK remains on the Map display even after the MASK is removed.
 I don't seem to find a way how to get rid of it.
 
 tested with fresh 6.4.3svn. After removing the mask (`r.mask -r`) the
 indicator is also removed from the Map Display.
 
 Unfortunately I cannot reproduce this problem. Martin
 
 You can reproduce it if you create a MASK in one mapset, then change
 to another mapset without a MASK, but with the first mapset in the
 search path. If a MASK is found in any mapset in the search path, the
 red word MASK will appear in the Map display. But only MASKs in the
 current mapset are respected by raster operations, thus that red word
 MASK should not be there in this case.

yes, that is exactly my case, I have a MASK in another mapset,

Helena

 
 Markus M

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

[GRASS-dev] MASK indicated on map display even after it was removed in GRASS 6.4.3 release

[Helena Mitasova]

This is not a serious problem but I just noticed  that the grass6.4.3 compiled 
on oct 18 on mac
the red word MASK remains on the Map display even after the MASK is removed.
I don't seem to find a way how to get rid of it.

Helena


All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Nov 12, 2012, at 3:41 AM, Maris Nartiss wrote:

 Sorry, Michael, but I also couldn't reproduce this issue on my AMD64
 Gentoo Linux system. Also code paths leading to crash site seemed to
 be reasonable. Could it be a bug outside of GRASS (in ctypes?)?
 
 No help unless somebody donates a new Mac to Martin or some other
 WXGUI person for GRASS on Mac testing, as it's not possible to
 download a free MacOS image for running in a VM.
 
 
 Maris.
 
 2012/11/12 Michael Barton michael.bar...@asu.edu:
 
 On Nov 11, 2012, at 1:00 PM, grass-dev-requ...@lists.osgeo.org wrote:
 
 From: Helmut Kudrnovsky hel...@web.de
 Subject: Re: [GRASS-dev] GRASS 6.4.3 release planning
 Date: November 10, 2012 4:22:01 PM MST
 To: grass-dev@lists.osgeo.org
 
 
 we may slowly consider 6.4.3RC2 to be prepared.
 
 
 +1 for RC2. Martin
 
 
 maybe it's worth to have a look at:
 
 wingrass6.4.3svn: raster3d problems
 http://trac.osgeo.org/grass/ticket/1784
 
 
 
 
 -
 best regards
 Helmut
 
 
 And volume display does not work at all for the most current 2 OS versions
 for Mac (versions after OS X 10.6).
 
 http://trac.osgeo.org/grass/ticket/1736
 
 Michael
 
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 
 voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
 fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
 www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 
 
 
 
 
 
 
 ___
 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

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

Re: [GRASS-dev] GRASS 6.4.3 release planning

[Helena Mitasova]

Maris, hold on - I was tied up with conferences and other things so I could not 
follow up with testing but 
I will try the volumes this week on 10.8 - I have it at work so I don't have it 
as handy as 10.6 that I have at home,
and I need some extra time for testing on 10.8(is it possible that it is only 
Michael, William and myself who have Mac?)

Also I have been getting complaints about r.mapcalc in the command console on 
MS Windows 
- I was able to run it but I had to remove the quotes and I still don't know 
exactly what combination of 
spaces/not-spaces, quotes/not-quotes works on MS Windows so the students have 
to run mapcalc from GUI.
(all combinations work on Mac)
Just yesterday there were some new troubles with r.thin and other commands in 
our flow routing
assignments that run in GUI but not in the Command console on windows.
(it is this - you can try to run it on MSWin in command console)
http://courses.ncsu.edu/mea582/common/GIS_anal_grass/GIS_Anal_grflow.html
Most of these troubles may be already fixed as this is GRASS6.4.3svn from 
september,
but I just would like to point out that there may be still problems.

I normally try to test as soon as I hear about the problems, but I have 
MacOS10.6 at home where
I can test right away, it gets more complicated in terms of logistics if it is 
MS Windows or MacOS10.8
And lot of the reported problems are just user error so I don't want to submit 
a bug report
before confirming that there is a real problem.

Helena



Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Nov 12, 2012, at 3:41 AM, Maris Nartiss wrote:

 Sorry, Michael, but I also couldn't reproduce this issue on my AMD64
 Gentoo Linux system. Also code paths leading to crash site seemed to
 be reasonable. Could it be a bug outside of GRASS (in ctypes?)?
 
 No help unless somebody donates a new Mac to Martin or some other
 WXGUI person for GRASS on Mac testing, as it's not possible to
 download a free MacOS image for running in a VM.
 
 
 Maris.
 
 2012/11/12 Michael Barton michael.bar...@asu.edu:
 
 On Nov 11, 2012, at 1:00 PM, grass-dev-requ...@lists.osgeo.org wrote:
 
 From: Helmut Kudrnovsky hel...@web.de
 Subject: Re: [GRASS-dev] GRASS 6.4.3 release planning
 Date: November 10, 2012 4:22:01 PM MST
 To: grass-dev@lists.osgeo.org
 
 
 we may slowly consider 6.4.3RC2 to be prepared.
 
 
 +1 for RC2. Martin
 
 
 maybe it's worth to have a look at:
 
 wingrass6.4.3svn: raster3d problems
 http://trac.osgeo.org/grass/ticket/1784
 
 
 
 
 -
 best regards
 Helmut
 
 
 And volume display does not work at all for the most current 2 OS versions
 for Mac (versions after OS X 10.6).
 
 http://trac.osgeo.org/grass/ticket/1736
 
 Michael
 
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 
 voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
 fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
 www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 
 
 
 
 
 
 
 ___
 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

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

Re: [GRASS-dev] r.modis in GRASS 7 trunk

[Helena Mitasova]

I agree with Glynn and Ben,
when working with students on 50+ different projects it is really great to have 
everything
in one package and not to worry about which additional tool to install and 
whether it will work with the latest release.
We used to have the code split into core, alpha and several other groups and it 
was pain to maintain,
I think it works much better now and the toolbox concept should be implemented 
at the GUI level.
Maybe PSC should have some mechanism to decide on which add-ons to move to 
trunk based on a defined set of criteria.

Helena 

On Oct 30, 2012, at 12:53 PM, Glynn Clements wrote:

 
 Martin Landa wrote:
 
 as a regular user of MODIS, I would like to call other MODIS users to
 express interest to include r.modis into GRASS 7 SVN.
 
 we cannot extend number of modules in trunk forever. Probably some
 modules should be reviewed and moved to addons.
 
 Why?
 
 Keeping modules in trunk ensures that any breakage resulting from
 changes to APIs or to the build system will be noticed. Also, the
 module will be included in the linkage database created by
 tools/sql.sh, and in any recursive grep of the source tree.
 
 Personally, I'd rather see most normal add-ons moved into trunk.
 
 OTOH, v.in.dwg should be moved to add-ons unless LibreDWG support is
 expected in the foreseeable future.
 
 -- 
 Glynn Clements gl...@gclements.plus.com
 ___
 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] removing nviz from trunk

[Helena Mitasova]

One question - Does the region change work properly for wxnviz in grass7?
In grass6.4.3 it is necessary to quit entire wxgui to get the region change to 
apply to wxnviz,
but based on the discussions with Anna this can be fixed in grass7?
(I just got back from europe so it will take me a day or too to catch up and 
get some time to test).

I agree that tcl/tk nviz can be removed from trunk - I have been using wxnviz 
exclusively for the research and edu work
for couple months now and I did not see a reason to go back to old nviz for 
anything so far.

Helena

Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Oct 27, 2012, at 3:11 AM, Anna Kratochvílová wrote:

 On Sat, Oct 27, 2012 at 12:13 AM, Martin Landa landa.mar...@gmail.com wrote:
 Hi all,
 
 nviz is the last Tcl/Tk application in trunk.
 
 wxNviz [1] covers almost 100% of functionality compared to original
 nviz and it's stable enough for other testing and development. This is
 the main reason why I would vote for removing nviz from trunk
 including related libraries like `form` or `gtcltk`.
 
 Hi,
 
 here [1] is the comparison of tcltk nviz and wxNviz functionality,
 feel free to edit it.
 
 Anna
 
 [1] 
 http://grass.osgeo.org/wiki/WxNviz#Comparison_of_Tcl.2FTk_nviz_and_wxNviz_functionality
 
 
 Martin
 
 [1] http://grass.osgeo.org/wiki/WxNviz
 
 --
 Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~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] dateutil dependency killing GRASS 7

[Helena Mitasova]

I can confirm that I have it on my 10.6 Mac 

/System/Library/Frameworks/Python.framework/Versions/Current/Extras/lib/python/dateutil

Helena

Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Oct 21, 2012, at 11:53 AM, William Kyngesburye wrote:

 System/Library/Frameworks/Python.framework/Versions/2.x/Extras/lib/python/

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

Re: [GRASS-dev] [GRASS GIS] #1736: wxNVIZ volume display crashes Mac

[Helena Mitasova]

Martin, Michael,

 I can update my 6.4.3 and try it again, but it is not just Mac, my student 
working on MSWindows could not 
get it working either. I will try to find some time to check where things stand 
right now.

Helena

Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Oct 15, 2012, at 4:18 PM, GRASS GIS wrote:

 #1736: wxNVIZ volume display crashes Mac
 ---+
 Reporter:  cmbarton   |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  blocker|   Milestone:  6.4.3
 Component:  wxGUI  | Version:  svn-releasebranch64  
 Keywords: |Platform:  MacOSX   
  Cpu:  OSX/Intel  |  
 ---+
 
 Comment(by cmbarton):
 
 This is something that did work within the past year and now is broken.
 Not sure why.
 
 But it effectively makes all the volume commands useless if you cannot
 display the result. I was trying to test some alternative files with
 Helena to debug this, but we found out that r3.in.ascii is also broken
 now. I don't know if she filed a report or not. I'd copy her here, but
 apparently there is no longer a way to add someone to this ticket.
 
 Michael
 
 -- 
 Ticket URL: http://trac.osgeo.org/grass/ticket/1736#comment:2
 GRASS GIS http://grass.osgeo.org
 
 ___
 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