OpenGuides-Dev June 2004

openguides-dev@lists.openguides.org

17 participants
48 discussions

[OpenGuides-Dev] GeoCache.pm
by Dominic Hargreaves 12 Oct '04

12 Oct '04

Earle, I saw on the dev wiki <http://openguides.org/dev/?node=Earle's%20To-Do> that you want to move it. But why does it need to exist at all? It can be done entirely within the templates: [% IF latitude AND longitude %] <a href="http://www.geocaching.com/seek/nearest_cache.asp?origin_lat=[% latitude %]&origin_long=[% longitude %]">Look for nearby geocaches</a> [% END %] Cheers, Dominic.

4 8

[OpenGuides-Dev] nwe project
by Martín Hernán Ferrari 21 Sep '04

21 Sep '04

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....

10 17

Re: [OpenGuides-Dev] locator plugins
by David Cantrell 23 Jul '04

23 Jul '04

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

2 1

[OpenGuides-Dev] CSS documenation
by Dominic Hargreaves 12 Jul '04

12 Jul '04

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.

3 3

[OpenGuides-Dev] Defacing resilience
by Dominic Hargreaves 30 Jun '04

30 Jun '04

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)

3 5

RE: [OpenGuides-Dev] locator plugins
by IvorW 29 Jun '04

29 Jun '04

> -----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.

1 0

Re: [OpenGuides-Dev] locator plugins
by Jo Walsh 29 Jun '04

29 Jun '04

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

5 4

Re: [OpenGuides-Dev] locator plugins
by Kate L Pugh 28 Jun '04

28 Jun '04

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

1 0

Re: [OpenGuides-Dev] locator plugins
by Stephen Stewart 28 Jun '04

28 Jun '04

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

1 0

RE: [OpenGuides-Dev] locator plugins
by IvorW 28 Jun '04

28 Jun '04

> -----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.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

OpenGuides-Dev June 2004