Another idea: This would probably be best thought-of as a feature for API 0.8, but basically the idea is to "fix" the current sloppy formatting of the database tags that contain measurements. This would include "maxspeed=", "maxheight=" and "maxwidth=" but there are weight limits too, and "est_width=" and other such tags.
The "problem" with 0.7 and earlier is that the data in these fields is free-form and this doesn't suit the needs of autorouters. The U.S users and a lot of U.K. users are inputting these values in imperial units, everyone else is doing it in metric units. Autorouters need to work in some consistent system and are currently having to parse out the freeform data. That's not too difficult for metric, but (say) a height limit in imperial may be stored as <<11' 6">> or <<11ft 6>> or <<11ft, 6in>> or <<11.5ft>> or.... you name it! And human users of editing programs might like to work in imperial-only (and see values that were entered in metric be converted for them) or metric-only (and see values that were entered in imperial be converted for them) or have it displayed the way it was entered. I suggest that API 0.8 would specify that any values in the database be stored in some appropriate canonical form, with a flag to say if it is naturally imperial or naturally metric. So heights and widths would be stored (say) in integer millimetres or integer inches with a one-bit flag to say which it is, and speed limits would be stored in integer km/h or integer mph with a one-bit flag to say which it is. The API call to obtain these values would have a parameter to say whether the user wants metric, imperial or "how-it-was-specified". ( The reason for the one-bit flags is to avoid converting data when it needn't be. Autorouters will certainly want to work in a single given system and won't mind if a speed limit is 48.27kph, but humans would probably rather see that one displayed as 30mph - even if they are French! Likewise human U.K users would probably want to see a French speed limit shown as 50km/h not 31.0752mph. ) The GSoC project would need to deal with writing a robot that could go through all the existing data, parse the extensive list of inventive abuses of the free-format data(!) and rewrite it in this canonical form. The project would also create this new API call to return the data of course. Presumably it would present data in human-readable form according to the "how I want to see it" parameter. Steve. _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
