I just ran into a couple modules that choke on map@mapset:
v.rast.stats
v.db.addtable
Perhaps there are others. Can these be updated to accept the map@mapset form?
Michael
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965-6262; fax: 480-965-7671
Michael Barton wrote:
I just ran into a couple modules that choke on map@mapset:
v.rast.stats
# does map exist in CURRENT mapset?
eval `g.findfile element=vector file="$VECTOR" mapset="$MAPSET"`
if [ ! "$file" ] ; then
g.message -e "Vector map <$VECTOR> not found"
exit 1
fi
------------------------------------------------------------------------
r23567 | markus | 2007-04-25 23:08:51 +0100 (Wed, 25 Apr 2007) | 2 lines
test improved: does map exist in CURRENT mapset?
v.db.addtable
# does map exist in CURRENT mapset?
eval `g.findfile element=vector file=$GIS_OPT_MAP mapset=$MAPSET`
if [ ! "$file" ] ; then
g.message -e "Vector map '$GIS_OPT_MAP' not found in current mapset"
exit 1
fi
------------------------------------------------------------------------
r22855 | markus | 2007-03-07 13:01:31 +0000 (Wed, 07 Mar 2007) | 2 lines
check if map exists in current mapset
Perhaps there are others. Can these be updated to accept the
map@mapset form?
One might assume that the author had some reason to require that the
map was in the current mapset, given that they put CURRENT in block
capitals.
In both cases, the script modifies the database associated with the
map, so it might only work for maps in the current mapset. Even if it
happens to work for maps in other mapsets, it may be reasonable to
explicitly prevent it (what if someone else is using the map?).
Or are you asking about the particular case of referencing maps which
happen to be in the current mapset using a qualified name? g.findfile
should[1] handle the situation where file= is qualified and the mapset
matches the mapset= option.
[1] I don't know whether it does; if it doesn't that's a g.findfile
bug.
Also, AFAICT, the parser only understands "old" maps (must exist, can
be in any mapset, won't be modified) and "new" maps (must not exist
unless --o etc is used, must be in the current mapset, will be
created). It doesn't have any concept of maps which are modified
in-place; this is rare for raster maps (only r.null springs to mind),
but seems to be not uncommon for vector maps.
--
Glynn Clements <glynn@gclements.plus.com>
To make this work better with the GUI parser and not generate an error, the script should just strip off the @mapset portion of the name.
Michael
______________________________
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
On Feb 12, 2008, at 1:25 PM, Glynn Clements wrote:
Michael Barton wrote:
I just ran into a couple modules that choke on map@mapset:
v.rast.stats
# does map exist in CURRENT mapset?
eval `g.findfile element=vector file="$VECTOR" mapset="$MAPSET"`
if [ ! "$file" ] ; then
g.message -e "Vector map <$VECTOR> not found"
exit 1
fi------------------------------------------------------------------------
r23567 | markus | 2007-04-25 23:08:51 +0100 (Wed, 25 Apr 2007) | 2 lines
test improved: does map exist in CURRENT mapset?v.db.addtable
# does map exist in CURRENT mapset?
eval `g.findfile element=vector file=$GIS_OPT_MAP mapset=$MAPSET`
if [ ! "$file" ] ; then
g.message -e "Vector map '$GIS_OPT_MAP' not found in current mapset"
exit 1
fi------------------------------------------------------------------------
r22855 | markus | 2007-03-07 13:01:31 +0000 (Wed, 07 Mar 2007) | 2 lines
check if map exists in current mapsetPerhaps there are others. Can these be updated to accept the
map@mapset form?One might assume that the author had some reason to require that the
map was in the current mapset, given that they put CURRENT in block
capitals.In both cases, the script modifies the database associated with the
map, so it might only work for maps in the current mapset. Even if it
happens to work for maps in other mapsets, it may be reasonable to
explicitly prevent it (what if someone else is using the map?).Or are you asking about the particular case of referencing maps which
happen to be in the current mapset using a qualified name? g.findfile
should[1] handle the situation where file= is qualified and the mapset
matches the mapset= option.[1] I don't know whether it does; if it doesn't that's a g.findfile
bug.Also, AFAICT, the parser only understands "old" maps (must exist, can
be in any mapset, won't be modified) and "new" maps (must not exist
unless --o etc is used, must be in the current mapset, will be
created). It doesn't have any concept of maps which are modified
in-place; this is rare for raster maps (only r.null springs to mind),
but seems to be not uncommon for vector maps.--
Glynn Clements <glynn@gclements.plus.com>
On Feb 12, 2008 9:25 PM, Glynn Clements <glynn@gclements.plus.com> wrote:
Michael Barton wrote:
> I just ran into a couple modules that choke on map@mapset:
>
> v.rast.stats# does map exist in CURRENT mapset?
eval `g.findfile element=vector file="$VECTOR" mapset="$MAPSET"`
if [ ! "$file" ] ; then
g.message -e "Vector map <$VECTOR> not found"
exit 1
fi------------------------------------------------------------------------
r23567 | markus | 2007-04-25 23:08:51 +0100 (Wed, 25 Apr 2007) | 2 linestest improved: does map exist in CURRENT mapset?
> v.db.addtable
# does map exist in CURRENT mapset?
eval `g.findfile element=vector file=$GIS_OPT_MAP mapset=$MAPSET`
if [ ! "$file" ] ; then
g.message -e "Vector map '$GIS_OPT_MAP' not found in current mapset"
exit 1
fi------------------------------------------------------------------------
r22855 | markus | 2007-03-07 13:01:31 +0000 (Wed, 07 Mar 2007) | 2 linescheck if map exists in current mapset
> Perhaps there are others. Can these be updated to accept the
> map@mapset form?One might assume that the author had some reason to require that the
map was in the current mapset, given that they put CURRENT in block
capitals.
AFAIK you can only update a vector map in the current mapset.
* v.rast.stats: Calculates univariate statistics from a GRASS raster
map based on vector polygons and uploads statistics to new attribute
columns.
AFAIK you can only add a new table to a vector map in the current mapset.
* v.db.addtable: Creates and adds a new attribute table to a given
layer of an existing vector map.
In both cases, the script modifies the database associated with the
map, so it might only work for maps in the current mapset.
...yes, I think so.
Even if it
happens to work for maps in other mapsets, it may be reasonable to
explicitly prevent it (what if someone else is using the map?).
So far the policy was to only modify maps in the current mapset.
...
Markus
Michael Barton wrote:
To make this work better with the GUI parser and not generate an
error, the script should just strip off the @mapset portion of the name.
Please answer the following question:
> Or are you asking about the particular case of referencing maps which
> happen to be in the current mapset using a qualified name?
If g.findfile doesn't handle the combination of mapset= and a
qualified name *where the mapsets are the same*, that's a bug in
g.findfile which should be fixed.
OTOH, if it's complaining because you're trying to use a map which
isn't in the current mapset, the scripts should be generating an
error. The scripts absolutely should not simply ignore the mapset.
--
Glynn Clements <glynn@gclements.plus.com>
On Feb 13, 2008, at 12:08 PM, Glynn Clements wrote:
Michael Barton wrote:
To make this work better with the GUI parser and not generate an
error, the script should just strip off the @mapset portion of the name.Please answer the following question:
Or are you asking about the particular case of referencing maps which
happen to be in the current mapset using a qualified name?If g.findfile doesn't handle the combination of mapset= and a
qualified name *where the mapsets are the same*, that's a bug in
g.findfile which should be fixed.OTOH, if it's complaining because you're trying to use a map which
isn't in the current mapset, the scripts should be generating an
error. The scripts absolutely should not simply ignore the mapset.
It's complaining that the map you are using isn't in the current mapset when it actually is in the mapset.
GRASS 6.3.svn (spearfish60_test):~ > v.rast.stats -e vector=sites@spatialtech2008 layer=1 raster=elevation.dem@PERMANENT colprefix=elev_ percentile=90
ERROR: sites@spatialtech2008_18153.0 is not in the current mapset
(spatialtech2008)
ERROR: An error occurred while converting vector to raster
G__open(r): mapset (spatialtech2008) doesn't match xmapset (spatialtech2008_18153.0)
G__open(r): mapset (spatialtech2008) doesn't match xmapset (spatialtech2008_18153.0)
ERROR: sites@spatialtech2008_18153.0 is not in the current mapset
(spatialtech2008)
But...
GRASS 6.3.svn (spearfish60_test):~ > v.rast.stats -e vector=sites layer=1 raster=elevation.dem@PERMANENT colprefix=elev_ percentile=90
Statistics calculated from raster map <elevation.dem@PERMANENT> and
uploaded to attribute table of vector map <sites>.
Done.
On Feb 13, 2008 7:35 PM, Michael Barton <michael.barton@asu.edu> wrote:
On Feb 13, 2008, at 12:08 PM, Glynn Clements wrote:
>
> Michael Barton wrote:
>
>> To make this work better with the GUI parser and not generate an
>> error, the script should just strip off the @mapset portion of the
>> name.
>
> Please answer the following question:
>
>>> Or are you asking about the particular case of referencing maps
>>> which
>>> happen to be in the current mapset using a qualified name?
>
> If g.findfile doesn't handle the combination of mapset= and a
> qualified name *where the mapsets are the same*, that's a bug in
> g.findfile which should be fixed.
>
> OTOH, if it's complaining because you're trying to use a map which
> isn't in the current mapset, the scripts should be generating an
> error. The scripts absolutely should not simply ignore the mapset.It's complaining that the map you are using isn't in the current
mapset when it actually is in the mapset.
I guess that you have a map with same name in a different path
and SEARCHPATH first defines that? What does
g.mapsets -p
say?
GRASS 6.3.svn (spearfish60_test):~ > v.rast.stats -e
vector=sites@spatialtech2008 layer=1 raster=elevation.dem@PERMANENT
colprefix=elev_ percentile=90
ERROR: sites@spatialtech2008_18153.0 is not in the current mapset
(spatialtech2008)
ERROR: An error occurred while converting vector to raster
G__open(r): mapset (spatialtech2008) doesn't match xmapset
(spatialtech2008_18153.0)
G__open(r): mapset (spatialtech2008) doesn't match xmapset
(spatialtech2008_18153.0)
ERROR: sites@spatialtech2008_18153.0 is not in the current mapset
(spatialtech2008)
Are you currently in "spatialtech2008" mapset? (just to be sure)
This "xmapset" thing is strange above.
Related: how old is your g.mapsets? I updated it on Feb 2:
http://trac.osgeo.org/grass/changeset/30030
http://trac.osgeo.org/grass/changeset/30031
http://trac.osgeo.org/grass/changeset/30032
to use longer buffers.
But...
GRASS 6.3.svn (spearfish60_test):~ > v.rast.stats -e vector=sites
layer=1 raster=elevation.dem@PERMANENT colprefix=elev_ percentile=90
Statistics calculated from raster map <elevation.dem@PERMANENT> and
uploaded to attribute table of vector map <sites>.
Done.
Maybe related to the previously too short buffers?
Markus
voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
On Feb 13, 2008, at 2:52 PM, Markus Neteler wrote:
It's complaining that the map you are using isn't in the current
mapset when it actually is in the mapset.I guess that you have a map with same name in a different path
No. This is the only map with this name.
and SEARCHPATH first defines that? What does
g.mapsets -psay?
spatialtech2008 PERMANENT
GRASS 6.3.svn (spearfish60_test):~ > v.rast.stats -e
vector=sites@spatialtech2008 layer=1 raster=elevation.dem@PERMANENT
colprefix=elev_ percentile=90
ERROR: sites@spatialtech2008_18153.0 is not in the current mapset
(spatialtech2008)
ERROR: An error occurred while converting vector to raster
G__open(r): mapset (spatialtech2008) doesn't match xmapset
(spatialtech2008_18153.0)
G__open(r): mapset (spatialtech2008) doesn't match xmapset
(spatialtech2008_18153.0)
ERROR: sites@spatialtech2008_18153.0 is not in the current mapset
(spatialtech2008)Are you currently in "spatialtech2008" mapset? (just to be sure)
yes
This "xmapset" thing is strange above.
Related: how old is your g.mapsets? I updated it on Feb 2:
Compiled from trunk 2 days ago
Changeset 30030 – GRASS GIS
Changeset 30031 – GRASS GIS
Changeset 30032 – GRASS GIS
to use longer buffers.But...
GRASS 6.3.svn (spearfish60_test):~ > v.rast.stats -e vector=sites
layer=1 raster=elevation.dem@PERMANENT colprefix=elev_ percentile=90
Statistics calculated from raster map <elevation.dem@PERMANENT> and
uploaded to attribute table of vector map <sites>.
Done.Maybe related to the previously too short buffers?
I don't know.
Michael
Markus
>> It's complaining that the map you are using isn't in the current
>> mapset when it actually is in the mapset.
...
>> ERROR: sites@spatialtech2008_18153.0 is not in the current mapset
>> (spatialtech2008)
It is trying to append _{$TMP} after map@mapset instead of just 'map'.
Try this:
http://trac.osgeo.org/grass/changeset/30118
(really please try that, I haven't tested it)
+++ /grass/trunk/scripts/v.db.addtable/v.db.addtable (revision 30118)
@@ -88,18 +88,20 @@
g.message -e "Vector map '$GIS_OPT_MAP' not found in current
mapset"
exit 1
+else
+ MAP_NAME=`echo "$GIS_OPT_MAP" | cut -f1 -d'@'`
fi
As for i.smap, the imagery library + modules are known to be very bad
at dealing with @mapset, my suggestion for users of imagery modules is
to not use @mapset at all. (yes I know the GUI insists on adding that,
sorry..)
Hamish
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Hamish wrote:
> >> It's complaining that the map you are using isn't in the current
> >> mapset when it actually is in the mapset.
...
> >> ERROR: sites@spatialtech2008_18153.0 is not in the current mapset
> >> (spatialtech2008)It is trying to append _{$TMP} after map@mapset instead of just 'map'.
Try this:
http://trac.osgeo.org/grass/changeset/30118
(really please try that, I haven't tested it)+++ /grass/trunk/scripts/v.db.addtable/v.db.addtable (revision 30118)
@@ -88,18 +88,20 @@
g.message -e "Vector map '$GIS_OPT_MAP' not found in current
mapset"
exit 1
+else
+ MAP_NAME=`echo "$GIS_OPT_MAP" | cut -f1 -d'@'`
fi
Completely bogus. Reverted.
This just papers over the symptoms without fixing anything.
If the name includes a mapset which isn't the current one, that's an
error. You don't just discard the mapset.
If you don't have a clue what's going on, don't just commit random
changes which make the problem appear to go away on your system.
--
Glynn Clements <glynn@gclements.plus.com>
Hamish wrote:
> It is trying to append _{$TMP} after map@mapset instead of just
> 'map'.
>
> Try this:
> http://trac.osgeo.org/grass/changeset/30118
> (really please try that, I haven't tested it)
>
> +++ /grass/trunk/scripts/v.db.addtable/v.db.addtable (revision
30118)
> @@ -88,18 +88,20 @@
> g.message -e "Vector map '$GIS_OPT_MAP' not found in current
> mapset"
> exit 1
> +else
> + MAP_NAME=`echo "$GIS_OPT_MAP" | cut -f1 -d'@'`
> fi
Glynn:
Completely bogus. Reverted.
This just papers over the symptoms without fixing anything.
If the name includes a mapset which isn't the current one, that's an
error. You don't just discard the mapset.
note that was placed after a test to see if the map existed in the
current mapset. I now am reminded of the case where the user wants to
use somemap@othermapset when there is already a map of the same name in
the current.
Hopefully what is there now works to everyone's statisfaction.
Hamish
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Hamish wrote:
> >> It's complaining that the map you are using isn't in the current
> >> mapset when it actually is in the mapset.
...
> >> ERROR: sites@spatialtech2008_18153.0 is not in the current mapset
> >> (spatialtech2008)It is trying to append _{$TMP} after map@mapset instead of just 'map'.
That's a bug in v.rast.stats.
I note that g.findfile doesn't include the unqualified name in its
output, e.g.:
name='newmap@glynn'
mapset='glynn'
fullname='newmap@glynn'
file='/opt/grass-data/global/glynn/vector/newmap'
There should probably be a (e.g.) basename= line in its output.
In its absence, v.rast.stats will need to manually obtain the
unqualified before appending _${TMPNAME}.
Try this:
http://trac.osgeo.org/grass/changeset/30118
(really please try that, I haven't tested it)+++ /grass/trunk/scripts/v.db.addtable/v.db.addtable (revision 30118)
Michael was reporting a problem with v.rast.stats, which is completely
unrelated to any problem which may or may not exist with v.db.addtable
(I don't even know if there *is* a problem with v.db.addtable; I have
yet to see any evidence that there is).
As for i.smap, the imagery library + modules are known to be very bad
at dealing with @mapset, my suggestion for users of imagery modules is
to not use @mapset at all. (yes I know the GUI insists on adding that,
sorry..)
The GUI *should* insist on adding that, at least for input maps.
Yet again: an unqualified input map name does *not* refer to a map in
the current mapset. It refers to the first map with that name in the
search path. They aren't the same thing.
Whether the GUI should add that for "new" maps is debatable. But
modules and scripts should still handle that case. If they don't, it's
a fault in the module rather than the GUI.
--
Glynn Clements <glynn@gclements.plus.com>
Glynn Clements wrote:
I note that g.findfile doesn't include the unqualified name in its
output, e.g.:name='newmap@glynn'
mapset='glynn'
fullname='newmap@glynn'
file='/opt/grass-data/global/glynn/vector/newmap'There should probably be a (e.g.) basename= line in its output.
In its absence, v.rast.stats will need to manually obtain the
unqualified before appending _${TMPNAME}.
Right.
Michael was reporting a problem with v.rast.stats, which is
completely unrelated to any problem which may or may not exist with
v.db.addtable
It's a similar class of problem. Once we have a good solution for one
script we can apply the same method to the other.
(I don't even know if there *is* a problem with v.db.addtable; I have
yet to see any evidence that there is).
v.db.addtable:
....
89 if [ $GIS_OPT_LAYER -eq 1 ] ; then
90 g.message "Using vector map name as table name:
$MAP_NAME"
91 table="$MAP_NAME"
92 else
93 # two avoid tables with identical names on higher layers
94 g.message "Using vector map name extended by layer
number as table name: ${MAP_NAME}_$GIS_OPT_LAYER"
95 table="${MAP_NAME}_$GIS_OPT_LAYER"
96 fi
....
Thus $MAP_NAME should be unqualified and in the current mapset.
Yet again: an unqualified input map name does *not* refer to a map in
the current mapset. It refers to the first map with that name in the
search path. They aren't the same thing.
I was not aware that it was possible for the current mapset NOT to be
the first entry in the search path? If it is possible for that to
happen, is there a valid reason why that should be allowed?
The g.mapsets module insists on putting the current one first, I
suppose it is possible to hack the $MAPSET/SEARCH_PATH file manaually
to change the order, but I don't know why someone would want to.
Whether the GUI should add that for "new" maps is debatable.
Well as long as we stick to the "only write to the current mapset"
rule^ it's redundant to qualify the name. And a lower signal to noise
ratio means typos are harder to spot.
(^ i.rectify)
But modules and scripts should still handle that case. If they don't,
it's a fault in the module rather than the GUI.
No arguement there.
Hamish
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Hamish wrote:
> > It is trying to append _{$TMP} after map@mapset instead of just
> > 'map'.
> >
> > Try this:
> > http://trac.osgeo.org/grass/changeset/30118
> > (really please try that, I haven't tested it)
> >
> > +++ /grass/trunk/scripts/v.db.addtable/v.db.addtable (revision
> 30118)
> > @@ -88,18 +88,20 @@
> > g.message -e "Vector map '$GIS_OPT_MAP' not found in current
> > mapset"
> > exit 1
> > +else
> > + MAP_NAME=`echo "$GIS_OPT_MAP" | cut -f1 -d'@'`
> > fiGlynn:
> Completely bogus. Reverted.
>
> This just papers over the symptoms without fixing anything.
>
> If the name includes a mapset which isn't the current one, that's an
> error. You don't just discard the mapset.note that was placed after a test to see if the map existed in the
current mapset. I now am reminded of the case where the user wants to
use somemap@othermapset when there is already a map of the same name in
the current.
Sorry. I completely mis-read what that line was doing. It's removing
the mapset when the check *succeeds*.
--
Glynn Clements <glynn@gclements.plus.com>
Hamish wrote:
> Yet again: an unqualified input map name does *not* refer to a map in
> the current mapset. It refers to the first map with that name in the
> search path. They aren't the same thing.I was not aware that it was possible for the current mapset NOT to be
the first entry in the search path?
From a library perspective, the search path can be set to anything;
the current mapset doesn't even need to be in the path.
If it is possible for that to
happen, is there a valid reason why that should be allowed?
Suppose that you're generating a set of output maps from a set of
input maps, the two sets share a common naming policy, and the
operations aren't simple 1:1 operations (generating a single output
from a single input with the same name). It would be quite easy to
inadvertantly use a map from the output mapset instead of the input
mapset.
The g.mapsets module insists on putting the current one first, I
suppose it is possible to hack the $MAPSET/SEARCH_PATH file manaually
to change the order, but I don't know why someone would want to.
AFAICT, g.mapsets adds the current mapset to the head of the search
path if it isn't already in the path, but won't move it if it's
elsewhere in the path.
> Whether the GUI should add that for "new" maps is debatable.
Well as long as we stick to the "only write to the current mapset"
rule^ it's redundant to qualify the name. And a lower signal to noise
ratio means typos are harder to spot.
(^ i.rectify)
The main problem there is that the parser interface doesn't have any
notion of "update in place", which is the situation for both
v.db.addtable and v.rast.stats.
The maps to be updated can't be declared as "new", because they have
to already exist. So, they're declared as "old", which means that the
GUI thinks that they can be in any mapset, and uses qualified names.
--
Glynn Clements <glynn@gclements.plus.com>
Hamish:
> The g.mapsets module insists on putting the current one first, I
> suppose it is possible to hack the $MAPSET/SEARCH_PATH file
> manaually to change the order, but I don't know why someone would
> want to.
Glynn:
AFAICT, g.mapsets adds the current mapset to the head of the search
path if it isn't already in the path, but won't move it if it's
elsewhere in the path.
I notice now that from the command line g.mapsets does give you more
control WRT mapset order than the GUI checkbox interface does.
[...]
The main problem there is that the parser interface doesn't have any
notion of "update in place", which is the situation for both
v.db.addtable and v.rast.stats.The maps to be updated can't be declared as "new", because they have
to already exist. So, they're declared as "old", which means that the
GUI thinks that they can be in any mapset, and uses qualified names.
One thing to consider is that these modules are not modifying the
vector maps per se (vertices and topology), they are modifying the
associated database tables. And DBs historically are designed to be
modified in place.
AFAIK the primary* modules which modify maps in place are d.rast.edit
and v.edit. Hmmm, actually that's wrong- d.rast.edit takes input= and
output=, so maybe it is just v.edit.
* I hesitate to say "only" due to the sheer number of oddball modules.
Back on the @mapset thing, I just found a bug in i.target when called
from the GUI.
Step 1: create a group with i.group.
Step 2: start the i.target tcltk module GUI. Select your group from
the GUI folder picker. It shows up as group@currentmapset.
Step 3: choose your target location & mapset, hit run.
Step 4: 'g.list groups'.
You will notice two groups, your original group and one called
"group@currentmapset" containing the new TARGET file.
As mentioned earlier re. i.smap:
imagery modules + @mapset = needs lots of cleanup work.
Hamish
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ