List Of Code - Trinidad J. Estrada

southdakotascrawnyΔιαχείριση Δεδομένων

29 Νοε 2012 (πριν από 4 χρόνια και 11 μήνες)

255 εμφανίσεις

CMOP Google Ocean
i


CMOP Data With Google Ocean

By Trinidad J. Estrada

Frontline mentor: Alex Jaramillo

Senior mentor: David Maier


Abstract


Using Google’s KML one can freely add content to Google Earth or Google Maps. KML
has several elements that can be used for representing CMOP data. These elements
include but
are not limited to placemarks, p
olylines
, p
olygons,
animations,
image

overlays, a
nd t
ours.
The
elements mentioned are those which were found to be useful for representing CMOP data. If one
compares working with Google Maps and Google Earth, it would be nearly the same thing;
however, Google Maps involves a 2
-
dimensional environment, wh
ereas Google Earth involves
3
-
dimensional, which brings up various issues
not to mention the
restrictions

one must be aware
about.

With the CMOP data, having used Python, along with PostGreSQL command, truly
simplified generating the KML files and it is very necessary in order to pull up to date or specific
information for Google Earth.
The reason why CMOP should find it convenient to

work on
Google Earth is because the newer version allows you to go underwater

and to

also add objects
underwater such as polygons, polylines,

3d models,

and placemarks.

Having this in mind, the
visual representation of CMOP data is possible.



CMOP Google Ocean
ii


Table O
f
Contents

Abstract











i

Table Of Contents










ii

List Of Figures











iii

List Of Code











iv

I.
Introduction











1

What is KML










1

KML Editors










1

Google Earth 5.0 features








2

II.
Elements of KML










3


Placemarks










3


Polylines










5


Polygons










6

Animations










7

Image Overlays










8


Tours











9

III. Generating KML files









11


Connecting to Database with Python







11


Queries Used










11


KML File
Generation Process








14

IV. Conclusion











15

V. References











16



CMOP Google Ocean
iii


List Of Figures


Figure 1
…………………………………………………………………………………………..3

Figure 2
…………………………………………………………………………………………..5

Figure 3
…………………………………………………………………………………………..6

Figure 4
…………………
………………………………………………………………………..8

Figure 5
…………………………………………………………………………………………..12

Figure 6
…………………………………………………………………………………………..13

Figure 7
…………………………………………………………………………………………..14



CMOP Google Ocean
iv


List Of Code


Code 1
……………………………………………………………………………………………1

Code 2
……………………………………………………………………………………………4

Code 3
……………………………………………………………………………………………4

Code 4
……………………………………………………………………………………………5

Code 5
……………………………………………………………………………………………7

Code 6
……………………………………………………………………………………………8

Code 7
……………………………………………………………………………………………8

Code

8
……………………………………………………………………………………………9

Code 9
……………………………………………………………………………………………9

Code 10
…………………………………………………………………………………………..10

Code 11
…………………………………………………………………………………………..11

Code 12
…………………………………………………………………………………………..11

Code 13
……………………………………………………………………………
……………..12

Code 14
…………………………………………………………………………………………..13

Code 15
…………………………………………………………………………………………..13

Code 16
…………………………………………………………………………………………..14




CMOP Google Ocean
1


I.

Introduction


What is KML

KML directly means

Keyhole Markup Language and it is

a
XML

encoded document
.
According to Google, the reason why they used
“Keyhole” as part of the name is because that
used to be the name of an old spy satellite that took imagery from the earth’s surface, which is
something very similar to how Google Earth imagery is displayed.
1

L
ike

any other

XML

document KML

mu
st indicate a

path to the schema
. The example below shows how that is done
in KML:

KML
files could
ha
ve

the extensions .kml and .kmz. The difference between these two is that a
.kml is basically the file with the code, whereas a .kmz will have a .kml file saved in it a
long
with
images

or 3
-
models if any. A .kmz file would be convenient to use when one wants to
distribute their kml files along with images or models. If it is simply code, with nothing else
attached, it would be more convenient to distribute it as .kml bec
ause it takes less memory space.


KML Editors


The only known KML editor
s

out there
are
NorthGates’ KML Editor
2

and KaMeLwriter
(by FreeMind)
3
. However, the disadvantage to these editors is that they have not been maintained
since 2007, so they may lack ma
ny new features and at the same time contain system
incompatibilities.
None of the KML editors

previously mentioned were used for the
project.
With the
newer

versions of Google Earth (4.0+), one hardly needs
to know any KML to insert
place
marks, polygons, and
poly
lines. However, when it comes to 3
-
d
polygons, 3
-
d polylines
,
<
?xml version="1.0" encoding="UTF
-
8"?>

<kml xmlns="http://www.opengis.net/kml/2.2"

xmlns:gx="http://www.google.com/kml/ext/2.2">

Code 1

CMOP Google Ocean
2


tours, animations (with or without real tim
e), and other complex elements, using KML would be
very convenient.

Notepad++ was the editor used for creating the KML with CM
OP data. As for
the debugging process, Google Earth would be the one indicating the error and its location in the
code.


Google Earth 5.0 Features

Unlike the previous versions, this newer version of Google Earth offers the abil
ity to
explore the ocean flo
or, use historical imagery from the world, and use tours with audio.
4


For
CMOP purposes, having the ocean floor feature is a very great tool.
With this feature, not only
can one explore the ocean floor using Google Earth, but one may also add objects
underneath the
water.

As for t
he historical imagery feature, that is also a very useful feature that CMOP can use,
because that allows to use ground overlays, which would indicate data, and see them change as
time progresses. As for using tours with audio,

no

work
has been done with it concerning
CMOP
, but it is possible and perhaps CMOP might want to include some audio with their tours
for the K
-
12 program.




CMOP Google Ocean
3


II.

Elements of KML

This section will describe the most used elements of KML during the CMOP
Google
Ocean project. There will be examples of each and some code to describe what it would look like
in the actual .kml file. These elements of KML have either already been used for CMOP data or
could be used.

These descriptions will not go into full dep
th but they will for the least give basic
information.


Placemarks

A placemark basically is a pinpoint, but with information from that location
of the earth
.
Each placemark would contain a location (as to where it will be positioned on the
earth), name
(the placemark needs a name), and description (information about the placemark). A placemark
can also have an image to mask it. Below is an example of a placemark from one of the CMOP
stations. Not
ice

that thi
s placemark has been clicked on

i
n order to cause

a popup to show up

with the description. On the
left hand side of the Google
Earth application take note
of the “Places” area, how it
organizes each of the
elements on Google Earth.
The KML code will give a
clearer description as to
what i
s going on there.
Organizing the elements in
Figure 1

CMOP Google Ocean
4


such a manner is important because as more

and

more elements are added
,

because

things tend to
get complicated.

The KML code for the placemark will look as follow:



The <Folder> tag is what organized this placemark in the “
Fixed

stations” folder as it was shown
on figure 1. Using this allows you to organize placemarks, 3
-
d models, tours
, images, etc… into
their own folders that way they will not be scattered.

A fixed station consists of only one
unchanged value because there is no database interaction.

The <Placemark> tag is what creates
the placemark to begin with.

The <name> tag is wha
t gives both the folder and the placemark a
name as shown on figure 1. The <Style> tag is what gave the placemark the CMOP logo. The
<description> tag is the information that pops out when click on a placemark. However,
<description> is not only limited to

text, it can also include images and HTML code. In order to
use HTML code your <description> will need to look as follow:


The <![CDATA[ tag is
what makes the use of html possible. An
ything that is HTML may be included in that tag except
<description>


This is the default Google Earth text for description.


<![CDATA[


<h1>Yay!</h1>


<p><b>Now</b> <i>I</i> <b
><i>Can</i></b> use HTML</p>


<img src=”
http://www.stccmop.org/files/images/cmop
-
small.png
”/>


]]>No more HTML :(

</description>

<Folder id="stations">


<name>
Static stations</name>


<ExtendedData>Corie and Saturn stations</ExtendedData>


<Placemark id="am169">



<name>am169</name>



<Style>


<Icon>




<href>http://www.stccmop.org/files/images/cmop
-
small.png</href>


</Icon>


</Style>


<description>time: 2009
-
06
-
09 13:38:33
-
07,conductivity: 0.31,


salinity: 0.18,temperature: 16.04</description>


<Point>


<altitudeMode>clampToGround</altitudeMode>


<coordinates>
-
123.852,46.196,0</coordinates>


</Point>


</Placemark>

<
/Folder>

Code 2

Code 3

CMOP Google Ocean
5


for scripts. The <Point> tag determines where and how <Placemark> will be located on the earth.
<altitudeMode> has these three choices: clampToGround, relativeToGround, and absolute.
The
<coordinates>
on Code 1 include a longitude, latitude, and depth or height, which basically gives
the point a position. When using <altitudeMode> and the value

clampToGround

, no matter
what the depth is, it will be ignored. This is why when trying to place an object u
nderwater, the
<altitudeMode> must be “absolute”.


Polylines

Polylines are made up of connected

points. Google Earth actually has a limit of 60,658
points that could be used for making one interconnected polyline. This was proved during the
testing phase with Python. Below is an example of how a Polyline should look.

This poly
line only uses three points for demonstration purposes. Below is the KML code for this
line:




Figure 2

<Placemark>


<name>Glider T
rail</name>


<visibility>1</visibility>


<LineString>


<extrude>0</extrude>


<tessellate>1</tessellate>


<altitudeMode>absolute</altitudeMode>


<coordinates>


-
124.606708,47.105091,0


-
124.60412,47.103493,0


-
124.6,47.103491,0


</
coordinates>


</LineString>

</Placemark>

Code 4

CMOP Google Ocean
6



On Code 3, notice that when making a line, it must be placed under placemark. The tag
<visibility>

is a Boolean (0,1) tag, which indicates whether or not to show the placemark. 1
means to show, 0 means not to show.
The tag <LineString> indicates that this placemark is a
line, not a <point>. <extrude> specifies if line is connected to the ground, which

in this case,
since it is value 0, it is not connected to the ground. <tessellate> indicates whether or not the line
follows the terrain. Using <tessellate> is very important when using large lines, because if it is
not used, then one large line might go
through the earth thus making it not visible. All the points
that make up the line go in <coordinates>.

Note: adding a depth could make a line 3 dimensional.


Polygons

Polygons are very similar to polylines by the fact that it uses lines
connecting from one point to
another. However,

one can
create 2
-
dimensional and 3
-
dimensional figures out of polygons
unlike polylines.

Below is an example of a 3
-
d cylinder made by using a 3
-
dimensional polygon.

When one thinks of polygons, one might only think about them as 2
-
dimensional, which could
also be true in Google Earth. But, since a height can be added to a
polygon that

means that it
Figure 3

CMOP Google Ocean
7


could also be 3
-
dimensional. The next page will have
the KML code for
Figure 3. Other
unnecessary pieces of the code, such as the polyg
on color, were left out
.


The polygon tags are very different in comparison to the polyline tags; however, notice that the
<coordinates> are done the same as a polyline. <MultiGeometry> specifies that placemark as
being a
figure with more than on
e element
.

In this case, there is a <Point> and a <Polygon>.
Figure 3 shows the CMOP icon and the cylinder together, and this was done through
<MultiGeometry> that way they would not be two separate objects. <outerBoundaryIs> specifies
that the <coordinate
s> inside <LinearRing> make the up the outer line for the polygon.
An
<innerBoundaryIs> tag

could be used

to cut out

(hollow) shapes

from a polygon.


Animations


Animations are done to update the appearance or location of an object.
There are two
approache
s that can be taken for making an animation in real
-
time: <TimeSpan> and
<TimeStamp>. With <TimeSpan> there’s a <begin> and <end> time, whereas <TimeStamp>
only has a <when> tag. For animation purposes in real
-
time, <TimeSpan> was found to be the
<Placemark id="saturn01">


<name>saturn01</name>


<MultiGeometry>


<Point>


<coordinates>
-
123.872,46.235,0</coordinates>


</Point>


<Poly
gon>


<extrude>1</extrude>


<tessellate>1</tessellate>


<altitudeMode>absolute</altitudeMode>


<outerBoundaryIs>


<LinearRing>


<
coordinates>

-
123.867,46.235,15000
-
123.868,46.2375,15000
-
123.87,46.2393,15000
-
123.872,46
.24,15000
-
123.875,46.2393,15000
-
123.876,46.2375,15000
-
123.877,46.235,15000
-
123.876,46.2325,15000
-
123.875,46.2307,15000
-
123.872,46.23,15000
-
123.87,46.2307,15000
-
123.868,46.2325,15000

-
123.867,46.235,15000


</coordinates>


</LinearR
ing>


</outerBoundaryIs>


</Polygon>


</MultiGeometry>

</Placemark>

Code 5

CMOP Google Ocean
8


most use
ful, because having the tw
o times
gives the object a duration to change location or
appearance rather than appearing at a specific time and disappearing after that time is over like
<TimeStamp>. The time values for either <TimeSpan> or <TimeStamp> have to
be in the
following format:
yyyy
-
mm
-
ddThh:mm:sszzzzzz
.
Below are examples of how the code should
look

like
.




Image Overlays


With Google’s Historical imagery from the world feature now enabled, that means
images can be overlayed on the earth’s surface.
The image below shows a very great example of
CMOP data being
displayed on Google Earth as an image overlay.

<TimeStamp id=ID>


<when>
2007
-
01
-
15T17:05:02Z
/when>

</TimeStamp>



<TimeSpan>


<begin>
2007
-
01
-
15T17:05:02Z
</begin>


<end>
2007
-
01
-
15T18:05:02Z
</end>

</TimeSpan>


Code 6

Code 7

Figure 4

CMOP Google Ocean
9


One of the easiest ways to deal with overlays is by adjusting the image on the surface of the earth
using Google Earth, rather than trying to guess what points to use in the KML file.
The
transparency of the p
icture can also be modified with Google Earth. As you may have noticed on
Figure 4, the surface of the ocean can still be seen even though there is an image right on top of
it. Below is how the KML code would look for this image overlay.


By default, the image will be sticking to the Earth’s surface that way it is not
flat

on a round
surface.


Tours

The way tours basically work is by moving the camera from one
point

to another.
The
camera view is
controlled by a tag called <LookAt>. This element has the following properties:
longitude, latitude, altitude, heading, tilt, and range. With these variables, total control of the
camera is possible. Below is an example of how the code should look for posi
tioning a camera:


<Grou
ndOverlay>


<Icon>


<href>
ground
-
image
.png</href>


</Icon>


<LatLonBox>


<north>46.81248888888888</north>


<south>45.33280833333333</south>


<east>
-
123.3422777777778</east>


<west>
-
125.0897694444444</west>


<rotation>
-
0.9415012362814723
</rotation>


</LatLonBox>

</GroundOverlay>

Code 8

CMOP Google Ocean
10




This code comes from the camera view of Figure 1.

The <range> indicates how far away to put
the camera from the <longitude> and <latitude> points. The <heading> indicates the direction of
the camera: North, South, East,

and West. The <tilt> has values in degrees, which indicate the
direction between the <LookAt> and the earth’s surface.
5



Now with a tour, whatever was in the <LookAt> tag as shown in Code 9, would have to
go inside of <gx:FlyTo> tags. The values specifie
d in <LookAt> will determine where and how
the camera will move during a tour. Below is the code of how a point for a tour should be
started:


Inside the <gx:Tour> there’s a <gx:Playlist> which con
tains a <gx:FlyTo> for every <LookAt>
value given for the tour. The time it takes for the tour to move from one point to another is
controlled by using <gx:duration>. <gx:flyToMode> determines if a camera moves by bouncing
<gx:Tour>


<name>Smooth tour example</name>


<gx:Playlist>


<gx:FlyTo>


<gx:duration>4.0<
/gx:duration>


<!
--
<gx:flyToMode>smooth</gx:flyToMode>
--
>


<LookAt>


<longitude>
-
124.083625</longitude>


<latitude>46.233842</latitude>


<altitude>0</altitude>


<heading>90</heading>


<tilt>0</tilt>


<ran
ge>22570.546801</range>


<altitudeMode>relativeToGround</altitudeMode>


</LookAt>


</gx:FlyTo>


</gx:Playlist>

</gx:Tour>

<LookAt>


<longitude>
-
123.852</longitude>


<latitude>46.196</latitude>


<range>1000</range>


<tilt>0</tilt>


<heading>0</heading>

</LookAt>

Code 9

Code 10

CMOP Google Ocean
11


III. Generating KML Files

Making small KML files can be easy; however, when dealing with CMOP data, a large
quantity of data may be needed. This is why Python had to be used in order for this to be
possible.
Along with the Python, PostGreSQL commands were used to grab the data dire
ctly
from the CMOP database.
In this project, a mod
-
python named psycopg2 was used along with an
Apache server, all done in a
Microsoft

Windows XP e
nvironment.
In order for mod
-
python to
recognize what type of media will be formed out from the script, the
req.content_type

(or media
type) must be ‘
application/vnd.google
-
earth.kml+xml
’.


Connecting to Database with Python

In order to connect to the

PostGreSQL

database

with Python the following command
must be put in Python:


This command is exactly what you

need in order to connect to the PostGreSQL database. Other
database systems, such as Oracle have their methods different
ly

through Python.
Once this step
has been completed, the queries are next.


Queries Used


The following queries were used

for plotting points in order to produce a polyline.

This
was the first Query used:


select depth, latitude, longitude from auv.gliderdata where mission='grays harbor
1' order by time

try:


conn = psycopg2.connect("dbname='cmop' user='
cmoper
' host='stccmop.org'
p
assword='
password
'");

except:


print "
Argh!!
I am unable to connect to the database"

Code 11

Code 12

CMOP Google Ocean
12


However, being as small as the command is, it had its disadvantages, one of them being that too
many points were being grabbed for this mission.
Many of the points had to be eliminated
through Python in order for Google Earth to make a polyline out of this.
This is the command
(Code 12) that caused Google Earth to nearly crash because of all the points being processed


Figure 5 is a very great exam
ple of the outcome for this mission with placemarks that is. Notice
how close they are to one another. This is just one piece for this mission, there are more points
ahead.



The following
SQL

query

filters some points truncating
time and
position of the sample.

Along with this,

a script written in Python generates a polyline that is a good approximation of
the glider trajectory.


select distinct(date_trunc('second',time)) as mission_hour, latitude(location,5) as latitude,
longitude(locat
ion,5) as longitude, round(m_depth,5) from auv.slocumrawdata where m_depth IS NOT
NULL and platform='unit_092' and time>'2009
-
06
-
15 00:00:00' order by mission_hour;

Figure 5

Code 13

CMOP Google Ocean
13


Notice the difference betwee
n Code 12 and Code 13. The information for Code 12 is coming
from a different table
, “auv.slocumrawdata”.

Figure 6 shows a significant difference on the
amount of points used for making the line.

The last Query used
,

proved to be the most efficient because Python did not spend any
time weeding out the unnecessary points

and it also gave a minimal amount of points, thus
making it easier on the glider tour.


Code 14 is the Query the final project of the Glider tour used with some adjustments. In order for
the PostGreSQL commands not to be ha
rd coded into the Python script, the following had to be
done in Python:



form = util.FieldStorage(req, keep_blank_values=1)


start_date = form['fromdate']


form = util.FieldStorage(req, keep_blank_values=1)


end_date = form['todate']


form = util.FieldStorage(req, keep_blank_values=1)


platform_name = form['platform']


sql = "select * from (select distinct on (latitude(location,3), longitude(location,3))
date_trunc('minute',time) as mission_hour, latitude(location,6) as latitude, lo
ngitude(location,6)
as longitude, round(m_depth,6) from auv.slocumrawdata where m_depth IS NOT NULL and platform='" +
platform_name + "' and time>'" + start_date +" 00:00:00' and time<'" + end_date +" 00:00:00') as
temptable order by mission_hour limit 200
"

select * from (select distinct on (latitude(location,3), lon
gitude(location,3))
date_trunc('minute',time) as mission_hour, latitude(location,6) as latitude, longitude(location,6)
as longitude, round(m_depth,6) from auv.slocumrawdata where m_depth IS NOT NULL and
platform='unit_092' and time>'2009
-
06
-
15 00:00:00') a
s temptable order by mission_hour limit
60658

Figure 6

Code 14

Code 15

CMOP Google Ocean
14


Having this in Python, now allows the user to get the specific information he or she wishes to get
simply by doing as follow:



KML File Generation Process

Figure 7 demonstrates visually what occurs when retrieving glider data and generating a
KML file out of it through
Python.


During the mission, the glider would send some of its data to the satellite and the satellite would
send that data to the database. After the glider has finished with the mission, it is then connected
to a computer, where all of the
data it collected is loaded on to it. From there, it is networked to
the database to make the data accessible. Once all of the data is in the database, the Python
script, along with the PostGreSQL commands, will grab the data specified by the Queries and
g
enerate a KML file. After the KML file is generated, it would be available for any user to use
on their computers with Google Earth 5.0 installed.

This concludes the KML file generation
process.



http://localhost/glider_mission.py?start_date=2009
-
06
-
15&end_date=2009
-
06
-
17&platform=unit_092

Code 16

Figure 7
6

CMOP Google Ocean
15


IV. Conclusion


In all, having used KML

to display CMOP dat
a on Google Ocean is indeed possible.
However, there is much work to be done with the database for quality control. If there is no
quality control, then using Google Earth as a means for education, will confuse or cause students
to get the wrong idea on ho
w something works. A great example of this would be the GPS
tracking of the Glider. Sometimes certain bizarre points are sent which makes the glider seem as
if it jumps sideways. There is also much work to be done with the KML, such as adding
g
auges
that i
ndicate temperature, depth, or salinity on Google Earth.
Doing this would enhance a user’s
experience when using Google Earth for viewing CMOP data.




CMOP Google Ocean
16


References

1.

http://code.google.com/apis/kml/documentation/kml_tut.html

2.

http://www.northgates.ca/KMLEditor

3.

http://www.kamelwriter.com

4.

http://earth.google.com/

5.

http://code.google.com/apis/kml/documentation/kmlreference.html

6.

http://www.wired.com/images_blogs/photos/uncategorized/2008/02/12/satellite.jpg