Hi list.
I can't get wrs2_descending.shp file (from <http://landsat.usgs.gov/documents/wrs2_descending.zip>\) to import sans errors (grass7). No matter the snap threshold. Anyone recently imported it?
Thanks, Nikos
Apologies for BUMPing. Anyone recently worked with this very data set?
Nikos
On 15.12.2014 12:56, Nikos Alexandris wrote:
Hi list.
I can't get wrs2_descending.shp file (from
<http://landsat.usgs.gov/documents/wrs2_descending.zip>\) to import
sans errors (grass7). No matter the snap threshold. Anyone recently
imported it?
On Wed, Jan 14, 2015 at 10:09 AM, Nikos Alexandris
<nik@nikosalexandris.net> wrote:
Apologies for BUMPing. Anyone recently worked with this very data set?
Nikos
On 15.12.2014 12:56, Nikos Alexandris wrote:
Hi list.
I can't get wrs2_descending.shp file (from
<http://landsat.usgs.gov/documents/wrs2_descending.zip>\) to import
sans errors (grass7). No matter the snap threshold. Anyone recently
imported it?
I think that their overlapping areas cannot be represented as pure
topological model.
Hence, you need to maintain them (AFAIK it is the -c option in v.in.ogr).
Please correct me if I am wrong.
The question is: what's you scope? Visualization?
Markus
Nikos Alexandris:
I can't get wrs2_descending.shp file (from
<http://landsat.usgs.gov/documents/wrs2_descending.zip>\) to import
sans errors (grass7). No matter the snap threshold. Anyone recently
imported it?
Markus Neteler wrote:
I think that their overlapping areas cannot be represented as pure
topological model.
Right.
Hence, you need to maintain them (AFAIK it is the -c option in v.in.ogr).
Please correct me if I am wrong.
I'll do so.
The question is: what's you scope? Visualization?
A complete set of tools for Landsat data, inside GRASS, requires a proper trimming utility. The existing add-on i.landsat.trim does not satisfy my needs.
Using a slightly modified version of <ttps://github.com/robintw/LatLongToWRS>, which I'll integrate into (my yet-unifinished personal mini-project) <i.landsat.wrs2trim>, one will simply need to tell which landsat scene(s) (or, optionally, the desired path & row combination(s)) should be border-pixel-trimmed.
I've decided to go the hardway, meaning, let the user or the script, get the "wrs2_descending.shp" file, import it in GRASS and let the module do its work. Or, perhaps, share along with the module a clean vector data set (in GRASS' native format? compressed?).
Nikos
On Wed, Jan 14, 2015 at 12:37 PM, Nikos Alexandris
<nik@nikosalexandris.net> wrote:
Nikos Alexandris:
I can't get wrs2_descending.shp file (from
<http://landsat.usgs.gov/documents/wrs2_descending.zip>\) to import
sans errors (grass7). No matter the snap threshold. Anyone recently
imported it?Markus Neteler wrote:
I think that their overlapping areas cannot be represented as pure
topological model.Right.
Yes, overlapping areas can be represented as a topological model
through M:N mapping: each area can belong to several categories,
several areas can have the same category. If you want to get the
coverage for a particular Landsat scene, just select the path and row
with where="PATH = x and row = y". See also the manual of v.buffer for
a similar example.
Hence, you need to maintain them (AFAIK it is the -c option in v.in.ogr).
Please correct me if I am wrong.
For this shapefile, original polygons can not be maintained (incorrect
boundaries, centroids exceeding number of areas).
Markus M
I'll do so.
The question is: what's you scope? Visualization?
A complete set of tools for Landsat data, inside GRASS, requires a proper
trimming utility. The existing add-on i.landsat.trim does not satisfy my
needs.Using a slightly modified version of
<ttps://github.com/robintw/LatLongToWRS>, which I'll integrate into (my
yet-unifinished personal mini-project) <i.landsat.wrs2trim>, one will simply
need to tell which landsat scene(s) (or, optionally, the desired path & row
combination(s)) should be border-pixel-trimmed.I've decided to go the hardway, meaning, let the user or the script, get the
"wrs2_descending.shp" file, import it in GRASS and let the module do its
work. Or, perhaps, share along with the module a clean vector data set (in
GRASS' native format? compressed?).Nikos
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Nikos Alexandris:
>>>> I can't get wrs2_descending.shp file (from
>>>> <http://landsat.usgs.gov/documents/wrs2_descending.zip>\) to import
>>>> sans errors (grass7). No matter the snap threshold. Anyone recently
>>>> imported it?
Markus Neteler wrote:
>> I think that their overlapping areas cannot be represented as pure
>> topological model.
> Right.
Markus Metz:
Yes, overlapping areas can be represented as a topological model
through M:N mapping: each area can belong to several categories,
several areas can have the same category. If you want to get the
coverage for a particular Landsat scene, just select the path and row
with where="PATH = x and row = y". See also the manual of v.buffer for
a similar example.
That is fine for a simple case. I want to build an easy way
of trimming many Landsat scenes, after they are imported in GRASS' db, each scene in
its own Mapset (using this currently:
<https://github.com/NikosAlexandris/i.landsat.import>\).
If a scene is "there", then we have it's center coordinates
(specifically, the useful info, at this point, will be the output of
`g.region -gcl |grep center_l`).
Using, then, something like <ttps://github.com/robintw/LatLongToWRS>, we
get the ID of the tile in question. The ID, represented by the
combination of Path and Row, is a safe option.
Having the ID will help to select the tile of interest, create a MASK
and trim. All a user needs to feed to the module,
would be the name of names of Mapset(s) of interest. Basta.
Landsat users, wouldn't need to re-import manually for each and every
case the tiles from the official Shapefile.
>> Hence, you need to maintain them (AFAIK it is the -c option in v.in.ogr).
>> Please correct me if I am wrong.
For this shapefile, original polygons can not be maintained (incorrect
boundaries, centroids exceeding number of areas).
But there must be a solution to this. Forget/erase all centroids. Let
the script select all polygons which will assembly the ID of interest,
create a MASK (or MASKs) based on them, trim, remove MASK(s).
Maybe, it's only necessary to treat for boundaries?
Nikos
Flash-backing on this one:
[..]
Markus M:
Yes, overlapping areas can be represented as a topological model
through M:N mapping: each area can belong to several categories,
several areas can have the same category. If you want to get the
coverage for a particular Landsat scene, just select the path and row
with where="PATH = x and row = y". See also the manual of v.buffer for
a similar example.
So, I guess I'll forget the idea to fully automatise the process of Landsat border trimming? Can't we just have all of the Path-Row tiles ready in a compressed GRASS format? Some sort of packed ASCII file which can be easily imported? No other ideas?
Nikos
Markus N:
Hence, you need to maintain them (AFAIK it is the -c option in v.in.ogr).
Please correct me if I am wrong.
For this shapefile, original polygons can not be maintained (incorrect
boundaries, centroids exceeding number of areas).
[..]
On Tue, Feb 24, 2015 at 3:28 PM, Nikos Alexandris
<nik@nikosalexandris.net> wrote:
Flash-backing on this one:
[..]
Markus M:
Yes, overlapping areas can be represented as a topological model
through M:N mapping: each area can belong to several categories,
several areas can have the same category. If you want to get the
coverage for a particular Landsat scene, just select the path and row
with where="PATH = x and row = y". See also the manual of v.buffer for
a similar example.So, I guess I'll forget the idea to fully automatise the process of Landsat
border trimming? Can't we just have all of the Path-Row tiles ready in a
compressed GRASS format? Some sort of packed ASCII file which can be easily
imported? No other ideas?
I think you can trim the borders using the Landsat raster data
themselves: according to the metadata, valid numbers are > 0. If the
sum of all bands is zero, the pixel is outside.
Markus M
Nikos
Markus N:
Hence, you need to maintain them (AFAIK it is the -c option in
v.in.ogr).
Please correct me if I am wrong.For this shapefile, original polygons can not be maintained (incorrect
boundaries, centroids exceeding number of areas).[..]
..
Markus M:
So, I guess I'll forget the idea to fully automatise the process of Landsat
border trimming? Can't we just have all of the Path-Row tiles ready in a
compressed GRASS format? Some sort of packed ASCII file which can be easily
imported? No other ideas?I think you can trim the borders using the Landsat raster data
themselves: according to the metadata, valid numbers are > 0. If the
sum of all bands is zero, the pixel is outside.Markus M
WoW! That I will try out once I find some time. It's a pity (for me) to have the script almost ready, waiting...
Thanks Markus
..
On 06/03/15 08:44, Nikos Alexandris wrote:
..
Markus M:
So, I guess I'll forget the idea to fully automatise the process of
Landsat
border trimming? Can't we just have all of the Path-Row tiles ready
in a
compressed GRASS format? Some sort of packed ASCII file which can be
easily
imported? No other ideas?I think you can trim the borders using the Landsat raster data
themselves: according to the metadata, valid numbers are > 0. If the
sum of all bands is zero, the pixel is outside.
If valid numbers > 0, why does the sum of all bands have to be zero ? Normally, all bands are aligned, so in my understanding any 0 can be set to NULL, or ?
Moritz
On Fri, Mar 6, 2015 at 8:55 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
On 06/03/15 08:44, Nikos Alexandris wrote:
..
Markus M:
So, I guess I'll forget the idea to fully automatise the process of
Landsat
border trimming? Can't we just have all of the Path-Row tiles ready
in a
compressed GRASS format? Some sort of packed ASCII file which can be
easily
imported? No other ideas?I think you can trim the borders using the Landsat raster data
themselves: according to the metadata, valid numbers are > 0. If the
sum of all bands is zero, the pixel is outside.If valid numbers > 0, why does the sum of all bands have to be zero ?
Normally, all bands are aligned, so in my understanding any 0 can be set to
NULL, or ?
I guess yes, but when developing the script it might be a good idea to
test if the bands are really aligned and if one band is zero, all
others should also be zero. Just to be safe.
Markus M
Moritz