Hey tagging@ Wearing my “maintainer of iD” hat today, I feel like it’s important to comment on this.
I agree it would be great to be able to build a dataset of legal defaults which can be used by routers and editors in interesting ways. This is a thing that comes up for discussion frequently. I commented here: https://github.com/osmlab/osm-planning/issues/5#issuecomment-371471072 <https://github.com/osmlab/osm-planning/issues/5#issuecomment-371471072> about the possibility of building a special index for these things. We could use this for defaults for turn restrictions, max speed, etc. However.. Any solution for encoding defaults should not depend on fully downloading relations to work. Just as a test, I fully downloaded the boundary of Germany https://api.openstreetmap.org/api/0.6/relation/51477/full <https://api.openstreetmap.org/api/0.6/relation/51477/full> On my connection, that call downloads about 27MB of xml and takes about 58sec to run. I think people do not realize how difficult it is for us who write software to work with huge relations. I can’t just pause whatever the user is doing for a minute to download the boundary of Germany in order to decide whether the user is currently editing in a spot that allows u-turns or not. Even if I were to do the downloading in a background thread, it means that there are things a user can’t do for several minutes, as we background download information about whatever relations the user is inside of. An editor like iD always has an incomplete picture of the world. So, some ideas that would work: - precompute this information into an index that we bundle with iD (similar to our imagery and community indexes) - fetch this info from a fast API (e.g. if local defaults were something Nominatim could return, that would be ok) Thanks for listening! Bryan > On Apr 6, 2018, at 4:03 AM, <osm.tagg...@thorsten.engler.id.au> > <osm.tagg...@thorsten.engler.id.au> wrote: > > Yes, that's from > https://wiki.openstreetmap.org/wiki/Proposed_features/Defaults which André > Pirard linked to just recently here. > > Personally, I'm not a huge fan of the syntax. I would prefer the use of > sub-relations. > > You would then have a type=defaults relation, with apply_to members that > specify the areas where the rules apply and match:(condition) members that > refer to type=default relations which can simply contain a set of plain > key=value tags (and don't need to have any members, they are just containers > for tags). > > If the same bunch of default values applies to different things with > different matching rules, you can just refer to the same sub-relation > multiple times. > > One issue with all this is that while you can encode a lot of useful > information this way, it doesn't help cases like the "it's not legal by > default to make u-turns at signal controlled intersections" in Queensland. As > such things can not be expressed with just a tag or two as default values on > existing objects. They require specific coded support in router engines. > > For that I would suggest something like > > rule:no_u_turn_at_signals=yes on the defaults relation, and the router > engines need to know what these mean then. > > Cheers, > Thorsten > >> -----Original Message----- >> From: Frederik Ramm <frede...@remote.org> >> Sent: Friday, 6 April 2018 16:39 >> To: tagging@openstreetmap.org >> Subject: Re: [Tagging] no_u_turn restrictions for every entry/exit >> into a roundabout when the way is split because of physical >> separation? >> >> Hi, >> >> On 04/06/2018 05:26 AM, osm.tagg...@thorsten.engler.id.au wrote: >>> Putting information about the legal default into OSM is not the >> problem. >>> It’s just that nobody has developed a schema for it yet. >> >> The French have invented something: Check the "Part of..." listing >> here >> >> https://www.openstreetmap.org/relation/11980 >> >> It seems that a couple more of these exist, e.g. >> >> https://www.openstreetmap.org/relation/1124248 >> >> I don't know if anyone actually uses them. >> >> Bye >> Frederik >> >> -- >> Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" >> E008°23'33" >> >> _______________________________________________ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging > > > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
