For some time now, my PCDB Waypoints app has been failing to retrieve map tiles from the default OpenStreetMap server MapNik.  It looked at first as though the problem was with the app, but after lots of investigation it became apparent that the issue was rather more deepseated.  Deep down in the OpenStreetMap website is a statement that OpenSteetMap.org can block apps that appear to be making excessive demands on their servers.  Thinking that PCDB Waypoints may have been blocked in this way, I looked for alternatives and found one in MapQuest.  Tiles from that website displayed OK, so obviously the app software wasn't at fault.  However, although MapQuest says that is uses tiles from OpenStreetMap, this isn't actually the case and some of the finer details from OpenStreetMap (such as lighthouses!) was missing.

Further investigation in OSMDroid itself turned up the news that it wasn't PCDB Waypoints that had been blocked by OpenStreetMap.org, but a widget called the Apache HTTP Client.  This is used by default in all OSMDroid apps, and it was the cumulative effect of all OSMDroid instances that was overloading OpenStreetMap and which had been blocked.

Even further investigation disclosed that this issue had recently been addressed by OSMDroid, and a fix (Patch 515) was available. The effect of this was to put a string such as "osmdroid(PCDB Waypoints)" in each HTTP call, so that OpenStreetMap could differentiate between all the various OSMDroid apps out there in the market, and only block those that were truly at fault.

However, this fix wasn't available in the latest OSMDroid download (Version 4.0), and I could only apply it if I could get hold of the source code and incorporate this into the app.  There's nothing wrong with this; it's an integral part of the OSM philosophy that developers should be able to do this, and it's perfectly easy to download a .jar file containing all the source code of Version 4.0.  It's something I've been planning to do for some time, but to date I've always been able to make changes by including individual top-level code and adapting it as appropriate.  The code affected by Patch 515 is deep down in the workings of OSMDroid, and I couldn't apply the patch without downloading the whole caboodle.

Downloading it was one thing.  Incorporating it into PCDB Waypoints was another, and took a large part of today.  But eventually I managed it, compiled the app, installed it on my tablet and checked that I could use the MapQuest tile server OK.

Once that was achieved, I could then apply Patch 515, compile it, install it, and Hey Presto! MapNik tiles started to display again.

A very satisfactory outcome.

As I indicated above, I've been incorporating modified versions of some OSMDroid code into my app for some time.  Now that I've got the whole development working, I can start making these available to other users if they're interested.  For example, there's a version of IconOverlay that has a "MinZoomLevel" parameter, so the Icon isn't displayed at low zoom levels.  And a version of ItemizedIconOverlay that exploits this feature.  There are similar extensions to PathOverlay, a Lat/Lon grid overlay, and others.

When I first developed the Android version of SuDokuSolver, it was derived from a Windows-based, mouse driven version which had been running for some years.  The first thing I noticed when I started to use the Android version "for real" was that the screen was the wrong way round.  As it was touch-based, touching the buttons on the left hand side with my right hand obscured the working areas in the centre and right, and that what I needed to do was reverse the order of these three principal screen areas.

However, instead of doing just that, I reasoned that I already had a version that was suited to left-handed people, and it seemed a shame to throw that away.  So I introduced some alternative screen layouts for right-handed users, and a menu-driven facility to switch from one to the other.

I recently managed to break my right wrist and elbow rather badly, and for the last few weeks I've been in plaster from the hand to above the elbow.  I've used the enforced idle time that this has generated (I should have been sailing for six weeks by now) to work my way through the pile of Sudoku and Killer Sudoku puzzles I had waiting to be processed by Sudoku Solver.  Using the Left-handed facility, of course!  It's worked a treat.  I've also taken the opportunity to make some changes to the layout XML files to bring them more in line with the latest Android standards.  I'll make a new release of both Sudoku Solver and SuDoku Lite when the plaster is off my elbow and I can type normally again; at present I'm restricted to using just one finger on my right hand.

However, though the left-handed facility worked just fine, I did notice one issue: my ComboBox widget had the drop-down button on the right-hand, so the text in the ComboBox was obscured by my left hand when using that button.  So after digging around in StackOverflow and other useful Android support sites, I've found a way to implement a layout parameter that enables me to specify whether the dropdown button should go on the left or the right.  This is now working, and by introducing left-hand variants of the Select Game and Save Game functions I can use this left-handed ComboBox in those variants. This will be in the next releases of SuDoku Solver and SuDoku Lite.  I'll share that ComboBox code via this website, again when my elbow is better.

It's been rather too long since I updated this blog, and lots has been going on.  This almost entirely affects PCDB Waypoints, but it is worth pointing out that one person has now purchased the full version of PCDB SuDoku Solver.   Unfortunately the aussie involved then found a bug in it and uninstalled it.  I'm looking into the bug,

Now to PCDB Waypoints.  It's looking very much like an Android-based chart plotter now, and there may be more of a market for that.  It has map-based facilities to define Marks, Waypoints and Places, and set up the links between them in the form of Routes and Voyages.  It can track the progress of  boat, and replay the track later on if needed.

Part of the reason for the hiaitus in updating the blog is that we've been on a cruise to Madeira, the Canary Isles, Morocco and Lisbon, to get some winter sun and warmth.  I used my tablet to track the progress of the ship whenever I could get up on deck and get a GPS signal. While on the last leg from Lisbon to Southampton, we hit a Violent Storm (F11 gusting F12) which caused some considerable discomfort and a lot of damage to fittings on the boat.  PCDB Waypoints made it clear that the captain had decided to detour into Vigo, in north west Spain, an hour or two before he announced that over the boat's tannoy.

The next major trail of PCDB Waypoints will come in April, when Caledonia is moved from Holyhead, her mooring for the last six years, to Troon Marina in the Firth of Clyde.  Western Scotland is a great sailing area, and the effect of this move is that we'll no longer have to trek up and down the Irish Sea to get to that area.  Much more enjoyable sailing for everyone apart ftom the April delivery crew.

The biggest struggle I've had with mapping in PCDB Waypoints is in drawing the grid lines.  The literature here is very skimpy, and in particular it's not easy to work out what pixel co-ordinates to use to draw something on the portion of the map that is currently on display.  But with the help of a few useful posts on Stack Overflow, I've managed to put together a class called  GridOverlay which extends Overlay and works with maps supported by OSMDroid.  OSMDroid is an alternative to the mapping facilities provided by Google Maps, which are limited to use with only maps provided by Google.  (Goodness knows what Google hope to achieve by that limitation.)  OSMDroid facilities aOverlays are usually used to draw markers of various sorts on the Map.  GridOverlay doesn't store any markers, or Points (as PathOverlay does), and doesn't have any onTap methods.  Instead, it contains a few getters and setters, and a draw() method which does all the work.

You can find the java code of GridOverlay here.

The draw() method calculates the grid size, aiming to get a minimum of two latitude lines within the MapView's current display area.  It draws the grid only on the portion of the map on display, and redraws it each time it is called, so applications using this overlay should call their MapView's invalidate() method after every zoom or scroll action.  It puts the grid latitude or longitude on each grid line, with longitudes displayed vertically.  The format in which these are displayed can be varied.  Supported formats are LLD (degrees and fractions, e.g. 52.03365°), LLDM (degrees, minutes and fractions of minutes, e.g. 004°13.255'W) or LLDMS (degrees, minutes, seconds and fractions of seconds, e.g. 52°13' 4.3").

To include grid lines on your MapView (represented here as mMapView), define a GridOverlay and add it the map's overlays, thus:

public void  drawGridLines()
{
        GridOverlay ol = new GridOverlay(
                     Color.GRAY, 
                      GridOverlay.LLDM,
                      mResourceProxy);

       ol.setStrokeWidth(1.0f);
        mMapView.getOverlays().add(ol);
}

Define a MapListener handler for the MapView, thus:

mMapView.setMapListener(new MapListener()
 {
         @Override
         public boolean  onZoom(ZoomEvent ev) 
          {
                updateMapPosition();
                mMapView.invalidate();

                return false;
         }

        @Override
        public boolean onScroll(ScrollEvent ev) 
        {
                updateMapPosition();
                mMapView.invalidate();

                return false;
        }
 });

(In my implementation, updateMapPosition() records the map's centre point and co-ordinates in the text boxes to the right hand side, as shown in the screen shots in my previous blog.)

Again, it's some time since I updated this blog, but the wait is, I hope, worth it.  PCDB Waypoints now has the ability to display a route on a map, with the waypoints indicated by markers and a line joining them.  The zoom level of the map is set to ensure that all points on it are included in the area shown.  Where a Waypoint is defined by reference to one or more nearby Marks (i.e. by the distance and bearing from the mark), then at an appropriate zoom level the marks, too, are shown with bearing lines joining them to the appropriate Waypoints.

And, the piece de resistance, grid lines are shown on the map which move around as the map is scrolled, and the grid spacing changes as the map is zoomed.

Here are some screen shots.  The map used is the Open Steet Mapping (OSM) default.  This covers the entire world, but at varying levels of detail, and there are indications that in some areas the coastline (at least) is not properly mapped.  But it's certainly enough to get this project going.

This shows a popular cruising route in North Wales, from Abersoch to the anchorage at Pilot's Cove behind Llanddwynn Island, just outside Caernarvon bar.

After zooming the map in a few times, and touching the icon representing the Waypoint just south of Llanddwynn Island, an InfoWindow pops up showing the details of this Waypoint and the two Marks that define its position.  One is a South Cardinal mark at 308.5 degrees, and the other the Llanddwynn Island lighthouse immediately North of the Waypoint.

It's been some while since I last added to this blog.  Most of that time has been devoted to my latest project: making PCDB Waypoints display a map over which it can overlay marks, waypoints, or collections of waypoints joined by a route.  It hasn't been easy!

Stage 1 was to get it to display a map - any map.  The eventual intention is to display chart-type data, but most of the mapa data available today is streat maps - either Google's or someone else's.  The Google mapping apps in Android can only be used with Google maps.  I don't want to be restricted in this way, so I've been looking at alternatives.  One is the Open Street Mapping (OSM) initiative, which provides a free-to-use street map of much of the world, and a set of Android APIs to enable an app to access these.  I've now got to the point where, starting from the Waypoints screen, I can call up the OSM map, and show the Waypoint's icon (starboard hand mark, fairway buoy, etc), suitably scaled and positioned at the correct point on the map.  I can then scroll the map and zoom it in and out.

The next stage is to overaly a sequence of Waypoints, find the geographic centre of them and position the map there, the set the zoom level so that the entire route is included on the map pane. That'll keep me busy for a while yet.

There's been a somewhat prolonged hiaitus in this blog during the summer, not all caused by some extended sailing trips.  The olympics is partly to blame!  But I've gone back to the PC version of PCDB Waypoints, and finished the rather tedious task of preloading it with all the information I can find about lighthouses, buoys and beacons around the UK and near European coast.  That is now complete.  I can also take that information (from a Microsoft Access database) and load it into an empty PCDB Waypoints app running on my tablet.  Doable, but somewhat slow.  However, it means that I can really load-test the app on an enormous amount of data before releasing it into the wild.

There's a funny glitch in Androis whereby if I run a number of debug sessions of the same app on the same device, I get a number of identical icons in the Apps screen on the tablet, each corresponding to some terminal state of the app at the end of a debug session.  I've got roughly a screenfull.  I uninstalled PCDB Waypoints and reinstalled it to get rid of those, and then found some errors in the database import process which are now fixed.  So now I can get on with completing the functionality of this app and getting it ready to market.

Along the way, I've uploaded a new version of PCDB SuDuku Solver, at a reduced price.  The new version follows the evolving Android conventions for widget appearance which are designed principally to conserve battery power.  Next, I need to upload the same version of PCDB SuDoku Lite...

Also along the way, Samsung successfully upgraded my tablet from Android 3.2 to 4.0.  I've picked up the latest version of the Eclipse IDE and now need to explore the facilities of both new versions.

Observant readers may have noticed a rather prolonged hiatus in this blog in recent weeks. This is because the author has been on an extended sailing holiday from Holyhead to Northern Ireland.  With a couple of crew changes, Caledonia has visited the Isle of Man (Port St Mary and Peel), and Ardglass, Bangor, Glenarm, Ballycastle and Rathlin Island in Northern Ireland.  Ship's dog Monty was the only constant crew member apart from myself.

Ardglass was the first and last stop in Northern Ireland.  A small marina in County Down, it is far and away the most convenient transit port between Dublin and Belfast.  It has the benefit of another resident Springer Spaniel, Monty's friend Ben.

Strangford Lough is an amazing place.  An enormous body of sea water in the heart of Northern Ireland.  Caledonia stopped at Quoile Yacht Club, a totally isolated spot miles from anywhere, with tranquill views over the river as here.

The narrow entrance to Strangford Lough is the site of the UK's first tidal electricity generator, seen here with the rotor blades raised for maintenance.  Tides run at great speed here, and on its first passage through the narrows Caledonia recorded 12.6 knots over the ground with the help of nearly 8 knots of tide.

Bangor Marina at the mouth of Belfast Lough is a convenient place for a crew change, with a 20 minute train ride and short shuttle bus to Belfast City airport.

Glenarm Marina, 25 miles north, is another convenient transit port.  We didn't see much of this, leaving at 0530 the next morning to get to Ballycastle in County Antrim.  Ballycastle has a great marina, and is a 40 minute bus ride from the Giant's Causeway.

Rathlin Island is a magical place, somewhat detached in many ways from the rest of Northern Ireland.  Here's a view of the harbour, with a new pontoon for visiting yachts.  It's chief visitor attractions are its three lighthouses, South (Rue Point), East (Altnacarry Point) and West.  But West Lighthouse is also the home of a major RSPB bird reserve, with thousands of sea birds including puffins, guillemots, razorbills, kittiwakes and many others.  The island is also home to the Irish Hare.

But the best part of this voyage, compared with previous ones to Ireland or Scotland, was the weather. It was ideal; much better than that enjoyed by the folks back home in England.  We lost one day's sailing to inclement weather, and apart from Portrush which we decided to avoid after hearing woeful stories of its facilities for visiting yachtsmen, managed to reach every port we'd planned.  The main objective in getting to Portrush was toe visit the Giant's Causeway, but we managed to reach that from Ballycastle instead.

Now, back to PCDB Waypoints...

I've just been notified by Google that PCDB S*D*K* Solver has been removed from the Google Play store in Japan.  Searching the web, there seems to be a concerted campaign by a Japanese company to remove any app with that word in its title, other than those they own, from the Japanese market.  Surprisingly, the Lite version (free) wasn't mentioned, but just to be on the safe side I've removed that from the Japanese market too.

There doesn't seem to be any such pressure elsewhere in the world.

Recent work on PCDB Waypoints has concentrated on getting it to generate KML ("Keyhole Markup Language") files that can be read by Google Earth.  This is now reasonably successful, at least in the PC version.  I've used it to generate files of the various voyages I've been on over the last 60-odd years, some in my own boat, some on troop ships when my father was in the army after the Second World War, and others in cruises that Elaine and I have enjoyed over the last few years.  Getting it to work wasn't particulary easy, as the documentation is a bit difficult to follow, but I can now follow the routes of each of the voyages I've recorded.  I still need to complete the sework on the Icons used to show the type of waypoint; that's easy but tedious.

The Android version of PCDB Waypoints is coming on apace, but doesn't support this feature yet.  However, I can copy KML files generated on the PC onto my tablet, and with the help of a useful app called "KML to Earth", show a voyage on the tablet's version of Google Earth (I'm running version 7.0).  I won't be taking my PC to Northern Ireland, but the Irish routes are now fully planned out and I can display them all on Google Earth.

Now if I could overlay this data on my Android Navionics app...