Discuss "Notes from discussion about 'How location, mapping, and geo stuff' would be if it were done properly from scratch

Discuss this wiki page titled Notes from discussion about 'How location, mapping, and geo stuff' would be if it were done properly from scratch

Pulled form wiki page:

raintonr: Actually, I have created a module (implementing a CCK type) that at the moment is storing sets of points entered in "a1,b1,...n1 a2,b2,...n2" sets. Each point must hold at least a relative distance from start. Altitude, latitude/Longitude and userdata are optional. Lat/lon are strangely optional, but did this for people who have a cycle computer for instance that only records distance and altitude - they can still use the CCK field to store and plot this data. I have the idea that userdata can be things like speed, heart rate, cadence, time, etc, etc. At the moment there is a formatter to plot distance/altitude graphs. It can normalise data to show multiple fields/nodes on the same graph if required. Adding userdata to the graphing capability is high on the list. No map is shown at the moment, although a KML export (see below) will make inclusion of Google Map trivial.

There will be a second field type that will store derived statistics from the first. Things like total distance, max speed, average gradient, etc. Such stats have to be in separate fields to be used in views (well - to use in view and avoid too many formatters anyhow).

I didn't see the need to have something to store single points - users can enter nodes at specific locations using current location functionality of course.

With the above, the KML module can be extended to include paths entered into this type of field.

I planned to have KML/GPX/CRS/HST (CRS & HST are Garmin course/history exports) import at some point (at the moment am creating the arbitrary sets of numbers required with a perl script). Other functionality that is here now though, is the ability to extract data sets from existing fields and have created a graphical JavaScript pop up for this. This allows trimming of a current node. Joining/cutting/adding from/into nodes could also be done with a similar tool without too much bother.

How this can be used is: when a user wants sets of points in a path though they can create a node type using the above CCK fields. As many derived fields as are required can be added. In fact, maybe the derivation module should have hooks so that it can be extended. Ie, someone stores userdata set of 'foo' they create a module that knows how to average 'foo' and how to work out some other stat based on 'foo' and distance.

Your idea of using WKT is interesting, but it seems to go beyond what we are looking for. For example, to just draw a graph of distance/altitude. WKT seems to be able to input many points and paths in a single field (or node) so in that case how could you relate these?

Sorry for the long edit, good ideas. I hope to have my code ready for general consumption and a demo very soon.

Grugnog: not sure if these should really each be separate projects - there are a LOT of countries in the world, and a lot of sites really want anyone in the world to be able to enter an address! Is there not a more lightweight setup that could be used (e.g. .inc files)?