Båtwiki
| Båtwiki | |
|---|---|
Wiki of the Month January 2014
| |
 | |
| Statistics (2013/12/30) | |
| Pages: | 348 |
| Users: | 33 (1 active) |
| Properties: | 44 |
| Categories: | 179 |
| Templates: | 304 |
| Forms: | 11 |
| Table of Contents | |
Båtwiki (pronounced "botwiki", with German o, translates to "boatwiki") is a Norwegian-language wiki site dedicated to practical boating information. It is partially a standard wiki, explaining boating terms, containing practical guides to yearly maintenance etc.; and partially a database of points of interest.
Scope[edit]
The primary purpose of Båtwiki is to provide Norwegian boaters travelling in Norway with practical boating information, in Norwegian. This scope is rather narrow, simply because we wanted to have realistic ambitions for the project. The scope may eventually be expanded to other countries/languages if someone would commit on helping the project.
Usage of SMW[edit]
The main contributor to the project was not aware of SMW when launching the project; it was primarly meant as a regular wiki without geographical information. Eventually some SMW enthusiasts wanted a POI database and gave the project momentum. (POI = Point of Interest, i.e. guest harbour or nature harbour).
Current usage of SMW[edit]
- POIs, obviously - we display map tiles mainly using OpenLayers (Google Maps is used in a few places). Two sources are use for map tiles; OpenStreetMap and the national Norwegian mapping state bureau - on top of that we add our POIs. The state bureau maps are used to display sea maps. Unfortunately they aren't free yet, there is a quite restrictive license and restrictions on how many tiles any given IP can download per day. There exists an OSM-based project called OpenSeaMaps, but as of 2013-04 it was considered not to be practically doable to use it with OpenLayers; probably because the backend server was too slow to serve the tiles. We could probably mirror the dataset and generate our own tiles, but for now we don't have the resources to do that.
- Translations - many articles contains an English translation of the page title, and it's possible to look up English phrases to find the Norwegian equivalent. There is also a dictionary available in table format, with categories and search feature.
- Company information
- Data about boat types (i.e. that the length of "Bavaria 36" is 36 feet). It's also possible for boat owners to make wiki pages about their own boat, by default inheritating the information from the boat type article, but if the boat has been modified one can override the attributes. (This is work in progress - only one boat type and one boat has been added so far).
- References - there is particularly one very popular Norwegian boating forum that is heavily referenced in the wiki and by using SMW forum participants should be able to look up where they are referred to. This is a work in progress; the framework is in place but there will be a lot of work converting all the old links and references
Planned usage of SMW[edit]
- A marketplace for used boats and used boating equipment.
- TODO-items within the wiki - we've imported many standard templates from Wikipedia, hence we have categories for "stubs", "citation needed", etc. It might be better to organize this meta-data through SMW instead of through usage of categories.
Challenges[edit]
Technical challenges[edit]
The project was started on Scientific Linux 6 (RHEL clone), running nginx, postgres and a bleeding-edge git version of MediaWiki. This just didn't work out; we spent quite much efforts before we landed on Ubuntu Precise, apache, mysql and MW 1.20.
Currently the map interface is quite suboptimal, it's missing interactivity. I.e., if the user searches for "guest harbours" near Oslo and navigates the map away from Oslo, the search results won't be updated, and no POIs will be shown. This is a bad user experience; it would be much better with an Ajax-style backgrounded search updating the map with POIs for the area shown. Maybe this will be possible in future versions of Semantic Maps?
We're currently missing a "mobile friendly" version of the site. We'd gain a lot more POI data if people could take some photographs, record the GPS location and post it with few clicks.
POI challenges[edit]
Think of a place with a guest harbour, a fuelling station right nearby, a food shop 200 metres away from the guest harbour and a restaurant 400 metres in the other direction. Our initial idea was to make each thing a POI of it's own, and have a service tag only on the strictly associated services. The guest harbour would have "fresh water", "electricity" and "toilet" as services, the grocery shop would apply a "grocery" service, and the restaurant a "dining"-service. The original idea was that even if the restaurant is directly on the quay, it should not be considered a service with the guest harbour if it's provided by a separate, independent company.
Now, a typical use-case scenario would be ... "we're sailing in this direction, we're low on diesel, and tonight we'd like to stay in a guest harbour where we can buy fresh groceries - but we're too lazy to cook dinner tonight, so we also need a restaurant. We're also too lazy to walk more than 1.4 km today". Such a query seems to be slightly non-trivial. So far we have no written guidelines on it, but I think we've accepted a more practical approach to the service concept - "groceries" should most likely be considered a "service" at the guest harbour if the grocery shop is within short walking distance. (Booleans would maybe work out even better then the services list ... and maybe not).
We also have a Boolean attribute "quay" on shops. The first hard-line idea was that only if the quay is directly associated with the shop and the walking distance less than 50 metres (with the justification that a regular car driver probably wouldn't accept walking more than 50 metres from the parking to the entrance of the grocery shop) should "quay" be switched to True - but eventually the more practical approach has won here as well; if there is a quay within reasonable walking distance, no matter ownership - and if it is acceptable to leave the boat at the quay and go visit the shop, then quay should be switched to True.
A guest harbour may have a harbour office where one can pay the harbour fee and ask questions - eventually just a "parking metre", it may have toilets, fuel pumps and so on ... and amazingly, finding those things may not always be easy. Even figuring out where, when and how to pay may be really tricky sometimes. We didn't want separate SMW entities (wiki-articles) on such minor things, so a macro was made for displaying a local map on an article. This local map can mix SMW search results with hard-coded local entities such as where to find the toilet, where to pay the harbour fee, etc. See Moss gjestehavn for example usage.
Community challenges[edit]
There are some very active boating forums in Norway, and some of the participants were enthusiastic towards the idea - but as of December 2013 there is only one active contributor. It's difficult to build a community; more research would be helpful on what is needed to attract and keep contributors and how to stop shedding contributors.
Regarding the forums, remarkably some of the participants are openly hostile to the idea; the wiki project may be "stealing activity" from the forum, there are also concerns about "stealing content" etc.
Semantic challenges[edit]
At first we started out with separate forms and infoboxes for grocery shops and fuelling stations. Particularly the latter was a problem because there aren't that many independent fuelling stations, it's quite often an integrated part of a marina, guest harbour and sometimes even a restaurant or a fish shop; creating a separate infobox in the same article as the marina was inelegant, doesn't work well with the semantic forms, and proved a no-go as we'd end up with one article with two coordinates. Currently we'll just add "petrol" or "diesel" as services to the marina - but it's still slightly inelegant as there may be other semantic information we'd like to apply on the fuel (i.e. pricing, opening hours, payment options, quality, etc).
To reduce the maintenance burden with too many infoboxes, the grocery shop and fuelling station forms and templates was deleted - one form/template to rule them all: "outlet". It could be an idea to apply some touches of javascript to the form, first asking the user about services offered, and then showing other relevant sections of the form (i.e. price of the diesel) dependent on what services is chosen.
Quite many dedicated shops facing boat customers in Norway are independent - so one shop, one company. Then there are the exceptions, i.e. nearly all grocery shops are members of some chain. The solution was to split "company" and "shop" into two distinct entities (templates, form). But for the simple one-company-one-shop it gets quite messy to have two separate info boxes, preferably spread over two different articles. Currently the solution seems to be three forms/templates - the third one for "company with exactly one shop". Then again, this introduces yet more maintenance, whenever some change is done to the shop form and template the same change needs to be done for the "company with exactly one shop"-form and template. We have a similar problem for the marinas owned by a boat owner association - current plan is to keep them as separate articles, but to use {{#show:...}} to display the information about the boat owner association on the marina page, and add other smart links to ease the creation and editing of the boat owner association article.
Another problem is that quite much of the data is very difficult to structure. I.e., how much does it cost to stay overnight in a guest harbour? We'd very much like to have it in a semantic format, but ... it often depends on the length of the boat, some harbours include electricity, others take paid and yet others doesn't offer it at all, yet others have off-season discounts ... and for many of the booleans neither "yes" nor "no" would be a correct answer ("yes, but ...").
Another problem with booleans - including a boolean in a form would usually generate a checkbox, clicking it sets the boolean to true, leaving it untouched sets the boolean to false. I'm also a bit confused as those values sometimes are translated and sometimes not. In many forms I would like the informant to be able to just click "save" without bothering to fill out the whole form, but then quite many booleans gets set to "No". I've solved both problems by explicitly setting input type=dropdown and values=ja,nei
Financing and licensing[edit]
This is a 100% volunteer project, and everything is licensed with CC-BY-SA 4.0. User "tobixen" provides domain registration fees, the SSL certificate price and much of the content and editorial work as well as system administration work. His employer provides bandwidth and hosting. This site will hopefully forever remain free and without ads. It's also on the to-do list to provide database dumps (minus the users table), to make it possible for independent persons to do disaster recovery.
