search

westnordost / osm-legal-default-speeds

Infer default legal speed limits from OpenStreetMap tags
https://westnordost.github.io/osm-legal-default-speeds
BSD 3-Clause "New" or "Revised" License
21 stars 8 forks source link

support for maxspeed:forward & backward #6

Closed karussell closed 1 year ago

karussell commented 1 year ago

Should the library support this tagging?

A tagging like maxspeed:forward=80 could be recognized and returned as maxspeed=80 or the tag could be just copied into the output (and maxspeed should be avoided).

If it is not supported then a consumer might get the wrong maxspeed I think. (but maybe I'm using it wrong - let me know :) )

westnordost commented 1 year ago

The output only contains what the input doesn't.

When maxspeed:forward is defined, then it is likely that maxspeed:backward is defined too, with a different value... so, not sure how to handle this... maybe it should not be handled at all, because:

Probably, what a data user would want is to make two queries then: One for forward, one for backward, no? (And then postfix every returned key with :forward and :backward, respectively)

karussell commented 1 year ago

When maxspeed:forward is defined, then it is likely that maxspeed:backward is defined too, with a different value... so, not sure how to handle this... maybe it should not be handled at all

Currently a default maxspeed tag is returned in this case which is should be avoided or documented, I think.

Probably, what a data user would want is to make two queries then: One for forward, one for backward, no? (And then postfix every returned key with :forward and :backward, respectively)

Really depends on how you define the scope of this library :) ... so if it should "complete" the input OSM tags then I would assume that only a single query is sufficient and there would be two cases to be handled:

  1. if forward and backward is given -> copy them to the output (but do not return a maxspeed tag)
  2. if forward or backward only -> copy this tag and add a default max speed for the other direction (also do not return a maxspeed tag)

Or again, documenting this "limitation" would be fine for me too :)

westnordost commented 1 year ago

Hmm, the scope of this library is to be a reference implementation of interpreting the JSON generated from that wiki page... I guess one could say that the "find road category by maxspeed" is already slightly out of scope... on the other hand, so much more maxspeed is tagged than source:maxspeed (et al), so to have this as a fallback seems kind of useful.

For maxspeed:forward and :backward and all the other specific maxspeed things like maxspeeds on certain hours etc., there are no country-specific rules. I.e. there is no country that specifies special rules for when the maxspeed is X in one direction and Y in the other. Insofar, I would say that that interpreting these is definitely out of scope. For users, it is also somewhat trivial to achieve this functionality themselves.

(Hmm, ...)

There is another rather gaping hole in terms of functionality that is not really in scope but would be kind of useful, but it would already involve quite a bit of guessing: What if the maxspeed does not fit one specific road category, but falls in-between two. E.g. maxspeed=70 in a country where there is a definition for urban = 60 km/h, rural = 80 km/h. Common-sense-wise, one should probably fall back to rural in that case and apply any additional restrictions of that category (e.g. if on rural, hazmat may only go 50 km/h).

Anyway, I am on vacation now so I may not answer here in the next time.

westnordost commented 1 year ago

So, I will close this one. After all, forward and backward may match (by speed) to different speed limits, which means that the interface would need to be changed to include a certitude: Certitude and a roadTypeName: String?for all of forward, backward and general. Better if the user of the library calls this himself, if he really thinks this is a good idea.