Introduction
Long distance trails is a huge tourist attraction and can evolve into a sustainable longterm  billion dolor industry. With New Zealand having completed their long distance hike in 2011, and to put South Africa on the international map with their own trail(s) this project proposal in article format came into being.

Background
Long distance trails have cultural, historic, economic, outdoor and tourism value amongst others.While the time taken to establish may differ, the baseline principles remain the same throughout.

Participants in a trails’ creation, maintenance and protection may consist of universities, government departments, non profit organizations, volunteers, land owners, philanthropists and of course hikers.

Commonly after establishment of a trail conservation, maintenance and after market efforts continues.

Trail models
A quick look at the differences and similarities of two popular long distance trails.

The Appalachian trail (AT) is one of a few long distance trails (PCT, CDT, Long trail etc.) in the USA and runs mostly  through state owned forest, is permit free (free access), has shelters (lean-to), had initial government intervention via laws to support land acquisition. Has a conservation body and volunteers to do maintenance. Between 1 to 8 days can be spent in shelters between resupply (in town) where accommodation is available. Rich in nature scenery. 3500 kilometer in total length.

The Camino Frances is one of perhaps 25 possible Camino’s  in Spain and runs mostly on tar and gravel roads (state owned), is therefore inherently permit free (free access), has well structured accommodation. Every night can be spent in a bed (in town), and resupply therefore daily available. Has decentralized organizations and volunteers to do maintenance. Rich in historic scenery. 800 kilometer in length.

Other trails like Te Araroa in New Zealand mostly uses campsites between towns, while Sweden opted to have food available at huts to resupply with on the kings trail.

Architecture
In order to design a long distance trail network, mainly the following  is required, as listed and elaborated upon below:

• Decentralized development organizations and efforts.
• Existing trails
• Cultural historic landmarks and places.
• Accommodation.
• Resupply
• Accessibility.
• Maintenance
• Trail Markings
• Collaboration.
• Trail Data
• Hiking community
• Suggested trails

Decentralized development
Since the size and duration of establishing a long distance trail network my differ from section to section, previous development models (AT) caused the creation of trail organizations by province/area. This allows for local knowledge and maintenance needed for that section of the trail.

Existing trails
Linking together existing trails is a option, although the following need to be taken into account in doing so. Existing trails may have permit systems in place and moving towards a fee-free trail to be on par with international standards, may not be adopted by existing businesses.

Effort is required to change permit systems as a means of revenue towards resupply, gear  and accommodation revenues instead.

Cultural historic landmarks and places
A good mixture of landscape and historic landmarks is required.  A trade-off between accommodation,   accessibility , resupply and existing trails should also be considered as factors or constraints.

Accommodation
Mainly these categories exist for hikers to sleep in namely off trail accommodation (guest houses, motels, hotels, backpackers) and on trail accommodation (campsites(tent), shelters/huts, caves).

AT shelters are free , Swedish huts are payed for, while some New Zealand (Te Araroa) campsites may have unmanned  money drop boxes.

An important factor to consider is payed versus free accommodation, where payed accommodation may be  structured around donation or standard priced fees. To maximize throughput (turnover)  always allow for a free on trail alternative (or discourage it depending  on interpretation).

Resupply
The distances between shops dictates pack weight. Historically the trail economy adapts to the general hiker demand. It would not be uncommon to foresee something similar to trail towns, or even some small on trail shops run by locals.  The categories for resupply is food, water and gear. Water resupply will be the biggest driving force in trail planning.

As already mentioned the kings trail in Sweden resupply at huts.

Accessibility
Here the issue of land ownership, a conservancy and government intervention becomes important. Since land owners mentality can initially lean towards permit systems as a means of revenue generation, such permit system would basically be a tollgate (and against international trail models) on a otherwise permit-less trail.

It is however acceptable and understandable that free or self help permits enables usage statistics for a certain area.

This risk towards the continuation of the trail network has two counter measures. Land acquisition by an independent organization financed by philanthropy or donations and/or government buyouts and legislation (state owned)

Another factor that influence availability is cellphone reception and wifi hot spots.

Collaboration
Intersection trail development collaboration boils down to ensure that two separately developed trails from two adjoining states connect with each other at the province border line.

The body receiving funds and donations need to determine where funds should be allocated to country wide. Overhead collaboration is also required in the areas of maintenance, ICT, project management, Incident management, trail/mountain rescue, impact assessment and research.

Maintenance
Volunteers usually maintain a section of trail, due to landslides, erosion, land acquisition, impact assessment. Logbook rotation and archiving thereof is delegated to the local province organization for that section.

Marketing as a continuous campaign may also be regarded as maintenance, while university studies and research may lead to trail changes.

Trail Markings
While this item may fall under maintenance, the trail markers should be a strategic decision adopted country wide. The Camino’s in Spain  use yellow arrows and the AT in the USA white ‘blazers’. Where trails have seasonal ice, snow or mist reflective material is added to the markers.

Other than the trail markers, local organization insignia due to decentralized organizations is also used to indicate the organizations area of operation.

Normal road signs also exist as well as information boards in places.
Sometimes a ‘battle of the signs’ can be observed and may be due to economic motivation (where a neighboring town wants a slice of the hiker business and repaint the markers to point their way instead) or non standardized trail markings on a section if the trail.

These nonstandard trail markings may be due to non collaboration between different organizations, for example where  mountain bike trails share the same route as hikers but use their own markings, resulting in multiple (duplicate) markings that in turn can confuse or ‘litter’ the environment.

Trail Data
With a newly established trail, trail data is one of the last and very important deliverables. Due to maintenance efforts this data will change, ensuring continuous after market revenue.

This trail data becomes available on line or in printed formats such as guidebooks, data sheets, maps, trail profiles , cellphone software  and  GPS tracks.

While there is profit to be made from trail data, it is generally understood that making a working set of these freely available ensures high turnover in visitation numbers that in turn stimulate the trail economy and subsequently increase profits.

Hiking community
Lastly collaborative in nature and also signaling the maturity of the trail network project, one will find websites and on line communities being established, utilizing existing Internet technologies.

These may include technologies such as blogs, mailing lists, social networks, packing lists, gear reviews, resupply strategies, logistical planning etc.

Suggested trails
Any trail is subject to continuous change and any suggestion for a trail without supportive analysis of any or all the factors mentioned, remains a suggestion only. The following can however be considered for a network of trails.

• A continuation of the existing rim of Africa trail.
• A trail from Cape Town to Kosi bay along the beach.
• A wine route trail (for actual hiking and mind map exercises aimed towards the establishment of other trails).
• A trail that include options for sea, high mountains and karoo semi-desert.
• Trails that start and end at the furtherest ends of the countries borders (north, south, east and west).

Legal
While freedom may be associated with a long walk and while it is also understood that a long walk may result in physiological, psychological and philosophical changes, these changes may not necessarily manifest itself in every hiker hiking a section or entire length of  the proposed ‘long walk way’ or network of trails.

Conclusion
This article aimed at indicating factors to be considered in the architecture and develpment of a long distance trail or network of trails.  It is by no means complete and should only be used as a starting point for interested parties.

The next steps in furtherance of information already contained herein would be to establish an on line collaboration platform and market its existence with preferably the first  ‘long walk way conference’.

Links
ATC
Te Araroa
Camino Forum
Rim of africa
MCSA
White blazes
PCT
The kings trail

Table of Contents

1. Introduction

1.1 Project Overview

The aim of this project is to use mobile technology to connect people with services or products requirements, with the supplier, the instant that the requirement or supply becomes available.

1.2 Background

Information on the internet is structured into sectors of information for example job seekers and head hunters, sellers and buyers of goods and services. This generic index caters for all supply and demand of services or products.

The usage of this system caters for information found in jobmail, junkmail, lovemail, personnel agencies, price list, auctions, sales clearances, calendar events, and emergency services.

The difference between this system and other static subscription directory systems is its design to notify the users thereof, immediately when information becomes available.

Even though subscription is possible, and extending the system feasible, this document concentrates on quickly connecting people when mutual requirements exist.

The user either queries for or enters keywords, including a region, name regarding the product, service or event. Therefore clients and advertisers are notified of their mutual interest immediately. The information expires after a certain time period, and can be renewed.

The system can also be adapted to cater for SMS/MMS auctions.

1.3 Vision and Scope

1.3.1 Vision Statement

To connect persons using mobile technology, the moment when mutual requirements exist for such a connection.

1.3.2 Opportunity Statement

With the rising popularity of the Cell phone, customers expect to gather information, obtain service contacts, receive notifications, and advertise or sell products and services without necessarily making contact with the company or a middleman.

1.3.3 Scope

From an end-user perspective, the SMS Index Project consists of two functional elements: a Web site and a SMS automation system.

1.3.3.1 Web Site

A Web site is to be developed for the SMS Index. To increase customer base and provide additional functionality for their existing customers, SMS Index website should include the following features:

• The customer will be able to browse current services and contact representatives, obtain detail on how to use specific services and how to pay.

• View real-time statistics of content in the system, broken down into region, category and keywords used, for the purpose of marketing.

• The user should not be able to search the database from the internet, because revenue is generated with reverse billing the system should only be accessible via SMS.

1.3.3.2 SMS Automation

A SMS Automation system will be developed for The SMS Index that will consist of an application to be used for report generation, credit accounting and SMS automation logic.

The application will include the following features:

• Cell phone notification (Account balance) to users and subscribers of the different solutions.
• Users receive/send content via Cell phones, based on criteria.

• Usage reports for Marketing and accounting.

• Connectivity with bulk SMS suppliers and content providers.

1.3.4 Out of Scope

The following functions are considered out of scope for Version 1 of the SMS Index. Versions 2.0 and 3.0 will address items not in scope, and those deemed not feasible during V1.0.

1.4 Critical Success Factors

Some factors identified is:

• Lack of content for keyword searched i.e. no content matched search criteria.
• The validity of queries against data and the validity of the data itself should be decreased over time. During the launch of the application data and queries against data should be kept on the system for longer to increase the chances of a notification. Thereafter the valid time for adverts and queries can be deceased.

1.5 Risk Assessment

Minimal risk exist to the system, given that the following is prevented

• Sql injection by cell phone.
• Attempts to upload data to the SMS gateway without using a cell phone.
• Database growth bigger than hard disk space.

3. Design Goals and Constraints

3.1 Performance

The system should be able to process 100 messages a second.

3.2 Availability

Because the Web site is accessed by customers across the world, it needs to be available 24 hours a day, 7 days a week.

3.3 Reliability

Because of the need for 24*7 availability, automatic failover will be required. In addition, existing disaster recovery and backup plans and procedures must be revised to incorporate the SMS Index Application.

3.4 Scalability

SMS Index anticipates an average load of 500 concurrent users after the system is fully operational, and expects that to grow by 5 percent each year for the next five years.

3.5 Security

The reception of SMS messages from the Gateway has to be secure, to ensure that messages can only be received from the gateway and not from any other source.

The message content should not allow content that will allow a hacker to compromise the system, its content or stability.

3.6 Interoperability

The website will periodically query the database for statistics over HTTP.

3.7 Location

There is no location specific requirements.

3.8 Internationalization

The application needs to support international currencies, character sets, and date/time formats.

3.9 Setup/Installation

System should be installable from disconnected media.

4. Features/Functionality

The following list requirements of the system

• System can receive SMS from Gateway over http, ftp, smpp
• System can send SMS to Gateway over http, ftp, smpp
• System can add information to system
• System can query information in system
• System can notify user when item matching search term is added
• Notify user when item is about expire and can be renewed
• User can top up credits with reverse billing
• Web user can view real time statistics of the content of the database by region , category or keyword, as well as usage statistics of the system.
• Warn administrator about critical factors of the system
• collect statistical data for report and analysis
• prevent unpaid content at ftp, http, smpp level
• end-user website tutorial on how to use the system
• information item expire after certain period
• information item must have a region in the message
• website must be search engine optimized
• website displays terms and condition indemnification

The following sections summarize features and functionality; use cases are available on request.

4.1 Add information item

4.1.1 Description

This function will enable consumer to place information into the SMS Index.

4.1.2 Business Need

This function will enable consumers place information in the SMS Index catalog directly from their mobile phone without the intervention of an SMS Index employee.

The SMS is reverse billed and expires after 24 hours. An SMS is sent back to the consumer to state that the information has been added. A reference number is returned in the message for renewal purposes. A SMS message is sent to the consumer 1 hour before the information item expires, to enable the consumer to renew the information.

4.1.3 Priority

High

4.2 Query information

4.2.1 Description

This function will enable consumer to search information in the SMS Index.

4.2.2 Business Need

This function will enable consumers to search for keywords in information items. Items that match are returned to the consumer as reference number name, cell number and URL. If items are more than one SMS size the consumer is notified thereof in the same SMS. The count of items that match is returned to the consumer in the same SMS. The consumer can request the next set of results by sending the same query again.

When there is no results the message becomes a query hit notification, and a SMS message stating this is returned to the consumer.

4.2.3 Priority

High

4.3 Query hit notification

4.3.1 Description

This function enables the consumer to be notified when information is added to the system that matches their search criteria.

4.3.2 Business Need

This happens either when there is no existing information for the query or when there already is, but the user wants immediate notification due to the type of information that is required.

Every information item that is added to the system is evaluated against all notifications pending, after the information entry is added in the database. Evaluation is based on keyword full text search.

The notification is valid for 24 hours where after the consumer is sent a reminder of renewal.

If no renewal message is received the notification is removed from the database.

4.3.3 Priority

High

4.4 Renew information

4.4.1 Description

This function allows the consumer to renew the valid time of the information item. Items are available for searching for 24 hours, and can be renewed.

4.4.2 Business Need

The consumer sends a reverse billed SMS message with the reference number and renewal keyword to the system. This can be done repeatedly, and the validity time of the information increased with each SMS message received by the system.

4.4.3 Priority

Medium

4.5 Credit top up

4.5.1 Description

This function allows the consumer to buy SMS credits for usage by the system. It will be a reverse billed short code with keyword. And will be used for all services that the system offers to the consumer.

4.5.2 Business Need

Where it is not feasible to bill per SMS or when the system sends more than one SMS back to the consumer or other consumers, credits are used.

4.5.3 Priority

Medium

4.6 Web View Statistical System information

4.6.1 Description

This function allows the consumer and management to see the state of the system

4.6.2 Business Need

As a marketing means and attracting attention to the system, prospective consumers can view numerical information of the system. The statistics should include.

• the total number of queries received
• total number of items received
• total number of query hits found
• number of current items
• number of current hit notification
• number of active items in the database
• number of active query notifications in the database
• summary count of items by keyword
• summary count of items by region

The system should be able to show virtual simulation statistics when there is no activity in the system.

4.6.3 Priority

Medium

4.7 Critical warnings

4.7.1 Description

This function allows the management to be warned of critical factors in the system.

4.7.2 Business Need

Immediate action should be taken when critical system state is observed. States that will need notification is .

Connectivity loss with SMS Gateways

Out of disk space

System logic failure

Unpaid arrival of messages

4.7.3 Priority

High

4.8 Send Message to Gateway

4.8.1 Description

This function allows the system to send messages to the SMS Gateway that the system is connected to.

4.8.2 Business Need

The system should manage connectivity loss, and should retry sending SMS after connectivity has been restored. The system state should not be lost if connectivity is broken for maintenance or upgrade purposes.

The system should have a function to pause and resume the sending of SMS to enable offline maintenance, or database maintenance.

Messages should only be sent within South Africa.

4.8.3 Priority

High

4.9 Receive Message from Internet

4.9.1 Description

This function allows the system to receive messages from the internet that has been sent by the consumer.

4.9.2 Business Need

The system should ensure that messages originate from the correct source, to prevent the reception of unpaid messages. Messages should either be passed via HTTP or FTP.

After the message has been received, processing based on its content should automatically follow, based on the commands contained inside the message.

4.9.3 Priority

High

4.9 Credit Management

4.9.1 Description

This function allows the system to increase, decrease and query the credit state of a consumer.

4.9.2 Business Need

The system should ensure that credits are increased and decreased when top ups is received and messages sent. Sending delays and sending failure due to connectivity should manage the credit count accordingly.

The credit system should also decrease credits from certain sources as the message is received.

The system should be able to enable or disable credit functionality for certain commands received by the system, since not all services that rely on incoming messages will utilize the credit system.

4.9.3 Priority

High

4.10 Usage reports

4.10.1 Description

This function allows management to view the overall usage of the system.

4.10.2 Business Need

The system should ensure that aggregate credit reports are available for accounting and marketing purposes. Usage reports by consumer and keywords for marketing purposes should also be possible.

The data for the reports should be in a separate database than the information items, to prevent performance of the production database.

Standard reports should be viewable on a secure webpage. Data should be exportable to a flat file and downloadable via FTP for future analysis. All reports should be encrypted with RSA 2048 bit encryption.

4.10.3 Priority

High

4.11 Website

4.11.1 Description

This function allows consumers to view information about the system.

4.11.2 Business Need

The website should provide static information about the capabilities and services of the system, and how to use the system. As well as usage statistics updated every minute.

Cell phone number contact details of management should be viewable on the site.

Only web colors should be used on the site.

The website should state areas where emergency services has added notifications events for consumers that adds for instance fire, rape, burglary or other schedule one crimes.

4.11.3 Priority

High

4.12 Maintenance

4.12.1 Description

This function allows administration personnel to make changes to the system.

4.12.2 Business Need

The system should not experience a loss of data ie. Database data, SMS messages or credit state when taken of line for maintenance, or when connectivity to the internet or the database is interrupted.

The system should be able to reload state and continue processing, after a power failure.

The system should function properly after a long shutdown , and not malfunction due to date time differences.

4.12.3 Priority

High

4.13 Logs

4.13.1 Description

This function allows administration personnel to debug events and resolve consumer queries.

4.13.2 Business Need

The system should log each message received and sent. And each database insert and delete and update.

4.13.3 Priority

High

4.14 Usage Scenarios

Usage scenarios that describe how users will use the solution within the context of the business are documented individually. For more information about usage scenarios, please contact Bits4Bytes:

5. Solution Architecture

5.1 Infrastructure

LAMP production Web space will be leased and bandwidth as well as additional database space bought. A separate sub web with database will be used for reporting. and accounting.

A separate web space will be used for the website with information about the system.

The Linux software package ‘kannel’ may be used if the leased web space allows for its installation and configuration.

5.2 Visual Design

For a Microsoft PowerPoint presentation outlining the website user interface, see SMS Index – Website User Interface.ppt.