I have a sites map, imported using decimal degree coords from 0-360
(instead of -180 to + 180)
(my data covers New Zealand & the area east, so straddles the 180
meridian)
The sites in the western hemisphere (lon > 180) do not display in the
monitor, although a query (d.what.sites) returns the values of sites
there. (it also returns the data for a site hundreds of miles away- poss
the nearest to the click, I'm still looking at that one)
If I convert the sites to a vector map & display it, locations > 180 plot
fine.
Any suggestions?
Thanks,
Brent Wood
I can't find this in any docs (yet), hopefully someone here can help.
I want to select features/records from a GRASS vector map to create a new
map which is a subset of the original. This is repeated for different maps
& the subsets are then merged into a new vector map (The vectors in this
case comprise points & lines, no polygons).
Can anyone tell me how this is best done using GRASS? It seems a pretty
fundamental capability of a vector GIS, but I can't find how to do this in
GRASS.
Thanks,
Brent Wood
I have some seabed contours & some point (site) data east of New Zealand,
covering both sides of the 180 deg meridian.
I set the region to
ellipsoid: wgs84
north: 42:16:48S
south: 45:07:40.8S
west: 172:02:45.6E
east: 172:50:02.4W
The point data (ascii xyz imported into sites) has x values of -160 to 190
(where 190 = -170 = 170W). GRASS only displays the data (in the monitor)
in the Eastern (<180) hemisphere (west side of the map). Converting the
sites to vectors allows all the points to display, both sides of 180.
Similarly, the vector contours (imported from a shapefile in mercator &
reprojected to lat long) display fine in the monitor.
I have converted the contours to a raster (v.surf.rst) but the resulting
raster map doesn't all display (just the base color of the minimum value)
not any cells East of 180 (ie, in the western hemisphere).
Much of my work involves data crossing the 180 meridian using lat/long, so
this functionality is critical for my use of GRASS.
If this is not a bug, is there a way to work with lat/long data/maps
(site, raster/vector) seamlessly across 180?
Appreciated,
Brent Wood
On Tue, Feb 04, 2003 at 10:44:43AM +1300, Brent Wood wrote:
I have some seabed contours & some point (site) data east of New Zealand,
covering both sides of the 180 deg meridian.
I set the region to
ellipsoid: wgs84
north: 42:16:48S
south: 45:07:40.8S
west: 172:02:45.6E
east: 172:50:02.4W
The point data (ascii xyz imported into sites) has x values of -160 to 190
(where 190 = -170 = 170W). GRASS only displays the data (in the monitor)
in the Eastern (<180) hemisphere (west side of the map). Converting the
sites to vectors allows all the points to display, both sides of 180.
Similarly, the vector contours (imported from a shapefile in mercator &
reprojected to lat long) display fine in the monitor.
I have converted the contours to a raster (v.surf.rst) but the resulting
raster map doesn't all display (just the base color of the minimum value)
not any cells East of 180 (ie, in the western hemisphere).
Much of my work involves data crossing the 180 meridian using lat/long, so
this functionality is critical for my use of GRASS.
If this is not a bug, is there a way to work with lat/long data/maps
(site, raster/vector) seamlessly across 180?
These are bugs in the respective programs, AFAIK. They need to call
G_adjust_easting() to fix up the easting. I've confirmed this with
d.sites and fixed it in CVS for the 5.0 HEAD branch.
--
echo ">gra.fcw@2ztr< eryyvZ .T pveR" | rot13 | reverse
I have a site map containg a few hundred thousand points (& only
points). I'm converting it to vector.
Why does v.build require 40 odd minutes to run on a P4 2.4Ghz?
It only uses 6% of system memory for the whole dataset, & I can't see what
topology is required for a map with only point features.
I know it will get there eventually, just wondering what my cpu is so
busy doing?
Is this worth a wish list/bug report?
Thanks,
Brent Wood
On Thursday 13 February 2003 07:15 am, Brent Wood wrote:
I have a site map containg a few hundred thousand points (& only
points). I'm converting it to vector.
Why does v.build require 40 odd minutes to run on a P4 2.4Ghz?
It only uses 6% of system memory for the whole dataset, & I can't see what
topology is required for a map with only point features.
I know it will get there eventually, just wondering what my cpu is so
busy doing?
Is this worth a wish list/bug report?
GRASS 5.0 (v.support) I expect.
Each point is registered as node, then for each next point v.build searches
through all registered nodes if such coordinates are already registered -
it takes some time ~ f( "few hundred thousand" ^ 2 )
In 5.1 it is a bit better - 1m29.441s / 405410 lines(shapefile) / 1.5GHz
Radim
I've had a search through the docs & can't find the answer to this:
How do I plot vector data with colours assigned by attribute/category ID?
There are good facilities for assigning colours to raster, but not that I
can find for vector data?
Any help appreciated.
Brent Wood
I have a sites map with 500,000 points. I have converted it to a vector
map. d.what.sites retrieves information about the nearest point pretty
much instantaneously.
d.what.vector takes several minutes before it is able to even respond.
Is there any way that I can improve the performance of a d.what.vector
query on a map with a large number of features?
Is there a way of structuring the data to help speed things up?
Thanks,
Brent Wood
On Friday 14 February 2003 01:54 am, Brent Wood wrote:
I have a sites map with 500,000 points. I have converted it to a vector
map. d.what.sites retrieves information about the nearest point pretty
much instantaneously.
d.what.vector takes several minutes before it is able to even respond.
Is there any way that I can improve the performance of a d.what.vector
query on a map with a large number of features?
Is there a way of structuring the data to help speed things up?
The same problem as with v.support - missing spatial index.
You could try 5.1, it is loading vector a bit longer (400000lines ~4s)
but then you get the line immediately. Better to put attributes
to real RDBMS, dbf is not sufficient for such large data sets.
Radim
PS: Warning: 5.1 is development version!
I have an ascii list of XYZ points (lat/long/depth). I have imported
them into a sites map, then converted to a vector.
I'm able to get the category description set to the depth (z) value, but
most of the GRASS vector commands only use the category ID.
The following exerpt from v.report shows the vector data structure.
+--------------------------------------------------------------------------+
| VECTOR MAP CATEGORY REPORT |
|LOCATION: nz Mon Feb 17 13:53:41 2003|
|--------------------------------------------------------------------------|
| north: 48:23:24S east: 179:36W |
| WINDOW south: 51:42:36S west: 176:54E |
| res: 0:00:36 res: 0:00:36 |
|--------------------------------------------------------------------------|
|MAP: antipodes2 in PERMANENT |
|--------------------------------------------------------------------------|
| Category Information |
| #|description count|
|--------------------------------------------------------------------------|
| 0|no data. . . . . . . . . . . . . . . . . . . . . . . . . . . | 600|
| 1|-757.000000000000000 . . . . . . . . . . . . . . . . . . . . | 1|
| 2|-760.000000000000000 . . . . . . . . . . . . . . . . . . . . .| 1|
| 3|-752.000000000000000 . . . . . . . . . . . . . . . . . . . . .| 1|
| 4|-708.000000000000000 . . . . . . . . . . . . . . . . . . . . .| 1|
...
Can anyone tell me how to get the # field, which I assume is the category
ID, set to the Z value for vector queries/coloring etc?
Thanks
Brent Wood