<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi,<br>
<br>
Is not quite significant. For example the 23090M data set loading
just finished.<br>
<br>
Total time was 3816 seconds.<br>
- Loading 1400 files (16 simult. process) took 3660 seconds.<br>
- Create primary index (obj_id/blk_id) took 2 seconds<br>
- Insert into USER_SDO_GEOM_METADATA was less than 1 second<br>
- Create spatial index was 35 seconds<br>
- Analyse table was 4 seconds<br>
- Gather_table_stats was 112 seconds<br>
<br>
So, it is reasonable<br>
<br>
O.<br>
<br>
<div class="moz-cite-prefix">On 12-08-15 12:03, Peter van Oosterom
wrote:<br>
</div>
<blockquote cite="mid:55CB1A05.603@tudelft.nl" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div class="moz-cite-prefix">Hi Oscar,<br>
<br>
Great that PDAL/Oracle now scales well!<br>
<br>
It might be that for large datasets analyze+stats may get
expensive part of load time.<br>
To avoid this step, an alternative would be to add hint for
query optimizer to use index.<br>
<br>
However, perhaps the analyze+stats at block level are not too
expensive (as it would<br>
be at point level) and in that case the needed time might be
neglectable, and in that<br>
case better to do so (as in your script now and without hit).<br>
<br>
Good to check how much time these steps take and then we know
what to do<br>
(especially for loading complete ahn with 640 billion points).<br>
<br>
Kind regards, Peter.<br>
<br>
Oscar Martinez Rubi schreef op 12-8-2015 om 11:53:<br>
</div>
<blockquote cite="mid:55CB17B7.5040907@esciencecenter.nl"
type="cite"> Hi,<br>
<br>
When you say that statistics are auto-gathered...by who? PDAL or
Oracle? <br>
- In PDAL OCIWritter I do not see anything to do the analyze
and gather_stats. I would maybe put it just after creating the
indexes, and also optional as the indexes creation, because you
only want to do that after the loading of the last file.<br>
- In Oracle itself I have not disabled anything (as far as I
remember) and they are indeed computed automatically after a
while, the problem is how long is "this while", to be sure, and
as you recommend, it is maybe just better to do it your own once
you know the loading is over.<br>
<br>
So, bottom line: I do the loading of all the files (with pdal)
with deactivated indexing. And then, the stuff I do after the
last pdal loading is:<br>
<br>
- Create primary key on obj_id/blk_id. This is the one you
suggest<br>
- Insert info in USER_SDO_GEOM_METADATA of the whole extent of
all the loaded data (from different files and in different PDAL
runs)<br>
- Create the spatial index<br>
- Analyze and gather stats<br>
<br>
The SQL commands for that are:<br>
<br>
ALTER TABLE AHN_BLCK ADD CONSTRAINT AHN_BLCK_PK PRIMARY KEY
(OBJ_ID, BLK_ID) USING INDEX TABLESPACE INDX;<br>
<br>
INSERT INTO USER_SDO_GEOM_METADATA VALUES
('AHN_BLCK','BLK_EXTENT',<br>
SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X',60000.0,100000.0,0.0001),<br>
SDO_DIM_ELEMENT('Y',425000.0,475000.0,0.0001)),28992);<br>
<br>
CREATE INDEX AHN_BLCK_SIDX ON AHN_BLCK (BLK_EXTENT) INDEXTYPE IS
MDSYS.SPATIAL_INDEX PARAMETERS ('TABLESPACE=INDX
WORK_TABLESPACE=PCWORK LAYER_GTYPE=POLYGON SDO_INDX_DIMS=2
SDO_RTR_PCTFREE=0') PARALLEL 16 ;<br>
<br>
ANALYZE TABLE AHN_BLCK COMPUTE SYSTEM STATISTICS FOR TABLE;<br>
<br>
BEGIN<br>
DBMS_STATS.GATHER_TABLE_STATS('PDAL23090M','AHN_BLCK',NULL,NULL,FALSE,'FOR
ALL COLUMNS SIZE AUTO',8,'ALL');<br>
END;<br>
<br>
After the doing all these steps the query times are as expected
so I am going to assume those are the exact proper steps. The
times are now scalable and quite nice (right now still busy with
the 23 billion dataset but I guess it is safe to assume they
will also be fine ;) )!<br>
<br>
<tt>Time[s] pdal20M pdal210M pdal2201M pdal23090M</tt><tt><br>
</tt><tt>--------- --------- ---------- -----------
------------</tt><tt><br>
</tt><tt>01_0 0.63 0.37 0.41 -</tt><tt><br>
</tt><tt>01_1 0.18 0.2 0.22 -</tt><tt><br>
</tt><tt>02_0 1.18 1.51 1.54 -</tt><tt><br>
</tt><tt>02_1 0.96 0.96 0.93 -</tt><tt><br>
</tt><tt>03_0 0.24 0.25 0.25 -</tt><tt><br>
</tt><tt>03_1 0.18 0.18 0.18 -</tt><tt><br>
</tt><tt>04_0 1.49 1.53 1.44 -</tt><tt><br>
</tt><tt>04_1 1.05 1.07 1.06 -</tt><tt><br>
</tt><tt>05_0 0.66 0.78 0.76 -</tt><tt><br>
</tt><tt>05_1 0.49 0.51 0.49 -</tt><tt><br>
</tt><tt>06_0 1.42 1.61 1.64 -</tt><tt><br>
</tt><tt>06_1 1.17 1.2 1.21 -</tt><tt><br>
</tt><tt>07_0 1.6 2.12 2.15 -</tt><tt><br>
</tt><tt>07_1 1.62 1.35 1.43 -</tt><tt><br>
</tt><br>
Thanks for your help and suggestions!<br>
<br>
Regards,<br>
<br>
O.<br>
<br>
<br>
<div class="moz-cite-prefix">On 12-08-15 00:30, Smith, Michael
ERDC-RDE-CRREL-NH wrote:<br>
</div>
<blockquote
cite="mid:D1EFEDEF.1172ED%25michael.smith@erdc.dren.mil"
type="cite">
<div>
<div>The statistics should actually auto gather (unless
you've disabled that part). Its done as part of the DBMS
Auto tasks and should gather when the tables are stale.
Although this is more for a production type operation. If
you are doing testing, you absolutely should make sure
your statistics are up to date otherwise you will get bad
access plans. </div>
<div><br>
</div>
<div>Its also recommended to set a unique index on your
Block table on the Obj_ID/Blk_ID (although this is
primarily used to individually select pointclouds). The
more info you can give the optimizer, the better your
query will perform. </div>
<div><br>
</div>
<div>You can run (and should) explain plan's on your data
access queries and see what estimates the optimizer
returns. If they don't match what you expect, then you're
probably feeding bad information to the optimizer.</div>
<div><br>
</div>
<div>Mike</div>
<div><br>
</div>
<div>
<div>
<div>----</div>
<div>Michael Smith</div>
</div>
<div>US Army Corps</div>
<div>Remote Sensing GIS/Center</div>
<div><a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:michael.smith@usace.army.mil">michael.smith@usace.army.mil</a></div>
<div><br>
</div>
</div>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt;
text-align:left; color:black; BORDER-BOTTOM: medium none;
BORDER-LEFT: medium none; PADDING-BOTTOM: 0in;
PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df
1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"> <span
style="font-weight:bold">From: </span><<a
moz-do-not-send="true"
href="mailto:pdal-bounces@lists.osgeo.org">pdal-bounces@lists.osgeo.org</a>>
on behalf of Oscar Martinez Rubi <<a
moz-do-not-send="true"
href="mailto:o.rubi@esciencecenter.nl">o.rubi@esciencecenter.nl</a>><br>
<span style="font-weight:bold">Date: </span>Tuesday,
August 11, 2015 at 11:04 AM<br>
<span style="font-weight:bold">To: </span>Peter van
Oosterom <<a moz-do-not-send="true"
href="mailto:P.J.M.vanOosterom@tudelft.nl">P.J.M.vanOosterom@tudelft.nl</a>>,
Albert Godfrind <<a moz-do-not-send="true"
href="mailto:albert.godfrind@oracle.com">albert.godfrind@oracle.com</a>>,
"<a moz-do-not-send="true"
href="mailto:pdal@lists.osgeo.org">pdal@lists.osgeo.org</a>"
<<a moz-do-not-send="true"
href="mailto:pdal@lists.osgeo.org">pdal@lists.osgeo.org</a>><br>
<span style="font-weight:bold">Cc: </span>Theo Tijssen
<<a moz-do-not-send="true"
href="mailto:T.P.M.Tijssen@tudelft.nl">T.P.M.Tijssen@tudelft.nl</a>>,
"<a moz-do-not-send="true"
href="mailto:mike.horhammer@oracle.com">mike.horhammer@oracle.com</a>"
<<a moz-do-not-send="true"
href="mailto:mike.horhammer@oracle.com">mike.horhammer@oracle.com</a>><br>
<span style="font-weight:bold">Subject: </span>[EXTERNAL]
Re: [pdal] Oracle PDAL queries not scaling<br>
<span style="font-weight:bold">Resent-From: </span>Michael
Smith <<a moz-do-not-send="true"
href="mailto:michael.smith@usace.army.mil">michael.smith@usace.army.mil</a>><br>
</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE"
style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5;
MARGIN:0 0 0 5;">
<div>
<div bgcolor="#FFFFFF" text="#000000">Hi,<br>
<br>
What I did now is to force statistics gathering, so:<br>
<br>
ANALYZE TABLE AHN_BLCK compute system statistics for
table;<br>
BEGIN<br>
dbms_stats.gather_table_stats('PDAL20M','AHN_BLCK',NULL,NULL,FALSE,'FOR
ALL COLUMNS SIZE AUTO',8,'ALL');<br>
END;<br>
<br>
And after doing this the queries are scalable, so in
this way I do not need to wait for the DB to learn...<br>
<br>
Regards,<br>
<br>
O.<br>
<br>
<br>
<div class="moz-cite-prefix">On 11-08-15 16:51, Peter
van Oosterom wrote:<br>
</div>
<blockquote cite="mid:55CA0C0C.6090700@tudelft.nl"
type="cite">
<div class="moz-cite-prefix">Hi Oscar,<br>
<br>
It feels like when you fetch the data, this is
based on a query execution plan that does a full
table scan to get the blocks. Even if there is an
index, the database may not use this. However, the
database may notice that the actual query
execution was disappointing (collecting
statistics), and that after repeating the same
tests, the database behaviour changed its
behaviour and does scale well. <br>
<br>
[others: this was not in email of Oscar, but after
repeating the test the data was fetched in about
0.02 seconds for all sizes 20M, 210M and 2201M.
So, also the fetching in case of small dataset
becomes significantly faster form 0.5 vs. 0.02
seconds.]<br>
<br>
Would be good to see the actual query execution
plain or force the database to use the index (with
an hint). My hand-on practical Oracle syntax
knowledge is too low to give exact hits how to do
this, but perhaps others can help here.<br>
<br>
Kind regards, Peter.<br>
<br>
<br>
On 11-8-2015 16:26, Oscar Martinez Rubi wrote:<br>
</div>
<blockquote
cite="mid:55CA061C.5080603@esciencecenter.nl"
type="cite">Hi,<br>
<br>
I have investigated a bit more this issue.<br>
<br>
I wanted to see what data does the OCI reader
actually reads, so I executed the pre-selection
query out of PDAL, in python. So I run the
attached script (freshly after loading the data).<br>
<br>
The script runs the same exact query as done in
PDAL twice and prints for each run the number of
returned blocks, time spent in the query and time
spent to fetch the results.<br>
<br>
the exact query is:<br>
<br>
SELECT <br>
l."OBJ_ID", l."BLK_ID", l."BLK_EXTENT",
l."BLK_DOMAIN", l."PCBLK_MIN_RES",
l."PCBLK_MAX_RES", l."NUM_POINTS",
l."NUM_UNSORTED_POINTS", l."PT_SORT_DIM",
l."POINTS", b.pc<br>
FROM <br>
AHN_BLCK l, AHN_BASE b, QUERY_POLYGONS g<br>
WHERE<br>
l.obj_id = b.id<br>
AND<br>
SDO_FILTER(l.blk_extent,g.geom) = 'TRUE' AND
g.id = 1;<br>
<br>
The results I get are:<br>
<br>
20M run 1:
<br>
#blocks: 12<br>
query time[s]: 0.113833904266<br>
fetch time[s]: <b>0.571593046188</b><br>
20M run 2:
<br>
#blocks: 12<br>
query time[s]: 0.000102996826172<br>
fetch time[s]: <b>0.500910997391</b><br>
210M run 1: <br>
#blocks: 13<br>
query time[s]: 0.0586049556732<br>
fetch time[s]: <b>5.09832000732</b><br>
210M run 2: <br>
#blocks: 13<br>
query time[s]: 0.000245094299316<br>
fetch time[s]: <b>5.05038785934</b><br>
2201M run 1: <br>
#blocks: 13<br>
query time[s]: 0.070690870285<br>
fetch time[s]: <b>52.4960811138</b><br>
2201M run 2: <br>
#blocks: 13<br>
query time[s]: 0.000225067138672<br>
fetch time[s]: <b>53.1006689072</b><br>
<br>
So, even though the query times and the number of
returned blocks are similar the fetch times are
the not. We can see the scaling issue there.
Somehow the fetching is much more expensive (10x)
when points are 10x.<br>
<br>
I also noticed that after a while doing queries
the times get much better and scalable even when I
do new queries with other polygons. So, the first
queries suffer of scaling issues but later it gets
better. <br>
<br>
Any idea why?<br>
<br>
Regards,<br>
<br>
O.<br>
<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 10-08-15 18:40,
Albert Godfrind wrote:<br>
</div>
<blockquote
cite="mid:8CDC3A42-0C98-461B-9569-33CB19E7D94E@oracle.com"
type="cite">
<div class="">Like many tools that access an
Oracle database, we lack the ability to see
what actually happens in the database at a
detailed level, i.e. which actual queries are
sent, and how the database executes them in
terms of CPU use, logical and physical I/Os,
network throughput and latency.</div>
<div class=""><br class="">
</div>
<div class="">So I think it is important to add
some debugging / tracing facility to let me
see what happens:</div>
<div class=""><br class="">
</div>
<div class="">1) An option to make PDAL
(actually the OCI driver here) log each SQL
statement it executes, together with the
elapsed time and the number of rows (blocks)
fetched. Obviously we have that statement in
the input XML file, but a trace would put
everything in a single log and include proper
measurements.</div>
<div class=""><br class="">
</div>
<div class="">2) More important: an option to
make the OCI driver enable SQL tracing at the
database side. This is simple to do by just
issuing an “ALTER SESSION …” statement before
running the queries. The resulting trace will
show all details about execution times as well
as resource consumption (CPU and IO) and wait
times. That could be added as an option in the
XML file. Or maybe extend the XML file with
the option to specify a SQ statement to be
performed before each query (we could then use
that to manually add the ALTER SESSION
statement.</div>
<div class=""><br class="">
</div>
<div class="">The resulting trace can help
isolate the bottleneck as one of:</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">1) the I/Os in the database, to
fetch the blocks from disk (mostly I/O)</div>
<div class="">2) the network time to pass the
blocks to the PDAL client (network
throughput and latency)</div>
<div class="">3) the time to process the
blocks in the PDAL client (mostly CPU)</div>
<div class=""><br class="">
</div>
</div>
<div class="">Albert</div>
<div class=""><br class="">
</div>
<div>
<blockquote type="cite" class="">
<div class="">On 5-Aug-2015, at 12:26, Oscar
Martinez Rubi <<a
moz-do-not-send="true"
href="mailto:o.rubi@esciencecenter.nl"
class="">o.rubi@esciencecenter.nl</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">Hi,<br class="">
<br class="">
I did a test to see how good Oracle with
PDAL scale with bigger data sets. I had 3
datasets that are self-contained with 20M,
210M and 2201M points. I loaded them in
different Oracle DBs with PDAL and
laz-perf. And, for each of them I ran 7
queries (via a pdal pipeline that
preselects blocks, applies a crop and then
write to a LAS file)<br class="">
<br class="">
The results are in the attached file.<br
class="">
<br class="">
Regarding the loading, for the 20M I only
used one core (it is only one file) while
for the others I used 16 cores, i.e. 16
simult. PDAL instances loading data to
Oracle. I opened an issue in GitHub
because I noticed that in some of the runs
the size that I got was too large, and I
do not know what caused that. The attached
numbers are when everything seemed to work
and the sizes were as expected.<br
class="">
<br class="">
This message, though, is about the
queries. Each query is run twice in each
DB. As you can see in the results file,
for 10x more points in the data set the
queries are 10x slower, at least for the
first run (with the 2201M the second run
is much faster but this does not happen
with the 210M).<br class="">
<br class="">
Find also attached one of the XML that i
used for the queries (example is for
query1). Note that the geometry is
previously inserted in oracle so I can use
to pre-filter blocks with the query option
in oci reader<br class="">
<br class="">
First I though that maybe the query option
in the oci reader in the XML was ignored
and that all the blocks of the dataset
were being processed by PDAL (that would
explain 10x more points 10x slower
queries) but I ran a pdal pipeline for
query1 with verbose and I saw that the
crop filter "only" processed 120000 points
which makes sense taking into account that
region of query 1 only has 74818 points.
Or maybe the crop still process all the
blocks extents but only opens and
decompress the points of the overlapping
ones?<br class="">
<br class="">
Any idea what is happening?<br class="">
<br class="">
Regards,<br class="">
<br class="">
O.<br class="">
<span
id="cid:05400F1D-9668-4C4F-86E3-029C914D8D51@fr.oracle.com"><results.txt></span><span
id="cid:3D842102-C6B1-41B1-A545-02B8CFC1CF77@fr.oracle.com"><query1.xml></span></div>
</blockquote>
</div>
<br class="">
<div class="">
<div style="color: rgb(0, 0, 0); font-family:
Helvetica; font-style: normal; font-variant:
normal; font-weight: normal; letter-spacing:
normal; line-height: normal; orphans: 2;
text-align: -webkit-auto; text-indent: 0px;
text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px;
-webkit-text-stroke-width: 0px; word-wrap:
break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space;"
class="">
<div style="color: rgb(0, 0, 0);
font-family: Helvetica; font-style:
normal; font-variant: normal; font-weight:
normal; letter-spacing: normal;
line-height: normal; orphans: 2;
text-align: -webkit-auto; text-indent:
0px; text-transform: none; white-space:
normal; widows: 2; word-spacing: 0px;
-webkit-text-stroke-width: 0px; word-wrap:
break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space;"
class=""> <span class="Apple-style-span"
style="border-collapse: separate;
border-spacing: 0px;">
<div style="word-wrap: break-word;
-webkit-nbsp-mode: space;
-webkit-line-break:
after-white-space;" class=""> <span
class="Apple-style-span"
style="border-collapse: separate;
color: rgb(0, 0, 0); font-family:
Helvetica; font-style: normal;
font-variant: normal; font-weight:
normal; letter-spacing: normal;
line-height: normal; orphans: 2;
text-align: -webkit-auto;
text-indent: 0px; text-transform:
none; white-space: normal; widows:
2; word-spacing: 0px;
border-spacing: 0px;
-webkit-text-decorations-in-effect:
none; -webkit-text-stroke-width:
0px;">
<div style="color: rgb(0, 0, 0);
font-family: Helvetica;
font-style: normal; font-variant:
normal; font-weight: normal;
letter-spacing: normal;
line-height: normal; orphans: 2;
text-align: -webkit-auto;
text-indent: 0px; text-transform:
none; white-space: normal; widows:
2; word-spacing: 0px;
-webkit-text-stroke-width: 0px;
word-wrap: break-word;
-webkit-nbsp-mode: space;
-webkit-line-break:
after-white-space;" class=""> --<br
class="">
<a moz-do-not-send="true"
href="BLOCKEDoracle.comBLOCKED"
class=""><img
moz-do-not-send="true"
alt="ORACLE"
src="BLOCKEDoracle.com/dm/design/images/oracle_sig_logo.gifBLOCKED"
style="border-width: 0px;
border-style: solid; width:
114px; height: 26px;" class=""></a><br
class="">
<font class="" color="#666666"
face="Verdana,Arial,Helvetica,sans-serif"
size="2">Albert Godfrind |
Geospatial technologies | Tel:
+33 4 93 00 80 67</font><span
class="Apple-converted-space"> </span><font
class="" color="#666666"
face="Verdana,Arial,Helvetica,sans-serif"
size="2">| Mobile: +33 6 09 97
27 23</font><span
class="Apple-converted-space"> </span><font
class="" color="#666666"
face="Verdana,Arial,Helvetica,sans-serif"
size="2">| Skype:<span
class="Apple-converted-space"> </span><a
moz-do-not-send="true"
href="skype:albert-godfrind"
class="">albert-godfrind</a></font><br
class="">
<font class="" color="#666666"
face="Verdana,Arial,Helvetica,sans-serif"
size="2"><font class=""
color="#ff0000">Oracle</font><span
class="Apple-converted-space"> </span>Server
Technologies<br class="">
400 Av. Roumanille,</font><font
class="" color="#666666"
face="Verdana,Arial,
Helvetica,sans-serif" size="2"><span
class="Apple-converted-space"> </span></font><font
class="" color="#666666"
face="Verdana,Arial,Helvetica,sans-serif"
size="2">BP 309 </font><span
class="Apple-converted-space"> </span><font
class="" color="#666666"
face="Verdana,Arial,Helvetica,sans-serif"
size="2">|</font><span
class="Apple-converted-space"> </span><font
class="" color="#666666"
face="Verdana,Arial,Helvetica,sans-serif"
size="2">06906 Sophia Antipolis
cedex<span
class="Apple-converted-space"> </span></font><font
class="" color="#666666"
face="Verdana,Arial,Helvetica,sans-serif"
size="2">|<span
class="Apple-converted-space"> </span></font><font
class="" color="#666666"
face="Verdana,Arial,Helvetica,sans-serif"
size="2">France<br class="">
<a moz-do-not-send="true"
href="BLOCKEDapress.com/9781590598993BLOCKED"
class="">Everything you ever
wanted to know about Oracle
Spatial</a></font></div>
<span style="color: rgb(0, 0, 0);
font-family: Helvetica;
font-style: normal; font-variant:
normal; font-weight: normal;
letter-spacing: normal;
line-height: normal; orphans: 2;
text-align: -webkit-auto;
text-indent: 0px; text-transform:
none; white-space: normal; widows:
2; word-spacing: 0px;
-webkit-text-stroke-width: 0px;"><span
style="font-family: Helvetica;
font-style: normal;
font-variant: normal;
font-weight: normal;
letter-spacing: normal;
line-height: normal; orphans: 2;
text-align: -webkit-auto;
text-indent: 0px;
text-transform: none;
white-space: normal; widows: 2;
word-spacing: 0px;
-webkit-text-stroke-width: 0px;"><span
style="font-family: Helvetica;
font-style: normal;
font-variant: normal;
font-weight: normal;
letter-spacing: normal;
line-height: normal; orphans:
2; text-align: -webkit-auto;
text-indent: 0px;
text-transform: none;
white-space: normal; widows:
2; word-spacing: 0px;
-webkit-text-stroke-width:
0px;"><span><span><a
moz-do-not-send="true"
href="BLOCKEDlocationintelligence.net/dc/BLOCKED"
style="font-family:
Helvetica; font-style:
normal; font-variant:
normal; font-weight:
normal; letter-spacing:
normal; line-height:
normal; orphans: 2;
text-align:
-webkit-auto;
text-indent: 0px;
text-transform: none;
white-space: normal;
widows: 2; word-spacing:
0px;
-webkit-text-stroke-width:
0px;" class=""><br
class="Apple-interchange-newline"
style="color: rgb(71,
135, 255);
font-family:
Helvetica; font-style:
normal; font-variant:
normal; font-weight:
normal;
letter-spacing:
normal; line-height:
normal; orphans: 2;
text-align:
-webkit-auto;
text-indent: 0px;
text-transform: none;
white-space: normal;
widows: 2;
word-spacing: 0px;
-webkit-text-stroke-width:
0px; text-decoration:
underline;">
</a></span></span></span></span></span></span></div>
</span></div>
</div>
<br class="Apple-interchange-newline">
<br class="Apple-interchange-newline">
</div>
<br class="">
</blockquote>
<br>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Peter van Oosterom <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:P.J.M.vanOosterom@tudelft.nl">P.J.M.vanOosterom@tudelft.nl</a>
Section GIS technology (room 00-west-520) Department OTB
Faculty of Architecture and the Built Environment, TU Delft
tel (+31) 15 2786950 Julianalaan 134, 2628 BL Delft, NL
fax (+31) 15 2784422 P.O. Box 5043, 2600 GA Delft, NL
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="BLOCKEDgeomatics.tudelft.nlBLOCKED">BLOCKEDgeomatics.tudelft.nlBLOCKED</a> MSc Geomatics
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="BLOCKEDmsc-gima.nlBLOCKED">BLOCKEDmsc-gima.nlBLOCKED</a> MSc GIMA (Geo-Info Management&Appl)
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="BLOCKEDgdmc.nlBLOCKED">BLOCKEDgdmc.nlBLOCKED</a>
</pre>
</blockquote>
<br>
</div>
</div>
</blockquote>
</span> </blockquote>
<br>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Peter van Oosterom <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:P.J.M.vanOosterom@tudelft.nl">P.J.M.vanOosterom@tudelft.nl</a>
Section GIS technology Department OTB
Faculty of Architecture and the Built Environment, TU Delft
tel (+31) 15 2786950 Julianalaan 134, 2628 BL Delft, NL
fax (+31) 15 2784422 P.O. Box 5030, 2600 GA Delft, NL
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://geomatics.tudelft.nl">http://geomatics.tudelft.nl</a> MSc Geomatics
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.msc-gima.nl">http://www.msc-gima.nl</a> MSc GIMA (Geo-Info Management&Appl)
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.gdmc.nl">http://www.gdmc.nl</a>
</pre>
</blockquote>
<br>
</body>
</html>