[GRASS-user] v.report produces corrupt table of attributes

[Stuart Edwards]

Markus

Thanks for your response.


On Jun 16, 2013, at 4:29 AM, Markus Neteler wrote:

> On Fri, Jun 14, 2013 at 2:23 AM, Stuart Edwards <sedwards2 at cinci.rr.com> wrote:
>> 
>> Hi --
>> 
>> This simple project involves digitizing and displaying the location of about
>> 200 borings. There is a pair of state plane co-ordinates and an
>> alpha-numeric boring designator - and of course a cat - for each of them.
>> The borings were duly digitized using v.digit in GRASS 7 (OS X) and after a
>> number of edits (relocations, modification of some attributes, and some
>> deletions) the file displays correctly using d.vect. It has also been
>> satisfactorily exported as a shapefile as part of an effort to create a
>> labeled dxf CAD layer.
> 
> So, just to be sure to understand: you have digitized circular polygons?

No, this becomes a vector points map that is then displayed over a raster photo base using the available symbols.  The attributes provide the boring numbers that are also displayed.

> 
>> However, v.report creates a table that appears to randomly (unlikely, I
>> know, but that's how it appears) redistribute the pairs of co-ordinates
>> among the points.
>> 
>> For example, at one boring location v.what generates:
>> 
>> v.what -a map=Borings at PERMANENT layer=-1
>> coordinates=1791366.79821,765499.232745 distance=2
> 
> The coordinate pair specified here, where does it fall into the polygon?
> Onto the boundary or onto the centroid or "anywhere" within the
> polygon?
This one is roughly in the middle of the 'cloud'
> 
>> East: 1791366.79821
>> North: 765499.232745
>> Map: Borings
>> Mapset: PERMANENT
>> Type: Point       <<<----  so you have points and not polygons?

yes -
>> Id: 117
>> Layer: 1
>> Category: 142
>> Driver: sqlite
>> Database: /Users/stu/grassdata/270test/PERMANENT/sqlite/sqlite.db
>> Table: Borings
>> Key column: cat
>> cat : 142
>> boringnumber : B-9-004-13
> 
> What does this print:
> 
> v.info -t Borings?

v.info -t Borings                                                               
nodes=0
points=212
lines=0
boundaries=0
centroids=0
areas=0
islands=0
primitives=212
map3d=0

Note - the total boring count is only 186 and there are no other features on this map.

> 
>> However, v.report gives:
>> 
>> 142|B-9-004-13|1793470.46145773|765224.666245354|0
>> 
>> for cat 142 which is the location of one of the other borings. Almost all of
>> the borings are incorrectly identified in the v.report table. I tried
>> v.build before running v.report but the results were the same.
> 
> Perhaps you could post a small map screenshot of the area of interest
> along with the map scalebar put on.

Please see attached.  The screen shot was taken with the cursor on the boring location (circled) and you can see that the co-ordinates  correspond reasonably well with the result of v.what mentioned above.

Is it possible that the db is not keeping up with the edits that are made subsequent to digitization and that when a boring is moved, points are not properly deleted, although a new point is created, and all the following cats are thrown off by a corresponding amount?  All of the co-ordinate pairs are perfectly represented - just with the wrong attribute.

Thanks again for your assistance ......

Stu

-------------- next part --------------
A non-text attachment was scrubbed...
Name: markus.jpg
Type: image/jpg
Size: 113910 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20130616/98a87343/attachment-0001.jpg>
-------------- next part --------------