#3286: Add Line_height as a valid attribute in v.to.db
---------------------------------------+-------------------------
Reporter: geografik | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.2.1
Component: Database | Version: 7.2.0
Keywords: Line_height, v.in.db, kml | CPU: All
Platform: All |
---------------------------------------+-------------------------
Imported kml files that include elevation data are structured generally as
shown below in GRASS (this is an example of a contour line):
Elevation data is maintained in the Line_height field which is not a
recognized attribute, and therefor precludes any further use of these data
in GRASS - beyond simple display and labling. 3D analysis, for example,
is not possible. The suggested improvement to v.to.db would add
Line_height to the list of attributes considered in this module so that
the elevation data could become part of the recognized feature attributes
and be useful in other modules.
#3286: Add Line_height as a valid attribute in v.to.db
--------------------------+---------------------------------------
Reporter: geografik | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.2.1
Component: Database | Version: 7.2.0
Resolution: | Keywords: Line_height, v.in.db, kml
CPU: All | Platform: All
--------------------------+---------------------------------------
Comment (by mlennert):
Replying to [ticket:3286 geografik]:
> Imported kml files that include elevation data are structured generally
as shown below in GRASS (this is an example of a contour line):
>
> east, north: -79.7630759471, 39.0874586371
> DBT@corH:
> Type: Line
> Id: 885
> Length: 275.746
> Line_height: 698.602997
> Layer: 1
> Category: 885
> Driver: sqlite
> Database: /Users/sesMacBook/grassdata/KML/corH/sqlite/sqlite.db
> Table: DBT
> Key_column: cat
> Attributes:
> cat: 885
> cat_: 885
> tessellate: -1
> extrude: -1
> visibility: -1
>
> Elevation data is maintained in the Line_height field which is not a
recognized attribute, and therefor precludes any further use of these data
in GRASS - beyond simple display and labling. 3D analysis, for example,
is not possible. The suggested improvement to v.to.db would add
Line_height to the list of attributes considered in this module so that
the elevation data could become part of the recognized feature attributes
and be useful in other modules.
Actually, Line_height is not a "field" in the data. v.what calculates the
minimum and the maximum height of all the vertices of a line and either
outputs both, or, if they are equal, only one value.
The question this raises, therefore, is: which "height" is the most
relevant for a line ? Should it be the mean height of all vertices ?
Should v.to.db provide lheight_min, lheight_mean and lheight_max ?
Elevation data is maintained in the Line_height field which is not a
recognized attribute, and therefor precludes any further use of these
data in GRASS - beyond simple display and labling. 3D analysis, for
example, is not possible. The suggested improvement to v.to.db would add
Line_height to the list of attributes considered in this module so that
the elevation data could become part of the recognized feature attributes
and be useful in other modules.
New description:
Imported kml files that include elevation data are structured generally as
shown below in GRASS (this is an example of a contour line):
Elevation data is maintained in the Line_height field which is not a
recognized attribute, and therefor precludes any further use of these data
in GRASS - beyond simple display and labling. 3D analysis, for example,
is not possible. The suggested improvement to v.to.db would add
Line_height to the list of attributes considered in this module so that
the elevation data could become part of the recognized feature attributes
and be useful in other modules.
#3286: Add Line_height as a valid attribute in v.to.db
--------------------------+---------------------------------------
Reporter: geografik | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.2.1
Component: Database | Version: 7.2.0
Resolution: | Keywords: Line_height, v.in.db, kml
CPU: All | Platform: All
--------------------------+---------------------------------------
Comment (by mmetz):
Replying to [comment:1 mlennert]:
> Replying to [ticket:3286 geografik]:
> > Imported kml files that include elevation data are structured
generally as shown below in GRASS (this is an example of a contour line):
> >
> > east, north: -79.7630759471, 39.0874586371
> > DBT@corH:
> > Type: Line
> > Id: 885
> > Length: 275.746
> > Line_height: 698.602997
> > Layer: 1
> > Category: 885
> > Driver: sqlite
> > Database: /Users/sesMacBook/grassdata/KML/corH/sqlite/sqlite.db
> > Table: DBT
> > Key_column: cat
> > Attributes:
> > cat: 885
> > cat_: 885
> > tessellate: -1
> > extrude: -1
> > visibility: -1
> >
> > Elevation data is maintained in the Line_height field which is not a
recognized attribute, and therefor precludes any further use of these data
in GRASS - beyond simple display and labling. 3D analysis, for example,
is not possible. The suggested improvement to v.to.db would add
Line_height to the list of attributes considered in this module so that
the elevation data could become part of the recognized feature attributes
and be useful in other modules.
>
>
> Actually, Line_height is not a "field" in the data. v.what calculates
the minimum and the maximum height of all the vertices of a line and
either outputs both, or, if they are equal, only one value.
>
> The question this raises, therefore, is: which "height" is the most
relevant for a line ? Should it be the mean height of all vertices ?
Should v.to.db provide lheight_min, lheight_mean and lheight_max ?
The correct mean height of a line is the sum of the weighted averages of
each line segment divided by the sum of weights. The weight of a line
segment is its 3D length.