-----Original Message----- From: openguides-dev-bounces@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.
openguides-dev@lists.openguides.org