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


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

Reply via email to