Custom Engine

I will be rolling my own custom engine.

Needs
* Search, routing
* Free-form navigation
* 3D audio output
* 2D mapping output
* GPS recognition

Implementation
* Java
* CityGML4J
* Android Platform
* Possibly C++
* MongoDB

Challenges
* Good 3D audio with effects (requires C++)
* Fast routing
* Variety of searches and ways to handle data
* Reasonably handling huge GML files
* Splitting up landscape
* Interface: supplying info to user (semantic and physical) purely through audio.
* Interface: Touch-screen that is blind friendly
* (These interface problems are partly addressed by my prototype)

User Study Continued

Optimal User Study
* Large volume of visually impaired persons
* App automatically converts model based on real-world version
* One group uses app to practice new space; control group does not
* Both groups navigate new space: Previously explained & surprise routes
* Study intends to show that automated conversion produces a map which does assist in real-world navigation.

Compromises:
* Sighted individuals
* Questionaire instead of real-world navigation
* Model is based on hypothetical building

User Study: Permission to use Human Subjects

Instructions are here:

https://www.wm.edu/offices/sponsoredprograms/preaward/policies/compliancereqs/humansubjects/instructions/index.php
"
A properly completed protocol will include a brief rationale for the study, full procedures,  description of the participants,  copy of all tests, questionnaires, all interview questions, the informed consent form, and other pertinent information.
Please allow sufficient time (3-4 weeks) for review
"

How does CityGML handle it?

(see posted CityGML tutorial). 

* Stores geometric and semantic info.

* xml-based

 * Geometric "bounding boxes"

 * Has a tree structure 

    But we are concerned not only with membership (a window is a member of a wall, a pc terminal is a member of a room) but also with proximity! We might have a closer, more desirable match in a different room, within a different sub-tree.

Model Obligations

Model Obligations / Functions

* user can "bookmark" spaces; important spaces are labelled--two-way searches (by location, by place-name) (e.g. "nearest rooms" or "(nearest) bathroom."

* simple, step-by-step traversal (user navigation; primary function) "Common case" (make common case fast)

* Model needs to understand function of elevators, stairs and doors.

Is speed important?

Not right now, but:

* Large scale representations--campus, town or even huge building -size -- could cause problems. We can't have n^2 or n^3 searches. Searches for unhashed/untabled spaces could be disastrous. So hash everything? could look up all "classrooms" in a table, find the nearest one.

* Also, CityGML files can get really big – there’s a lot of info here.

* Need reasonable "nearest" searches. Distance may be so great that non-verbal aural feedback is useless; we still want to provide information like "the closest comuter terminal is one floor up, 100 yards south"

* Routing -- we will often want to be able to quickly provide a route for these places. Long-distance routing, too.

Free v. Gridded Movement

    The prototype, which is essentially a 2D floorplan (although it does use standard heights to generate trully 3D sound), operates as a grid. The floorplan is split up into step-size squares that form a grid. Is this appropriate for a final product—could we have step-size “cubes”? Should we have finer detail? This also connects to the question of how the user should move through the space. There are pros and cons to both free-movement and gridded movement.

Free Movement

• Pro: More like real life. More fluid. More user freedom.
• Con:  More difficult to represent & implement programmatically. More difficult for user to track routing & orientation. Lose some “step-counting” functionality. Steeper learning curve for user.

3D Space

How to represent 3D space?

What data structure(s) ?

Need both metadata (semantic info) & 3D geometry (this is why CityGML is a good fit).

 (Why do we need 3D space?)

* need to provide spatial information via audio cues (how big a space is, reflected sounds, echos) -- requires coarse but variable height

* need to represent multiple stories/floors -- doesn't require variable height; floors could be separate entities.

    For the coming user study, we don't need "true 3D," because we may not emulate advanced aural feedback--it is likely that our study will be with sighted persons, who probably can't take advantage of this. We will use OpenAL to generate basic 3D sound, neglecting echos, etc. This is to save time.

However, we have to parse the CityGML anyway, and we might as well store all the information; if we don't use it now, we'll want it later.

    So how do we concisely and simply represent our 3D space? Most relevant studies are concerned with 2D floorplans.