Re: [GRASS-dev] r.colors.matplotlib

[Steven Pawley]

Thanks Vaclav,

Will see if I can figure out.

Steve

On Thu, Jun 1, 2017 at 8:51 PM, Vaclav Petras  wrote:

> Hi Steve,
>
> On Tue, May 30, 2017 at 3:10 PM, Steven Pawley 
> wrote:
>
>>
>> Thanks for writing the r.colors.matplotlib tools because I use the
>> matplotlib colorramps very frequently both in GRASS and in python more
>> generally.
>>
>
> Glad to hear that.
>
>
>>
>> I seem to be having a problem of using the perceptually uniform ramps in
>> the r.colors.matplotlib add on, receiving the error: ERROR: Matplotlib
>> 2.0.2 does not contain color table 
>>
>> I'm on linux and matplotlib 2.0.2 has the perceptually uniform ramps, and
>> I can use them if I display data in python within a GRASS session directly
>> (i.e. plt.imshow(numpyraster, cmap='plasma').
>>
>> Is there a reason why r.colors.matplotlib can't see these ramps? It still
>> works with all of the traditional matplotlib ramps.
>
>
> The module does not check for specific color maps in mpl, but it uses
> general code to check the presence of a requested color map. It imports
> matplotlib.cm.datad dictionary. Perhaps, this dictionary does not contain
> the new color maps. The checking is not ideal, it should based on
> cm.get_map() function. I think the reason why I "ask for permission" here
> instead is that I was not able to figure out what is the error state from
> get_map() or how to transfer it to the user. But perhaps you will be more
> successful or 2.0 behaves differently. The relevant code is here:
>
> https://trac.osgeo.org/grass/browser/grass-addons/grass7/
> raster/r.colors.matplotlib/r.colors.matplotlib.py#L164
>
> Best,
> Vaclav
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3350: wxGUI: map decorations are not removed when creating new workspace (Ctrl-N)

[GRASS GIS]

#3350: wxGUI: map decorations are not removed when creating new workspace 
(Ctrl-N)
--+---
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.2
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  wxGUI display decorations
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by annakrat):

 In [changeset:"71165" 71165]:
 {{{
 #!CommitTicketReference repository="" revision="71165"
 wxGUI: remove decorations when creating new workspace, see #3350
 }}}

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Week 01 Report - Integration Of PDAL into GRASS GIS

[Paul Schrum]

Submitted by Paul Schrum
Also available at Integration Of PDAL into GRASS GIS



   1. What did you get done this week?


   - Built GRASS73 from source from my local repo directoy.
   - Stepped into a module (v.in.ascii) using the debugger to watch it work
   at the source code level. This was only proving the concept of stepping
   into the code – just getting it to work.
   - Talked with my mentor about the nature of the existing v.in.pdal
   module and what are some of the things which must be changed, fixed, or
   improved.


   1. What do you plan on doing next week?


   - Continue stepping through v.in.ascii to see how it works at the source
   level in order to understand how to write points to a vectormap.
   - Get GRASS 73 to link to current version of PDAL.
   - Fix broken references to PDAL data structures in the GRASS source
   - Refactor existing v.in.pdal so that operations which r.in.pdal and r3
   .in.pdal will need are in a
   separate module and available as functions to be called from all three of
   them.
   - Learn the process of calling PDAL and how to get it to do the basic
   operation of reading a lidar file and handing over the data to the caller.
   - Set up a basic set of test data for PDAL, open it from pdal without
   GRASS, then open it using pdal through GRASS with only the most basic
   options in operation.
   - Get PDAL to be able to read .laz (compressed) files. For some reason
   it can’t do that after build-from-source.


   1. Are you blocked on anything?

I had two listed on the Wiki when I originally posted it, but my mentor
helped me work through those before the end of the reporting period for
Week 1. So there are currently no issues blocking me.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3356: v.to.db: incorrect area calculations in lat-long location

[GRASS GIS]

#3356: v.to.db: incorrect area calculations in lat-long location
--+---
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.4.0
 Component:  Vector   |Version:  svn-trunk
Resolution:   |   Keywords:  v.to.db area lat-long
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by annakrat):

 I fixed the rendering issue in r71163 and r71164. But the area computation
 problem must be somewhere in
 
[https://grass.osgeo.org/programming7/area__poly1_8c.html#af6f1f53bacc34249be98006c95369695
 G_ellipsoid_polygon_area], probably related to very small numbers, but I
 couldn't pinpoint the problem. There is something specific about this
 polygon, when I draw a similar one, it gives more reasonable results.

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [SoC] GSoC 2017 Weekly Report 1 - SOS tools in GRASS GIS

[Ondřej Pešek]

Hi everyone!

Here is the first report of my GSoC project - SOS tools in GRASS GIS. You
can see my project at wiki at [1]


What did you get done this week?

* I have studied OWSLib and its interaction with SOS. Especially with
istSOS. I am also in contact with guys about OWSLib and we're discussing
things related to SOS to improve.

* Solved issue [2].

* Created converter between normal JSON output from OWSLib and geoJSON
What do you plan on doing next week?

* Solve this issue [3]

* Test OWSLib on more severs.

* I would like to create converter working with
responseFormat=text/xml;subtype="om/1.0.0" responseFormat.

Are you blocked on anything?

* I was blocked in creating converter from above mentioned format, because
the OWSLib didn't give me right response. I'm discussing it with people
around OWSLib to solve whether is it bug or something.


Regards,
Ondrej

[1] https://trac.osgeo.org/grass/wiki/GSoC/2017/SOSInGRASS
[2] https://github.com/geopython/OWSLib/issues/347
[3] https://github.com/geopython/OWSLib/issues/248
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [SoC] Week 01 Report - Locations from Public Data

[Zechariah Krautwurst]

Hello All,

WEEK 01 REPORT: MAY 30 - JUNE 02
GRASS GIS Locations from Public Data [1]
Zechariah Krautwurst

ACCOMPLISHED:
- Mentor meetings
- Refined project scope
- Selected target data sources and scale
- Discussed coordinate projection issues and solutions
- Researched USGS NED data download process and web services
- Reviewed GRASS Location Wizard functionality
- Created user scenarios for various software possibilities
- Set up local development tools and coding environment
- Reviewed existing methods and Python scripts for data download into GIS
formats

NEXT WEEK:
- Create initial data download script for NED data
- Establish user defined boundaries for import data
- Reconcile coordinate projection difficulties
- Review wxPython
- Reach out to GRASS community for thoughts and resources

BLOCKS:
- None

[1]
https://trac.osgeo.org/grass/wiki/GSoC/2017/GRASSGISLocationsfromPublicData



-- 

Zechariah F. Krautwurst

NCSU College of Natural Resources

MGIST Candidate 2017

zfkra...@ncsu.edu

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