Re: [GRASS-dev] [GRASS GIS] #2509: d.mon output overwrite

[GRASS GIS]

#2509: d.mon output overwrite
-+--
 Reporter:  martinl  |   Owner:  martinl
 Type:  defect   |  Status:  assigned   
 Priority:  normal   |   Milestone:  7.0.0  
Component:  Display  | Version:  unspecified
 Keywords:  d.mon|Platform:  Unspecified
  Cpu:  Unspecified  |  
-+--

Comment(by martinl):

 Replying to [comment:7 martinl]:
 > Summary: originally reported bug has been fixed in r63466 and related
 commits (r63467 and r63465).

 For record: backported to relbr70 in r63533.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] v.proj: line densification added for reprojection error minimization

[Helmut Kudrnovsky]

>The result (see screenshot, maybe an extreme example but yet helpful
>to show the improvement) shows how nicely the projection is performed
>now (green color is new output).
>Please benchmark this with other GIS... 

attached, done with a GIS from redmont


 



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/v-proj-line-densification-added-for-reprojection-error-minimization-tp5177786p5177808.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 GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by cmbarton):

 I've been dealing with end of semester and traveling. Wow! A lot of words
 spilled over a small suggestion to simplify parsing in code and in
 commands. FWIW, the underscore makes it a *little* easier to parse and
 potentially shorten (if that is desirable) the term for GRASS's unique
 3D/voxel format. It also makes it a little easier to quickly differentiate
 the 2D raster things (raster and raster.x) from the 3D raster things
 (raster_3D and raster_3D.x).  I don't find an underscore that much trouble
 to type, except on my iPad where I can't run GRASS anyway.

 That said, it's not a big deal to me either way. Since one is very
 minimally more difficult to type than the other (1 character), I'd suggest
 whichever form makes programming easier. Maybe a simple vote is needed to
 move on. I'm delighted to go along with the majority so we release the
 next beta

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] v.proj: line densification added for reprojection error minimization

[Helmut Kudrnovsky]

Helmut Kudrnovsky wrote
>>The result (see screenshot, maybe an extreme example but yet helpful
>>to show the improvement) shows how nicely the projection is performed
>>now (green color is new output).
>>Please benchmark this with other GIS... 
> 
> attached, done with a GIS from redmont

to be fair, there is a tool there for densifying lines and polygons; applied
this first, vector reprojecting also works correctly there.


 



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/v-proj-line-densification-added-for-reprojection-error-minimization-tp5177786p5177819.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] v.proj: line densification added for reprojection error minimization

[Markus Neteler]

On Sun, Dec 14, 2014 at 6:14 PM, Helmut Kudrnovsky  wrote:
> Helmut Kudrnovsky wrote
>>>The result (see screenshot, maybe an extreme example but yet helpful
>>>to show the improvement) shows how nicely the projection is performed
>>>now (green color is new output).

BTW; now posted also here:
http://courses.neteler.org/grass-gis-7-vector-data-reprojection-automated-vertex-densification/


>>>Please benchmark this with other GIS...
>>
>> attached, done with a GIS from redmont
>
> to be fair, there is a tool there for densifying lines and polygons; applied
> this first, vector reprojecting also works correctly there.
>
> 

Good - but is that the default or requires extra tricks/knowledge?

And how about QGIS? Because ogr2ogr delivers only the trapezoid with
default settings.

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

Re: [GRASS-dev] v.proj: line densification added for reprojection error minimization

[Helmut Kudrnovsky]

>>

>
>Good - but is that the default or requires extra tricks/knowledge? 

2 steps with 2 different tools are needed: (1) densify polygon line, (2)
reproject to new SRS; and of course the knowledge that large polygons may
need some densifying.



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/v-proj-line-densification-added-for-reprojection-error-minimization-tp5177786p5177823.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] v.proj: line densification added for reprojection error minimization

[Helmut Kudrnovsky]

> And how about QGIS?

the same, 2 steps are needed: (1) densify data, (2) reproject vector



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/v-proj-line-densification-added-for-reprojection-error-minimization-tp5177786p5177825.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 7 - Ubuntu package build problem on Launchpad

[Ivan Mincik]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 13.12.2014 18:15, Nikos Alexandris wrote:
> On 13.12.2014 13:39, Markus Neteler wrote:
>> Hi Nikos,
>> 
>> since you are also listed, could you please press the button?
>> 
>> thanks Markus
> 
> Done.  Well, at least I think I did it correctly!

Thanks Nikos, now packages are finally built.

- -- 
Ivan Minčík
ivan.min...@gmail.com  GPG: 0x79529A1E
http://imincik.github.io/0x79529A1E.key
ivan.min...@gista.sk GPG: 0xD714B02C
http://imincik.github.io/0xD714B02C.key
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUjhmyAAoJEPfdLsR5UpoeoBEH/2/wPA3IgF+Dqs8bXaocON3Z
FO7YJp5CTCAhjRgJL+G1kTMJBkagF7HAdRRfJyl1Tw+8XmHRYiaqdGy053zpfUSZ
49egSX7NkZTGeabJ8ogtZ0uB5ZWhB2Gmgef+4lhyb9jFx/upJCc3glUv02DueaM4
aYNQGvKtfwzplgHGv6m0uC669zEjLBmZJEtspWA6q6NYcmnVsblpW6DWPnxz2F8o
ZkRxJ0nCpqO1z870p7fZswc+IextGDOY60fEWDKAffsbJCkziRku6VFlk33mfFkU
EM5cBe1DFoF5R5OzUEwJzNhcT81n/79QNoPvNOfFPDgfs7HLRb0vBlJb3XEXP1E=
=8Ivm
-END PGP SIGNATURE-
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2509: d.mon output overwrite

[GRASS GIS]

#2509: d.mon output overwrite
-+--
 Reporter:  martinl  |   Owner:  martinl
 Type:  defect   |  Status:  assigned   
 Priority:  normal   |   Milestone:  7.0.0  
Component:  Display  | Version:  unspecified
 Keywords:  d.mon|Platform:  Unspecified
  Cpu:  Unspecified  |  
-+--

Comment(by glynn):

 Replying to [comment:16 neteler]:

 > > > The current behaviour of d.* to silently write into a PNG file is
 unhelpful.
 > >
 > > Yet, that's how those commands behaved since the display system was
 re-written.
 >
 > Maybe that was the idea but for sure not clearly communicated or
 implemented in all d.* modules.

 I'm not sure how it could have been communicated more clearly. And the
 behaviour is consistent across all display[*] modules. It cannot be
 otherwise, as the behaviour comes from lib/display, not any particular
 module.

 [*] I'd like to say "all d.* modules", but there are a number of cases
 where people have used that prefix for modules which are unrelated to the
 display system, e.g. d.mon, d.out.file, etc.

 > > I don't recall any discussion about the behaviour; it got changed by
 accident and now that's how it's "supposed" to be? When did we agree to
 this change, and why?
 >
 > Now which change?

 r46984 and r46999.

 When the support for 6.x-style monitors was removed in r32584, immediate
 rendering became the only supported mode of operation (as was already the
 case on Windows). Thus, it was no longer necessary to set
 GRASS_RENDER_IMMEDIATE; executing any display command would simply
 generate an image file (default map.png, configurable via $GRASS_PNGFILE,
 later changed to $GRASS_RENDER_FILE).

 r46984 and r46999 re-introduce a form of the "monitor" concept (although
 I'm not clear on the details, it has something to do with $MONITOR).
 AFAICT, r46984 effectively disabled direct rendering. r46999 re-enabled
 it, but forced $GRASS_RENDER_IMMEDIATE to be explicitly set (if neither
 $MONITOR nor $GRASS_RENDER_IMMEDIATE are set, it generated a fatal error).

 In case it wasn't clear from [http://lists.osgeo.org/pipermail/grass-
 dev/2014-December/072274.html this thread], the requirement for
 GRASS_RENDER_IMMEDIATE to be set was news to me (I had explicitly set it
 while investigating differences between the cairo and PNG drivers, and
 forgotten to remove the setting).

 > I just asked that the d.* modules please say what they do since I don't
 check the file system for a new file every time I issue a command.

 You were unaware of immediate rendering? Or of it having been the default
 since the earliest days of GRASS 7?

 > If it matters, more people are interested in a working d.mon/command
 line approach:

 I don't doubt it. I've tried to have discussions on such things in the
 past. But some people prefer to just implement hacks like $MONITOR without
 any discussion. Ultimately, that's likely to be counter-productive in
 terms of any reasonable solution.

 FWIW, I don't actually object to requiring $GRASS_RENDER_IMMEDIATE to be
 set. I do object to it being done by /fait accompli/. I'm also less than
 keen on the way that wxGUI seems to be slowly getting shoehorned into
 somehow being "part of" the display system (e.g. using the d.* prefix for
 commands which have nothing to do with the display system per se).

 If the wxGUI developers need additional functionality from the display
 system, that should be resolved through discussion rather than "edit
 wars". Otherwise, it's likely to result in a display system which is of no
 use for anything but wxGUI.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by glynn):

 Replying to [comment:116 wenzeslaus]:

 > [comment:111 annakrat] and [comment:113 hcho] don't want the underscore
 for 3D raster, so this changes "`raster` and (`raster_3d` and `raster3d`)"
 just to "`raster` and `raster3d`". [comment:102 I] already said that I
 prefer `raster3d` over `raster_3d`. In my opinion such a common option
 name as one for 3D raster (common for me and name of one of the basic
 types) should not have an underscore.

 Can someone, anyone, explain what exactly is the problem with underscores?
 Why are they bad, why shouldn't we use them, etc?

 To my mind, any name that is made of more than one word should have some
 kind of separator between the words. For GRASS option names, "some kind of
 separator" equates to an underscore.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by glynn):

 Replying to [comment:117 mlennert]:

 > More generally, this whole issue shows to me what happens in an
 unorganised release process where we start to release betas without being
 sure that we are in a stable enough state to do so and then begin such a
 fundamental review such as this one very late into the process...

 It's always the same. If something can be left until later, it is. Once we
 reach the "last chance to comment" stage, all of the discussions which
 should have happened over the last half-dozen years start.

 This isn't specific to GRASS. The standard that eventually became C++11
 spent most of its life being referred to as "C++0x" on the assumption that
 it would be published by the end of 2009 at the latest.

 It's something of a chicken-and-egg problem. You don't get adequate
 feedback until many people start using it, and many people won't start
 using it until it's perceived as stable.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] v.proj: line densification added for reprojection error minimization

[Markus Metz]

On Sun, Dec 14, 2014 at 7:34 PM, Helmut Kudrnovsky  wrote:
>> And how about QGIS?
>
> the same, 2 steps are needed: (1) densify data, (2) reproject vector

for non-topological polygons, 3 steps are needed:
1) densify
2) snap
3) reproject

snapping is needed to avoid small overlapping areas and small gaps
between polygons. For topological areas composed of boundaries, this
is not an issue.

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

Re: [GRASS-dev] GRASS 7 - Ubuntu package build problem on Launchpad

[Nikos Alexandris]

On 15.12.2014 01:13, Ivan Mincik wrote:
..

Thanks Nikos, now packages are finally built.


Nice.  If you think my registration here might be an obstacle in 
getting things done, please, feel free to remove my name (or I'll dot 
it, if necessary) from the group.


:-)

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

Re: [GRASS-dev] GRASS 7 - Ubuntu package build problem on Launchpad

[Markus Neteler]

On Mon, Dec 15, 2014 at 8:39 AM, Nikos Alexandris
 wrote:
> On 15.12.2014 01:13, Ivan Mincik wrote:
> ..
>>
>> Thanks Nikos, now packages are finally built.
>
>
> Nice.  If you think my registration here might be an obstacle in getting
> things done, please, feel free to remove my name (or I'll dot it, if
> necessary) from the group.

I think on the contrary! You are currently the only person to generate
the packages.

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