[GRASS-user] v.in.ogr of a 3d shape

[Benjamin Ducke]

You have 3D polygons in your input data.

Getting 3D polygon data into GRASS can be
tricky.

Since GRASS uses a 2D topology model for
polygons, it will butcher all 3D polygons that
do not overlap in 3D space, but do so from a 2D
perspective. It will also have trouble with
polygons that extend only along the Z axis
and have no X-Y area.

Even if you manage to get the data into
GRASS using v.in.ogr's "-c" flag, you won't
be able to do much with it, because the result
will not have a valid GRASS topology.

If import into GRASS fails, you basically
have two choices:

1. Import polygons as polylines (use the
"type" option in v.in.ogr). But that of
course will modify your geometries.

2. Use GRASS7 and v.external to attach
the Shapefile directly (GRASS 6.4 cannot
attach 3D vector data sources).

Best,

Ben

Btw. QGIS has a strictly 2D vector data model, so
that won't get you anywhere.


On 10/14/2011 05:19 PM, Markus Metz wrote:
> Sebastian Schubert wrote:
>> Hi,
>>
>> I want to read a 3d shape. Unfortunately, it does not finish (killed
>> after 2 hours!). Qgis is able to import it although I guess it is done
>> in 2d what grass is also capable of without the -z switch. Here is the
>> output with grass 6.4.1:
>>
>>>   v.in.ogr --v -z dsn=St_Flaeche_3D.shp out=basel3d
>> Projection of input dataset and current location appear to match
>> Using temporary vector<basel3d_tmp>
>> Layer: St_Flaeche_3D
>> Counting polygons for 1192679 features...
>> Boundary splitting distance in map units: 176.386
>> Importing map 1192679 features...
>>   100%
>> -----------------------------------------------------
>> Building topology for vector map<basel3d_tmp>...
>> Registering primitives...
>> 397678 primitives registered
>> 1549444 vertices registered
>> Topology was built
>> Number of nodes: 268594
>> Number of primitives: 397678
>> Number of points: 0
>> Number of lines: 0
>> Number of boundaries: 397678
>> Number of centroids: 0
>> Number of areas: -
>> Number of isles: -
>> -----------------------------------------------------
>> WARNING: Cleaning polygons, result is not guaranteed!
>> -----------------------------------------------------
>> Break polygons:
>>   100%
>>   100%
>> -----------------------------------------------------
>> Remove duplicates:
>>   100%
>> -----------------------------------------------------
>> Break boundaries:
>>   100%
>> Intersections: 239035
>> -----------------------------------------------------
>> Remove duplicates:
>>   100%
>> -----------------------------------------------------
>> Clean boundaries at nodes:
>> -----------------------------------------------------
>> Break boundaries:
>>   100%
>> Intersections: 22
>> -----------------------------------------------------
>> Remove duplicates:
>>   100%
>> -----------------------------------------------------
>> Clean boundaries at nodes:
>> -----------------------------------------------------
>> Break boundaries:
>>   100%
>> Intersections: 0
>> -----------------------------------------------------
>> Remove duplicates:
>>   100%
>> -----------------------------------------------------
>> Clean boundaries at nodes:
>> -----------------------------------------------------
>> Change dangles to lines:
>>   100%
>> -----------------------------------------------------
>> Remove bridges:
>>   99%
>>
>>
>> Here it stops to produce output but still there is 100% CPU usage. Any idea?
>
> Yes. It takes very long because of a high number of potential bridges.
> This can happen with some larger vector files and processing speed has
> been improved in 6.4.2 and above. Please try 6.4.2RC1 if possible.
>
> Markus M
> _______________________________________________
> grass-user mailing list
> grass-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user



-- 
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

   benducke at fastmail.fm