[OSM-talk] Classifying Ways worldwide (was: Numbers and i18n)

Thu Aug 3 10:38:12 BST 2006

On 8/3/06, Collinson Mike <mike at ayeltd.biz> wrote:
>
>  I've been a passive member of OSM for over a year now and feel that over
> the last few weeks it has moved from being a purely experimental UK-centric
> system to being a (the!) working worldwide repository of open source street
> map data and of collaborative standards.  I've therefore spent a few days to
> add all my accumulated collection.  On that experience, I feel the one big
> difficulty I still have as a beginner is how to systematically describe the
> Ways that I make in terms that can be easily used by other members to make
> maps, navigation systems and hopefully to show more information on the
> www.openstreet.org main page map itself.
>
> I'm therefore very interested in a suggestion made by Wollschaf  a couple
> of days ago and feel it is very elegant, so add some arguments in favour of
> it.  It solves a number of problems for me mapping outside the UK and is
> flexible enough to create a set of "starter" tag values for beginner's to
> use and still be useful for complex situations and new uses.
>
> The essence of what Wollschaf said (below) was: use two tags, one for the
> administrative classification and one for the physical:
>
> waytype=A (2 lanes+ 1 breakdown lane on a motorway, or very wide road)
> waytype=F (1 lane, wide enough for a car)
>

One problem with the waytype categorisation is that it tries to encode
several physical attributes into one value.  It seems to combine the
physical width and the number of lanes into one subjective key.

The number of marked and usable lanes is often quite distict from the
physical width of the road.  The presence of a breakdown lane is unrelated
to the width or any other characteristic of the road.

If we are seeking a purely physical description of the roads then shouldn't
there be a separate key for each aspect of the road.  The following would
describe one carriageway of a motorway:
lanes=3
width=18m
breakdown_lane=yes
oneway=yes

And this would describe a Sydney lane:
lane=1
width=3m

One problem with this is that there is no easy way to accurately measure the
width of a road with a GPS unit.  Maybe the width attribute should allow
units other than metres (1 car, 2 trucks, 1 person), or approximate values
0-5m, 5-10m, or even comparative values: very narrow, narrow, normal, wide,
very wide.

wayclass=uk:primary
> wayclass=uk:motorway
> wayclass=de:autobahn
> wayclass=de:bundesstrasse
> wayclass=au:stateroute_a (Single carriageway interstate or interregional
> primary highways)
> wayclass=au:expressway
>
> and I'd add a "global" generic wayclass value set that should be as small
> as possible and non-overlapping but allowing personal common-sense
> judgement:
>
> wayclass=expressway or 1 (typically dual carriageway freeway with use
> restrictions)
> wayclass=primary or 2 (typically arterial and/or heavily used sealed dual
> or single carriage way used by long distance traffic or major cross-town
> traffic within cities)
> wayclass=secondary or 3 (typically reasonably good quality single carriage
> way roads [sealed or unsealed according to local custom] linking smaller
> towns, moderate traffic)
> wayclass=minor or 4 (local use only, ordinarily little traffic)
> wayclass=access or 5 (generally short access roads to/in residential
> areas, industrial estates, commercial forests, fire trails, tourist
> features, expressway service centres etc)
>

If a small or undeveloped country does not have a road classification scheme
why should we presume to impose one.  If some small Carribean island has not
created any kind of administrative classification of their roads then I
don't think we should do it arbitrarily.  The physical scheme should be used
in this case.

IMHO, each set of adminstrative classifications should be mapped exactly and
precisely to the administration of the country they belong to.  I realise
that this could be below country level in some cases.  Road classifications
in New South Wales might not be the same as  Western Australia, so you might
need to have au.nsw:highway=lane, but this might have a different meaning to
au.wa:highway=lane.

Why I like it:
>
> (1) *Not everywhere has a classification system.*  I'm mapping in the
> Philippines which has no publicly visible road classification system at all
> that I'm aware of.  Using the current system means that I'm assigning
> 'highway=' classifications based purely on personal judgement and whim.  I
> think that is the most powerful argument for having both tags.
>

Physical classification is the way to go here.  It would be misleading to
attribute highway=primary if the Phillipines administration does not have
such a classification.

(2) *Administrative classification systems vary*. I'm also mapping in
> Australia which has a relatively complex administrative classification of
> National Routes, Metroads, State Highways M, A, B, C, D, Tourist Drives with
> State variations, ( http://en.wikipedia.org/wiki/Australian_highways).
> Mapping the current 'highway='  values is possible but only approximate and
> may differ from person to person.  The current system needs
> internationalising.
>

There should be an  administrative classification scheme for each
administrative region, whether that is a federation, a state, a territory,
an island or whatever the relevant unit of administration.  The use of
namespaces would help to manage these.

(3) *Being accurate and informative with the data available.*  I wonder if
> I'm not alone in not scrupulously recording the administrative
> classification of a road? Indeed it may not be displayed on road signs?  At
> the moment I have to guess or leave 50km+ lengths of road with no clue to
> map makers about how to display it.  With a 'waytype' parameter I can easily
> remember the width of road and assign accordingly.  Therefore a useful
> descriptor can always be captured.
>

Renderers need to colour the roads using the adminstrative classification
first, but fall back to the physical attributes for roads without one.

(4) *Beginners.*  It has taken me a year to be confident about entering Ways
> that might be meaningful to map makers, thanks to
> http://wiki.openstreetmap.org/index.php/Map_Features - but I still scratch
> my head in many situations.  I'm still rather at sea when it come to
> practicality for navigation software.  With the proposed system, I think it
> would be very easy to instruct a beginner:
>         - Enter nodes, join them up as segments and mark one-way segments,
>
>         - then map your road names over the top as Ways,
>         - enter the 'name' of your Way and what 'waytype' you observed it
> as being,
>         - *If* you know the classification, add the 'wayclass' too.
>         - If you want to go further, refer to xxxxx.
> Easy!  A low entry barrier and will result in data that can be displayed
> in a meaningful way.
>

We need to make it easy - there is a lot of mapping to do...

(5) * Type and class can complement each other for display and navigation
> purposes.  *As an example, Sydney has lots of alleys - very narrow
> metalled through tracks often providing access to the rear of buildings
> which are clearly worth flagging to route navigation software as something
> worth avoiding and missing out or de-emphasizing on map displays.  Using the
> current 'highway=' classification, I feel I can only mark them as ''minor',
> 'unclassified' or 'residential'.  Unfortunately I have exactly the same
> choice for the nice wide residential streets around about.  So, either I
> invent a new 'alley' classification that may not be understood in all
> cultures or I simply mark it as 'residential' with a 'waytype' to show it as
> very narrow.
>

Sydney's lanes are distinct and very characteristic of that city.  If they
are a recognised road category in Australia or NSW or Sydney then I would
suggest au:highway=lane (or au.nsw:highway=lane or au.nsw.syd:highway=lane).
If not then a physical classification would be more appropriate (lanes=1,
width=3m).

(6) *Elegant. *Using 'waytype' and 'wayclass'  seems very elegant and simple
> to me.  Self-obvious and obviously relates to the usual parent Way.   It
> gets rid of the UK-centric 'highway' definition. I am British but it has no
> or different meaning outside that country and pedantically not really within
> it, (what about "Byways"?).
>
> (7) *Easily backwards compatible. * Take 'highway' key, rename it
> 'wayclass' and either put 'uk:' in front of the current tag values or
> convert them to a smaller global set.
>
> *Variations
>
> *One alternative mentioned using numbers could also be combined:
>
> wayclass=1
>
> where 1:
> uk:motorway
> de:autobahn
> etc
>
> I think this has merit from an internationalisation point of view (map
> making software won't have to have built in tables of all the international
> variations) but may be dangerous when there are mismatches between
> countries.  I can't think of a good example - perhaps there are none - but
> as  a thought experiment would a UK motorway be mapped to a US Interstate
> Freeway or to a State Freeway?
>
> *Drawbacks?
>
> *The only potential drawback I can see so far is to the 'wayclass' in that
> in some countries, roads can have more than one administrative
> classification.  In the US, as I recall, roads can have both Interstate and
> State designations That problem though may be more for the 'ref' tag to sort
> out, the 'wayclass' would just take the more important one as a single
> value.
>
> Mike
>
>
> At 09:56 PM 31/07/2006, Wollschaf wrote:
>
> On Mon, 31 Jul 2006 11:50:44 +0100, Etienne wrote:
>
>
> > I think in this context (Street Maps) we should really be considering
> > administrative classifications.  OSM can accommodate physical
> > characteristics but that, to me, seems secondary for the most common
> kind
> > of uses of OSM data.
>
> In my opinion it is important to have both. Route planning software can
> make better decisions if the physical properties are known. Looking at
> maps.google.com (teledata maps) in my area, there are so many roads
> rendered as if you could actually drive on them. In reality, you can't -
> one car coming from the other direction and both are terribly stuck. Using
> my route planning software, I've been sent through vineyards several
> times. Usually, bigger roads were nearby that obviously were classified
> the same way, perhaps as minor. Currently, I can't do better in OSM.
>
> What should I tag a secondary road with that's several times bigger and
> faster to drive on than the primary road nearby, thus clearly being the
> preferred way to travel?
>
> I think we need two sets of tags: one for physical properties and one for
> the administrative classification, based on a scheme for every country.
> This way everything can be tagged. Not every country is as ordered as we
> are used to. I have severe trouble to fit the current highway values to
> the roads I created in Sardinia, Italy. A lot of interpretation is needed
> to fit the tags to the roads, and by reading a map created out of the
> guesswork misunderstandings will occur.
>
> To make OSM better than commercial map suppliers, we need as much metadata
> as we can get. Physical road properties will definitely improve the maps.
>
> Examples for a separated way classification:
>
> waytype=A (2 lanes+ 1 breakdown lane on a motorway, or very wide road)
> waytype=F (1 lane, wide enough for a car)
> wayclass=uk:primary
> wayclass=uk:motorway
> wayclass=de:autobahn
> wayclass=de:bundesstrasse
>
> Administrative classification could then also be used to set permissions
> and speed limits, which is currently not possible because of the diversity
> of rules in different countries.
>
> Perhaps the tag values should be all in english, to improve readability. I
> would not want to write software using all these tags without
> understanding the language behind. The tag value names are not as
> important as the correlation... numbers are sufficient, but hard to
> remember.
>
> Wollschaf
>
> **wondering now about highway=us:highway, and why whether just to remove
> the high in way to make more sense. We're just dealing with ways, aren't
> we?
>
>
>
>
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
>  http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20060803/57e66e8a/attachment.html>