Re: [GRASS-dev] [GRASS GIS] #3077: r.colors: flag to output color table type and value range

[GRASS GIS]

#3077: r.colors: flag to output color table type and value range
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.2.1
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  r.colors, v.colors, cartography
   CPU:  All  |   Platform:  All
--+-
Changes (by neteler):

 * keywords:  r.colors, gsoc2016, cartography => r.colors, v.colors,
 cartography
 * milestone:  7.2.0 => 7.2.1


Comment:

 I like you proposal, how hard would it be to be implemented?

--
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] #3210: r.texture: bug when non continuous series of values

[GRASS GIS]

#3210: r.texture: bug when non continuous series of values
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  reopened
  Priority:  normal   |  Milestone:  7.2.0
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  r.texture
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mmetz):

 Replying to [comment:32 mlennert]:
 > Replying to [comment:31 mmetz]:
 > > Replying to [comment:28 mlennert]:
 > > > Replying to [comment:27 mmetz]:
 > > > >
 > > > > We could remove cropping at margins, the results would not be
 perfect, but better than nothing.
 > > >
 > > > That's debatable. In my colleagues tests we saw that PCI Geomatica
 "solves" this problem by just replicating the margin row/col as many times
 as necessary depending on window size. This leads to weird textures at the
 margins.
 > >
 > > Inventing values is a bad idea.
 > > >
 > > > Another (IMHO preferrable) option would be to calculate the texture
 with just the available pixels, but this would mean that for a 3x3 window
 you would only have one neighbor in each direction (except for the n-s or
 e-w). Don't know if this is an issue ?
 > >
 > > I would use just the available pixels, the question is then more
 general, how to handle NULL cells, also inside the current region. If NULL
 cells are allowed, there is no reason to crop at the margins. If NULL
 cells are not allowed, any moving window that contains NULL cells would be
 skipped, also very large moving windows with only a single NULL cell.
 Therefore I would prefer to allow NULL cells.
 >
 > +1

 I have added a flag to allow NULL cells which also avoids cropping along
 edges of the computational region in trunk r69965.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] how to reproject a raster map with absolute numbers without losing data

[Markus Metz]

On Thu, Dec 1, 2016 at 12:01 PM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:
>
> On 30/11/16 09:40, Paulo van Breugel wrote:
>>
>>
>>> On Tue, Nov 29, 2016 at 5:44 PM, Moritz Lennert
>
>
>>>
>>> > An area() function in r.mapcalc would be nice...
[...]
>
>> |r.mapcalc "rcs = (sin(y()+$nsres/2) - sin(y()-$nsres/2)) * ($ewres *
>> $PI/180) * float($a)^2";|
>>
>
> I tested this approach as well. I.e.
>
> area = above formula
> pop_density = pop / area
>
> reproject pop_density
>
> pop = pop_density * (ewres*nsres)
>
> It is faster than the r.in.xyz approach. But it does not seem to be as
precise.
>
> I still lost about 100.000 inhabitants, and more when I smooth more (the
"loss" increases from nearest neighbor to bilinear to bicubic).
>
> In order to avoid precision issues, I tried with both density by m2 and
density by km2, but results are similar.
>
> I don't know which part of the error comes from the use of spheroid
approximation and which part comes from the resampling at reprojection.
>
> But I do think that if it is important to maintain exact totals, then the
r.to.vect - v.proj - v.out.ascii - r.in.xyz solution seems to be more
reliable.

But with this approach you get spatial artefacts. Assume there are 9 cell
in source with

10 10 10
10 10 10
10 10 10

they can become in target e.g.

10  0 20
10  0 20
10 10 10

Total count is maintained, but some target cells might receive no source
cell whereas other target cells might receive more than one source cell.

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

Re: [GRASS-dev] how to reproject a raster map with absolute numbers without losing data

[Paulo van Breugel]

On Thu, Dec 1, 2016 at 2:31 PM, Markus Metz 
wrote:

>
>
> On Thu, Dec 1, 2016 at 1:16 PM, Paulo van Breugel 
> wrote:
> >
> >
> >
> > On 01-12-16 12:01, Moritz Lennert wrote:
> >>
> >> On 30/11/16 09:40, Paulo van Breugel wrote:
> >>>
> >>>
>  On Tue, Nov 29, 2016 at 5:44 PM, Moritz Lennert
> >>
> >>
> 
>  > An area() function in r.mapcalc would be nice...
> >>>
> >>>
> >>> Would indeed be a nice addition, but it isn't too difficult to compute,
> >>> using:
> >>>
> >>> |g.region rast=afripop10@PERMANENT|
> >>> |PI=3.1415926536 <0415%20926%20536>|
> >>> |export `g.region -g`|
> >>> |export `g.proj -j`|
> >>
> >>
> >> This doesn't work for me as the output is
> >>
> >> g.proj -j
> >>
> >> +proj=longlat
> >> +no_defs
> >> +a=6378137
> >> +rf=298.257223563
> >> +towgs84=0.000,0.000,0.000
> >>
> >> and +a is not acceptable as variable name.
> >
> >
> > You are right, that should  be g.proj -g I think
> >
> >>
> >>> |r.mapcalc "rcs = (sin(y()+$nsres/2) - sin(y()-$nsres/2)) * ($ewres *
> >>> $PI/180) * float($a)^2";|
> >>>
> >>
> >> I tested this approach as well. I.e.
> >>
> >> area = above formula
> >> pop_density = pop / area
> >>
> >> reproject pop_density
> >>
> >> pop = pop_density * (ewres*nsres)
> >>
> >> It is faster than the r.in.xyz approach. But it does not seem to be as
> precise.
> >>
> >> I still lost about 100.000 inhabitants, and more when I smooth more
> (the "loss" increases from nearest neighbor to bilinear to bicubic).
>
> Note that some of the loss happens when a non-zero cell is bordering a
> NULL cell, unless you use one of the *_f interpolation methods.
> >
> >
> > Just guessing, but an issue I had in the past with layers like Afripop
> is that it may contain cells with extremely high values (a result of the
> inter/extrapolation methods used to create those layers I guess, not sure
> it is an issue for e.g., Wordpop). Depending on the resampling method, this
> could also add to the differences in totals.
> >
> >>
> >> In order to avoid precision issues, I tried with both density by m2 and
> density by km2, but results are similar.
>
> Why not per hectare? The target cell size is close to one hectare, it
> could be set to exactly one hectare.
> >
> > Does it make a difference if you use a much higher target resolution?
>
> In theory, a higher target resolution should result in a higher total sum,
> a lower target resolution in a lower total sum.
> >>
> >>
> >> I don't know which part of the error comes from the use of spheroid
> approximation and which part comes from the resampling at reprojection.
> >
> >
> > It would be interesting to see how results are if using the same routine
> as above (convert to densities, reproject, convert back to totals), but
> using the more precise G_area_of_cell_at_row() function to compute the cell
> areas.
>
> Try the new area() function of r.mapcalc ;-)
>

Missed that in the meantime it was already implemented, awesome!


>
> in the source location
> record absolute count as src_count
> convert absolute count to density per hectare with
> r.mapcalc "pop_dens_ha = 1.0 * pop_count / area()"
>
> in the target location
> set the region according to r.proj -g
> use reasonable grid geometry with e.g. g.region -pa res=100
> reproject pop_dens_ha with r.proj method=bilinear_f
> now density is equal to the absolute count because density is per hectare
> and cell size is 1 square meter
> record absolute count as tgt_count
>
> fix any deviations between src_count and tgt_count with
> r.mapcalc "pop_count_calibrated = pop_dens_ha * $src_count / $tgt_count"
>
> this calbration could also be done for administrative units separately
>
> Markus M
> >
> >
> >>
> >> But I do think that if it is important to maintain exact totals, then
> the r.to.vect - v.proj - v.out.ascii - r.in.xyz solution seems to be more
> reliable.
> >>
> >> Moritz
> >>
> >>
> >
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] how to reproject a raster map with absolute numbers without losing data

[Markus Metz]

On Thu, Dec 1, 2016 at 1:16 PM, Paulo van Breugel 
wrote:
>
>
>
> On 01-12-16 12:01, Moritz Lennert wrote:
>>
>> On 30/11/16 09:40, Paulo van Breugel wrote:
>>>
>>>
 On Tue, Nov 29, 2016 at 5:44 PM, Moritz Lennert
>>
>>

 > An area() function in r.mapcalc would be nice...
>>>
>>>
>>> Would indeed be a nice addition, but it isn't too difficult to compute,
>>> using:
>>>
>>> |g.region rast=afripop10@PERMANENT|
>>> |PI=3.1415926536|
>>> |export `g.region -g`|
>>> |export `g.proj -j`|
>>
>>
>> This doesn't work for me as the output is
>>
>> g.proj -j
>>
>> +proj=longlat
>> +no_defs
>> +a=6378137
>> +rf=298.257223563
>> +towgs84=0.000,0.000,0.000
>>
>> and +a is not acceptable as variable name.
>
>
> You are right, that should  be g.proj -g I think
>
>>
>>> |r.mapcalc "rcs = (sin(y()+$nsres/2) - sin(y()-$nsres/2)) * ($ewres *
>>> $PI/180) * float($a)^2";|
>>>
>>
>> I tested this approach as well. I.e.
>>
>> area = above formula
>> pop_density = pop / area
>>
>> reproject pop_density
>>
>> pop = pop_density * (ewres*nsres)
>>
>> It is faster than the r.in.xyz approach. But it does not seem to be as
precise.
>>
>> I still lost about 100.000 inhabitants, and more when I smooth more (the
"loss" increases from nearest neighbor to bilinear to bicubic).

Note that some of the loss happens when a non-zero cell is bordering a NULL
cell, unless you use one of the *_f interpolation methods.
>
>
> Just guessing, but an issue I had in the past with layers like Afripop is
that it may contain cells with extremely high values (a result of the
inter/extrapolation methods used to create those layers I guess, not sure
it is an issue for e.g., Wordpop). Depending on the resampling method, this
could also add to the differences in totals.
>
>>
>> In order to avoid precision issues, I tried with both density by m2 and
density by km2, but results are similar.

Why not per hectare? The target cell size is close to one hectare, it could
be set to exactly one hectare.
>
> Does it make a difference if you use a much higher target resolution?

In theory, a higher target resolution should result in a higher total sum,
a lower target resolution in a lower total sum.
>>
>>
>> I don't know which part of the error comes from the use of spheroid
approximation and which part comes from the resampling at reprojection.
>
>
> It would be interesting to see how results are if using the same routine
as above (convert to densities, reproject, convert back to totals), but
using the more precise G_area_of_cell_at_row() function to compute the cell
areas.

Try the new area() function of r.mapcalc ;-)

in the source location
record absolute count as src_count
convert absolute count to density per hectare with
r.mapcalc "pop_dens_ha = 1.0 * pop_count / area()"

in the target location
set the region according to r.proj -g
use reasonable grid geometry with e.g. g.region -pa res=100
reproject pop_dens_ha with r.proj method=bilinear_f
now density is equal to the absolute count because density is per hectare
and cell size is 1 square meter
record absolute count as tgt_count

fix any deviations between src_count and tgt_count with
r.mapcalc "pop_count_calibrated = pop_dens_ha * $src_count / $tgt_count"

this calbration could also be done for administrative units separately

Markus M
>
>
>>
>> But I do think that if it is important to maintain exact totals, then
the r.to.vect - v.proj - v.out.ascii - r.in.xyz solution seems to be more
reliable.
>>
>> Moritz
>>
>>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] how to reproject a raster map with absolute numbers without losing data

[Paulo van Breugel]

On 01-12-16 12:01, Moritz Lennert wrote:

On 30/11/16 09:40, Paulo van Breugel wrote:



On Tue, Nov 29, 2016 at 5:44 PM, Moritz Lennert




> An area() function in r.mapcalc would be nice...


Would indeed be a nice addition, but it isn't too difficult to compute,
using:

|g.region rast=afripop10@PERMANENT|
|PI=3.1415926536|
|export `g.region -g`|
|export `g.proj -j`|


This doesn't work for me as the output is

g.proj -j

+proj=longlat
+no_defs
+a=6378137
+rf=298.257223563
+towgs84=0.000,0.000,0.000

and +a is not acceptable as variable name.


You are right, that should  be g.proj -g I think




|r.mapcalc "rcs = (sin(y()+$nsres/2) - sin(y()-$nsres/2)) * ($ewres *
$PI/180) * float($a)^2";|



I tested this approach as well. I.e.

area = above formula
pop_density = pop / area

reproject pop_density

pop = pop_density * (ewres*nsres)

It is faster than the r.in.xyz approach. But it does not seem to be as 
precise.


I still lost about 100.000 inhabitants, and more when I smooth more 
(the "loss" increases from nearest neighbor to bilinear to bicubic).


Just guessing, but an issue I had in the past with layers like Afripop 
is that it may contain cells with extremely high values (a result of the 
inter/extrapolation methods used to create those layers I guess, not 
sure it is an issue for e.g., Wordpop). Depending on the resampling 
method, this could also add to the differences in totals.




In order to avoid precision issues, I tried with both density by m2 
and density by km2, but results are similar.

Does it make a difference if you use a much higher target resolution?


I don't know which part of the error comes from the use of spheroid 
approximation and which part comes from the resampling at reprojection.


It would be interesting to see how results are if using the same routine 
as above (convert to densities, reproject, convert back to totals), but 
using the more precise G_area_of_cell_at_row() function to compute the 
cell areas.




But I do think that if it is important to maintain exact totals, then 
the r.to.vect - v.proj - v.out.ascii - r.in.xyz solution seems to be 
more reliable.


Moritz




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

Re: [GRASS-dev] Fwd: [Belgium] Fwd: [OSGeo-Discuss] Geospatial devroom at FOSDEM 2017 on Sunday 5/2/2017 in Brussels

[Moritz Lennert]

Le 1 décembre 2016 12:32:39 GMT+01:00, Moritz Lennert 
 a écrit :
>There have been discussions about a GRASS presentation at FOSDEM, but 
>I'm just too overloaded to take the lead on this. I'm willing to help 
>though.
>
>Anyone else planning on coming to Brussels ?
>
>Topics that have been suggested in previous discussions:
>
>- testing framework
>- raster compression performance, including null file compression
>- easy/automatic GUI programming through declarative programming
>


Another idea: Temporal GRASS GIS




>If someone can prepare slides I am willing to present them, but as I 
>said, I cannot take the lead on this. So, if someone is willing to do 
>that part of the work, but cannot be present at FOSDEM, just go ahead
>an 
>submit a proposal.
>
>Moritz
>
>
>
>
> Forwarded Message 
>Subject: [Belgium] Fwd: [OSGeo-Discuss] Geospatial devroom at FOSDEM 
>2017 on Sunday 5/2/2017 in Brussels
>Date: Thu, 1 Dec 2016 12:05:40 +0100
>From: Johan Van de Wauw 
>To: belg...@lists.osgeo.org 
>
>Reminder: we have a call for papers for the geospatial devroom at
>FOSDEM ending tonight!
>
>Kind Regards,
>Johan
>
>-- Forwarded message --
>From: Johan Van de Wauw 
>Date: Thu, Nov 24, 2016 at 10:19 PM
>Subject: Re: [OSGeo-Discuss] Geospatial devroom at FOSDEM 2017 on
>Sunday 5/2/2017 in Brussels
>To: OSGeo Discussions , Margherita Di Leo
>
>
>
>Hi all,
>
>This is a gentle reminder for the call for participation for the
>geospatial devroom at FOSDEM.
>For those of you who don't know FOSDEM, it is one of the biggest open
>source conferences, and a highly developer oriented one. Next to the
>geospatial devroom there will be lots of other talks in the main
>tracks and devrooms [1].
>I'm sure it is also interesting for everyone active in OSGeo - so go
>ahead and submit :-)
>
>Hope to see many of you in Brussels
>Johan
>[1] https://fosdem.org/2017/news/2016-10-10-accepted-developer-rooms/
>
>On Thu, Oct 13, 2016 at 4:54 PM, Margherita Di Leo 
>
>wrote:
>> Call for Presentations
>>
>> Please forward!
>>
>>
>> FOSDEM is a free and non-commercial event bringing together about
>5000
>> developers in Brussels, Belgium. The goal is to provide open source
>software
>> developers and communities a place to meet and share thoughts. The
>> participation is free of charge, although donations are welcome. The
>next
>> edition will take place on 4 - 5 February 2017. For the third (!)
>time there
>> will be a Geospatial devroom and will be happening on Sunday
>5/2/2017!
>>
>> Geospatial technologies and mapping used to be specialist work, but
>nowadays
>> location and maps are becoming part of many projects/applications,
>which
>> usually use only a small subset of the possibilities the data and
>software
>> offer.
>>
>> The geospatial devroom is the place to talk about open, geo-related
>data and
>> software and their ecosystem. This includes standards and tools, e.g.
>for
>> spatial databases, and online mapping, geospatial services, used for
>> collecting, storing, delivering, analysing, and visualizing purposes.
>>
>> We welcome submissions about:
>>
>> Web and desktop GIS applications;
>>
>> Collaborative editing / versioning of geodata and metadata;
>>
>> Interoperable geospatial web services and specifications;
>>
>> Collection of data using sensors / UAVs / satellites;
>>
>> Geo-analytic algorithms / libraries;
>>
>> Geospatial extensions for classical databases (indexes, operations)
>and
>> dedicated databases;
>>
>> Big geodata, scalable GIS applications;
>>
>> Volunteered Geographic information - Crowdsourced geodata.
>>
>>
>> HOW TO SUBMIT YOUR PROPOSAL FOR A TALK
>>
>>
>> Are you thrilled to present your work to other open source
>developers? Would
>> you like to run a discussion? Any other ideas?
>>
>> Please submit your proposal at:
>>
>>  https://fosdem.org/submit
>>
>> Make sure to select the 'Geospatial devroom' as 'Track'. If you have
>an
>> account from previous years, you should be using the same.
>>
>> Please specify in the notes if you prefer for your presentation
>either a
>> short timeslot (lightning talks ~10 minutes) or a long timeslot (20
>minutes
>> presentation + discussion). However, note that time slots are
>indicative and
>> will be assigned according to the timing of the session.
>>
>>
>> The DEADLINE for submissions is Thursday **1st December 2016**.
>>
>> Notification of acceptance will be sent to the Authors by 11/12/2016
>at the
>> latest.
>>
>> Should you have any questions, please do not hesitate to get in touch
>with
>> the organisers of the devroom at fosdem-geospatial at gisky.be!
>>
>> Want to know what FOSDEM geospatial is like? Check out the videos and
>the
>> presentations of our previous two editions: [1,2]
>>
>>
>> The organizers
>>
>> Johan Van de Wauw
>>
>> Margherita Di Leo
>>
>> 

[GRASS-dev] Fwd: [Belgium] Fwd: [OSGeo-Discuss] Geospatial devroom at FOSDEM 2017 on Sunday 5/2/2017 in Brussels

[Moritz Lennert]

There have been discussions about a GRASS presentation at FOSDEM, but 
I'm just too overloaded to take the lead on this. I'm willing to help 
though.


Anyone else planning on coming to Brussels ?

Topics that have been suggested in previous discussions:

- testing framework
- raster compression performance, including null file compression
- easy/automatic GUI programming through declarative programming

If someone can prepare slides I am willing to present them, but as I 
said, I cannot take the lead on this. So, if someone is willing to do 
that part of the work, but cannot be present at FOSDEM, just go ahead an 
submit a proposal.


Moritz




 Forwarded Message 
Subject: [Belgium] Fwd: [OSGeo-Discuss] Geospatial devroom at FOSDEM 
2017 on Sunday 5/2/2017 in Brussels

Date: Thu, 1 Dec 2016 12:05:40 +0100
From: Johan Van de Wauw 
To: belg...@lists.osgeo.org 

Reminder: we have a call for papers for the geospatial devroom at
FOSDEM ending tonight!

Kind Regards,
Johan

-- Forwarded message --
From: Johan Van de Wauw 
Date: Thu, Nov 24, 2016 at 10:19 PM
Subject: Re: [OSGeo-Discuss] Geospatial devroom at FOSDEM 2017 on
Sunday 5/2/2017 in Brussels
To: OSGeo Discussions , Margherita Di Leo



Hi all,

This is a gentle reminder for the call for participation for the
geospatial devroom at FOSDEM.
For those of you who don't know FOSDEM, it is one of the biggest open
source conferences, and a highly developer oriented one. Next to the
geospatial devroom there will be lots of other talks in the main
tracks and devrooms [1].
I'm sure it is also interesting for everyone active in OSGeo - so go
ahead and submit :-)

Hope to see many of you in Brussels
Johan
[1] https://fosdem.org/2017/news/2016-10-10-accepted-developer-rooms/

On Thu, Oct 13, 2016 at 4:54 PM, Margherita Di Leo  
wrote:

Call for Presentations

Please forward!


FOSDEM is a free and non-commercial event bringing together about 5000
developers in Brussels, Belgium. The goal is to provide open source software
developers and communities a place to meet and share thoughts. The
participation is free of charge, although donations are welcome. The next
edition will take place on 4 - 5 February 2017. For the third (!) time there
will be a Geospatial devroom and will be happening on Sunday 5/2/2017!

Geospatial technologies and mapping used to be specialist work, but nowadays
location and maps are becoming part of many projects/applications, which
usually use only a small subset of the possibilities the data and software
offer.

The geospatial devroom is the place to talk about open, geo-related data and
software and their ecosystem. This includes standards and tools, e.g. for
spatial databases, and online mapping, geospatial services, used for
collecting, storing, delivering, analysing, and visualizing purposes.

We welcome submissions about:

Web and desktop GIS applications;

Collaborative editing / versioning of geodata and metadata;

Interoperable geospatial web services and specifications;

Collection of data using sensors / UAVs / satellites;

Geo-analytic algorithms / libraries;

Geospatial extensions for classical databases (indexes, operations) and
dedicated databases;

Big geodata, scalable GIS applications;

Volunteered Geographic information - Crowdsourced geodata.


HOW TO SUBMIT YOUR PROPOSAL FOR A TALK


Are you thrilled to present your work to other open source developers? Would
you like to run a discussion? Any other ideas?

Please submit your proposal at:

 https://fosdem.org/submit

Make sure to select the 'Geospatial devroom' as 'Track'. If you have an
account from previous years, you should be using the same.

Please specify in the notes if you prefer for your presentation either a
short timeslot (lightning talks ~10 minutes) or a long timeslot (20 minutes
presentation + discussion). However, note that time slots are indicative and
will be assigned according to the timing of the session.


The DEADLINE for submissions is Thursday **1st December 2016**.

Notification of acceptance will be sent to the Authors by 11/12/2016 at the
latest.

Should you have any questions, please do not hesitate to get in touch with
the organisers of the devroom at fosdem-geospatial at gisky.be!

Want to know what FOSDEM geospatial is like? Check out the videos and the
presentations of our previous two editions: [1,2]


The organizers

Johan Van de Wauw

Margherita Di Leo

Anne Ghisla

Martin Hammitzsch

[1] https://archive.fosdem.org/2015/schedule/track/geospatial/

[2] https://archive.fosdem.org/2016/schedule/track/geospatial/



--
Margherita Di Leo

___
Discuss mailing list
disc...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

___
Belgium mailing list
belg...@lists.osgeo.org

Re: [GRASS-dev] [GRASS-SVN] r69960 - grass/trunk/vector/v.proj

[Moritz Lennert]

On 01/12/16 11:20, Markus Neteler wrote:

Hi Moritz,

On Thu, Dec 1, 2016 at 11:16 AM,   wrote:

Author: mlennert
Date: 2016-12-01 02:16:36 -0800 (Thu, 01 Dec 2016)
New Revision: 69960

Modified:
   grass/trunk/vector/v.proj/main.c
Log:
v.proj: add no topology flag


...

+flag.no_topol = G_define_flag();
+flag.no_topol->key = 'b';
+flag.no_topol->label = _("Do not build vector topology");
+flag.no_topol->description = _("Recommended for massive point conversion");


I'd suggest to rephrase it to
_("Recommended for massive point reprojection");

to avoid confusion (unless there is a particular reason to use
"conversion" here which sounds like format change to me).


Agreed and done in r69961 (including adding mention of the flag in the 
man page).


The wording was the result of a shameless copy and paste from r.to.vect 
and so of my laziness...


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

Re: [GRASS-dev] how to reproject a raster map with absolute numbers without losing data

[Moritz Lennert]

On 30/11/16 09:40, Paulo van Breugel wrote:



On Tue, Nov 29, 2016 at 5:44 PM, Moritz Lennert




> An area() function in r.mapcalc would be nice...


Would indeed be a nice addition, but it isn't too difficult to compute,
using:

|g.region rast=afripop10@PERMANENT|
|PI=3.1415926536|
|export `g.region -g`|
|export `g.proj -j`|


This doesn't work for me as the output is

g.proj -j

+proj=longlat
+no_defs
+a=6378137
+rf=298.257223563
+towgs84=0.000,0.000,0.000

and +a is not acceptable as variable name.


|r.mapcalc "rcs = (sin(y()+$nsres/2) - sin(y()-$nsres/2)) * ($ewres *
$PI/180) * float($a)^2";|



I tested this approach as well. I.e.

area = above formula
pop_density = pop / area

reproject pop_density

pop = pop_density * (ewres*nsres)

It is faster than the r.in.xyz approach. But it does not seem to be as 
precise.


I still lost about 100.000 inhabitants, and more when I smooth more (the 
"loss" increases from nearest neighbor to bilinear to bicubic).


In order to avoid precision issues, I tried with both density by m2 and 
density by km2, but results are similar.


I don't know which part of the error comes from the use of spheroid 
approximation and which part comes from the resampling at reprojection.


But I do think that if it is important to maintain exact totals, then 
the r.to.vect - v.proj - v.out.ascii - r.in.xyz solution seems to be 
more reliable.


Moritz


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

Re: [GRASS-dev] [GRASS-SVN] r69960 - grass/trunk/vector/v.proj

[Markus Neteler]

Hi Moritz,

On Thu, Dec 1, 2016 at 11:16 AM,   wrote:
> Author: mlennert
> Date: 2016-12-01 02:16:36 -0800 (Thu, 01 Dec 2016)
> New Revision: 69960
>
> Modified:
>grass/trunk/vector/v.proj/main.c
> Log:
> v.proj: add no topology flag

...
> +flag.no_topol = G_define_flag();
> +flag.no_topol->key = 'b';
> +flag.no_topol->label = _("Do not build vector topology");
> +flag.no_topol->description = _("Recommended for massive point 
> conversion");

I'd suggest to rephrase it to
_("Recommended for massive point reprojection");

to avoid confusion (unless there is a particular reason to use
"conversion" here which sounds like format change to me).

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

Re: [GRASS-dev] how to reproject a raster map with absolute numbers without losing data

[Moritz Lennert]

On 01/12/16 08:49, Markus Metz wrote:


r.to.vect converts only non-null cells, no mask needed, at least for me
in trunk.


Weird, I waws convinced that I saw otherwise before, but now I can 
confirm. Sorry for the noise...





>2. reproject these vector points to the target location

I locally modified v.proj to add a 'Don't build topology' flag.

Is there any indication against this ?


No.


Ok, added in trunk with r69960.



>
>The method options of r.in.xyz  could be added to

r.proj for spatial

>aggregation, but that would mean that most of the code of r.in.xyz



>would
>need to be copied to r.proj, then adapted. That would be an interesting
>enhancement, also considering that gdalwarp offers as resampling
>methods
>near, bilinear, cubic, cubicspline, lanczos, average, mode, max, min,
>med,
>Q1, Q3.

But it doesn't offer sum


True, but it offers statistical aggregates. And for average, you need to
have the sum internally anyway, then divide by the cell count (number of
source cells falling into the current target cell), at least this is how
I imagine how average would be calculated.


True ;-)

Moritz

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

Re: [GRASS-dev] t.register ruins end timestamps

[Sören Gebbert]

Seems to be a bug in t.register if it still ruins the timestamp.
However, try this with the increment option:
t.register input=test maps=clip start='1987-02-26 09:12:36' -i incr="1
second"

This works only for a single map.

Question: why are you using r.timestamp to set the timestamps? It is not a
good idea to use them in conjunction with the temporal framework.

Am 01.12.2016 10:08 AM schrieb "Martin Landa" :

> Hi,
>
> 2016-12-01 9:19 GMT+01:00 Sören Gebbert :
> > Skip the interval option, it is not required if you specify a time
> interval
> > in the raster metadata or in an input file.
>
> it doesn't seems to work or I am still missing something. I fixed
> timestamps to (1 second interval):
>
> $ r.timestamp clip_LT51910261987057XXX02_B1
> 26 Feb 1987 09:12:36 / 26 Feb 1987 09:12:37
>
> $ t.register input=test maps=clip_LT51910261987057XXX02_B1 --o
>
> Still ruins end time timestamp:
>
> $ r.timestamp clip_LT51910261987057XXX02_B1
> 26 Feb 1987 09:12:36
>
> t.register fails with -i or increment='1 seconds':
> ERROR: The increment option requires the start option
>
> ? Ma
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] t.register ruins end timestamps

[Martin Landa]

Hi,

2016-12-01 9:19 GMT+01:00 Sören Gebbert :
> Skip the interval option, it is not required if you specify a time interval
> in the raster metadata or in an input file.

it doesn't seems to work or I am still missing something. I fixed
timestamps to (1 second interval):

$ r.timestamp clip_LT51910261987057XXX02_B1
26 Feb 1987 09:12:36 / 26 Feb 1987 09:12:37

$ t.register input=test maps=clip_LT51910261987057XXX02_B1 --o

Still ruins end time timestamp:

$ r.timestamp clip_LT51910261987057XXX02_B1
26 Feb 1987 09:12:36

t.register fails with -i or increment='1 seconds':
ERROR: The increment option requires the start option

? Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] t.register ruins end timestamps

[Martin Landa]

Hi,

2016-12-01 9:24 GMT+01:00 Sören Gebbert :
> The timestamp "24 Sep 2011 09:39:44 / 24 Sep 2011 09:39:45" has a one second
> interval, hence its interval time in the temporal framework. If the start
> and end time are equal its a time instance with no duration, hence it has no
> end time. No interval no end-time.

I see :-) Sorry, no I got it. Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] t.register ruins end timestamps

[Veronica Andreo]

Hi Martin,

Some time ago, I tried to exemplify most ways of registering maps in time
series in this wiki:
https://grasswiki.osgeo.org/wiki/Temporal_data_processing/maps_registration

please, change and enhance as needed :)

Vero

2016-12-01 9:19 GMT+01:00 Sören Gebbert :

> Skip the interval option, it is not required if you specify a time
> interval in the raster metadata or in an input file.
>
> 2016-12-01 9:17 GMT+01:00 Martin Landa :
>
>> Hi,
>>
>> 2016-12-01 9:10 GMT+01:00 Luca Delucchi :
>> >> $ r.timestamp clip_LT51910262011267KIS01_B1
>> >> 24 Sep 2011 09:39:44 / 24 Sep 2011 09:39:44
>> >>
>> >> After registration to spatial-temporal dataset:
>> >>
>> >> $ t.register inp=test maps=clip_LT51910262011267KIS01_B
>>
>> yes, but than t.register fails:
>>
>> t.register inp=test maps=clip_LT51910262011267KIS01_B1 --o -i
>> WARNING: Temporal database connection defined as:
>> /work/geodata/grassdata/zddp-landsat/PERMANENT/tgis/sqlite.db
>> But database file does not exist.
>> ERROR: The interval flag requires the start option
>>
>> Start option should be taken from timestamp, or? Ma
>>
>> --
>> Martin Landa
>> http://geo.fsv.cvut.cz/gwiki/Landa
>> http://gismentors.cz/mentors/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 mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] t.register ruins end timestamps

[Sören Gebbert]

Skip the interval option, it is not required if you specify a time interval
in the raster metadata or in an input file.

2016-12-01 9:17 GMT+01:00 Martin Landa :

> Hi,
>
> 2016-12-01 9:10 GMT+01:00 Luca Delucchi :
> >> $ r.timestamp clip_LT51910262011267KIS01_B1
> >> 24 Sep 2011 09:39:44 / 24 Sep 2011 09:39:44
> >>
> >> After registration to spatial-temporal dataset:
> >>
> >> $ t.register inp=test maps=clip_LT51910262011267KIS01_B
>
> yes, but than t.register fails:
>
> t.register inp=test maps=clip_LT51910262011267KIS01_B1 --o -i
> WARNING: Temporal database connection defined as:
> /work/geodata/grassdata/zddp-landsat/PERMANENT/tgis/sqlite.db
> But database file does not exist.
> ERROR: The interval flag requires the start option
>
> Start option should be taken from timestamp, or? Ma
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/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] t.register ruins end timestamps

[Martin Landa]

Hi,

2016-12-01 9:14 GMT+01:00 Sören Gebbert :
> You time stamp is a time instance with no duration, hence its not an

see r.timestamp, than what means syntax datetime1/datetime2?

> interval. Introduce a interval of one second and it should work as expected.

Do you mean:

$ t.register inp=test maps=clip_LT51910262011267KIS01_B1 --o inc='1 seconds'
ERROR: The increment option requires the start option

? Why start option needs to be given? There is timestamp which defines
start, right? Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] t.register ruins end timestamps

[Martin Landa]

Hi,

2016-12-01 9:10 GMT+01:00 Luca Delucchi :
>> $ r.timestamp clip_LT51910262011267KIS01_B1
>> 24 Sep 2011 09:39:44 / 24 Sep 2011 09:39:44
>>
>> After registration to spatial-temporal dataset:
>>
>> $ t.register inp=test maps=clip_LT51910262011267KIS01_B

yes, but than t.register fails:

t.register inp=test maps=clip_LT51910262011267KIS01_B1 --o -i
WARNING: Temporal database connection defined as:
/work/geodata/grassdata/zddp-landsat/PERMANENT/tgis/sqlite.db
But database file does not exist.
ERROR: The interval flag requires the start option

Start option should be taken from timestamp, or? Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] t.register ruins end timestamps

[Martin Landa]

Hi,

I have raster maps with timestamp defined as eg.

$ r.timestamp clip_LT51910262011267KIS01_B1
24 Sep 2011 09:39:44 / 24 Sep 2011 09:39:44

After registration to spatial-temporal dataset:

$ t.register inp=test maps=clip_LT51910262011267KIS01_B

the timestamp is changed to

$ r.timestamp clip_LT51910262011267KIS01_B1
24 Sep 2011 09:39:44

The end time is removed:

$ t.rast.list test
clip_LT51910262011267KIS01_B1|pisek_tabor|2011-09-24 09:39:44|None

Or I am doing something wrong? Thanks, Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev