Case Study on Vector Spatial Analysis - Open Source Geospatial Tools: Applications in Earth Observation - page 280

<Placemark>
<name>forest</name>
<styleUrl>#msn_ylw-pushpin0</styleUrl>
<Polygon>
<tessellate>1</tessellate>
<outerBoundaryIs>
<LinearRing>
<coordinates>
-95.33019290829751,29.71502065408062,0
→ -95.33023998155338,29.71492923099211,0
→ -95.33081818953008,29.71366350900777,0
→ -95.3297776904874,29.71328607997145,0
→ -95.32919339535898,29.71390928719686,0
→ -95.3291748843684,29.71396347919087,0
→ -95.32914646493829,29.71416138651291,0
→ -95.32916878564538,29.71433433554835,0
→ -95.32929146327913,29.71490212316071,0
→ -95.33019290829751,29.71502065408062,0
</coordinates>
</LinearRing>
</outerBoundaryIs>
</Polygon>
</Placemark>

16.2 Preprocessing Data

Once all of the features have been created, we will use OGR to export them to a new
Spatialite database, which will contain all of the features. Since Google Earth uses the
WGS84 projection (EPSG:4326), we will also need to reproject the training data to
the projection used in the IEEE Contest (EPSG:26915). As mentioned above, when
creating KML files there is one pre-requisite which is that each feature must have a
field called Name and Description . The option -dsco SPATIALITE="YES"
in ogr2ogr ensures that the Spatialite parameters and functions are added to the newly
created database:

ogr2ogr -f "SQLite" -dsco SPATIALITE="YES" -s_srs "EPSG:4326"
→ -t_srs "EPSG:26915" google_vector.sqlite input.kml

→ -dsco DescriptionField='ADDRESS'

We can use ogrinfo to run a quick consistency check on the Spatialite database
to ensure that all of the features have been added. We see from the output that the
feature count is five and that their spatial extent (bounding box) is consistent with
the extent of the area of interest surrounding the University of Houston.