Revised parsed Schema

[westnordost]

This PR is based on the branch osm-default-speeds, which could be merged to master in my opinion.

This PR includes:

• added ability to parse "current weight"
• fixed an issue when parsing filters such as "ref~^I and highway~^motorway|motorway_link$" (resulted in ref~^Iandhighway~^motorway|motorway_link$ prior to the fix)
• revised final output schema, see below

The output schema is now

{
 "speed_limits": {
  "US-WA": [
   {
    "name": "",
    "tags": {
     "maxspeed": "50 mph"
    }
   },
   {
    "name": "Washington state highway",
    "filter": "ref~^WA",
    "tags": {
     "maxspeed": "60 mph",
     "maxspeed:conditional": "60 mph @ (weightrating>4.536); 60 mph @ (trailer); 60 mph @ (caravan); 60 mph @ (articulated)",
     "maxspeed:tricycle": "30 mph"
    },
    //...
   }
  ],
  //...
 },
 "warnings": [
  //...
 ]
}

Reasons:

1. it is not helpful to have the road names/filters as a key in a map. They are not accessed by key.

2. the order of the speed limits has an important and semantic meaning, so the order from the table must not be changed:

   The blank road type is the default road type that applies if no other road type applies, usually, but not always the standard "rural road". The rules that define road types (see second table, #Translating road types to tags) don't all have to be mutually exclusive, the tags on a road may match with several road types. In this case, the following algorithm is used to determine the road type: If the tags match with a road type specified in a row above the default (blank) one, the road type that specifies the lowest speed limit applies. Otherwise, if the tags match with a road type specified below the default one, the road type with the highest speed limit applies.

3. we can not realistically assume that we have a (community approved) mapping of tags to road categories for all the roads in all the countries (initially). So let's have a data structure that accomodates for incomplete metadata. In the above data structure, a road category can have a name and optionally a filter. Of course a filter is necessary to actually do anything with the data OSM-wise, but it might not always be available

4. I think it is better if we bake all the maxspeed data into OSM tags (maxspeed:goods=...) instead of group them by category:

   1. I don't reckon a common use case where it makes sense to categorize the speed limits by vehicle type ("goods": { ... }, "hgv": { ... }).

   2. A router using OSM data will need to parse the full maxspeed schema anyway, so it is no extra effort to interpret data in that form while it might be extra effort in the current form.

   3. Current schema is a source of error (based on misinterpretation), because one might assume that if I drive a hgv, only the rules specified under the "hgv" key apply to me. This is not the case because the rules for "goods" if any apply to me as well, plus also each the default rules IF the unconditional maxspeed is not overwritten:

      Note that unconditional speed limits are only overwritten by an unconditional speed limit while an unconditional one also overwrites conditional speed limits (see the example and compare it with the table).

5. There should be a way to output warnings / errors without completely exiting the parsing. So I thought the warnigs and errors could be included in the output json. Maybe there is a better method though. (Output warnings on the console while requiring the "real" output to be a filename?)

[pep8speaks]

Hello @westnordost! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

There are currently no PEP 8 issues detected in this Pull Request. Cheers! 🍻

Comment last updated at 2021-04-03 14:10:50 UTC

[westnordost]

I changed it now so that the real output is written to a file and the warnings show up on the console

[westnordost]

ping