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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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?

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

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

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

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