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