Tod, Can you clarify what residential and rural roads mean to you? Is a residential road corresponding to the osm tag? When is a road rural? Can you determine this for each osm way?
Regards m Op 1 sep. 2017 18:53 schreef "Tod Fitch" <t...@fitchdesign.com>: > 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
