Hi,
can we convert 3D polygons or tins to a DEM? Possibly a job for
v.to.rast...
v.to.rast help
...
use Source of raster values:
z - use z coordinate (points or contours only)
Would it be a big mess to extend that?
Markus
Ciao Markus,
2008/1/21, Markus Neteler <neteler@osgeo.org>:
can we convert 3D polygons or tins to a DEM? Possibly a job for
v.to.rast...v.to.rast help
...
use Source of raster values:
z - use z coordinate (points or contours only)Would it be a big mess to extend that?
I guess wouldn't be so complicated to add support also for faces (and
3d lines in general) to v.to.rast... I can try take a look.
Martin
--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *
Hi,
2008/1/21, Martin Landa <landa.martin@gmail.com>:
2008/1/21, Markus Neteler <neteler@osgeo.org>:
> can we convert 3D polygons or tins to a DEM? Possibly a job for
> v.to.rast...
>
> v.to.rast help
> ...
> use Source of raster values:
> z - use z coordinate (points or contours only)
>
> Would it be a big mess to extend that?I guess wouldn't be so complicated to add support also for faces (and
3d lines in general) to v.to.rast... I can try take a look.
just idea,
tin ->
v.to.points -n
v.clean tool=rmdupl
v.surf.* -> dem
??
Martin
--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *
On Jan 21, 2008 4:22 PM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2008/1/21, Martin Landa <landa.martin@gmail.com>:
> 2008/1/21, Markus Neteler <neteler@osgeo.org>:
> > can we convert 3D polygons or tins to a DEM? Possibly a job for
> > v.to.rast...
> >
> > v.to.rast help
> > ...
> > use Source of raster values:
> > z - use z coordinate (points or contours only)
> >
> > Would it be a big mess to extend that?
>
> I guess wouldn't be so complicated to add support also for faces (and
> 3d lines in general) to v.to.rast... I can try take a look.just idea,
tin ->
v.to.points -n
v.clean tool=rmdupl
v.surf.* -> dem
well, this would only give an approximation AFAIK.
I realize that it is easy with (inclined) triangles but less so
with whatever-polygons (are that always faces or could it be
a more complex form?).
Markus
On Jan 21, 2008, at 11:23 AM, Markus Neteler wrote:
On Jan 21, 2008 4:22 PM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2008/1/21, Martin Landa <landa.martin@gmail.com>:
2008/1/21, Markus Neteler <neteler@osgeo.org>:
can we convert 3D polygons or tins to a DEM? Possibly a job for
v.to.rast...v.to.rast help
...
use Source of raster values:
z - use z coordinate (points or contours only)Would it be a big mess to extend that?
I guess wouldn't be so complicated to add support also for faces (and
3d lines in general) to v.to.rast... I can try take a look.just idea,
tin ->
v.to.points -n
v.clean tool=rmdupl
v.surf.* -> demwell, this would only give an approximation AFAIK.
that is right - if you want to preserve the triangle facets in the TIN
you need to do linear interpolation using the 3 points of each triangle facet
and you get something like this
(this is TIN converted to raster in some old version of Arc)
http://skagit.meas.ncsu.edu/~helena/gmslab/interp/F1b.gif
If you convert to points and run interpolation or approximation
you can get various surfaces e.g. this
http://skagit.meas.ncsu.edu/~helena/gmslab/interp/F1c.gif
or this
http://skagit.meas.ncsu.edu/~helena/gmslab/interp/F1f.gif
although for some applications the interpolated surface is preferable
to get rid of various artifacts created by TIN and create a continuous surface,
there are applications that include designed features and structures where
TIN was used in the design and you need to preserve the breaklines
defined by the TIN.
I am not sure whether this should be part of v.to.rast - maybe a separate
module (v.surf.linear) that would also compute the slope and aspect
map for each facet would be more appropriate,
Helena
I realize that it is easy with (inclined) triangles but less so
with whatever-polygons (are that always faces or could it be
a more complex form?).Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On Jan 21, 2008 7:59 PM, Helena Mitasova <hmitaso@unity.ncsu.edu> wrote:
On Jan 21, 2008, at 11:23 AM, Markus Neteler wrote:
> On Jan 21, 2008 4:22 PM, Martin Landa <landa.martin@gmail.com> wrote:
>> 2008/1/21, Martin Landa <landa.martin@gmail.com>:
>>> 2008/1/21, Markus Neteler <neteler@osgeo.org>:
>>>> can we convert 3D polygons or tins to a DEM? Possibly a job for
>>>> v.to.rast...
>>>>
>>>> v.to.rast help
>>>> ...
>>>> use Source of raster values:
>>>> z - use z coordinate (points or contours only)
>>>>
>>>> Would it be a big mess to extend that?
>>>
>>> I guess wouldn't be so complicated to add support also for faces
>>> (and
>>> 3d lines in general) to v.to.rast... I can try take a look.
>>
>> just idea,
>>
>> tin ->
>>
>> v.to.points -n
>> v.clean tool=rmdupl
>> v.surf.* -> dem
>
> well, this would only give an approximation AFAIK.that is right - if you want to preserve the triangle facets in the TIN
you need to do linear interpolation using the 3 points of each
triangle facet and you get something like this
(this is TIN converted to raster in some old version of Arc)
I discovered that we have tin.c in vectlib:
int
Vect_tin_get_z (
struct Map_info *Map,
double tx, double ty,
double *tz, double *angle, double *slope)
Markus
On Jan 25, 2008, at 2:46 PM, Markus Neteler wrote:
On Jan 21, 2008 7:59 PM, Helena Mitasova <hmitaso@unity.ncsu.edu> wrote:
On Jan 21, 2008, at 11:23 AM, Markus Neteler wrote:
On Jan 21, 2008 4:22 PM, Martin Landa <landa.martin@gmail.com> wrote:
2008/1/21, Martin Landa <landa.martin@gmail.com>:
2008/1/21, Markus Neteler <neteler@osgeo.org>:
can we convert 3D polygons or tins to a DEM? Possibly a job for
v.to.rast...v.to.rast help
...
use Source of raster values:
z - use z coordinate (points or contours only)Would it be a big mess to extend that?
I guess wouldn't be so complicated to add support also for faces
(and
3d lines in general) to v.to.rast... I can try take a look.just idea,
tin ->
v.to.points -n
v.clean tool=rmdupl
v.surf.* -> demwell, this would only give an approximation AFAIK.
that is right - if you want to preserve the triangle facets in the TIN
you need to do linear interpolation using the 3 points of each
triangle facet and you get something like this
(this is TIN converted to raster in some old version of Arc)I discovered that we have tin.c in vectlib:
int
Vect_tin_get_z (
struct Map_info *Map,
double tx, double ty,
double *tz, double *angle, double *slope)
that looks promising - I checked v.delaunay and unfortunately it
ignores the z-coordinate even if you give it 3D vector points - so first
the v.delaunay would have to be updated to preserve the z-coordinates
and write 3D vector map rather than 2D (perhaps not too complicated task)
and then the simplest way would be just to call the above function for each grid point
with Map being the 3D vector area map from v.delaunay.
The computation of slope and aspect is missing but adding those should be easy.
maybe somebody with better C-programming skills could look at it - just adding
the z coordinate to v.delaunay would add the missing TIN support to GRASS
and the result could be visualized as 3D vector,
Helena
Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hi Helena and others.
Unfortunately 3D vector ignorance isn't the only problem of v.delaunay
- it still (as of 6.3.0RC4) fails to work correctly with more than
32XXX vector points [1] - thus making it not an option for large
datasets. Yesterday I looked on v.delaunay source and unfortunately
understood, that my C skills are too poor to fix it. 
Fixing large dataset and 3D support problems would be a nice
improvement of GRASS vector support 
Maris.
1. http://wald.intevation.org/tracker/index.php?func=detail&aid=335&group_id=21&atid=204
2008/1/28, Helena Mitasova <hmitaso@unity.ncsu.edu>:
On Jan 25, 2008, at 2:46 PM, Markus Neteler wrote:
> On Jan 21, 2008 7:59 PM, Helena Mitasova <hmitaso@unity.ncsu.edu>
> wrote:
>> On Jan 21, 2008, at 11:23 AM, Markus Neteler wrote:
>>> On Jan 21, 2008 4:22 PM, Martin Landa <landa.martin@gmail.com>
>>> wrote:
>>>> 2008/1/21, Martin Landa <landa.martin@gmail.com>:
>>>>> 2008/1/21, Markus Neteler <neteler@osgeo.org>:
>>>>>> can we convert 3D polygons or tins to a DEM? Possibly a job for
>>>>>> v.to.rast...
>>>>>>
>>>>>> v.to.rast help
>>>>>> ...
>>>>>> use Source of raster values:
>>>>>> z - use z coordinate (points or contours only)
>>>>>>
>>>>>> Would it be a big mess to extend that?
>>>>>
>>>>> I guess wouldn't be so complicated to add support also for faces
>>>>> (and
>>>>> 3d lines in general) to v.to.rast... I can try take a look.
>>>>
>>>> just idea,
>>>>
>>>> tin ->
>>>>
>>>> v.to.points -n
>>>> v.clean tool=rmdupl
>>>> v.surf.* -> dem
>>>
>>> well, this would only give an approximation AFAIK.
>>
>> that is right - if you want to preserve the triangle facets in the
>> TIN
>> you need to do linear interpolation using the 3 points of each
>> triangle facet and you get something like this
>> (this is TIN converted to raster in some old version of Arc)
>>
>> http://skagit.meas.ncsu.edu/~helena/gmslab/interp/F1b.gif
>
>
> I discovered that we have tin.c in vectlib:
>
> int
> Vect_tin_get_z (
> struct Map_info *Map,
> double tx, double ty,
> double *tz, double *angle, double *slope)that looks promising - I checked v.delaunay and unfortunately it
ignores the z-coordinate even if you give it 3D vector points - so first
the v.delaunay would have to be updated to preserve the z-coordinates
and write 3D vector map rather than 2D (perhaps not too complicated
task)
and then the simplest way would be just to call the above function
for each grid point
with Map being the 3D vector area map from v.delaunay.
The computation of slope and aspect is missing but adding those
should be easy.maybe somebody with better C-programming skills could look at it -
just adding
the z coordinate to v.delaunay would add the missing TIN support to
GRASS
and the result could be visualized as 3D vector,Helena
> Markus
> _______________________________________________
> 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
On Jan 28, 2008 9:29 AM, Maris Nartiss <maris.gis@gmail.com> wrote:
Fixing large dataset and 3D support problems would be a nice
improvement of GRASS vector support
Possibly we need to substitute the algorithm? I found for example
http://www.qhull.org/
"Qhull computes the convex hull, Delaunay triangulation, Voronoi
diagram, halfspace intersection about a point, furthest-site Delaunay
triangulation, and furthest-site Voronoi diagram. The software runs in
2-d, 3-d, 4-d, and higher dimensions. Qhull implements the Quickhull
algorithm for computing the convex hull. It handles roundoff errors
from floating point arithmetic. Qhull also computes volumes, surface
areas, and approximations to the convex hull."
(seems to be GPL compliant)
Markus
I noticed this one too a few days back when I was looking for a
3D hull algorithm. Looks like a promising collection of algorithm
for GRASS.
However, for a quick fix of v.delaunay, as suggested by Helena:
Might it not be enough to replace the 2D distance measure in
v.delaunay with a 3D distance, so it will do the tesselation in
3D space correctly?
I could try and find some time to look into that if you think
it feasible.
Benjamin
Markus Neteler wrote:
On Jan 28, 2008 9:29 AM, Maris Nartiss <maris.gis@gmail.com> wrote:
Fixing large dataset and 3D support problems would be a nice
improvement of GRASS vector supportPossibly we need to substitute the algorithm? I found for example
http://www.qhull.org/
"Qhull computes the convex hull, Delaunay triangulation, Voronoi
diagram, halfspace intersection about a point, furthest-site Delaunay
triangulation, and furthest-site Voronoi diagram. The software runs in
2-d, 3-d, 4-d, and higher dimensions. Qhull implements the Quickhull
algorithm for computing the convex hull. It handles roundoff errors
from floating point arithmetic. Qhull also computes volumes, surface
areas, and approximations to the convex hull."(seems to be GPL compliant)
Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany
Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg
On Jan 28, 2008 10:40 AM, Benjamin Ducke <benjamin.ducke@ufg.uni-kiel.de> wrote:
I noticed this one too a few days back when I was looking for a
3D hull algorithm. Looks like a promising collection of algorithm
for GRASS.
What about further code from Joseph O'Rourke?
http://maven.smith.edu/~orourke/books/compgeom.html
http://maven.smith.edu/~orourke/books/ftp.html
It also does Delaunay etc. In this case it should go in as
geometry library into GRASS (instead of using it at module
level).
markus
In relation to handling of large data sets - changing the algorithm
may not solve the issue. I haven't tried it with larger data set but
based on my previous experiences it may get stuck on topology building.
So that would need to be solved first (and you cannot skip topology
this time, as we did with points, because the result are areas and
nothing would work with the resulting map without topology).
As for 3D - Benjamin, if you could just add the original z value to the
output vertices (the value for centroid can be computed by calling the
tin.c ) that will be sufficient to get the basic functionality and display
the resulting TIN in 3D. For more sophisticated triangulations using
the existing libraries would be a more comprehensive solution,
as suggested by Markus (as long as we can make them part of GRASS
distribution)
Helena
On Jan 28, 2008, at 4:40 AM, Benjamin Ducke wrote:
I noticed this one too a few days back when I was looking for a
3D hull algorithm. Looks like a promising collection of algorithm
for GRASS.However, for a quick fix of v.delaunay, as suggested by Helena:
Might it not be enough to replace the 2D distance measure in
v.delaunay with a 3D distance, so it will do the tesselation in
3D space correctly?
I could try and find some time to look into that if you think
it feasible.Benjamin
Markus Neteler wrote:
On Jan 28, 2008 9:29 AM, Maris Nartiss <maris.gis@gmail.com> wrote:
Fixing large dataset and 3D support problems would be a nice
improvement of GRASS vector supportPossibly we need to substitute the algorithm? I found for example
http://www.qhull.org/
"Qhull computes the convex hull, Delaunay triangulation, Voronoi
diagram, halfspace intersection about a point, furthest-site Delaunay
triangulation, and furthest-site Voronoi diagram. The software runs in
2-d, 3-d, 4-d, and higher dimensions. Qhull implements the Quickhull
algorithm for computing the convex hull. It handles roundoff errors
from floating point arithmetic. Qhull also computes volumes, surface
areas, and approximations to the convex hull."(seems to be GPL compliant)
Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
GermanyTel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
I need some clarifications before I can get to work on this,
because I am getting a bit confused.
If we have 3D input points for the TIN construction, then
the resulting triangles should be 3D face primitives not
areas (of which I assumed they were 2D primitives in the
GRASS vector model), shouldn't they?
We would then also be talking about kernels, not centroids,
which should be placed in the 3D geometric center of each
traingular face?
Or am I getting this totally wrong?
Also, it seems to me that for a 3D delaunay triangulation
the algorithm has to search for the nearest point in 3D
space, because if it uses a 2D search, than it will be fooled
by undercutting points and triangulate the wrong
point triplets (I admit that undercuts don't usually appear in terrain
surface modelling, but I have some data where they do).
I guess the problem of building topology for massive data sets should
be solved in the GRASS vector libraries, not in individual modules?
Benjamin
Helena Mitasova wrote:
In relation to handling of large data sets - changing the algorithm
may not solve the issue. I haven't tried it with larger data set but
based on my previous experiences it may get stuck on topology building.
So that would need to be solved first (and you cannot skip topology
this time, as we did with points, because the result are areas and
nothing would work with the resulting map without topology).As for 3D - Benjamin, if you could just add the original z value to the
output vertices (the value for centroid can be computed by calling the
tin.c ) that will be sufficient to get the basic functionality and display
the resulting TIN in 3D. For more sophisticated triangulations using
the existing libraries would be a more comprehensive solution,
as suggested by Markus (as long as we can make them part of GRASS
distribution)Helena
On Jan 28, 2008, at 4:40 AM, Benjamin Ducke wrote:
I noticed this one too a few days back when I was looking for a
3D hull algorithm. Looks like a promising collection of algorithm
for GRASS.However, for a quick fix of v.delaunay, as suggested by Helena:
Might it not be enough to replace the 2D distance measure in
v.delaunay with a 3D distance, so it will do the tesselation in
3D space correctly?
I could try and find some time to look into that if you think
it feasible.Benjamin
Markus Neteler wrote:
On Jan 28, 2008 9:29 AM, Maris Nartiss <maris.gis@gmail.com> wrote:
Fixing large dataset and 3D support problems would be a nice
improvement of GRASS vector supportPossibly we need to substitute the algorithm? I found for example
http://www.qhull.org/
"Qhull computes the convex hull, Delaunay triangulation, Voronoi
diagram, halfspace intersection about a point, furthest-site Delaunay
triangulation, and furthest-site Voronoi diagram. The software runs in
2-d, 3-d, 4-d, and higher dimensions. Qhull implements the Quickhull
algorithm for computing the convex hull. It handles roundoff errors
from floating point arithmetic. Qhull also computes volumes, surface
areas, and approximations to the convex hull."(seems to be GPL compliant)
Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
GermanyTel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany
Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg
As topology building for large vector datasets works slowly but
correctly, I would blame delaunay module for generating garbage. I
interupted v.delaunay run during topology building phase and was able
to display resulting vector map as lines instead of areas and still it
made sense only for first 1/3 of map. IMHO it means, that module
chokes somewhere before requesting to Vect_build_partial
(vector/v.voronoi/dt_main.c:108).
Just my 0.002,
Maris.
I tested it with the nc_spm data set on an older Mac (~500MB RAM)
and it ran fine with
elev_lid792_randpts (6000 points)
subset of elev_lid792_bepts within the rural_1m region (~45000 points)
and crashed with the full elev_lid792_bepts (319000 points)
with the following message:
GRASS 6.3.cvs (nc_spm_05):~ > v.delaunay -r elev_lid792_bepts out=tintest_bebig
v.delaunay(182) malloc: *** vm_allocate(size=8421376) failed (error code=3)
v.delaunay(182) malloc: *** error: can't allocate region
.
v.delaunay(182) malloc: *** error: can't allocate region
v.delaunay(182) malloc: *** set a breakpoint in szone_error to debug
node.c:48: failed assertion `n'
Abort trap
It may run with that data set on a bigger machine but it is obvious that
there is a problem with the triangulation as you have suggested.
I am not sure how difficult the fix would be and whether it is worth the effort
if it is going to be replaced with something more general,
Helena
On Jan 30, 2008, at 4:07 AM, Maris Nartiss wrote:
As topology building for large vector datasets works slowly but
correctly, I would blame delaunay module for generating garbage. I
interupted v.delaunay run during topology building phase and was able
to display resulting vector map as lines instead of areas and still it
made sense only for first 1/3 of map. IMHO it means, that module
chokes somewhere before requesting to Vect_build_partial
(vector/v.voronoi/dt_main.c:108).Just my 0.002,
Maris.
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
In sw_main.c, function readsite ( void ) I find this:
sites = (struct Site *) myalloc(4000*sizeof(*sites));
Since the "sites" structure is meant to contain all points of the
input map: why is it allocated to a pre-defined number of 4000?
Should this not rather be the number of points in the input map?
The size of 4000 is roughly the magnitude of Helena's dataset, so
it would not be too surprising if it crashes for anything well
above that.
(myalloc is a function that just does some out-of-mem error catching).
Benjamin
Helena Mitasova wrote:
I tested it with the nc_spm data set on an older Mac (~500MB RAM)
and it ran fine with
elev_lid792_randpts (6000 points)
subset of elev_lid792_bepts within the rural_1m region (~45000 points)
and crashed with the full elev_lid792_bepts (319000 points)
with the following message:GRASS 6.3.cvs (nc_spm_05):~ > v.delaunay -r elev_lid792_bepts
out=tintest_bebig
v.delaunay(182) malloc: *** vm_allocate(size=8421376) failed (error code=3)
v.delaunay(182) malloc: *** error: can't allocate region
.
v.delaunay(182) malloc: *** error: can't allocate region
v.delaunay(182) malloc: *** set a breakpoint in szone_error to debug
node.c:48: failed assertion `n'
Abort trapIt may run with that data set on a bigger machine but it is obvious that
there is a problem with the triangulation as you have suggested.
I am not sure how difficult the fix would be and whether it is worth the
effort
if it is going to be replaced with something more general,Helena
On Jan 30, 2008, at 4:07 AM, Maris Nartiss wrote:
As topology building for large vector datasets works slowly but
correctly, I would blame delaunay module for generating garbage. I
interupted v.delaunay run during topology building phase and was able
to display resulting vector map as lines instead of areas and still it
made sense only for first 1/3 of map. IMHO it means, that module
chokes somewhere before requesting to Vect_build_partial
(vector/v.voronoi/dt_main.c:108).Just my 0.002,
Maris.
_______________________________________________
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
--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany
Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg
Hi,
2008/1/30, Benjamin Ducke <benjamin.ducke@ufg.uni-kiel.de>:
If we have 3D input points for the TIN construction, then
the resulting triangles should be 3D face primitives not
areas (of which I assumed they were 2D primitives in the
GRASS vector model), shouldn't they?
AFAIU, face is 3D boundary, kernel is 3D centroid for volume (3D
corpus, the topological composition of faces and kernel). So resulting
triangles should be zero-height volumes (volumes constracted from one
face and kernel). ??
We would then also be talking about kernels, not centroids,
which should be placed in the 3D geometric center of each
traingular face?
yes.
Or am I getting this totally wrong?
Also, it seems to me that for a 3D delaunay triangulation
the algorithm has to search for the nearest point in 3D
space, because if it uses a 2D search, than it will be fooled
by undercutting points and triangulate the wrong
point triplets (I admit that undercuts don't usually appear in terrain
surface modelling, but I have some data where they do).I guess the problem of building topology for massive data sets should
be solved in the GRASS vector libraries, not in individual modules?
Yes, it need to be solved on library level.
[snip]
Regards, Martin
--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *
Benjamin Ducke:
> If we have 3D input points for the TIN construction, then
> the resulting triangles should be 3D face primitives not
> areas (of which I assumed they were 2D primitives in the
> GRASS vector model), shouldn't they?
Martin Landa wrote:
AFAIU, face is 3D boundary, kernel is 3D centroid for volume (3D
corpus, the topological composition of faces and kernel). So
resulting triangles should be zero-height volumes (volumes
constracted from one face and kernel). ??> We would then also be talking about kernels, not centroids,
> which should be placed in the 3D geometric center of each
> traingular face?yes.
For a long time it has been unclear to me, do kernels live in the
middle of each face like an area centroid with 3D coordinates, or is it
for true 3D topology like a single point somewhere within a closed
volume defined by many faces.
ie would a cube get a single kernel in the center of it* or six
kernels, one on each face?
[*] if kernel-as-center-of-volume that could hold attribute info like
building address or geological mineral type. For kernel-on-face I can't
think of what kind of attribute you would want to attach to a wall
besides something obvious like "north facing".
Thus I'm leaning to the kernel-as-center-of-volume meaning.
In that case a TIN describing a DEM might just get a single kernel, in
the middle of XY space and placed below the surface to describe the
interior side. (?)
But it would probably only be meaningful for a closed TIN "sphere" of
the entire geoid surface.
??,
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:
For a long time it has been unclear to me, do kernels live in the
middle of each face like an area centroid with 3D coordinates, or is it
for true 3D topology like a single point somewhere within a closed
volume defined by many faces.ie would a cube get a single kernel in the center of it* or six
kernels, one on each face?
That's exactly what I'd like to know too! My recent updates to v.hull
for generating 3D hulls from 3D points threw this one up.
I have decided to put one single kernel into the center of gravity for
the hull, as it seemed to me that this is the 3D equivalent to a 2D
boundary with one centroid.
However, if anyone here sees a need for adding kernels to all faces,
that would be a trivial thing I could add to v.hull (perhaps with
a flag to turn them on?).
[*] if kernel-as-center-of-volume that could hold attribute info like
building address or geological mineral type. For kernel-on-face I can't
think of what kind of attribute you would want to attach to a wall
besides something obvious like "north facing".Thus I'm leaning to the kernel-as-center-of-volume meaning.
In that case a TIN describing a DEM might just get a single kernel, in
the middle of XY space and placed below the surface to describe the
interior side. (?)But it would probably only be meaningful for a closed TIN "sphere" of
the entire geoid surface.??,
Yes, this question would definitely be interesting to discuss for the
v.delaunay 3D update, too.
Benjamin
--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany
Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg
Hi Hamish and others.
IMHO there is use for both variants - kernel inside of cube (six
faces) to hold info about whole object (i.e. house address, owner
etc.) and also centroid on face (wall color, material, received energy
from sun, slope, aspect etc.). If current GRASS vector model does not
support BOTH variants (attribute data to volume and face), then it
should be changed before there are lot of implementations, that relay
on unoptimal vector model.
A task for GRASS 7?
Just took a small glimpse into GRASS programmers manual [1]:
"face: a 3D area; kernel: a 3D centroid in a volume; volume: a 3D
corpus, the topological composition of faces and kernel." If I read it
correctly - both variants are supported - no problem?
Just my 0.002,
Maris.
1. http://download.osgeo.org/grass/grass6_progman/
2008/2/4, Hamish <hamish_b@yahoo.com>:
ie would a cube get a single kernel in the center of it* or six
kernels, one on each face?[*] if kernel-as-center-of-volume that could hold attribute info like
building address or geological mineral type. For kernel-on-face I can't
think of what kind of attribute you would want to attach to a wall
besides something obvious like "north facing".Hamish
