Dirk.Net

Go to Irrawaddy.org (published here in Chiang Mai) to learn in-depth about the appalling political and human-rights situation in Burma and the continuing struggle for freedom.

Vista-style cursors can be downloaded here (white pointer) and here (black pointer). Unzip anywhere on your hard drive, right-click the .inf files and select “Install…”. Then select the cursor at Start Button>Control Panel>Mouse>Pointers. One more reason NOT to upgrade to Vista. Still looking for a “red expanding circle at mouse-click location like in the Camtasia videos” which is (probably?!, I have no Mac) available for OS X but not for Windows. 

Visual Studio 2002 and 2003 created resx resource files for each and every ascx and aspx file. When upgrading to ASP.NET 2.0 these files are no longer needed as resource files are centrally stored in the resource folders and compiled.

So if after removing the resx files you get compilation errors such as the following

simply open the project file (.csproj or .vbproj) in Notepad and delete the entries that look like this:

<EmbeddedResource Include=”panorama\search.aspx.resx”>
     <DependentUpon>search.aspx.cs</DependentUpon>
   </EmbeddedResource>
   <EmbeddedResource Include=”panorama\tellafriend.aspx.resx”>
     <DependentUpon>tellafriend.aspx.cs</DependentUpon>
   </EmbeddedResource>
   <EmbeddedResource Include=”panorama\upload.aspx.resx”>
     <DependentUpon>upload.aspx.cs</DependentUpon>
   </EmbeddedResource>

 Then the project should build without problems. Hope it helps.

Introduction

Geotagging of photos and other data items today is a tedious and error-prone affair, not least because latitude and longitude have to be entered 100% correctly. One wrong digit and you may be many meters or many miles off. Certainly there are numerous tools to these task easier and new ones are released almost daily in this age of geotagging craze. Even with these products, having to deal with high precision numbers, positive and negative, matching time etc. can be quite daunting.

So as with domain names (which obviate remembering IP addresses), wouldn’t it be easier to describe the latitude and longitude numbers with a simple “babble language” consisting of “friendly names” for each location? Some alternative ways have been tried to do away with the numerical notation of location coordinates:

Grid Systems

There are numerous grid systems using letters as well as numbers with the best known example being the Universal Transverse Mercator (UTM). Grid systems are not directly supported by modern GPS devices which use the WGS84 datum. So for easy conversion the latitude and longitude should be kept the established decimal numeric form.

Numbers into words

It would be desirable to have a system that expresses numbers as pronounceable words, which could be understood in any language and in spoken conversation, such as over the telephone. 

Babble bubble

The bubble babble encoding uses alternating consonants and vowels, facilitating  public key validation in verbal form, like over the telephone, as the resulting string can be more easily pronounced and understood than hexadecimal sequences of letters and numbers. Btw., here’s a port of Bubble Babble to C#.

Koremutake

Another take on a related problem is Koremutake, which devises a system to express large integer numbers as a sequence of syllables (phonemes). It is a binary encoding with a base of 128, using 128 distinct syllables to encode integers. While this system works fine for integers, trying to expand this system to fractions one quickly runs into the well-known problems of converting decimal numbers into binary format. Displaying a simple decimal number like 0.1 “would need an infinitely recurring binary fraction”. So while the Koremutake-encoded integer 65535 is an easy-to-remember BOTRETRE, the floating point number 65535.1 would be encoded as BOTRETRE.FAFRAMOHESUDRA if Koremutake covered floating numbers, and precision would still be only adequate. Btw., here’s a port of Koremutake to C#.

Decimal Encoding

To ward off the rounding and approximation issues of floating point numbers, a modified system based on decimal numbers should be used. First of all, decimal numbers are what users are familiar with and more importantly, they are supported by most operating systems and programming languages today (C#, C++, Java, Visual Basic), and even ECMA-Script/JavaScript will support them in the near future.

Centimal system

A base-100 (centimal, centesimal?) system is a tall order if only ASCII vowels and consonants are to be used. Citing the ancient major system, one suggested centimal system uses both numbers and syllables made up of consonants and vowels to encode integers. Then again, the combination of numbers and letters are notoriously hard to remember, probably because they are stored and processed in different parts of the brain. Numbers mixed with letters also hamper the reading flow and introduce local translations (for the numbers) into the flow of (language-agnostic) syllables.

Expanding the vowels to 10

Living in Thailand, I’m used to using 18 consonants and 6 diphthongs, so I expanded the usual a, e, o, u with  “ai”, “an”, “ao”, “in”,  “oi”, “on” to make 10 vowels, sorted alphabetically this makes the sequence “a”, “ai”, “an”, “ao”, “e”, “in”, “o”, “oi”, “on”, “u”. The artificial Itkhuil language uses the “expand the vowel stock”-approach but that’s a different ball game entirely. ‘I’ and ‘y’ are not used as vowels (unlike Koremutake) since i is pronounced as ‘ee’ in many languages including German, Dutch and Italian.

Ten consonants

We now need only 10 consonants to form all our base-100 “digits”. For international compatibility ’c', ’j’ (pronounced like i in German, Dutch) and w (pronounced like v in German, not used in some romance languages) are excluded from the consonants and so is v. Furthermore, ’r' is left out because it is not distinguished from ’l’ in many spoken Asian languages. The result reminds one of Chinese, Vietnamese or Thai, due mainly to the expansion of vowels. But luckily, unlike the aforementioned languages, our system is not tonal ;).

So now we have a coherent and predictable 10 x 10 base-100 number system consisting of easy-to-read and-pronounce syllables. Two issues remain:

Negative numbers

What about negative numbers? One way to express them could be to use lower case for negative numbers and capitalize all letters for positive numbers. However, this is against the established customs for identifiers like web-URLs or e-mail addresses, where case does not matter. Consequently, many users will not distinguish much between lower and upper case.

The prefix letter A could be prepended to negative numbers as one of only two letters in the alphabet (the other being H) it has a “full-width” vertical line. This also fits well into the flow of the languages, with a leading A generally easy to pronounce for all the syllables we will use.

Fractions (Non-Integers)

The dot of fractional numbers (what’s the antonym of integer anyway?) should be replaced by a distinctive syllable. I was thinking of using “Poi” as a short for “Point”, but I want to use both P as a consonant and oi as a vowel in the number system. So I settled for “Ha”, which is also shorter. So 1.2 becomes BaiHaBan. The word “point” is too idiomatic for English, many European languages use “comma” instead of a point as the decimal separator.

Here are the 100 distinct syllables of the centimal system:

Application to Geocoding and geotagging

Latitude and longitude

Next step, how to apply this encoding or notation to geocoding and geotagging? Especially what to do with the (decimal) point?

How can these solutions facilitate geocoding and geotagging, which often involves verbalization or memorization of latitude and longitude information?

The classic notation of latitude and longitude is sexagesimal (example: 52

Transact-SQL doesn’t have arrays or nifty string functions like the C# System.String.Split () or java’s String.split() returning arrays in one swoop. Then again, SQL knows the SELECT … IN statement like

SELECT * FROM table1 WHERE id in (1,2,3,526) 

so why no looping through comma-delimited strings?

A “Table-valued User-defined Function” returning a table variable is a handy and versatile workaround letting you query and loop through the values with near array-like ease.

The code could look like this:

CREATE FUNCTION [dbo].[StringToTable]
(
@inputString nvarchar(max),
@separator char (1)
)
RETURNS @ResultTable TABLE ( [String] nvarchar(max) )
AS
BEGIN

    DECLARE @stringToInsert nvarchar (max) 

    WHILE LEN(@inputString) > 0
    BEGIN
        SET @StringToInsert      = LEFT(
                                @inputString,
                                ISNULL(NULLIF(CHARINDEX(@separator, @inputString) - 1, -1),
                                LEN(@inputString)
                                )
                                )
        SET @InputString = SUBSTRING(@InputString,

                                     ISNULL
                                     (NULLIF
                                     (CHARINDEX(@separator, @InputString),
                                     0),
                                     LEN(@InputString)) + 1,
                                     LEN(@InputString))

        INSERT INTO @ResultTable
        (
        [String]
        )
        VALUES
        (
        @StringToInsert
        )

        END

    RETURN
END

Again, the Transact-SQL string functions seem clumsy and inadequate compared with high-level languages. Short of using CLR functions in the database table-valued functions can put custom string operations at your immediate disposal.