Re: [Tagging] RFC: Defaults are paramount, abandoning Proposed_features/ is a HUGE mistake

[Neil Matthews]

I have some sympathy for expressing defaults within a bounded area.

However, some thought needs to be put into the logistics when mapping /
inputting data.

I would "hope" that there would be editor support -- otherwise how does
one determine whether a given tag/value combination can be omitted --
because it is the default!

Unfortunately, that means that every editor would have to iterate out to
find defaults in ever increasing areas -- unless defaults aren't allowed
to be nested, which imho reduces their usefulness significantly.

Similarly, I'm having trouble conceptualizing what adding / changing a
default value on a bounding area should mean -- are existing inherited
default values now implicitly updated, or do they need to be examined
individually.

Finally, how does one indicate that a value is not able to be determined
-- and should not immediately be inherited -- leaving it blank is no
longer an option!

Apologies, that was longer than I intended,
Neil



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC: Defaults are paramount, abandoning Proposed_features/ is a HUGE mistake

[Tod Fitch]

In the jurisdiction I live, I would apply the state’s default residential speed 
to OSM residential and unclassified highways. I would apply the state’s default 
55 MPH for untagged roads to OSM tertiary, secondary, primary and trunk 
highways. I would apply the state 65 MPH limit for freeways to OSM motorways.

If defaults are at the smallest enclosing administrative boundary probably not 
required in my area: One of the characteristics of tertiary, secondary, primary 
and trunk highways within a incorporated municipality and even in built up but 
non-incorporated areas, is that by law each of those road types must have the 
speed limit set based on a traffic study and signs are posted based on the 
decision made following the study. The end result is that non-residential, 
non-unclassified (using OSM terms) are pretty well signed in urban areas.

Tod

> On Sep 1, 2017, at 2:21 PM, Marc Gemis  wrote:
> 
> 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"  >:
> 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 > > 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=* 
>>>  speed limit and 
>>> driving_side=*  or 
>>> there are defaults.
>>> I'm reviving this remark because the examples are numerous:
>>> The Belgian Flemish community wants to tag 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 
>

Re: [Tagging] RFC: Defaults are paramount, abandoning Proposed_features/ is a HUGE mistake

[Marc Gemis]

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" :

> 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  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*=*
>  speed limit and
> *driving_side*=* 
> or there are defaults.
> I'm reviving this remark because the examples are numerous:
>
>- The Belgian Flemish community wants to tag *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
>  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 b

Re: [Tagging] RFC: Defaults are paramount, abandoning Proposed_features/ is a HUGE mistake

[Colin Smale]

On 2017-09-01 21:32, Nick Bolten wrote:

> 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.

The boundary with the highest value of admin_level? 

//colin___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC: Defaults are paramount, abandoning Proposed_features/ is a HUGE mistake

[Nick Bolten]

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  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  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*=*
>  speed limit and
> *driving_side*=* 
> or there are defaults.
> I'm reviving this remark because the examples are numerous:
>
>- The Belgian Flemish community wants to tag *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 (

Re: [Tagging] RFC: Defaults are paramount, abandoning Proposed_features/ is a HUGE mistake

[Clifford Snow]

I have been following this discussion on default maxspeed tagging.
Searching the wiki hasn't been helpful. There is an inactive proposal [1],
a wiki page on country default speeds [1] but nothing definitive on how to
map.

The default scheme seems to be a reasonable approach for jurisdictions that
have a maxspeed for unposted roads.

Can someone point to a wiki page that explains how to map?

[1] https://wiki.openstreetmap.org/wiki/Proposed_features/Defaults
[2] https://wiki.openstreetmap.org/wiki/Country_specific_default_values

Clifford
-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC: Defaults are paramount, abandoning Proposed_features/ is a HUGE mistake

[Tod Fitch]

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  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=* 
>>  speed limit and 
>> driving_side=*  or 
>> there are defaults.
>> I'm reviving this remark because the examples are numerous:
>> The Belgian Flemish community wants to tag 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 
>>  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 
>>

Re: [Tagging] RFC: Defaults are paramount, abandoning Proposed_features/ is a HUGE mistake

[Dave F]

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*=* 
 speed limit and 
*driving_side*=* 
 or there are 
defaults.

I'm reviving this remark because the examples are numerous:

  * The Belgian Flemish community wants to tag *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 
 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

Re: [Tagging] RFC: Defaults are paramount, abandoning Proposed_features/ is a HUGE mistake

[Martin Koppenhoefer]

2017-08-31 13:49 GMT+02:00 André Pirard :

>
>- The Belgian Flemish community wants to tag *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?
>
>


We are doing this in Italy for many years now, and it is quite robust and
reliable. We are adding the source:maxspeed tags additionally to explain
whether the maxspeed is explicit (sign / road marking etc.) or implicit
(usually derived from a zone like "inside a settlement", "on a motorway",
"outside of a settlement", etc.). In all countries I am aware of you can't
reliably detect default limits without knowing if the road is inside or
outside of a settlement, which is typically not dependent on the actual
settlement but on street signs that tell you when you enter or leave a
(traffic code related) settlement. It has also proven useful for
maintenance and verification to map actual speed limit signs
(traffic_sign=maxspeed, maxspeed=n ) at the side of the road (to have the
direction stored).



>
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.
>


it really depends on the kind of "default" you are after. What about a
maxspeed=50 sign in Germany inside a settlement (i.e. it is a sign which
states the default). If the law for the default changes, this 50ies sign
will not have to change (unless they are going to modify the sign). If the
road is simply tagged with "highway=tertiary" you can't know whether this
is incomplete data, or the mapper had a lot of defaults in mind like
lit=yes, lanes=2, surface=asphalt, maxspeed=50, sidewalk=both, oneway=no,
smoothness=good, etc. (assuming a smaller road in a city).  You can't even
know whether the road is (legally) inside a city.

I guess you would have to define really complex defaults / processing to
cater just for the more used properties. A tag like source:maxspeed allows
to change all speed limit defaults in a country at once because they are
explicitly marked as defaults.

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC: Defaults are paramount, abandoning Proposed_features/ is a HUGE mistake

[François Lacombe]

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 :

> Hi,
>
> Examples: either each road is tagged with *maxspeed*=*
>  speed limit and
> *driving_side*=* 
> or there are defaults.
> I'm reviving this remark because the examples are numerous:
>
>- The Belgian Flemish community wants to tag *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
>  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