date:20160223

[GRASS-dev] [GRASS GIS] #2933: v.label issue

2016-02-23 Thread GRASS GIS

#2933: v.label issue
-+-
 Reporter:  vincent  |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:  7.0.4
Component:  Vector   |Version:  svn-trunk
 Keywords:   |CPU:  Unspecified
 Platform:  Linux|
-+-
 v.label "where" option is broken. Depending on the sql statement provided
 it results in a 0/1 filter (zero or all features labeled).

--
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] #2838: d.labels placement issue

2016-02-23 Thread GRASS GIS

#2838: d.labels placement issue
--+-
  Reporter:  vincent  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.4
 Component:  wxGUI|Version:  unspecified
Resolution:   |   Keywords:  label placement
   CPU:  Unspecified  |   Platform:  Linux
--+-
Changes (by vincent):

 * milestone:  7.1.0 => 7.0.4


--
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] #2932: z values read instead of intensity in r.in.lidar

2016-02-23 Thread GRASS GIS

#2932: z values read instead of intensity in r.in.lidar
---+-
  Reporter:  dnewcomb  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:  7.1.0
 Component:  Default   |Version:  svn-trunk
Resolution:|   Keywords:
   CPU:  x86-64|   Platform:  Linux
---+-

Comment (by dnewcomb):

 I think in this case the value of the increased functionality justifies
 the increase in complexity. It was my (mistaken) understanding that you
 could use the base raster and Z values to filter for the points you want
 to analyse , then depending on whether the -i flag was set or not you
 either the run the statistics on the Z values or run the statistics on the
 intensity values.

 This would allow you to look at the mean intensities of the points within
 half a meter above and below the base raster surface or get the mean
 intensities of the top 3 meters of the canopy.  One could even acquire
 intensity statistics in 2m horizontal sections of the canopy.

 My apologies in not communicating properly

--
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] #2932: z values read instead of intensity in r.in.lidar

2016-02-23 Thread GRASS GIS

#2932: z values read instead of intensity in r.in.lidar
---+-
  Reporter:  dnewcomb  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:  7.1.0
 Component:  Default   |Version:  svn-trunk
Resolution:|   Keywords:
   CPU:  x86-64|   Platform:  Linux
---+-

Comment (by wenzeslaus):

 The current implementation of `-i` uses intensity instead of z from the
 beginning and applies it for all subsequent operations:

 {{{
 #!c
 if (intens_flag->answer)
 /* use z variable here to allow for scaling of intensity below */
 z = LASPoint_GetIntensity(LAS_point);
 else
 z = LASPoint_GetZ(LAS_point);
 }}}

 Thus both `zrange` and `base_raster` are working with intensity. Is this
 the behavior you observe?

 I think it does not make much sense and `zrange` and `base_raster` always
 using z is more expected and useful behavior. This raises two questions.

 Does it make sense to have `intensity_range` or `irange` and
 `intensity_scale`?

 Is it OK to make this change when it is in fact changing behavior? Is the
 previous behavior simply a bug, so we can just changed it? We are talking
 about `zrange` and `zscale` (`base_raster` is 7.1 only). MarkusN added the
 intensity in r61480 with the aforementioned comment ''allow for scaling of
 intensity below''. Another flag (`-j` "stats on intensity, filters on z")
 or even and option (`values=z|intensity|combined`) can implement this in a
 backward compatible way for the price of complicating the interface and
 the code.

--
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.net.distance/path calculate the route in the reverse way

2016-02-23 Thread Pedro Venâncio

Hi Moritz,

Thank you for your test!

Can you try to run v.net.distance with the same sample data?

v.net.distance --overwrite input=mynet@PERMANENT output=distance_7779_7780
from_layer=2 from_cats=7779 to_layer=2 to_cats=7780 arc_column=FT_COST
arc_backward_column=TF_COST

v.net.distance --overwrite input=mynet@PERMANENT output=distance_7780_7779
from_layer=2 from_cats=7780 to_layer=2 to_cats=7779 arc_column=FT_COST
arc_backward_column=TF_COST

In the image attached, green line is the result of the first run
(from_layer=2 from_cats=7779 to_layer=2 to_cats=7780), and red line is the
result of (from_layer=2 from_cats=7780 to_layer=2 to_cats=7779).

It seems that it calculates the route in the reverse way. What do you think?

Thank you very much!

Best regards,
Pedro






2016-02-23 16:27 GMT+00:00 Moritz Lennert :

> On 23/02/16 15:44, Pedro Venâncio wrote:
>
>> Hi,
>>
>> I was testing the v.net.distance (in QGIS) and noticed something
>> strange. Apparently the route is calculated in a reverse way.
>>
>> If you see in this screencast
>>
>>
>> https://dl.dropboxusercontent.com/u/5772257/qgis/processing_grass_v_net_distance.ogv
>>
>>
>> I have a network of streets with two-way (green) and some with only
>> one-way (in red, with the arrow indicating the direction of traffic).
>> The two-way cost is in "dois_senti" field of the attribute table, and
>> the sections of one-way have -1 value in the "um_senti" field of the
>> attribute table.
>>
>> The starting point is the orange pentagon ("ponto_inicio"), and the
>> destination point is the green star ("ponto_chegada").
>>
>> As you can see, v.net.distance calculate the route in the reverse way,
>> that is, when I choose "ponto_inicio" as "from", and "ponto_chegada" as
>> "to" (first run in the screencast), it gives me the route by the south
>> ("ponto_chegada" -> "ponto_inicio"). In the second run, I choose
>> "ponto_chegada" as "from", and "ponto_inicio" as "to", and it uses the
>> one-way street. So, the topology is respected, but it seems that "from"
>> and "to" are used in a reverse manner.
>>
>> I thought it might be a mistake in implementing the tool in QGIS
>> Processing, but then I performed the same procedure on GRASS 7.0.2
>> native, and the result is the same.
>>
>> Médéric Ribreux has done also some tests and concluded that from_layer
>> is used as to_layer.
>>
>> It seems to be a GRASS problem because the point layers order is correct:
>> - layer 2 is imported from FROM_CENTERS QGIS layer.
>> - layer 3 is imported from TO_CENTERS QGIS layer.
>> - layer 2 is used as from_layer in v.net.distance.
>> - layer 3 is used as to_layer in v.net.distance.
>>
>> He has tried with v.net.path and got the same results than for
>> v.net.distance.
>>
>> Could it be a mis-interpretation of forward and backward costs? A bug?
>> Or simply how the tool works?
>>
>
>
> I cannot reproduce this with the NC demo data set;
>
> v.net -c streets_wake op=nodes out=mynet
> v.db.update map=mynet@user1 column=TF_COST value=-1 where=ONE_WAY='FT'
> v.db.update map=mynet@user1 column=FT_COST value=-1 where=ONE_WAY='TF'
> echo "1 7779 7780
> 2 7780 7779" | v.net.path mynet out=paths arc_column=FT_COST
> arc_backward_column=TF_COST
>
> Display:
> d.vect map=mynet@user1
> d.vect map=mynet@user1 display=shape,dir where="ONE_WAY='FT' OR
> ONE_WAY='TF'" color=red attribute_column=ONE_WAY yref=top
> d.vect map=mynet@user1 layer=2 display=shape,cat cats=7779-7780
> fill_color=255:165:0 icon=basic/circle label_layer=2
> d.vect map=paths@user1 display=shape,cat cats=1 color=0:128:0 width=2
> label_color=0:128:0
> d.vect map=paths@user1 display=shape,cat cats=2 color=128:0:128 width=2
> label_color=128:0:128
>
> gives the expected result (see attached image).
>
> Note that the line connecting 7779 and 7780 directly has a one_way value
> of 'TF' meaning that it is one-way in direction to-from, i.e. from 7780 to
> 7779 (direction of the line being indicated by the arrows).
>
> Errors can occur if the costs are not well-defined or too small. In the
> source code of the Vect_net_build_graph() function which builds the network
> graph the path is found upon, it says:
>
> "Internal format for edge costs is integer, costs are multiplied before
> conversion to int by 1000"
>
> This means that if you have a cost lower than 1/1000, you might end up
> with costs = 0.
>
> This is noted as a todo in the source code:
>
> "/* TODO int costs -> double (waiting for dglib) */"
>
> But AFAICS, dglib still uses integers for costs.
>
> This is not mentioned in the man page, and should be.
>
> Please verify if this is the origin of your problem.
>
> If yes, please post a bug report on bad documentation. If this isn't the
> problem, please post a bug report with a reproducible example.
>
> Moritz
>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #2932: z values read instead of intensity in r.in.lidar

2016-02-23 Thread GRASS GIS

#2932: z values read instead of intensity in r.in.lidar
--+-
 Reporter:  dnewcomb  |  Owner:  grass-dev@…
 Type:  defect| Status:  new
 Priority:  normal|  Milestone:  7.1.0
Component:  Default   |Version:  svn-trunk
 Keywords:|CPU:  x86-64
 Platform:  Linux |
--+-
 The following command:

 r.in.lidar -o -i -d --overwrite
 input=/data1/lidar_test/LA_37_20960803_20150430.las
 output=803_20ft_ground_intensity
 base_raster=D05_37_20960803_20141231@PERMANENT method=mean zrange=-10,0
 class_filter=1,2,3,4,5,6,8,9,10,11,12,13,14,15,16,17,18

 Gives me a grid with values with negative numbers.  LiDAR intensities are
 always positive, so the mean values should also be positive.  Since I have
 only included Z values less in elevation than the ground surface, I assume
 the values are from the Z coordinates.

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #2931: r.neighbors shifts output raster by 360 degrees (WGS 84)

2016-02-23 Thread GRASS GIS

#2931: r.neighbors shifts output raster by 360 degrees (WGS 84)
-+-
 Reporter:  markinpt |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:  6.4.6
Component:  Default  |Version:  6.4.3
 Keywords:   |CPU:  x86-64
 Platform:  MSWindows 8  |
-+-
 Input raster is an elevation raster that goes from -180 to 180 longitude
 (WGS 84). I am using r.neighbors to calculate the elevation standard
 deviation over 9 cells circular.

 The output comes back as 180 to 540 degrees in longitude. Not exactly a
 desirable outcome as I have to then shift it back to +- 180.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] -s flag in temporal modules

2016-02-23 Thread Sören Gebbert

Hi,

2016-02-23 18:50 GMT+01:00 Luca Delucchi :
> On 23 February 2016 at 17:59, Sören Gebbert
>  wrote:
>> Hi,
>
> Hi,
>
>> the "-s" flag is in use by many temporal modules for different
>> purposes in grass71.
>
> yes, could we try to simplify this using -s for only one purpose?
>
>> Only the aggregation modules use "-s" flag to signal the usage of
>> start time as suffix for basename creation.
>> We should not change all the modules that make use of the flag "-s"
>> for column name suppression or spatial topology activation.
>>
>> I would like to suggest that we do not use a flag for suffix
>> specification, but instead an option for this purpose. Like "suffix"?
>>
>> The suffix option will specify which type should be created:
>> * time with full format (time)  2001-01-01T00:00:00
>> * time depending on the granularity (gran) 2001 or 2001-01 or 2001-01-01 ...
>> * numerical suffix with a specific number of digits (num + %05, ...)
>> "_0001" or "_01"
>>
>> Parameter for the option suffix: "time","num","gran" and C format
>> specification like "%05" or "%03" in addition to num.
>>
>> What do you think?
>>
>
> make sense for me, I could implement "gran" and "num" during Paris
> code sprint and if I have more time try to work also on "time".
> Do you think the C format specification should be in other parameter
> or inside the "suffix" option?

I think it should be part of the option.
Option "num" without number of digits uses a default of "%05",
otherwise the user can specify "num%03" for three leading zeros,
"num%07" for seven leading zeroes and so on. The option parser simply
scans for the keyword "num" and expects either a %  followed by
several digits or nothing to use the default "%05".

Best regards
Soeren

>> Best regards
>> Soeren
>>
>
> --
> 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

Re: [GRASS-dev] -s flag in temporal modules

2016-02-23 Thread Luca Delucchi

On 23 February 2016 at 17:59, Sören Gebbert
 wrote:
> Hi,

Hi,

> the "-s" flag is in use by many temporal modules for different
> purposes in grass71.

yes, could we try to simplify this using -s for only one purpose?

> Only the aggregation modules use "-s" flag to signal the usage of
> start time as suffix for basename creation.
> We should not change all the modules that make use of the flag "-s"
> for column name suppression or spatial topology activation.
>
> I would like to suggest that we do not use a flag for suffix
> specification, but instead an option for this purpose. Like "suffix"?
>
> The suffix option will specify which type should be created:
> * time with full format (time)  2001-01-01T00:00:00
> * time depending on the granularity (gran) 2001 or 2001-01 or 2001-01-01 ...
> * numerical suffix with a specific number of digits (num + %05, ...)
> "_0001" or "_01"
>
> Parameter for the option suffix: "time","num","gran" and C format
> specification like "%05" or "%03" in addition to num.
>
> What do you think?
>

make sense for me, I could implement "gran" and "num" during Paris
code sprint and if I have more time try to work also on "time".
Do you think the C format specification should be in other parameter
or inside the "suffix" option?

> Best regards
> Soeren
>

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

Re: [GRASS-dev] -s flag in temporal modules

2016-02-23 Thread Sören Gebbert

Hi,
the "-s" flag is in use by many temporal modules for different
purposes in grass71.
Only the aggregation modules use "-s" flag to signal the usage of
start time as suffix for basename creation.
We should not change all the modules that make use of the flag "-s"
for column name suppression or spatial topology activation.

I would like to suggest that we do not use a flag for suffix
specification, but instead an option for this purpose. Like "suffix"?

The suffix option will specify which type should be created:
* time with full format (time)  2001-01-01T00:00:00
* time depending on the granularity (gran) 2001 or 2001-01 or 2001-01-01 ...
* numerical suffix with a specific number of digits (num + %05, ...)
"_0001" or "_01"

Parameter for the option suffix: "time","num","gran" and C format
specification like "%05" or "%03" in addition to num.

What do you think?

Best regards
Soeren



2016-02-19 14:31 GMT+01:00 Luca Delucchi :
> Hi devs,
>
> according to this ticket [0] Soeren added the -s flag to
> t.rast.aggregate and t.rast.aggregate.ds, I would like to extend (I
> already started) this flag to all the temporal modules using basename
> option. I discovered that -s flag is used in other modules for other
> meanings.
> In grass70 the only modules with basename and -s are t.rast*.mapcalc
> (-s is used also by t.sample). In grass71 several other modules are
> using -s.
> I would like to standardize the -s for the "start time" and also the
> other flags in the temporal modules.
>
> I would like to modify trunk and release the new flags only in the
> next major release, what do you think?
>
> [0] https://trac.osgeo.org/grass/ticket/2294
>
> --
> 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] IAU to wkt C code (converted from Trent Hare's Python code)

2016-02-23 Thread Yann


Hi,

I am at the OSgeo Code Sprint in Paris, I have converted the Python 
script from Trent Hare to generate on the fly PROJCS and GEOCS 
WKTdescriptions for all IAU2000 and IAU2009.


I am now looking at inserting that info in GRASS to support these 
planetary projections.

Any help welcome, I am here 2 more days.

Cheers,
Yann

PS: GDAL is also going to insert it.

--
-
Yann Chemin
Address: 3 Toul Melin, 56400 Plumergat
Mobile: +33 (0)7 83 85 52 34

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

Re: [GRASS-dev] v.net.distance/path calculate the route in the reverse way

2016-02-23 Thread Moritz Lennert


On 23/02/16 15:44, Pedro Venâncio wrote:

Hi,

I was testing the v.net.distance (in QGIS) and noticed something
strange. Apparently the route is calculated in a reverse way.

If you see in this screencast

https://dl.dropboxusercontent.com/u/5772257/qgis/processing_grass_v_net_distance.ogv


I have a network of streets with two-way (green) and some with only
one-way (in red, with the arrow indicating the direction of traffic).
The two-way cost is in "dois_senti" field of the attribute table, and
the sections of one-way have -1 value in the "um_senti" field of the
attribute table.

The starting point is the orange pentagon ("ponto_inicio"), and the
destination point is the green star ("ponto_chegada").

As you can see, v.net.distance calculate the route in the reverse way,
that is, when I choose "ponto_inicio" as "from", and "ponto_chegada" as
"to" (first run in the screencast), it gives me the route by the south
("ponto_chegada" -> "ponto_inicio"). In the second run, I choose
"ponto_chegada" as "from", and "ponto_inicio" as "to", and it uses the
one-way street. So, the topology is respected, but it seems that "from"
and "to" are used in a reverse manner.

I thought it might be a mistake in implementing the tool in QGIS
Processing, but then I performed the same procedure on GRASS 7.0.2
native, and the result is the same.

Médéric Ribreux has done also some tests and concluded that from_layer
is used as to_layer.

It seems to be a GRASS problem because the point layers order is correct:
- layer 2 is imported from FROM_CENTERS QGIS layer.
- layer 3 is imported from TO_CENTERS QGIS layer.
- layer 2 is used as from_layer in v.net.distance.
- layer 3 is used as to_layer in v.net.distance.

He has tried with v.net.path and got the same results than for
v.net.distance.

Could it be a mis-interpretation of forward and backward costs? A bug?
Or simply how the tool works?



I cannot reproduce this with the NC demo data set;

v.net -c streets_wake op=nodes out=mynet
v.db.update map=mynet@user1 column=TF_COST value=-1 where=ONE_WAY='FT'
v.db.update map=mynet@user1 column=FT_COST value=-1 where=ONE_WAY='TF'
echo "1 7779 7780
2 7780 7779" | v.net.path mynet out=paths arc_column=FT_COST 
arc_backward_column=TF_COST


Display:
d.vect map=mynet@user1
d.vect map=mynet@user1 display=shape,dir where="ONE_WAY='FT' OR 
ONE_WAY='TF'" color=red attribute_column=ONE_WAY yref=top
d.vect map=mynet@user1 layer=2 display=shape,cat cats=7779-7780 
fill_color=255:165:0 icon=basic/circle label_layer=2
d.vect map=paths@user1 display=shape,cat cats=1 color=0:128:0 width=2 
label_color=0:128:0
d.vect map=paths@user1 display=shape,cat cats=2 color=128:0:128 width=2 
label_color=128:0:128


gives the expected result (see attached image).

Note that the line connecting 7779 and 7780 directly has a one_way value 
of 'TF' meaning that it is one-way in direction to-from, i.e. from 7780 
to 7779 (direction of the line being indicated by the arrows).


Errors can occur if the costs are not well-defined or too small. In the 
source code of the Vect_net_build_graph() function which builds the 
network graph the path is found upon, it says:


"Internal format for edge costs is integer, costs are multiplied before 
conversion to int by 1000"


This means that if you have a cost lower than 1/1000, you might end up 
with costs = 0.


This is noted as a todo in the source code:

"/* TODO int costs -> double (waiting for dglib) */"

But AFAICS, dglib still uses integers for costs.

This is not mentioned in the man page, and should be.

Please verify if this is the origin of your problem.

If yes, please post a bug report on bad documentation. If this isn't the 
problem, please post a bug report with a reproducible example.


Moritz


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

Re: [GRASS-dev] -s flag in temporal modules

2016-02-23 Thread Luca Delucchi

On 23 February 2016 at 15:52, Anna Petrášová  wrote:
>
>
> Are we releasing 7.1 from current trunk? Any way we can make the changes in
> 7.1 in a compatible way? If not (in case of t.sample) we might say the
> interface is a bug and fix it, I would like to avoid waiting for the changes
> till GRASS 8.
>

t.sample has no basename, so probably we could leave it as now. I also
would like to avoid to wait GRASS 8.

> Thanks,
> Anna
>


-- 
ciao
Luca

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

Re: [GRASS-dev] GRASS CMake build

2016-02-23 Thread Vaclav Petras

On Tue, Feb 23, 2016 at 7:02 AM, Rashad Kanavath 
wrote:
>
> Did anyone tried to add cmake build system to grass ?. It can even
co-exist with existing autoconf tools.

There is a repository with an exploratory effort to use CMake for GRASS GIS
[1] but there is a lack of CMake experts with time which can be dedicated
to mirroring current GRASS build.

Vaclav

[1] https://github.com/starseeker/grass
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] -s flag in temporal modules

2016-02-23 Thread Anna Petrášová

On Tue, Feb 23, 2016 at 9:02 AM, Luca Delucchi  wrote:

> On 19 February 2016 at 14:31, Luca Delucchi  wrote:
> > Hi devs,
> >
>
> Hi again,
>
> > according to this ticket [0] Soeren added the -s flag to
> > t.rast.aggregate and t.rast.aggregate.ds, I would like to extend (I
> > already started) this flag to all the temporal modules using basename
> > option. I discovered that -s flag is used in other modules for other
> > meanings.
> > In grass70 the only modules with basename and -s are t.rast*.mapcalc
> > (-s is used also by t.sample). In grass71 several other modules are
> > using -s.
> > I would like to standardize the -s for the "start time" and also the
> > other flags in the temporal modules.
> >
> > I would like to modify trunk and release the new flags only in the
> > next major release, what do you think?
> >
> > [0] https://trac.osgeo.org/grass/ticket/2294
> >
>
> nobody has to suggest a way to follow?
> without any comment against tomorrow I'll start to commit changes in trunk
>

Are we releasing 7.1 from current trunk? Any way we can make the changes in
7.1 in a compatible way? If not (in case of t.sample) we might say the
interface is a bug and fix it, I would like to avoid waiting for the
changes till GRASS 8.

Thanks,
Anna


>
> --
> ciao
> Luca
>
> 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] v.net.distance/path calculate the route in the reverse way

2016-02-23 Thread Pedro Venâncio

Hi,

I was testing the v.net.distance (in QGIS) and noticed something strange.
Apparently the route is calculated in a reverse way.

If you see in this screencast

https://dl.dropboxusercontent.com/u/5772257/qgis/processing_grass_v_net_distance.ogv

I have a network of streets with two-way (green) and some with only one-way
(in red, with the arrow indicating the direction of traffic). The two-way
cost is in "dois_senti" field of the attribute table, and the sections of
one-way have -1 value in the "um_senti" field of the attribute table.

The starting point is the orange pentagon ("ponto_inicio"), and the
destination point is the green star ("ponto_chegada").

As you can see, v.net.distance calculate the route in the reverse way, that
is, when I choose "ponto_inicio" as "from", and "ponto_chegada" as "to"
(first run in the screencast), it gives me the route by the south
("ponto_chegada" -> "ponto_inicio"). In the second run, I choose
"ponto_chegada" as "from", and "ponto_inicio" as "to", and it uses the
one-way street. So, the topology is respected, but it seems that "from" and
"to" are used in a reverse manner.

I thought it might be a mistake in implementing the tool in QGIS
Processing, but then I performed the same procedure on GRASS 7.0.2 native,
and the result is the same.

Médéric Ribreux has done also some tests and concluded that from_layer is
used as to_layer.

It seems to be a GRASS problem because the point layers order is correct:
- layer 2 is imported from FROM_CENTERS QGIS layer.
- layer 3 is imported from TO_CENTERS QGIS layer.
- layer 2 is used as from_layer in v.net.distance.
- layer 3 is used as to_layer in v.net.distance.

He has tried with v.net.path and got the same results than for
v.net.distance.

Could it be a mis-interpretation of forward and backward costs? A bug? Or
simply how the tool works?

Thanks!

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

Re: [GRASS-dev] -s flag in temporal modules

2016-02-23 Thread Luca Delucchi

On 19 February 2016 at 14:31, Luca Delucchi  wrote:
> Hi devs,
>

Hi again,

> according to this ticket [0] Soeren added the -s flag to
> t.rast.aggregate and t.rast.aggregate.ds, I would like to extend (I
> already started) this flag to all the temporal modules using basename
> option. I discovered that -s flag is used in other modules for other
> meanings.
> In grass70 the only modules with basename and -s are t.rast*.mapcalc
> (-s is used also by t.sample). In grass71 several other modules are
> using -s.
> I would like to standardize the -s for the "start time" and also the
> other flags in the temporal modules.
>
> I would like to modify trunk and release the new flags only in the
> next major release, what do you think?
>
> [0] https://trac.osgeo.org/grass/ticket/2294
>

nobody has to suggest a way to follow?
without any comment against tomorrow I'll start to commit changes in trunk


-- 
ciao
Luca

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

[GRASS-dev] GRASS CMake build

2016-02-23 Thread Rashad Kanavath

Hello all,

Did anyone tried to add cmake build system to grass ?. It can even co-exist
with existing autoconf tools.


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

[GRASS-dev] installing wx.metadata fails

2016-02-23 Thread Paulo van Breugel

I just tried to update the wx.metadata addon using g.extension (on grass 7
master), resulting in the error below:

(Tue Feb 23 09:55:19
2016)
g.extension extension=wx.metadata
url=
WARNING: Extension  already installed. Re-installing...
Fetching  from GRASS GIS Addons repository (be patient)...
Compiling...
Traceback (most recent call last):
  File "/tmp/grass7-paulo-8596/tmpWf3irR/wx.metadata/scripts
/db.csw.admin", line 127, in 
from mdlib.cswutil import *
ImportError: No module named mdlib.cswutil
make[1]: *** [db.csw.admin.tmp.html] Error 1
Traceback (most recent call last):
  File "/tmp/grass7-paulo-8596/tmpWf3irR/wx.metadata/scripts
/g.gui.cswbrowser", line 22, in 
from mdlib.cswlib import CSWBrowserPanel,
CSWConnectionPanel
ImportError: No module named mdlib.cswlib
make[1]: *** [g.gui.cswbrowser.tmp.html] Error 1
Traceback (most recent call last):
  File "/tmp/grass7-paulo-8596/tmpWf3irR/wx.metadata/scripts
/g.gui.metadata", line 43, in 
from mdlib import mdgrass
ImportError: No module named mdlib
make[1]: *** [g.gui.metadata.tmp.html] Error 1
Installing...
/usr/bin/install: cannot stat ‘/tmp/grass7-paulo-8596/tmpW
f3irR/wx.metadata/docs/html/db.csw.admin.html’: No such
file or directory
make[1]: *** [install] Error 1
/usr/bin/install: cannot stat ‘/tmp/grass7-paulo-8596/tmpW
f3irR/wx.metadata/docs/html/g.gui.cswbrowser.html’: No
such file or directory
make[1]: *** [install] Error 1
/usr/bin/install: cannot stat ‘/tmp/grass7-paulo-8596/tmpW
f3irR/wx.metadata/docs/html/g.gui.metadata.html’: No such
file or directory
make[1]: *** [install] Error 1
make: *** [installsubdirs] Error 2
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #2933: v.label issue

Re: [GRASS-dev] [GRASS GIS] #2838: d.labels placement issue

Re: [GRASS-dev] [GRASS GIS] #2932: z values read instead of intensity in r.in.lidar

Re: [GRASS-dev] [GRASS GIS] #2932: z values read instead of intensity in r.in.lidar

Re: [GRASS-dev] v.net.distance/path calculate the route in the reverse way

[GRASS-dev] [GRASS GIS] #2932: z values read instead of intensity in r.in.lidar

[GRASS-dev] [GRASS GIS] #2931: r.neighbors shifts output raster by 360 degrees (WGS 84)

Re: [GRASS-dev] -s flag in temporal modules

Re: [GRASS-dev] -s flag in temporal modules

Re: [GRASS-dev] -s flag in temporal modules

[GRASS-dev] IAU to wkt C code (converted from Trent Hare's Python code)

Re: [GRASS-dev] v.net.distance/path calculate the route in the reverse way

Re: [GRASS-dev] -s flag in temporal modules

Re: [GRASS-dev] GRASS CMake build

Re: [GRASS-dev] -s flag in temporal modules

[GRASS-dev] v.net.distance/path calculate the route in the reverse way

Re: [GRASS-dev] -s flag in temporal modules

[GRASS-dev] GRASS CMake build

[GRASS-dev] installing wx.metadata fails

19 matches

Site Navigation

Mail list logo

Footer information