Boat database

Hi,

I want to start building a database of powerboats including advanced marine craft (such as hydrofoils, SES etc).

I know that many designers have such a database and I was wondering if anybody has ideas or is willing to reveal their "lessons learned". Obviously, a database like this needs to be designed well before anything else.

My questions at this stage include:

• How to handle uncertainties, such as reported speeds, non-consistent dimensions (e.g. Lh vs LWL) etc
• How to handle missing information, guess, or leave blank. If guess, how to highlight that it is a guess for future reference?
• What format, Excel, CSV or something else?
• Should each craft type have their own database?
• I would like to add images of each craft but this complicates the database and adds size. Is a database without images completely useless?

Thanks in advance

 

Filemaker would be pretty great.

Each category of boat would have different data. For example, a catamaran has bridgedeck clearance. So, you would keep a data table for each subtype. But the same database can have multiple tables.

Not sure about what is already out there..

 

• How to handle uncertainties, such as reported speeds, non-consistent dimensions (e.g. Lh vs LWL) etc

There are 2 questions here. First, uncertainties. Data sources should be reduced to the most reliable ones. For instance, RORC certificates, World Sailing registrations, EC certificates for boats under 24m. These sources should also be consistent, ie for each database entry, share the same definition and way of measurement. Or at least, have some established practices, which could help defining coherent entries.
Second, non consistent dimensions. Why LH and LWL would be inconsistent ? Depending on what you want to analyse, both dimensions have their importance. For instance, LWL can be used in hydrodynamics comparison, while LH can be used for taxation comparison. One can also want to use the difference between LH and LWL. So keep every dimensions, every parameters, even if it creates voids inside the database.

• How to handle missing information, guess, or leave blank. If guess, how to highlight that it is a guess for future reference?

I wouldn't recommend any mix between guesses and reliable information. If you don't have any known value for a particular field, do not cheat. Leave it blank. Instead, the source of any data could be added in a separate field. That way, you should be able to do some proper statistics when needed, and evaluate uncertainties in trade-offs.

• What format, Excel, CSV or something else?

Should also be asked to a true data scientist, but the XML format is very handy. It combines different entries with different fields. Many pre built softwares or modules efficiently manage this file format. Using an algorithm, you can also export in HTML pages, if you want to publish this database from time to time. CSV is also widely used. Anyway, I wouldn't recommend any proprietary file format, like EXCEL.

• Should each craft type have their own database?

In the end, that's the conclusion i've made after some trials.

• I would like to add images of each craft but this complicates the database and adds size. Is a database without images completely useless?

Images should be put in the database with purpose. For instance, the silhouette of a boat could be handy to have, for an collision avoidance system. Top view images could be used to build a boat detection system using drone or satellite inputs. GA's could help visualizing available surfaces... Etc...
Anyway, images should be consistent with one another, just like any information. If not, it could be useless to put images in your database.

 

A picture is worth a thousand words. Pictures give information in an instant. They also provide a context for the rest of the data. For a database that will be the size of a public library, you need to have a search engine that is easy to use and makes the information accessible.

 

Thank you very much for all the replies. They are very valuable and helpful to me.

fallguy: makes perfect sense to have different databases for different boats.

Alan, regarding LH and LWL: I feel that these parameters are often presented in a non-systematic or non-standard way. E.g. the displacement related to the LWL given might be uncertain. LH is easier, but e.g. in case of RHIBs, it is not always clear whether the tubes are included or not. I like the idea of XML format, I will take a look at it. If the database becomes useful, I definitely want to be able to make it a web app.

Gonzo: I agree, images most likely will prove to be very useful especially to estimate whether some dimensions make sense and to find "similar" looking hulls (parameters alone are not always enough). But like Alan said, would be optimal to have them in a consistent format.

 

What kind of database software were you thinking about if any. You need something that can do more than just store data fields. It also needs to be able to store and display images, not only photo images but drawings from CAD programs . Part of my job with the Coast Guard was creating and maintaining databases of boat manufacturers, recalls and other relevant data. Probably the most powerful database management software is Oracle, but that's probably way out of your picture financially. Microsoft Access is a powerful and flexible database management software that comes with Microsoft Office. That's what we used and it handled everything well. There are other less expensive options . On the free side there is LibreOffice and it , like Microsoft Office, comes with a database manager. I have never tried the Libre Office database manager but the price is certainly right. What ever you chose has to able to handle a very large number of files unless you limit it to specific types of boats. It should also be able to load and display data from other database software such as Access, Excel, Dbase, SQL (Oracle) and others. If you take up this project you will find that other people have built databases of certain types of boats and they may be willing to give you the files.

 

@Ike
Thanks for your valuable thoughts!

The primary goal of the database is to understand trends and design ratios. I want to stick to high-speed craft at this point.

I started with MS Access as I am also familiar with it.
My idea is to start with separate tables for different:

• Hull types
• Propulsor types
• Engine types

and define relationships between these using primary keys.

I think Access is a good starting point as it is easy to scale and data can be exported easily to be analyzed in other software.

Regarding drawings. Access allows "attachment" and "hyperlink" datatypes. I am thinking of including pdf drawings using either datatype.

 

2 and3 are relatively easy. 1 is very subjective. For example, the term "trawler" is used to describe working fishing boats that drag nets, and yachts that have nothing in common with the previous.

 

Access is a good choice. It's flexible and fairly easy to use. And as you said the files are transportable.

 

Agreed, Ben Land, there are some uncertainties. Not only regarding the lenghts, but also regarding some other parameters that you may want to use. The displacement (Empty, Maximum, In between... depending on what definition you use), the speed (declared speed is very often a maximum speed, that you cannot reach fully loaded), the engine power (multiple options available). And so on, and so on...

To overcome this kind of issues, I prefer keeping a maximum of parameters. When I study a particular trend, I make sure I can distinguish between inconsistent and consistent datas. For instance, using a graphical representation, before filtering and drawing some tendencies. In the example down-below, the size of the markers is proportionnal to the maximum declared power. Diamond markers are for RIBS, and the color depends on the main material.

Among all, you can identify three boat models (yellow arrow and yellow box), whose declared powers are not consistent with the general trend. Indeed, after checking, they correspond to three motor multihulls, that have been put by error in this extraction.