search

osmandapp / OsmAnd

OsmAnd
https://osmand.net
Other
4.64k stars 1.01k forks source link

Routing: Add support for maxspeed:type=* #13066

Open Neuwessi11 opened 2 years ago

Neuwessi11 commented 2 years ago

Probably because of the implementation in StreetComplete, there are a quite high number of streets tagged with maxspeed:type=*, but OsmAnd does not recognize.

I think it would be great if OsmAnd would support this tagging, because up to now there are already a lot of streets tagged like that, and will in future become more and more, because of StreetComplete and because it is a very useful tagging scheme.

starsep commented 1 year ago

I think it could be implemented in map generation step. There is https://github.com/westnordost/osm-legal-default-speeds library implemented in Kotlin which allows that. Example: https://westnordost.github.io/osm-legal-default-speeds/#tags=maxspeed%3Atype%3DPL%3Aurban%0A&cc=PL

If this approach makes sense I could try implementing it. Please point me in the right direction.

mnalis commented 1 year ago

I think it would better be on device instead of on map-generation. Given immense number of street segments, majority of which uses implied speed limits, it would hugely bloat the map if it were done in map generation step. E.g. every segment of highway=motorway in Italy would have to have this block of tags added:

maxspeed=130
maxspeed:bus:conditional=100 @ (weightrating>8); 80 @ (articulated)
maxspeed:conditional=110 @ (wet); 100 @ (weightrating>3.5); 100 @ (weightrating>12)
maxspeed:hazmat=50
maxspeed:hgv=100
maxspeed:hgv:conditional=80 @ (weightrating>12); 80 @ (trailer); 80 @ (articulated)
maxspeed:truck_bus:conditional=80 @ (weightrating>5)

Repeating it for every road is not a good idea. Much better would be if OsmAnd itself would download that speedlimits database (perhaps along with other downloads like global world map etc, for easy updating?) and then translate maxspeed:type with help of that database to actual speed limit for current vehicle type. (and hey, with weather plugin, it might even parse wet maxspeed conditionals!)

That would avoid needlessly wasting space (and map download sizez), and would not be much more complicated to implement.

vshcherb commented 1 year ago

Good point @mnalis though still technically these tags needs to be added during map generation, parsing these values won't be possible for routing to get anywhere fast enough. Though adding these tags anyway will make routing slower

Except all conditional should be replaced with "artificial" profiles cause conditional are evaluated only at client side

maxspeed:bus_8=100 
maxspeed:bus_articulated=80
maxspeed:hazmat=50
maxspeed:hgv=100
...
mnalis commented 1 year ago

though still technically these tags needs to be added during map generation

Wouldn't that make map downloads (and storage) significantly larger? (e.g. road-only maps would easily increase by 200%-500% ?). If so, that would IMHO be a deal-breaker.

parsing these values won't be possible for routing to get anywhere fast enough

You'll know better of course! I have no idea what are the current speed bottlenecks in OsmAnd routing are, and how much of that is due to current speed limits parsing (I'm guessing at least highway=* and maxspeed=*?) and thus by how much would additional code there slow it down. But unless "fastest" routing is checked, it should not make a difference, right? (e.g. for "shortest" route probably speed limits are not consulted anyway?)

It could always be used at least for speeding warnings with (I guess) no slowness issues there at least?

To clarify, I envisioned it might look like this:

So currently I guess that OsmAnd code for speed warning looks something like this (pseudocode):

if (current_road_tag["maxspeed"] != null && current_vehicle_speed > current_road_tag["maxspeed"]) 
  then warn_user_about_speed_limit();`

with the above idea implemented, it would look like this:

if (
   (current_road_tag["maxspeed"] != null && current_vehicle_speed > current_road_tag["maxspeed"]) ||
   (current_road_tag["maxspeed:type"] != null && current_vehicle_speed > current_speed_database[current_road_tag["maxspeed"]]) 
   )
   then warn_user_about_speed_limit();`
vshcherb commented 1 year ago

We use A algorithm so tag processing time is very important (without A it is not possible anyway cause it requires 3-5 times more map data for each routing profile).

Here getting data bigger (obviously with tags zipping and compacting) is the only choice, how much data increase will be needs to be tested obviously.

aceman444 commented 5 months ago

Hi, If you mean roads are tagged with maxspeed:type only and no 'maxspeed', then that is wrong according to current wiki. A bug should be filed against StreetComplete. I am not against OsmAnd having per-country database of maxspeeds (and many other parameters), which I have proposed many times. But the report here is not a valid argument for it, when there is invalid data in OSM.

mnalis commented 5 months ago

Hi, If you mean roads are tagged with maxspeed:type only and no 'maxspeed', then that is wrong according to current wiki.

I don't see where you got that idea. Even the first paragraph of that wiki page clearly states "[...] data-consumer-side parsing of actual speed limits is preferred by some (in cases where exact value of km/h or mph is not explicitly signed)." which is talking exactly about that: tagging maxspeed:type without maxspeed.

Also note that wiki is descriptive (i.e. it documents how things are being done), and not prescriptive (i.e. it is not a law, as OSM is based on ATYL). In other words, when wiki and reality disagree, it is the wiki that should be updated to match the reality.

The fact is that always some people will prefer one tagging scheme, and other people other tagging scheme. That of course makes life more complicated for data consumers (who need to support multiple tagging schemas if they want to have the best coverage), but is also a biggest single reason why OSM thrives.

As a random usage example: for e.g. maxspeed:type=DE:urban, out of 84k values, only some 37k have also maxspeed tagged (i.e. less than 45%). Other countries have different number, for example in my HR only about 21% of roads tagged with maxspeed:type also have maxspeed.

In some other country it might be reverse of course - statistics in any case does not care what you or I might prefer to be our ideal utopia, it just says what the situation currently is .

Of course, OsmAnd could decide to just ignore maxspeed:type and go with only maxspeed - but that would be throwing out ~79% of the urban maxspeed data in Croatia, which would likely make it less popular here. Or they could implement both which would make it better everywhere, but that requires more effort, which they could've used to solve some other issues, which might be bringing more paying users. Its a balancing act...

A bug should be filed against StreetComplete.

Why? Because you happen to prefer different tagging schema then they? I'm not sure that it would be a good enough reason, but if you do decide to go that way, I'd advise you to please first read all closed issues containing "maxspeed" in that issue tracker, as that has been discussed several times already (so please only do that if you can bring new information to the table, in order to not waste yours and everyone else's time).

But the report here is not a valid argument for it, when there is invalid data in OSM.

But having only maxspeed:type tagged without maxspeed is not "invalid". It is simply different preference then yours.

Anyway, I don't have a horse in that race really (I simply try to give bits of information I'm familiar with, so people in charge here can make better informed decisions of their own), but one of the advantages of using maxspeed:type=HR:urban without also specifying maxspeed=60 are (supposedly, among others):

Of course tagging maxspeed has its advantages too; mainly that it is significantly easier to parse for data consumers who then wouldn't need to worry about default speed limits. But that does not come for free, but by shifting that burden to mappers. I'd prefer data consumers to carry that burden, for all the reasons above, but also because there are much less of them, so it is way more efficient.

aceman444 commented 5 months ago

You are right there, but if the data and wiki disagree, you actually don't know how people use the tag as it is not documented anywhere. Then you do not know what the tag means and you cannot start to use it in any application.

At for why I say maxspeed:type should be accompanied by maxspeed, it is said directly in the first line of https://wiki.openstreetmap.org/wiki/Key:maxspeed:type . Yes, you quote the other part of that paragraph. But that is kind unclear what it means. 'data-consumer-side parsing of 'actual speed limits 'is preferred by some' - parsing from where and how based on maxspeed:type? Yes, I guess I understand what it means, but the wiki is not explicit about it (that consumers need to know all the maxspeed types for each country).

The tag is supposed to mean 'how the maxspeed value was set into force' on a particular road. It does not seem to be meant to imply what the actual value is.

mnalis commented 5 months ago

But that is kind unclear what it means. 'data-consumer-side parsing of 'actual speed limits 'is preferred by some'

I've tried to clarify on the wiki, feel free to further improve if still unclear (English is not my native language :man_shrugging: ).

  • parsing from where and how based on maxspeed:type?

The tag is supposed to mean 'how the maxspeed value was set into force' on a particular road. It does not seem to be meant to imply what the actual value is.

Actually, it does? At least to my knowledge that seems to be one of the main motivations for moving to maxspeed:type from source:maxspeed ?

It seems to me that you look only from personal-car perspective, where _"oh well it is just one extra tag maxspeed=60mph, not much work to add to that maxspeed:type=GB:nsl_single"_.

But the reality is not such that you'd need to add maxspeed=60mph - to be actually correct with explicit tagging, you would need to add:

maxspeed=60 mph
maxspeed:bus=50 mph
maxspeed:conditional=50 mph @ (trailer); 20 mph @ (trailers>=2)
maxspeed:hgv=50 mph
maxspeed:motorhome:conditional=50 mph @ (emptyweight>3.05)

to every single one of them (don't know about you, but I certainly don't know all of them by heart even for my own country, so would have to keep it in some kind of custom presets or whatever). And then track the law & keep them in sync every time the law changes.

or, we can let OsmAnd (and other routers) implement parsing of maxspeed:type, let mappers tag only that (unless there is explicit maxspeed:type=sign where we obviously must add maxspeed=* for it to make sense), and save millions of mappers a huge amount of work, while being more precise at the same time.

As the saying goes, "The needs of the many outweigh the needs of the few" :smile_cat:

aceman444 commented 5 months ago

It would be great if it worked like you say :) It would save many duplications of tags on many roads. But we first need to get into such a state before we remove explicit 'maxspeed' on roads. OsmAnd developers so far refuse maintain their internal per-country tables of default speeds, access restrictions, maxheights, etc. But OsmAnd developers may not need to maintain those tables alone. If there was better support for 'defaults' relation (https://wiki.openstreetmap.org/wiki/Proposal:Defaults) in OSM, those speed tables could be actually maintained by OSM mappers, not app developers. OsmAnd would just pull defaults from those relations.

mnalis commented 5 months ago

But we first need to get into such a state before we remove explicit 'maxspeed' on roads

I don't advocate for removing existing tags (that is bound to make people who put them there annoyed). When they tag new roads (or when on-the-ground updating old ones), sure, I'd recommend that people use the easier and more correct one for their new tagging... If at some moment it becomes overwhelmingly more popular method od tagging (I'm thinking like 98% of the uses at the least), then someone might want to take on mechanical edits to remove them, fine. But not anywhere near now...

Anyway, regarding OsmAnd I'm just saying that both tagging schemas exists in popular use, so one should support both for best results.

OsmAnd developers so far refuse maintain their internal per-country tables of default speeds

Seems like a sensible choice :smile:

But there is already such maintained database of default speeds at https://westnordost.github.io/osm-legal-default-speeds/ - so OsmAnd doesn't need to invent nor maintain their own. Just find a way to use existing one (but that also requires some work, I know).

If there was better support for 'defaults' relation (https://wiki.openstreetmap.org/wiki/Proposal:Defaults) in OSM, those speed tables could be actually maintained by OSM mappers, not app developers. OsmAnd would just pull defaults from those relations.

Sure. Although that "OsmAnd would just pull" is also likely to be big amount of work (not just by data consumers, but by mappers too - relations inside relations inside relations etc are prone to breaking; which is why I suspect that proposal haven't been hugely popular although the idea of keeping it all in the same OSM database is nice). Anyway I prefer to leave evaluation of what-if situations to Randall :smiley_cat:

aceman444 commented 5 months ago

That default speeds database is nice. And the source is at https://wiki.openstreetmap.org/wiki/Default_speed_limits .