I'm planning on starting a openguide for the Buenos Aires city (Argentina).
I already have a draft (http://guiaba.mine.nu/cgi-bin/openguides/og), but I
have some doubts and I want to share them with you:
I'm concerned about language. I hope the guide to be used for locals and
visitors, but specially for locals. So, english doesn't seem to be a good
option. But: all the other pages in openguides are in english, including
Oslo's; and the software doesn't seem to suppor multi-language.
I'm not really convinced on using openguides as a platform, since the only
features I see which gave me some advantage over other wiki engines are
categories and locales (which can be implemented with some hack), and they
aren't trated in a special way, it is the same if I put a link at the
bottom of the page
The rest of metadata doesn't seem to be used except to be shown in the same
page (the coordinates system can't be used, since i'm outside the uk).
Another important fact is that it is too slow withour mod_perl.. is there
any provision for running under it?
I don't want to be a flamer, just those are questions that arose when
starting this project (which I had in mind before knowing openguides), and
may be someone can help me....
At present, clicking a page's title will get you a list of backlinks. It
would be useful if this listing included pages redirecting to the page as
well, although I'm not sure if that would require additional stuff in the
database. At that point, the list could then include backlinks to the
redirecting page as well.
I just released OpenGuides 0.38, which has major improvements to the
search results ordering. Check out
which is running on a snapshot of the London data from this afternoon.
The summaries still need work, but at least the results are coming out
in a sensible order now.
On Tue, Jun 29, 2004 at 09:29:48AM -0400, IvorW wrote:
> More to the point is the accuracy of the other factor - the radius of the Earth.
The variation is of the order of 20km in 6370km.
> If you assume that this is a constant, you are assuming that the Earth is a sphere.
The deviations in distance measured along the surface compared to that
calculated from the "mean sphere" will, if my sums are correct, produce a
maximum error of up to 1m in 2km at the poles and a shade more than that at
the highest point on the equator. At the poles we'd calculate 2.001km,
at Mount Kenya, about 1.999km.
That one metre only matters if you're trying to serve someone their soup
by dropping it from orbit, not if you're merely trying to hit the right
Even if my sums are wrong and I'm out by a factor of a HUNDRED, the
maximum error is a mere 5%, or 100m in 2km, or 25m in 500m. Which still
doesn't matter when you're trying to find a restaurant near the theatre.
> Also, how would you go about measuring the distance from a given point on the Earth's
> crust to the centre of the earth?
The above shows that we can safely assume that the earth is a sphere
with a radius of 6370km.
David Cantrell | Reprobate | http://www.cantrell.org.uk/david
It's my experience that neither users nor customers can articulate
what it is they want, nor can they evaluate it when they see it
-- Alan Cooper
I'd welcome feedback from OpenGuides people as well.
> -----Original Message-----
> From: london.pm-admin(a)london.pm.org
> [mailto:email@example.com]On Behalf Of Tim Sweetman
> Sent: 23 July 2004 15:02
> To: london.pm(a)london.pm.org
> Subject: Re: wiki-ness (Was: Re: devolving and crack fuel)
> > if you choose the right
> > software you can make them go away.
> > http://search.cpan.org/~kake/CGI-Wiki-Kwiki-0.52/ is quite
> nice when you
> > make it use usemod formatting and make it not use studly
> caps for links.
> I think there's a basic conflict here:
> 1. authors want to write links like
> [shepherds bush]
> [shepherd's bush] and have them work.
> StudlyCaps are just plain easier to type, and avoid doing
> ]this, and confusing the parser, and the writer, who's not that
> technical and isn't used to incorrect syntax blowing the
> bloody doors off.
> 2. readers want stuff to be formatted like English (if they
> care, which
> they might not) and to avoid miscontextualisation along the lines of
> ... the bodyguard shepherds Bush through the throng ...
> (not saying if it was Kate, Vannevar or a George, mind)
> Punctuation helps. StudlyCapsLookAwful, especially to
> nonprogrammers who
> are just plain not used to them.
> My solution would be:
> a) pages can have multiple names, one of which is the
> preferred/canonical one. (This is a bit like the more widespread
> "redirect node" feature)
> b) links are written with the node's canonical name.
> writer writes ShepherdsBush (or [shepherd's bush])
> reader sees Shepherd's Bush.
> (This could work well with people/entities who insist on
> spelling their
> names in a "difficult" way, such as with accents your
> keyboard doesn't have)
> 3. Names may themselves want canonicalisation. Is it Earl's Court or
> Earls Court? Probably depends which sign you read, and with
> place names
> even LynneTruss is bound to get it wrong sometimes.
> No, I haven't implemented this.
I raised this on the OpenGuides-dev list last year, see
I'd be very interested if it is possible to resolve these issues - at least
arriving at a sensible compromise. OpenGuides and its intrinsic search
function could do with having this matter resolved.
This is how it works at the moment:
1. Node names are normalised before being inserted into the database. This
involves turning spaces to underscores, capitalising initial letters (Title Case),
and escaping out of pathological metacharacters that would otherwise break the
2. Links are normalised as they are followed, permitting use of unnormalised text
e.g. different case.
3. Punctuation characters in titles are preserved (e.g. apostrophes, hyphens)
4. Permitted search strings have a restricted character set
As keeper of the search, I would like to know if we have got this right or not,
especially the normalisation aspect of this.
We are also being faced with new challenges, regarding character sets and internationalization.
Your feedback would be most welcome :).
back in london my friends earle and kake run an Open Guide to London which has been on the dorkbot circuit a few times. http://london.openguides.org/ - a wiki-based city guide, with spatial metadata which you can get in RDF.
http://sf.openguides.org/ is an SF one i set up while staying here, tinkered with to add geocoding and a map service. i'm really a tourist though and don't know a community of interest like the london one had - a lot of perl hackers with shared interest in real ale and sushi. so i would appreciate contributions to it or commentary about it... i am aggregating the metadata in a spatial model useful on local free wireless services.
I've compiled what I hope is a complete list of the classes and ids used
within the guide, and their purposes (in most cases obvious, but it is
helpful to have a complete record).
It's temporarily at
<http://www.ox.compsoc.net/~dom/openguides-patches/README.CSS> - I'll
either commit it to CVS in that form or incorporate it into the comments
in a plain CSS file to be distributed as a default file.
Until I do this it would be helpful if developers could ping me of they
make any changes that would affect this file.
It may be useful for you to check that your CSS is consistent with this
list (assuming of course that you are running the CVS codebase - a few
changes in classes and ids have been made this weekend not yet
Since people are starting to want to contribute photos the Oxford Guide,
I've been thinking about what level of integration is appropriate with
My initial plan is as follows:
Config var image_base is a partial URL defining where to find images.
Standard subdir scheme $image_base/thumb and $image_base/normal for a
simple two-size hierachy of images.
A macro #EMBED_PHOTO [imagename] or similar, which would do, approximately:
src="$image_base/thumb/$imagename width="$width" height="$height"
border="0" alt="Image for $node_name"></a>.
A new special field in the node "photo" which would be used to define
the "primary" image for the node. This could be automagically displayed,
if present, for example to the right of the metadata in the standard web
Photo uploading I am leaving as a separate problem for now. If people
have any particular ideas I'd be interested in them, but the way I see
it the photos probably want to be reviewed rather than made public
straight away, and there is no particular need to have uploading
integrated into OpenGuides itself. I may investigate DAV, or a simple
CGI script for POSTing files.
An example hierachy is
<http://www.ox.compsoc.net/openguides/oxford/photos/>. Note that I also
have a full/ directory for the full-size photos (useful for
"remastering" the guide into print, for example) and a simple note of
who took the photo.
Any comments before I start trying to code this?