Administrative Stuff

ECE 297

Administration

• Milestone 0: – Submit by Friday at 5 pm– Demo in lab this week– Write your name on the board when ready to

be marked first on board, first to be marked

Administration

• Milestone 1:– Plan to release today (course website)– Submit by Monday, Feb. 2 @ 5 pm– 9% of final mark

• 6% auto-graded– 4% functionality– 2% runtime (pass / fail speed tests)

• 3% by TA– Coding style, SVN use and log messages, created unit

tests, can answer questions about code– TA will ask questions the week of the submission (Feb.

2)

Administration

• Tutorial: more advanced STL containers– <list> (linked list)– <map> (binary tree)– iterators let you walk through these data

structures

• All tutorial rooms / times will happen– Friday 9 – 11: both GB 412 & SF 2202

• Team selection– Select by Friday night– Head TA will be setting up wiki pages &

shared directories over weekend

OpenStreetMap and Graphs

ECE 297

OpenStreetMap

• Open geographic database of the world– Created by regular people contributing data

OSM Data

• (lattitude,longitude) points (OSM nodes)– Each also has a unique integer id

• Lists of points (OSM ways) that form – A piece of a road– A shoreline– A park boundary– etc.

• Optional tags on these points and ways– key,value pairs– e.g. name = Yonge– e.g. natural = water

• Documented at http://wiki.openstreetmap.org/wiki/Main_Page

Big Data!

• Can download all the data for the planet, in xml format– planet.osm: 498 GB file!

• Hard to work with!• Have extracted & downloaded 3 cities

– Toronto.osm (383 MB)– Hamilton– Cairo

OSM Trade-offs

• Positive– Powerful: lots of data, few restrictions– XML is text human readable

• Negative– Data is low-level can be hard to interpret– Data can be somewhat inconsistent (e.g. few

absolute rules on names entered by volunteers)

– Big (383 MB for Toronto)– Slow to load (45 seconds for Toronto)

Solution: Parse, Reduce, Refine

• osm2bin program– Written by course TA (Jeff Cassidy)– Reads in raw OSM data– Applies consistency checks– Organizes data– Writes out only essential data in exact binary

form needed to load our (libstreetsdatabase) classes

• toronto.bin: 38 MB

– Can load this data back in very fast (1 s) to initialize the same classes

• This is called class serialization• We use a library called boost serialization

API layers in milestone 1

.osmOSM2BIN toronto.osm

This is the api you will build higher level, more full featured

You will talk to this api need to understand it

You are given this header need to write the implementation (.cpp files) for all the functions in it

Organizing the Map Data

The lower-level API you’ll talk to

What Will We Do with the Data?

• Milestone 1: Use The provided API (StreetsDatabaseAPI.h) to implement various functions. E.g. vector<string> find_intersection_street_names (

string intersection_name);

• Milestone 2: Graphics – use the provided API and m1 functions to visualize the map.

• Milestone 3: Pathfinding – find paths through the map between 2 intersections

• Milestone 4: Courier company (Traveling Salesman) – find a path through n points on the map.

How would you represent a street map?

• As a graph!– G = (V, E)– Vertices (V)?– Edges (E)?

Intersections

Street Segments (City blocks)

Map as a Graph

libstreetsdatabase

• How to identify each vertex? – unique integer id small, fast

• 0 to getNumberOfIntersections() - 1;• ~166,000 for Toronto

– unique string name convenient for end user

0

1

2

3

4

Bloor & Yonge

Bay & College

Bloor & Bay

College & Spadina

DVP & unknown(20)

libstreetsdatabase

• How to identify each edge (StreetSegment)? – unique integer id small, fast

• 0 to getNumberOfStreetSegments() - 1;• ~215,000 for Toronto

– no unique string name

0

1

2

3

4

Bloor & Yonge

Bay & College

Bloor & Bay

College & Spadina

DVP & unknown(20)

01

2 3

4

5