Re: [GRASS-user] problem creating secant Lambert Conformal Conic projection

[Moritz Lennert]

On 14/05/16 16:14, Markus Neteler wrote:

Hi Eric,

On Fri, May 13, 2016 at 6:16 PM, Eric Patton  wrote:

Hi guys,

I am trying to make a new Grass location with the secant Lambert Conformal
Conic projection.


To be sure, that's this one, right?
http://www.remotesensing.org/geotiff/proj_list/lambert_conic_conformal_2sp.html


I have noticed that if I am selecting the projection parameters through the
Grass GUI dialog, and lat_0 = lat_1, the value of lat_2 doesn't seem to be
included in the projection definition (see attached screenshot
lat_2_is_gone.png).


Strange. I have replicated it here and it looks fine:

GRASS 7.0.3 (lcc):~ > g.proj -w
PROJCS["Lambert Conformal Conic",
 GEOGCS["wgs84",
 DATUM["WGS_1984",
 SPHEROID["WGS_1984",6378137,298.257223563],
 TOWGS84[0.000,0.000,0.000]],
 PRIMEM["Greenwich",0],
 UNIT["degree",0.0174532925199433]],
 PROJECTION["Lambert_Conformal_Conic_2SP"],
 PARAMETER["standard_parallel_1",65],
 PARAMETER["standard_parallel_2",75],
 PARAMETER["latitude_of_origin",60],
 PARAMETER["central_meridian",60],
 PARAMETER["false_easting",0],
 PARAMETER["false_northing",0],
 UNIT["Meter",1]]




In your case let_0 != lat_1, so this corresponds to the case where it 
works also for Eric. It's the case when lat_0 = lat_1 that doesn't work 
for him.


Testing here with grass64, grass70, grass71 it works, though (see 
attached screenshot). No idea what is going wrong for you, there, Eric.


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

Re: [GRASS-user] [GRASS-dev] Added i.landsat8.swlst in grass-addons

[Nikos Alexandris]

* Blumentrath, Stefan  [2016-05-14 21:21:25 +]:


Hei Nikos (and others),


H(e)i :-)

(
On my way to understand how to work as, what you described, an educated
programmer (more than half-way through a series of excellent courses,
Rice University).

To this end, I try to build good programming habits:  clean
and extensively commented code, modularity (assisting re-usability) and
tests, tests and tests.  And of course, (algorithm-ic) efficiency (read
input size vs. running time).

That's why I use a lot of helper functions, instead of "lambda" functions.
)



Actually, on a second thought, I am considering to change the module
significantly. Maybe better to just generate a file with
reclassification rules for all possible combination of bitpattern?



That would simplify the module (only the filter criteria are required
as input), and the resulting r.reclass rules can be applied to any
landsat scene... So they can be generated once and then reused.



That would be more efficient if several scenes should be processed with
the same procedure.


Decreasing the final running time, yes.  Another option, in such a case
of multiple scenes, might be to cache the rules in question, after the
first loop (?).



However users would have to run r.reclass themselfs
in a next step... But that is probably more in line with the modular
concept of GRASS...



What do you think /prefer?


I'll have more time next month and, I think, I can contribute in this
discussion.  I am sorry if this isn't of great help at the moment.

I started implementing the idea of a dedicated Landsat8 python class
(for GRASS, of course):
https://github.com/NikosAlexandris/landsat8_metadata.

One of the To Do points is "Implement mechanism to translate QA pixel
values to QA bits, and vice versa?".

It would be wonderful to have feedback from higher level experts in the
list.

Warmest Regards, Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user