CGA Lab: Computational Geometry and Applications

Algorithms and Data Structures with a Geometric Flavor

The Computational Geometry and Applications Lab at the Department of Computer Science (FB Informatik) of the University of Salzburg is directed by Martin Held. This page contains links to surveys (and color images) of some of the research topics that my students and I had or have been working on during the last few years. Mostly, only application-oriented work with a geometric flavor is included. The reader is referred to my papers for work on algorithms and data structures that is focussed more on theory than on application.

Please be warned that this page (and most of the pages referenced from it) are permanently under construction, and that the presentation of my application-oriented research work is far from being complete! However, I try to enable only those links that do work; please let me know if you happen to encounter a link that does not work. Thanks!

Please respect the fact that I maintain the copyright for all material made available on my WWW pages. By downloading any material provided on my WWW pages you do accept my legal guidelines!

A good deal of the work done till about 2000 was carried out in close cooperation with the Computational Geometry Lab of the State University of New York at Stony Brook, and received funding by both NSF and industry. In recent years, research funding for the CGA Lab has been provided by the Austrian Science Foundation FWF and the Austrian Research Promotion Agency FFG, and by grants received from various companies and industrial partners located all around the world.

I am always open for suggestions for a collaboration with industry, and you are welcome to contact me if you'd be interested in handing me an R&D problem. Ever since I started with academic work I have had a keen interest in industrial applications. Real-world applications provide tons of challenging problems, and I find it more satisfying to extract concise problem formulations from practical applications than to study abstract problems and later on try to come up with a practical application.

However, as companies tend to complain about their interactions with academia, academia tends to complain about its experiences with companies. I am used to industrial inquiries, and I have also had my fair share of "surprises". The subsequent statements may seem obvious but I rather risk to state something obvious than to run into yet another case of wrong assumptions on either end.

First of all, I do not run a software company! I am a university faculty who enjoys working with industry, willing to motivate our best students to take on industrial R&D problems. But I do not have the infrastructure of a commercial company, and I am not interested in acting like a commercial company. This means that I cannot and will not offer formal or legally binding "guarantees", no matter whether future maintenance of some code is concerned, or whether deliverables are to be produced within a project. Existing code is always supplied "as is" (even if the company acquires a license), and agreements for a new collaboration will never include legally binding statements on the functionality or fitness of a code to be developed. Also, the fact that I am affiliated with a university rather than a software company means that every project has to contain some sort of genuine "R&D work" rather than only mere programming tasks. In any case, R&D tasks will take some time, and will need a bit of ahead planning. (I do not have the means to double or triple my work-force within a few weeks' notice if a problem assigned to me turns out to be much more urgent for the company than originally thought.)

Second, and equally important, although I do not run a commercial enterprise, my and my student's work does not come for free. That is, I refuse to let a student work for free on an algorithm or code that is to be transferred to a company for the company's commercial use. (Besides allowing me to pay a fair salary to the students involved in a project, a financial compensation for a collaboration supports travel costs for attending conferences (for me and the students) and allows the purchase or renewal of equipment in addition to what I could hope to get from the University.) Still, companies quickly realize that the costs associated with such a collaboration tend to be orders of magnitude lower than what an in-house development would cost.

Finally, during a collaboration I expect to have somebody to talk to at the company's side. I appreciate the fact that part of the success of an innovative company is based on the company's know-how. I understand that companies value their business plans and little secrets, and I do never disclose sensitive information acquired during a collaboration without explicit permission. Unless specifically authorized, I do not even disclose the company's name or topic of a collaboration to anybody, except for what I have to disclose to my superiors. However, any fruitful collaboration requires the sharing of information and, possibly, data or code. It is painful to try to cooperate with a company if nobody at the company is authorized or willing to reveal details of what the new algorithm or code to be developed is supposed to accomplish. Needless to say, we use standard security measures on our computer system and, if preferred by the company, I am willing to sign an appropriate NDA. (Granted, a university lab is not a top-security place or organization.)

file last modified: Thursday, 26-Sep-2024 08:18:30 CEST