Hi!
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....
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'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.
A week or so ago someone completely destroyed the home page of the
Oxford Guide [1]. This was a pain, and to recover the state I had to paste
the content from mysql command line output because it wasn't possible to
recover the earlier version from the CGI.
Two possible solutions (ideally both should be implemented I think):
- Implement a "delete revision" function (to go with the "Delete node"
functions. I would not want to keep most malicious edits: bear in mind
that you are still effectively publishing them through the historical
versions. When this is spamming for googlejuice... [2]
- Allow editing of historical versions:
16:40 <@grault> load the text of an earlier version into the edit
buffer; save it as a new version when you hit save.
Dominic.
[1] http://www.ox.compsoc.net/oxfordguide/?id=Home&version=81
[2] http://www.ox.compsoc.net/oxfordguide/?id=Home&version=XX
(replace XX with 65)
> -----Original Message-----
> From: openguides-dev-bounces(a)openguides.org
> [mailto:openguides-dev-bounces@openguides.org]On Behalf Of David
> Cantrell
> Sent: 29 June 2004 01:16
> To: OpenGuides software developers
> Subject: Re: [OpenGuides-Dev] locator plugins
>
>
> IvorW wrote:
>
> > An ellipsoidal projection about one great circle will only
> provide an accurate projection
> > regarding distances, for a very small percentage of
> locations on Earth.
>
> I know we've talked about simply calculating distances from
> point A to
> point B on the surface of a sphere in the past, and rejected
> it because
> you lose accuracy over small distances, due to rounding
> errors in cos()
> and sin().
>
> I wonder, if we used an arbitrary precision FP library like
> Math::BigFloat does this problem go away? It doesn't provide trig
> functions, but they can be derived thus:
>
> cos(x) = 1 - x^2/2! + x^4/4! - x^6/6! + ... (x in radians)
>
> and
>
> sin(x) = x - x^3/3! + x^5/5! - x^7/7! + ...
>
> This is guaranteed to give us accurate results provided we use
> sufficiently accurate values for sin(x) and cos(x), I wonder
> what the
> performance hit would be.
>
More to the point is the accuracy of the other factor - the radius of the Earth.
If you assume that this is a constant, you are assuming that the Earth is a sphere.
Also, how would you go about measuring the distance from a given point on the Earth's
crust to the centre of the earth?
An alternative approach woud be to use a linear approximation (slides 24-26)
http://un.earth.li/~ivorw/slides/geogmod.ppt
Having defined an origin for our guide (e.g. Charing+, Carfax, etc.)
We could go out there with a GPS and a trundle wheel (or some other means of measuring
distances in a straight line accurately), and come up with the appropriate X and Y
scale factors for our own grid. This was my original idea, before I learned about UTM
and ellipsoids.
Ivor.
On Mon, Jun 28, 2004 at 06:48:23AM -0400, IvorW wrote:
> I thought that you needed different ellipsoids for different parts of the globe.
> wgs84 or nad83 may work well for California, but I doubt if they would for Europe.
no, wgs84 is a global model. streetmap.co.uk gives you lat and long back in wgs84. you need to worry about the different archaic reference datums used in different countries grid projections only when projecting geodata onto flat maps that are already georeferenced according to the other projection.
UTM is where this makes a difference for different countries grid systems - i wouldn't know my own local mapping agency projection, though...
i would send a link with better metainfo but have to run...
zx
On Sun 27 Jun 2004, Jo Walsh <jo(a)frot.org> wrote:
> then i think the 2 plugins should be totally compatible, and i just
> change mine to use base CGI::Wiki::Plugin::Locator::UTM, and add the
> geocoding method. nice one ivor.
Couldn't the two plugins be merged into one? And
CGI::Wiki::Plugin::Locator::UK should be made obsolete as well.
> a further thought! Schuyler objects that distances in metres and
> kilometres meant little to people not used to seeing them /
> converting between them and yards/miles, e.g. pesky merkins.
On Mon 28 Jun 2004, IvorW <ivorw-openguides(a)xemaps.com> wrote:
> Sounds like a case for using Data::Dimensions.
That's real overkill for a simple conversion.
Anyhow, it looks like you two have this well in hand so I shall leave
it up to you.
Kake
On Mon, Jun 28, 2004 at 06:48:23AM -0400, IvorW wrote:
>
>
> > -----Original Message-----
> > From: openguides-dev-bounces(a)openguides.org
> > [mailto:openguides-dev-bounces@openguides.org]On Behalf Of Jo Walsh
> > Sent: 28 June 2004 00:42
> > To: OpenGuides software developers
> > Subject: [OpenGuides-Dev] locator plugins
> >
> >
> > > an additional piece of data by way of the ellipsoid. This
> > > needs to be prompted
> > > for in the setup, and held in the config file.
> >
> > i kind of assume it will always be wgs84 - 23 for
> > Geo::Coordinates::UTM - or nad83 which is centimetres of
> > difference. this is what gps, the big mapping sites, etc use
> > - this could be a default config option without a prompt?
>
> I thought that you needed different ellipsoids for different parts of the globe.
> wgs84 or nad83 may work well for California, but I doubt if they would for Europe.
>
Ireland works on a Modified Airy Ellipsoid afaik, so I think you're
right in saying it needs different ellipsoids for different areas of
the globe.
What a miss-shapen world we live on.
:)
Stephen
> -----Original Message-----
> From: openguides-dev-bounces(a)openguides.org
> [mailto:openguides-dev-bounces@openguides.org]On Behalf Of Jo Walsh
> Sent: 28 June 2004 00:42
> To: OpenGuides software developers
> Subject: [OpenGuides-Dev] locator plugins
>
>
> > an additional piece of data by way of the ellipsoid. This
> > needs to be prompted
> > for in the setup, and held in the config file.
>
> i kind of assume it will always be wgs84 - 23 for
> Geo::Coordinates::UTM - or nad83 which is centimetres of
> difference. this is what gps, the big mapping sites, etc use
> - this could be a default config option without a prompt?
I thought that you needed different ellipsoids for different parts of the globe.
wgs84 or nad83 may work well for California, but I doubt if they would for Europe.
> > In terms of metadata, the module needs (and relies on)
> latitude and longitude.
> > The pythagorean distance finder needs zone, easting and
> northing. The plugin
> > will provide these via the location method. The distance
> finder needs zone,
> > easting and northing to be stored in the database.
>
> i never needed to use the zone, but things will blow up if a
> guide spans more than one and gets different spatial references?
> as 'easting' and 'northing' rather than os_x / os_y?
The zone is just there as a memorandum field. The distance finder only detects
locations in the same zone as the place you are searching from.
Also, the distance method checks the zone. I guess it could return undef, and allow
calling code to use a different distance algorithm - such as one which works off lat/long.
I only think this is an issue when we get a guide that spans multiple zones.
>
> then i think the 2 plugins should be totally compatible, and
> i just change mine to use base
> CGI::Wiki::Plugin::Locator::UTM, and add the geocoding
> method. nice one ivor.
Good! That shows my initial idea was sound :).
> a further thought! Schuyler objects that distances in metres
> and kilometres meant little to people not used to seeing them
> / converting between them and yards/miles, e.g. pesky
> merkins. i could do metre/mile conversion and change the
> distances - or keep it like it is - but it's definitely a question.
Sounds like a case for using Data::Dimensions.
Ivor.