I'd like to second Tod's point that defaults are difficult when they depend on regional variation. When a tag's default has significant geographical variation, one has to have corresponding regional geodata to figure out what value to use - shouldn't that geodata be in OSM?
Perhaps a compromise would be to place defaults that vary by region on an administrative boundary. This way, the default can be explicit without needing to be on every single road. It is also how these default limits are defined: unless otherwise marked, all roads (perhaps of a certain class) in this administrative region have X speed limit. To figure out the default, you'd need to get (potentially large) admin boundaries and do point-in-polygon queries. But then again, this is what you would have to do if this data weren't in OSM, using multiple external datasets. I also don't know the best way to establish a hierarchy for *which* boundary settings to honor, if a given street is within admin boundaries for city, region, and national having different maxspeeds. It makes sense to assume that the most-local administrative boundary should be honored, but that may not be consistent with the law. Best, Nick On Fri, Sep 1, 2017 at 9:53 AM Tod Fitch <t...@fitchdesign.com> wrote: > I take exception to the comment that “there will be too many exceptions to > the rule”. > > In the country I live in each state has a set of “prima facia” speed > limits for various types of roads. Those are basically default speed limits > to be enforced unless otherwise posted by sign. Virtually no residential > road in my state has a speed limit sign but if you exceed 25 MPH you can be > ticketed for speeding. Rural highways are signed only at infrequent > intervals, but exceeding 55 MPH can result in a ticket. > > Given: > A) We should only tag what is on the ground verifiable. By that rule we > should not currently tag these “prima facia” speed limits (no speed limit > sign to verify a maxspeed tag value). > > B) A routing app currently has no way to determine a default speed (one to > be used if no maxspeed=* tag found on way). These can vary by jurisdiction > and I can imagine situations where a national default is overridden by a > state default and/or local municipality default. Should all routing apps go > to a different geographical database to get defaults? If so, why not go to > that other database for everything and ignore OSM? > > It make perfect sense to me to allow administrative areas to be tagged > with default values for otherwise untagged items within the jurisdiction. > If something deviates from the default, as in your “speed limits varies > depending on local topography”, then it will be signed and we should tag > per the sign. But many, many roads in my area are not signed and yet have > legally set maximum speeds. > > At present, I usually ignore the local verifiability constraint and simply > put a maxspeed value on residential roads after I’ve surveyed them even if > they are not signed. If I am feeling a bit more energetic than usual I may > also add a source:maxspeed with a value citing my state’s motor vehicle > code. It would be a lot easier if I could rely on a default value set on my > state’s administrative boundary. > > > On Sep 1, 2017, at 9:25 AM, Dave F <davefoxfa...@btinternet.com> wrote: > > Hi André > > Assuming or defining a default should be based on the number of different > values within the set. > > For the examples you give: > > maxspeed shouldn't have a default. Apart from on motorway classed roads, > speed limits varies depending on local topography. There will be too many > exceptions to the rule. > > driving_side is defined nationally so has a default. (I'm sure now someone > will now provide examples where that's not the case). Any router worth its > salt, should be able to check which country it is in. > > DaveF > > > On 31/08/2017 12:49, André Pirard wrote: > > Hi, > > Examples: either each road is tagged with *maxspeed*=* > <https://wiki.openstreetmap.org/wiki/Key:maxspeed> speed limit and > *driving_side*=* <https://wiki.openstreetmap.org/wiki/Key:driving_side> > or there are defaults. > I'm reviving this remark because the examples are numerous: > > - The Belgian Flemish community wants to tag *maxspeed*=* > <https://wiki.openstreetmap.org/wiki/Key:maxspeed> on every road > instead of using a default. Is this a new specification and where is it > written? Must that now be done in every country? > - The current language= proposition wants to do it without defining > defaults. Really? language= on every name= ? > - Other examples are maxheight in tunnels. Osmose just accused me of > someone else's omitting maxheight. It shouldn't be necessary if it's the > default, that is if there is no sign for it, but Osmose likes to yell just > in case. > - countless etc. > > Please choose. > > Either the defaults are in the OSM database and it takes just a routinely > map fetch to get them all updated timely, > or each other router (GPS) writer implements them each their own way from > various random other files. It's not well clear how contributors ca update > all those files instead of OSM and it typically needs a full software > update for each little default change, depending on writer's availability. > > Please choose. > > There is a Proposed_features/Defaults > <https://wiki.openstreetmap.org/wiki/Proposed_features/Defaults> that > puts the defaults in OSM and it's an EXTREMELY HUGE mistake to have marked > such a paramount good work as abandoned because nobody continued the work. > For the sake of OSM, especially routing, please reopen it. > I don't claim that it is the good solution but I do claim we should work > on such a default database *in priority*. > > I didn't analyze it in full depth, but I have the following remarks: > - Why not allow the def keyword in the border relation itself? But it > could be called zzdef to cluster at the key end. > - If a separate relation is preferred, it should be pointed at by a > "defaults" role in the corresponding border or other relations so that it > can be found. > - to ease scanning a border tree upwards, a "parent" relation should exist > in border relations. > > In hope of a well structured OSM, > > Cheers > > André. > > > > > _______________________________________________ > Tagging mailing > listTagging@openstreetmap.orghttps://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 >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
