On 8/3/06, <b class="gmail_sendername">Laurence Penney</b> <<a href="mailto:lorp@lorp.org">lorp@lorp.org</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Wollschaf and Mike Collinson makes some good points on separating physical<br>descriptions and administrative classes, but I agree with Etienne that the<br>physical descriptions need to be further split up. (Terminology is also

<br>problematic: 'waytype' and 'wayclass' are way too close!)<br><br>We need shorthand methods of referring to whole physical descriptions of ways,<br>and defining them would ideally be possible within apps. Neighbourhoods often

have many similar streets. E.g. once you'd set up a "typical Manhattan street" (width=2 trucks, parking=both, pavement=both, pavement_width=5 people), then you could use that for all streets that matched the initial physical definition.

<br><br>I am in favour of human and vehicular units of measurement. We'll get fewer<br>errors that way IMO (although perhaps North Americans will use "1 car" to mean 4<br>or even 5m, considering how difficult they find driving in Europe...). Width in

metres might be added automatically: (width_derived=5.3m)</blockquote><div> To me, width=3m  implies an accuracy of +/-1m.  Since our GPS surveying methods do not measure the width of anything to that kind of accuracy we could be in danger of creating data that is open to misinterpretation.

By all means have a width tag in metres, but only use it for cases where the width has actually been measured to at least +/-1m accuracy.  For other cases approximate_width=3m or subjective_width=narrow seems to me to be a better record what we are able to observe.

<br> <br>Etienne<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">-- Laurence<br><br>Joerg Ostertag (OSM Munich/Germany) wrote:

<br>> ...<br>><br>>> If we are seeking a purely physical description of the roads then shouldn't<br>>> there be a separate key for each aspect of the road.  The following would<br>>> describe one carriageway of a motorway:

<br>>> lanes=3<br>>> width=18m<br>>> breakdown_lane=yes<br>>> oneway=yes<br>>><br>>> And this would describe a Sydney lane:<br>>> lane=1<br>>> width=3m<br>>><br>>> One problem with this is that there is no easy way to accurately measure

<br>>> the width of a road with a GPS unit.  Maybe the width attribute should<br>>> allow units other than metres (1 car, 2 trucks, 1 person), or approximate<br>>> values 0-5m, 5-10m, or even comparative values: very narrow, narrow,

<br>>> normal, wide, very wide.<br>><br>> I would restrict the field to meters. Since this way we have a chance of<br>> making use of it in automatic processing.<br>> And give the user some hints to enter data:

<br>>  1m   for bikes and Foot only ;-)<br>>  3m   one car(narrow)<br>>  3,5m one car easily<br>>  4    one truck<br>>  7m   two cars narrow<br>>  ...<br>><br>> -<br>> Joerg<br>><br>> _______________________________________________

<br>> talk mailing list<br>> <a href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br>> <a href="http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk">http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

</a><br><br><br><br>_______________________________________________<br>talk mailing list<br><a href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br><a href="http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk">

http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk</a><br></blockquote></div><br>