Hi folks. I just joined the list because I've long held a dream of
building a specific site.
What I'm talking about is a geek/engineer tourism site. I'm one of
those sad types who, when touring around Vietnam, stops and gawks at big
(http://www.rumble.net/travel/photos/vietnam/nw/thumb/nwdamfish-9-0.html)
and small
(http://www.rumble.net/travel/photos/vietnam/nw/thumb/nwhydro3-9-0.html)
engineering marvels.
So I'd like to have a site that collects information about this kind of
thing. Power stations, significant dams, historic sewage system
features, giant tunnels, spy stations, bomb shelters, architectural
marvels and follies, engineering accidents, atomic bomb test sites etc
etc. The site would include photos, historical information, transport
information, opening hours and prices, details of preferred viewing
sites and GPS coordinates.
So it occurred to me that Openguides has already achieved much of this
in a suitably open and geek-ready format. However, it doesn't fit your
ontology. Your site gives guides for a particular city or region,
whereas this idea would work best as an integrated, global site. That
way you could look at a meta-topic on an area of interest (say, atomic
test sites).
I can see this cross-guide linking is probably a problem you've already
encountered (compare the tube networks of London and New York) and
discussed, so I'm curious to hear your thoughts.
So is this something Openguides would be interested in pursuing? Of
course, I'm offering to maintain the content.
--
Rev Simon Rumble <simon(a)rumble.net>
www.rumble.net
"Which is more musical, a truck passing by a factory
or a truck passing by a music school?"
- John Cage
I just released OpenGuides 0.38, which has major improvements to the
search results ordering. Check out
http://un.earth.li/~kake/cgi-bin/og/wiki.cgi
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.
Kake
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
restaurant.
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:london.pm-admin@london.pm.org]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]
> ShepherdsBush
> [shepherd's bush] and have them work.
>
> StudlyCaps are just plain easier to type, and avoid doing
> [this
>
> or
>
> ]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
http://openguides.org/mail/openguides-dev/2003-October/thread.html#91
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
parsing.
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 :).
Ivor.
hello sfdorkbots,
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.
jo
xx
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
released).
Cheers,
Dominic.
Since people are starting to want to contribute photos the Oxford Guide,
I've been thinking about what level of integration is appropriate with
OpenGuides.
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:
<a href="$image_base/normal/$imagename"><img
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
layout.
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?
Cheers,
Dominic.