Hi Andre, i wasn't aware of this proposal and read it right now. It's a good explanation and pretty easy to understand
But question : Why do we need to put conditions to set a default values to a collection of features ? The only purpose is to activate the default on matching features only. Then : simply don't add as member the mismatching ones :) It sounds like a try to move part of a data consuming logic in the data themselves. What if I need a different set of defaults ? Will I have to create a second or third relation inside main OSM dataset ? I don't agree to this sentence in the Why chapter : "It seems easier to insert those metadata into the database in a special kind of relation.". Your defaults are not necessarily mine. All the best François 2017-08-31 13:49 GMT+02:00 André Pirard <a.pirard.pa...@gmail.com>: > 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 list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
