There have been a couple of announcements recently about marrying Business Intelligence Suites with Mapping- which all sound really exciting, though I’m still a little hazy about exactly what these olap hypercubes are, with their snowflake schema and other such nonsense important sounding things. Immature comments aside, I’m yet to be convinced of the advantages over a standard relational approach. I am, however, keen to understand the Geo BI offerings, as I think they could be key in persuading people in management positions of the real value and power of online mapping. At the moment I find it hard to evaluate the different approaches, so I need to spend some time setting them both up (reports will follow).

Similarly, via the antiquist list and All Points Blog, we hear about a Linked Geodata Browser for Open Street Map. Go to the APB post for the details, as reading the documentation sent me down a wikipedia rabbit-hole, again revisiting olap and his hypercubes. In this case, it’s not so much the drilling down through the dimensions of the data that interests me, though that’s mighty cool, but the RESTful interface that they have added. My experience of REST so far is limited to chapter 1 of the O’Reilly Book and dabbling a bit with Featureserver, but I like what I see (and I’m impatient to see the MapGuide Open Source REST extension too). Call me simplistic if you want, but I like the inherent “linkiness” of it all and I’ll keep paddling in the shallow water until I can take my waterwings off…

It’s funny how you can have a fairly quiet time of things, then suddenly everything happens in one week…

So Monday was the first Open Source GIS conference in the UK, affectionately known to it’s friends as OSGIS 2009. The event was sold out in advance (150 people) ,  and seemed to be well received, though it was hectic, with two streams and workshops going on through most of the day.  I quite enjoyed the quick-fire aspect of the talks, with most being limited to 15-30 minutes. Perhaps my favourite was from Rob Booth, who talked about using Open Source for Spire- the UK Department for the Environment, Food, and Rural Affairs’ (DEFRA)  SDI. While there were issues with scaling, the flexibility, response and community/developer support were all big plus points in choosing that solution. This is a good counter-example to bring up whenever anyone says that open source is just for the little guys.

We had the first AGM of the OSGeo UK local chapter after the conference, and many thanks to those hardy souls who stayed around for it. The main point of discussion was whether the chapter should become an ‘organisation’, in the voluntary sense, which would allow us to have a bank account and various useful things like that. We also discussed putting a bid together for FOSS4G in 2011, and decided that 2012 would be a better bet, it being Olympic year and all that. Mateusz had some really good points to make about using social networking to get people involved, and the idea of having informal get-togethers outside of the big conferences. So- we now have a linkedin group, a facebook group and some tools for helping people plan meetups will be following shortly. Lunch-time pub get-togethers were very popular. Can’t imagine why… join the groups though- the more the merrier!

So- to next year. Bigger, better, and shinier. There’s a date for OSGIS 2010 already, and plans are afoot to spread it over 1.5 days, with an afternoon of workshops either before the main event or after it. See you there!

A quick post to give people a heads up that there seems to be a google groups problem affecting the portable-gis group, amongst others.

If you have signed up with a googlemail account (not gmail, or any other email account) then your messages may get bounced back with a permissions error.  This seems to be a general problem affecting many groups, so no doubt a fix is in progress, but just so you know, I’m not blocking anyone (hell, I can’t post to my own group at the moment!).

What do you mean exactly? I’m not sure I agree with all of Seth Godin’s examples, particularly his comments about standards, but this shows just how much of a buzz-word “Open” has become. Once you’ve got your terminology sorted, head over here for a cultural band-wagon to jump on. Personally, I’d rather see Open Source adoption in terms of people seeing the light rather than simply admitting defeat, but it does mean there’s hope in the long run…

You might have seen this post last week about how the Ordnance Survey once again saved the universe from un-approved uses of “their” data, by blocking an incredibly useful application that overlays Ordnance Survey mapping over Google Earth. You might have seen this post about it too. You might even have written to the Ordnance Survey to complain about it.

However, unless, like me, you had these posts tagged in your feed reader ready to write something about them, you might not have realised that the Ordnance Survey have (sort of) relented.  I say “sort of”, because apparently there’s still an issue between the terms of Google Earth’s license and that of the Ordnance Survey, but at least Gavin gets his API key back again.

Power to the people!

Not my own words, but copied verbatim from Chris Schmidt on the OpenLayers Mailing List. Change the name, and they are mostly applicable to any package, not just OpenLayers. Having been guilty of not following these instructions myself, I’d advocate that all new mailing list subscribers should read it before signing up…

Many times, users have come to me, or asked questions in IRC, related to
getting help with a particular behavior. Whether that behavior is a bug
or user error, there is one thing that you can do to make it more
likely that a developer will be able to quickly help you with your
problem. (In some cases, this is the difference between getting help at
all, and simply not receiving any.) I have never seen any situation
where this rule does not apply, and so I want to share it publicly with
the users and dev communities so that we can all learn from it, and
learn how to help each other more quickly and easily.

(Throughout this post, I use the terms ‘developers’ and ‘users’. By
these terms, I mean “persons who have knowledge of the code inside of
the OpenLayers library” and “persons who have knowledge of using the
OpenLayers library, but not what is inside the library itself.”)

Minimizing Test Cases
———————

In order for developers to help fix a problem, they first have to
understand it. In order to do that, they need to understand everything
thati s going on in a situation where the problem is reproducible.
Oftentimes, the particular behavior is only existing in a certain type
of situation, or in a limited case that is not exploited by the commonly
used code. (In addition, some problems are the result of user error in
some way.)

In order to help developers help you, the best thing to do is to
minimize the error to the *smallest amount of code that can cause it to
happen*. Additionally, when attempting to reproduce, any developer will
need to set up the code so that it is possible to run in the developer’s
test environment. This means that it is ideal to remove external
references to other Javascript files, and external files at all, where
possible. (Clearly, this is not always possible: WFS server bugs can’t
typically be demonstrated inside of a single page, for example — but
you should minimize external dependancies as much as possible.)

Once you’ve done this, you should remove *all non-neccesary lines of
code* from your example. Does the problem require the ScaleBar control
in order to manifest itself? If not, toss it. Does it need multiple
layers? If not, toss them. In short, any line of code that is not
directly related to reproducing the problem should be removed, as each
line will need to be read by the developer — and in the case of
multiple developers working on a problem, read by *each* developer — in
order to determine whether the problem is related to that.

This minimization step should include removing any unneccesary
Javascript, unneccesary CSS files, unneccesary HTML, etc. until the
resulting code is as small as possible.

Many times, in doing this, you will come across a particular
minimization step that causes the problem to go away. This is a good
sign, because it means you have narrowed the problem down to that
particular aspect of code. Put it back, and keep minimizing.

Additionally, many times in doing this, you find a particular construct
in your code that can help you understand how to work around the
problem.

If not, then continue onto the next section.

OpenLayers Library References
=============================

There are multiple hosted versions of the OpenLayers library.

http://openlayers.org/api/OpenLayers.js

This will always represent the most recent released ’stable’ version of
the OpenLayers API.

http://openlayers.org/dev/OpenLayers.js

This is always a 10-minute delayed build of OpenLayers trunk.

To simplify allowing developers to set up the code on their own testing
environments, it is often beneficial to point directly to one of these
library URLs. In addition, this also ensures that the problem is not
something specific to your build of OpenLayers.

Publishing your Problem
———————–

Once you have minimized your test case, you need to publish it. In
general, it is easiest if you publish an HTML page on a web accessible
URL. Even if your project is not yet public, you can likely put a page
up on another server which demonstrates the problem. Doing this is much
more likely to have a developer actually follow the link and explore
your problem. This is *especially* true for things like WFS which
require a proxy to work correctly:  Downloading the page, setting up a
proxy, and testing locally is a lot of work for a developer simply to
confirm that a problem exists.

If you do not have *any* place to publish webpages, you can attempt to
paste your code to a public site like ‘nopaste.com’. However, be aware
that doing so means that a developer has to perform more steps to
reproduce your problem — and every step is one that makes the problem
less likely to be solved quickly and easily.

Communicating about your Problem
——————————–

The best way to communicate your problem is to send an email to the
users list demonstrating the problem. Oftentimes other users will be
able to point out a particular flaw in your code that is causing the
error, or explain that the behavior is a known lack of functionality in
OpenLayers.

*Be clear on steps for reproduction*. Users who don’t know what they’re
supposed to do to cause the bug will not be able to see it, and if they
can’t see it, they can’t help you.

If you have determined the particular change in the OpenLayers source
code which is required to change the behavior, then it is more likely
that the Developers list is the best place to go. Any discussion which
involves code from OpenLayers itself is probably better suited for the
dev list.

Finally,
——–

By following the steps:
* Simplify/Minimize
* Publish
* Communicate

(If you’d like, you can toss a “???, Profit!” at the end of this.)

You can ensure that it is as easy as possible for a developer to
determine whether the problem you’re having is with the library. You
also make it easier for develpoers and users to find potential problems
in your usage of the library and suggest solutions. Finally, you may
find in the process that you find the bug yourself, thus saving yourself
and everyone else time in trying to debug.

The end result is a more workable system for everyone. The easier it is
to understand the problem you’re having, the faster, and more easily,
you will be able to get help.

Best Regards,
–
Christopher Schmidt
MetaCarta

A nice short guide on how to start making your data open from Open Data Commons. This shows how simple it really is.

OK, I’m excited to announce that the new version of Portable GIS, complete with the latest versions (as of today- I have to draw the line somewhere) of all the software, is now in testing phase and pretty much ready to release. It’s a bit slicker that the previous version, and comes with some extra software and utilities.

Here is my problem: the last release weighed in at just less that 1GB downloaded, but the new one looks like coming in at approx 1.6GB though I’m going to zip it up in an exe which might help a bit. Software tends to increase in size from version to version, so some “bloat” is unavoidable, but is 1.6GB excessive?

I have a couple of options that I can take to reduce the size. The first is to strip out programmes, so that, for instance, there is only 1 desktop GIS package, or only 1 map server package. The second is to turn this setup into a Portable App, which gives me options to compress the files. I have previously been reluctant to go down the second route because I want the files in Portable GIS to be as similar to those in a standard download as possible, so that people can dig in and see what’s going on and use Portable GIS as a spring board to installing the apps themselves. I worry that “Portable-ising” the files will alter them in some way, but if someone can reassure me about that it’s something to consider.

So, questions:

1. Is 1.6GB excessive for a download of this type?
2. Should I only provide one desktop package and one map server?
3. Should I turn Portable GIS into a fully fledged portable app?

Thanks for your feedback!

Time for another round-up…

• The Ordnance Survey have revised the terms and conditions of using their OpenSpaces mapping API (via Mapperz), which is a step in the right direction, since they now allow adverts on your site. There’s still a daily limit to the number of views/address lookups that you can do too. However, there are a couple of points that need mentioning/clarifying… firstly there’s a strange condition that you can’t use this for “internal business administration”. Not sure what that really means, but I assume it’s so you don’t stick it behind a firewall and stop OS counting your number of page views or something. Furthermore, there’s nothing obvious on the site about whether you need a license to use the data still, in which case it’s still a show-stopper. I’ve emailed them for clarification about that, so watch this space…
• Tyler Mitchell has an article in Direction Magazine about “Reassuring End Users of Open Source“.  I’m uneasy about the term “Reassuring”, as it has slightly negative connotations (”don’t worry!”, “worry, who said anything about worrying?”), but the article is well worth a read with some useful comments on the advantage of open source for businesses and the role of OSGeo.
• No doubt everyone already knows about the OpenGeo Architecture White Paper. Personally I think it’s another good paper to have around and quote from (or steal slides from) when trying to convince people that using open source geospatial software  is a more flexible and all round sensible approach to your geospatial stack.
• OStatic have an article about Open Source software at NASA. Not so much geospatial stuff going on there, but it’s good to see the top two reasons why NASA go for Open Source:

To increase NASA software quality via community peer review

To accelerate software development via community contributions

It’s good to see “quality” as an argument for choosing Open Source, rather than “saving money”!

I’m excited to announce that the list of papers and workshops for the first UK Open Source GIS conference is now available on the website. With Tyler Mitchell doing the keynote,  and a choice of 25 papers and 4 workshops, it’s going to be a really good day. We’re hoping to finish up with the first AGM of the UK local chapter of OSGeo too, so I hope you’ll join us!