Re: [Tagging] Waterway length

[Werner Hoch]

Hi,

it is an optional tag an it is useful for quality checks of the data.

Am Dienstag, den 29.01.2019, 18:37 +0300 schrieb Eugene Podshivalov:
> Hi all,
> The relation:waterway wiki page recommends using "distance" tag for
> "the total length of river in km". Was there any discussion of this
> choice?
> It seems a bit incorrect and confusing, because "distance" is more
> suitable for routes as discribed on its proper page. The existing
> "length" tag would fit better, woudn't it?

length vs. distance is only a wording issue.

The tag just enables you to compare the geometric length with the
lenght tag. If they are close (maybe within 5% of error) the river is
mapped fine.

As many length tags might have been taken from wikipedia (or wikidata)
it is redundant as soon as you add a wikidata tag.
see https://www.wikidata.org/wiki/Q584 (Rhine on Wikidata with its
lenght 1232.7 km).

Geometrical analyses of the river: 1160.34 km.

Not a precics match, but close enought that no major parts of the river
is missing.

Regards
Werner


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

Re: [Tagging] Waterway tributary role

[Werner Hoch]

Hi,

Am Samstag, den 13.04.2019, 11:48 + schrieb marc marc:
> destination is the opposite, no ?
> if river A go into river B  :
> in relation A : destination=B
> in relation B : A with rôle tributary

Destination helps human mappers to understand the data.
It is optional.
https://wiki.openstreetmap.org/wiki/Relation:waterway

Currently I only add it if the connection data of the waterway segments
do not end in another river.

e.g. a river flows into an ocean and it has the tag
destination="atlantic ocean".
This tag is usefull as you now don't have to look for an downstream
river, where just some node connection is missing.

For larger rivers you can use wikidata for connection analyses, too.
If the wikidata tags are added to the waterway relations you can
compare the geometric connection (from osm) with the logical
connections described in wikidata:

E.g. the Ohio River https://www.wikidata.org/wiki/Q4915 flows into
(mouth of the watercourse) the https://www.wikidata.org/wiki/Q1497
Mississippi River that flows into Gulf of Mexico https://www.wikidata.
org/wiki/Q12630 which is part of the American Mediterranean Sea
https://www.wikidata.org/wiki/Q470088 and that is part of the Atlantic
Ocean https://www.wikidata.org/wiki/Q97

In my opinion the best mapping method now is to add the wikidata tag
and define the mouth of watercourse in wikidata (if not already there).
I do not like the tributary role in waterway relations and not the
watershed relations.

Regars
Werner



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

Re: [Tagging] Waterway tributary role

[Werner Hoch]

Hi,

Am Donnerstag, den 11.04.2019, 13:48 +0300 schrieb Eugene Podshivalov:
> Hi all,
> Does anyone remember where "tributary" role of waterway relations was
> discussed.
> It is used quite often in Fance but I could not find any reference on
> the wiki.

From 2010 to 2012 the mapping of waterway relations has been unified
and https://wiki.openstreetmap.org/wiki/Relation:waterway was the
result of it.

Part of the discussion about the tributary role is here:
https://wiki.openstreetmap.org/wiki/Talk:Relations/Proposed/Waterway#tributary_vs._tributary_of_relation_role

The role has not made it into the the final definition of the waterway
relation model, but is still used in France.

You can see the bad side effect in Wikipedia:
Nice rivers in the map:
https://en.wikipedia.org/wiki/Danube
https://en.wikipedia.org/wiki/Mississippi_River

The Seine with it's tributaries
https://en.wikipedia.org/wiki/Seine
displays the watershed.

In parallel there is the
https://wiki.openstreetmap.org/wiki/Relation:watershed mapping. This at
least divides the mapping of watersheds and waterway into seperate
models. Nobody ever wrote a proposal about this.

Regards
Werner




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

Re: [Tagging] tributary role in waterway relations: widespread?

[Werner Hoch]

Am Montag, den 29.02.2016, 12:01 +0100 schrieb Mateusz Konieczny:
> On Mon, 29 Feb 2016 11:21:44 +0100
> David Marchal  wrote:
> 
> > 
> > Hello, there.
> > 
> > I wondered: I saw the' tributary' role on some waterway relations;
> > while I understand its usage — to represent the fact that a
> > waterway
> > flows into another —, I would like to know if it is widespread or
> > even widely accepted, if not voted on wiki, as JOSM complains about
> > not knowing it every time I use it.
> > 
> > Awaiting your answers,
> > 
> > Regards.    
>             
> For such purposes taginfo is an useful tool - see
> http://taginfo.openstreetmap.org//search?q=tributary
> 
> It seems to be used extremely rarely. Also, this information is
> duplicating geometry of waterways - somebody who needs it may get it
> by
> constructing waterway graph.

It's mainly/only used in France. France used/uses this schema:
http://wiki.openstreetmap.org/wiki/User:Frodrigo/Relation:Waterway

It has been dropped during the voting/unification for the waterway
relation definition.
http://wiki.openstreetmap.org/wiki/Relation:waterway

If you need the graph you can trace the connections.
http://www.h-renrew.de/h/osm/osmchecks/07_watershed/fr/hierarchical.htm
l
But it's easier to use wikidata to build the graph, too.
http://www.h-renrew.de/h/osm/osmchecks/07_watershed/fr/wikidata_osm.htm
l

Just add a wikidata tag to the river and the connection as wikidata
property. (mouth of watercourse)

Bad side effect of the tributary usage in France:
It destroys the wikipeda maps, as you'll always get the basin and not
the river:
https://en.wikipedia.org/wiki/Rh%C3%B4ne -->  bad
https://en.wikipedia.org/wiki/Danube    -->  nice
(look at the map beside the coordinates)

HTH

Regards
Werner


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

Re: [Tagging] relation type for raceways

[Werner Hoch]

Hi,

Am Montag, den 16.03.2015, 20:04 -0400 schrieb Richard Welty:
 as i go forward mapping raceways in north america, one of the
 issues is modeling multi configuration courses such as Watkins
 Glen and Lime Rock.
 
 one solution is to use route relations, and add a new
 route type,
 
 route=raceway


There is type=circuit
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Circuit

example (Monaco)
http://www.openstreetmap.org/relation/148194

It is used about 60 times in OSM.


 in this model, i would use forward and backward roles where
 necessary. right now the best example of this i have is of
 my model of the Thompson road courses over the years at
 Thompson Speedway in Connecticut, which is in OHM. some
 sections of the raceway were used in different directions in
 different variations of the course, hence the need for
 forward  backward.

Is in the proposal, have a look at it.

Regards
Werner



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

Re: [Tagging] Reviewing the use of addr:housename

[Werner Hoch]

Am Sonntag, den 15.06.2014, 16:02 +0200 schrieb fly:
 Please, be careful. Not all of the numeric housenames are errors. You
 have to check them individually or maybe better contact the user and ask
 for clarification.


I've added a feature request for keepright:
https://github.com/keepright/keepright/issues/37

Regards
Werner



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

Re: [Tagging] Wikipedia tag validator

[Werner Hoch]

Hi,

I'm wondering, if you're aware of WIWOSM:
https://wiki.openstreetmap.org/wiki/WIWOSM

They provide lists of bad wikipedia tags, too:
https://wiki.openstreetmap.org/wiki/WIWOSM#Logging

regards
Werner



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

Re: [Tagging] Giant river multipolygons

[Werner Hoch]

Hi Paul,

Am Montag, den 28.01.2013, 17:47 -0600 schrieb Paul Johnson:
 On Monday, January 28, 2013, Werner Hoch wrote:
 There are a few of that monster relations out there:
 
 http://www.h-renrew.de/h/osm/osmchecks/02_Relationstypen/planet/bd8a1061c196c9de.html
 
 Some are tagged with type=collection. That's not better or
 worse, just different.
 
 What's wrong with
 http://wiki.openstreetmap.org/wiki/Relation:waterway?

This relation type only defines relations for center lines of the river.

Why?

It's really easy to maintain this kind of relations for center lines of
waterways. The longer the river, the river became wider. The node
density of the center line gets smaller and smaller. Even large rivers
only have a few thousand nodes.

In the opposite the riverbank ways and areas don't scale with the width
of the river. You have to place a node every 10 to 100 meters for the
riverbank ... on both sides  and islands.

The riverbank relations are not maintainable, as they are much larger
I guess by factor off 10 to 100. I've never seen a complete riverbank
relation of a large river, yet. But few thousand river/waterway
relations of center lines.

The other reason not to collect the riverbanks is, as soon as you have
the centerline, a GIS program can collect all riverbank areas along that
centerline. It is a waste of time to collect them manually.

If you look into the wikipedia articles:
http://en.wikipedia.org/wiki/Danube [1]
or
http://en.wikipedia.org/wiki/Amazonas_River [2]
and use the globe symbol beside the coordinats (top right), You'll see
the waterway relations on the map (see WIWOSM [3] for details).

[1] http://www.openstreetmap.org/browse/relation/89652   6567 nodes
[2] http://www.openstreetmap.org/browse/relation/2295651  821 nodes

In comparison the Danube riverbank, only 50% mapped to Black Sea
http://www.openstreetmap.org/browse/relation/1189126  28933 nodes

[3] http://wiki.openstreetmap.org/wiki/WIWOSM

Regards
Werner


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

Re: [Tagging] Giant river multipolygons

[Werner Hoch]

Am Dienstag, den 29.01.2013, 13:25 +0100 schrieb Janko Mihelić:
 2013/1/29 Richard Mann richard.mann.westoxf...@gmail.com
 The Danube river is perfectly adequately made whole by looking
 for name:en=Danube. Get the computer to do the work, not
 mappers.
 
 What if there is a little river Danube, somewhere in Ohio?
 
 I guess other tags like wikipedia=de:Donau might be ok, although it
 doesn't sound very reliable.

Look at http://en.wikipedia.org/wiki/en:Danube (map symbol) It looks
pretty mutch like the Danube river. The wikipedia tag is uniq.

name=danube could be a cafe, a club, another river, a ... too.

Regards
Werner



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

Re: [Tagging] Giant river multipolygons

[Werner Hoch]

Hi,

Am Montag, den 28.01.2013, 17:26 +0100 schrieb Tobias Knerr:
 Nevertheless, there appears to be a trend to merge them into a single
 area for the entire river via multipolygons. This has been brought to my
 attention by a recent changeset
 http://www.openstreetmap.org/browse/changeset/14808765
 which added previously separate sections of the Danube river into this
 multipolygon: http://www.openstreetmap.org/browse/relation/1189126

This wasn't a multipolygon before. It was a collection of riverbank
elements.
Nobody likes them but nobody is bold enough to delete them.

Tagged back to:
  type=waterway
  waterway=riverbank
and added a note=

There are a few of that monster relations out there:
http://www.h-renrew.de/h/osm/osmchecks/02_Relationstypen/planet/bd8a1061c196c9de.html

Some are tagged with type=collection. That's not better or worse, just
different.

Regards
Werner


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

Re: [Tagging] Names on relations and not component ways

[Werner Hoch]

Am Sonntag, den 06.01.2013, 16:43 -0600 schrieb Toby Murray:
 On Sun, Jan 6, 2013 at 3:54 PM, Werner Hoch werner...@gmx.de wrote:
  AFAIR there's currently no relation type that inherits it's tags to the
  member ways, so that the name tags are rendered on the map.
 
 Relations with type=multipolygon render the name tag on the map.
 http://www.openstreetmap.org/browse/relation/1530467

Yeah, missed that, but the multipolygon is just a different way to
define Area elements. see:
http://wiki.openstreetmap.org/wiki/Area

It just uses the OSM Relation data type to achive this.

  Road routes do not inherit there ref tags to the highways,
  associatedStreets do not inherit there street name to the highway
  segments. Those relations use duplicate tags, too.
 
 There are efforts to render highway shields in the US based on network
 and ref tags of highways.

That sounds interesting, please let us know, when this gets deployed to
the map.

Regards
Werner


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

Re: [Tagging] Names on relations and not component ways

[Werner Hoch]

Hi ceyockey,

Am Freitag, den 04.01.2013, 08:43 -0500 schrieb dies38...@mypacks.net:
 I recently created a waterway where I put the name of the waterway 
 on the relation but not on the component ways which are grouped by 
 the relation.  
 This results in the name of the waterway not appearing in the standard 
 Map view. 

AFAIR there's currently no relation type that inherits it's tags to the
member ways, so that the name tags are rendered on the map.

Road routes do not inherit there ref tags to the highways,
associatedStreets do not inherit there street name to the highway
segments. Those relations use duplicate tags, too.

There's only one rarely used concept of tag inheritance:
http://wiki.openstreetmap.org/wiki/Relation:multilinestring
that is AFAIR not supported by the renderers.

 I am wondering what current best practice is. 
 Should name be applied to both component ways and relation, 
 or is application of name to relation sufficient.  

For waterways, adding one name to ways and all names to the relation is
at least useful. Longer waterways (rivers) sometimes do not have the
same name over the complete length, because they flow across different
countries.

e.g. The Danube river:
http://www.openstreetmap.org/browse/relation/89652

 To me, not duplicating data would seem to be the better overall 
 practice, and duplication of name on relation and component ways 
 would seem to be a case of tagging-for-the-renderer.  

IMHO, redundancy is not always a bad thing. Just do not add too much.


 (p.s. the waterway in question = 
 http://www.openstreetmap.org/browse/relation/2676618)

For that short waterway it wouldn't create a waterway relation [1], as
the benefits of the extra relation are low.
* no international names required
* no wikipedia reference
* the waterway has the same name on all segments.
* no gnis reference tag, ...

[1] http://wiki.openstreetmap.org/wiki/Relation:waterway

Regards
Werner (werner2101)


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

Re: [Tagging] Voting for Relation type=waterway

[Werner Hoch]

Hi Chris,

Am Sonntag, den 19.02.2012, 15:53 + schrieb Chris Hill:
 I do not agree with the whole basis of this thread.
 
 There are no such things as approved tags, tagging is open and people 
 are free to use *any* tags they like.
 
 There are no such things as deprecated tags, tagging is open and people 
 are free to use *any* tags they like.
 
 A vote by a few people is certainly not a justification to begin mass 
 edits or wide spread change of other people's carefully chosen work.

 Discuss: certainly, document: yes please, impose your will over 
 thousands over other mappers: no.

You can find the discussion in the wiki. Even users that used the
type=collection tag agreed to unify the tagging.

Two years ago I've contacted all users that have contributed waterway
relations and invited them to discuss.

 Advertise your ideas and encourage acceptance. Show how well it works 
 any why it is better but don't use a phoney voting process ignored by 
 the vast majority as a mandate for action.

I've advertised and talked and the stats shows, that many users use the
unified tagging scheme.
See:
http://www.h-renrew.de/h/osm/osmchecks/02_Relationstypen/planet_waterways.html

The final vote is just to finish the proposal and unify the last few
tags ...

Regards
Werner


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

Re: [Tagging] Voting for Relation type=waterway

[Werner Hoch]

Am Montag, den 20.02.2012, 20:11 + schrieb Chris Hill:
 On 19/02/12 23:38, Steve Bennett wrote:
  On Mon, Feb 20, 2012 at 2:53 AM, Chris Hillo...@raggedred.net  wrote:
  I do not agree with the whole basis of this thread.
 
  There are no such things as approved tags, tagging is open and people are
  free to use *any* tags they like.
  ...
  Advertise your ideas and encourage acceptance. Show how well it works any
  How would you know whether a tag had acceptance? Wouldn't
  documenting it somewhere make sense? Maybe...in a wiki?
 I did say document and discuss the OP.
  What would you
  call acceptance? Would approved be a reasonable synonym for that?
 No. It implies some official status that leads people to remove other 
 tags, sometimes with mass edits.

Chris, I've said nothing about mass or automatic editing.
Every change will be done carefully and manually.

  The wiki and (currently broken) approval mechanism is not some
  horrible bureaucracy that exists to ruin your life. It's there so we,
  as a community, can document the tags we use, and agree on how we use
  them. While it's ok to spontaneously invent a new tag and use it to
  solve your current problem, you can surely see the benefits of
  everyone eventually converging on the same tag?
 
  And if so, what would you do with all the old tags that people used
  before you converged? Wouldn't you deprecate them?

 No, some tags will wither away, fine. Some seemingly similar tags will 
 exist side-by-side and that is fine too. Most importantly, distinctive 
 differences can emerge too.
 
 Just think this through. Approval implies some sort of enforcement, 
 without enforcement what is the point of approval? Just who would make 
 this enforcement happen and how? What would that do to an open project? 
 If only approved tags are used then how would mappers map what they 
 actually see? Wait weeks for some committee to discuss, argue and 
 approve or reject the tag? If you are free to use any tag, what is an 
 approval process for?
 
 If approval or 'acceptance' means a tag is rendered or used in a router 
 or whatever then which tool do you mean? There are hundreds run by OSM 
 and other organisations, companies and individuals.

 Flattening the tag structure by homogenising tags is destroying the fine 
 detail, sometimes carefully crafted by mappers and I will continue to 
 speak out against mass edits that attempt to do just that.

It's just different tagging, no fine detail.

Please show me the difference of the type=collection and the
type=waterway relations we're talking about here.

All the difference comes in the tagging history, when the australian
mappers started with a different tagging stile than the european
mappers.

Regards
Werner


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

[Tagging] Voting for Relation type=waterway

[Werner Hoch]

Hi all,

the relation type=waterway proposal was written long times ago but never
formally approved:
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Waterway

The relation is widely used as you can see in statistics:
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Waterway#Tools

It would be cool if you could vote for the proposal:
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Waterway#Voting


It would help to clean up the OSM database from a few similar relations
that are rarely used but not yet follow the above scheme.


Kind Regards
Werner (werner2101)


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

[Tagging] Converting relation type relatedStreet to assiciatedStreet

[Werner Hoch]

Hi there,

the relation type page:
http://wiki.openstreetmap.org/wiki/Types_of_relation

lists the relatedStreet relation as an similar type of associatedStreet.

Are there any objection to convert and cleanup the relatedStreets into
associatedStreet relations?

Often there could be merge several relatedStreet relations together to
one associatedStreet relations, as relatedStreets sometime only
connected single houses to a street.

Here is my current statistic of street-like relations:
http://www.h-renrew.de/h/osm/osmchecks/02_Relationstypen/planet_street.html


Kind Regards
Werner (werner2101)


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

Re: [Tagging] Converting relation type relatedStreet to assiciatedStreet

[Werner Hoch]

Am Sonntag, den 19.02.2012, 11:07 +0100 schrieb David Paleino:
 On Sun, 19 Feb 2012 10:56:19 +0100, Werner Hoch wrote:
  the relation type page:
  http://wiki.openstreetmap.org/wiki/Types_of_relation
  
  lists the relatedStreet relation as an similar type of associatedStreet.
  
  Are there any objection to convert and cleanup the relatedStreets into
  associatedStreet relations?
  
  Often there could be merge several relatedStreet relations together to
  one associatedStreet relations, as relatedStreets sometime only
  connected single houses to a street.
 
 I'm one of those pushing for type=street, and I'd be glad if we could merge 
 all
 somethingStreet to it :) (which is less error-prone, less chars to type, 
 easier
 to remember)

Well, one relation type would be perfect. But for now I think we should
try to reduce the different types one by one.

 (we should also include type=collection + collection=street and type=route +
 route=street -- rationale for the latter is that named routes should be
 route=road)

AFAIK type=route + route=road  is different to the street relations.
road routes: primary, secondary road routes with the same ref.
street: houses and highway elements with the same name/address.

  Here is my current statistic of street-like relations:
  http://www.h-renrew.de/h/osm/osmchecks/02_Relationstypen/planet_street.html
 
 Oh, nice.

Here you can find other listings:
http://www.h-renrew.de/h/osm/osmchecks/02_Relationstypen/index.html
e.g. the list for italy:
http://www.h-renrew.de/h/osm/osmchecks/02_Relationstypen/it.html

Regards
Werner



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

Re: [Tagging] Converting relation type relatedStreet to assiciatedStreet

[Werner Hoch]

Am Sonntag, den 19.02.2012, 12:12 +0100 schrieb David Paleino:
 On Sun, 19 Feb 2012 11:56:39 +0100, Werner Hoch wrote:
  Well, one relation type would be perfect. But for now I think we should
  try to reduce the different types one by one.
 
 Then I propose merging relatedStreet directly to street :P

   (we should also include type=collection + collection=street and 
   type=route +
   route=street -- rationale for the latter is that named routes should be
   route=road)
  
  AFAIK type=route + route=road  is different to the street relations.
  road routes: primary, secondary road routes with the same ref.
  street: houses and highway elements with the same name/address.
 
 That's exactly what I'm saying, see below.
 From your originally linked page, I can see there are some route=street 
 around.
 I was saying that these should be merged too. My reference to route=road was
 that, if a route=street has a ref=, this should really be a route=road. So
 there shouldn't be *any* route=street around.

Yes. But you have to look inside all route=street relations to make a
judge wether it should be a road=route or a street (or
associatedStreet).


 Regarding route=road, here is one more thought. In some cases, people (I, for
 one, in my beginnings) use route=road to link different pieces of a ref-less
 street: this is wrong. But surely this can't be done automatically :)

Cleanup is hard and timeconsuming work ;-)

Regards
Werner


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

Re: [Tagging] Voting for Relation type=waterway

[Werner Hoch]

Am Sonntag, den 19.02.2012, 22:16 +1100 schrieb Steve Bennett:
 The proposal looks pretty sensible to me. I just wish there was a
 meaningful process we could follow. Probably what we really want to do
 is deprecate any alternative tagging schemes, and direct people to
 this one.

As soon as the the proposal gets approved the other relations can be
declared deprecated.

The usage of type=river decreased over the last year as the major
waterway contributors already switched to the type=waterway scheme.

I think an approved proposal would give us enough support to start the
cleanup of the older tagging schemes.

I'd be of course one of the volunteers to unify the taggings.

Regards
Werner


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

Re: [Tagging] highway=path, path=hiking

[Werner Hoch]

Hi,

On Samstag, 16. Juli 2011, Steve Bennett wrote:
 On Sat, Jul 16, 2011 at 11:51 PM, SomeoneElse
 
 li...@mail.atownsend.org.uk wrote:
  highway=path, path=hiking doesn't say any more to me than
  highway=footway on its own would.
 
 The distinction is well constructed versus rough, minimal
 maintenance.
 
 highway=path, path=hiking:
 http://www.publicdomainpictures.net/pictures/12000/nahled/hiking-path
 -1-238412973779541Zf.jpg

This way looks wide enough for agricultural vehicles.
I'd tag this as: highway=track  tracktype=grade2

 highway=footway:
 http://www.freefoto.com/images/808/12/808_12_2972---Footpath-through-
 Strid-Wood_web.jpg?k=Footpath+through+Strid+Wood

And this as highway=path  sac_scale=hiking   and maybe surface=ground

 This distinction exists and is meaningful. The question is whether
 this is a good way to express it.

Take a look at taginfo:
sac_scale:
http://taginfo.openstreetmap.org/keys/sac_scale#values

path:
http://taginfo.openstreetmap.org/keys/path#values

surface:
http://taginfo.openstreetmap.org/keys/surface#values

Regards
Werner (werner2101)

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

Re: [Tagging] Proposal - Draft: key=osm for aerial imagery and internel objects

[Werner Hoch]

Hi Serge,

On Mittwoch, 15. Dezember 2010, Serge Wroclawski wrote:
 On Wed, Dec 15, 2010 at 6:51 AM, Werner Hoch werner...@gmx.de wrote:
  I've created a proposal for imagery objects and other objects that
  are only used internaly in osm.
   http://wiki.openstreetmap.org/wiki/Proposed_features/osm
  
  Aerial Imagery:
  ---
  With the new Bing images many new relations have been created that
  contain boundaries of hires images. I think it would be cool to
  have a uniq tagging for such objects.
  Examples without unified tagging:
   http://www.openstreetmap.org/browse/relation/1291579
   http://www.openstreetmap.org/browse/relation/396170
 
 These are features of Bing, not of the earth. They belong with the
 Bing dataset, or else another dataset which collects metadata about
 imagery, but I don't think it belongs in OSM.

The data is already in the osm database. I'm just proposing to add uniq 
tags to make it easier to work with them. Robert Naylor postet a the 
link to the bing coverage with lots of ways/areas of hires bing maps.

I've no opinion whether the data should be in the database or not.

 
  Worksets, Experimental Tagging, ...
  -
  Sometimes mappers are creating objects with experimental tagging or
  collections of objects for personal use.
 
 They can do that on a dev server.
 
  Mappers that do QA work sometimes delete or change that objects.
 
 They shouldn't be doing QA work on the production dataset.

QA work is only required in the production dataset. Nobody cares of the 
data in the dev server.

  These messages can only be read by human mappers, not by bots. To
  make it easier for the QA mapper, the bots and the mappers that
  are working on new things it would be nice to have a uniq tagging
  for such objects. The proposed tags are:
   osm=experimental; osm=test; osm=temporary; osm=workset
  
  Comments and additional ideas are welcome.
 
 We have a mechanism for people to experiment with; that's the dev
 server.

Yes, but some users are adding experimental/new stuff to the osm 
database.
I've just proposed to add tags to make it obvious. In the proposal, I 
wrote too, that the mappers are responsible to delete the stuff as soon 
as it's no longer needed.
 
 If you're saying that's not sufficient, I'd like to hear why and what
 we can/should be providing to aid mappers's experimentation without
 effecting our production dataset.

Sorry, I don't know how to tell _all_ mappers to use the dev server for 
experiments.

If you like to avoid test/experimental/new stuff in the production 
database, you have to restrict the commits to known/official tags.

Regards
Werner

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

Re: [Tagging] Proposal - Draft: key=osm for aerial imagery and internel objects

[Werner Hoch]

Hi Robert,

On Mittwoch, 15. Dezember 2010, Robert Naylor wrote:
 On Wed, 15 Dec 2010 12:08:37 -, Serge Wroclawski wrote:
  On Wed, Dec 15, 2010 at 6:51 AM, Werner Hoch werner...@gmx.de   
  Examples without unified tagging:
   http://www.openstreetmap.org/browse/relation/1291579
   http://www.openstreetmap.org/browse/relation/396170
  
  These are features of Bing, not of the earth. They belong with the
  Bing dataset, or else another dataset which collects metadata about
  imagery, but I don't think it belongs in OSM.
 
 Also see top  of http://wiki.openstreetmap.org/wiki/Bing/Coverage
 
 Please use this page for recording coverage. Do not use boundary
 relations. Large, detailed relations can be exceptionally slow to
 retrieve and cause very high server load, especially when accessible
 via an OpenLayers slippymap client. Significant problems have
 already been caused by people trying to map coverage with a
 relation, and then posting the relation URL.

Just a short note: With proper tags on the areas/ways you could generate 
the whole wiki page out of the osm data.

Regards
Werner

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

Re: [Tagging] Proposal - Draft: key=osm for aerial imagery and internel objects

[Werner Hoch]

On Mittwoch, 15. Dezember 2010, Pieren wrote:
 On Wed, Dec 15, 2010 at 1:37 PM, Robert Naylor rob...@pobice.co.uk 
wrote:
  Also see top  of http://wiki.openstreetmap.org/wiki/Bing/Coverage
  
  Please use this page for recording coverage. Do not use boundary
  relations. Large, detailed relations can be exceptionally slow to
  retrieve and cause very high server load, especially when
  accessible via an OpenLayers slippymap client. Significant
  problems have already been caused by people trying to map coverage
  with a relation, and then posting the relation URL.
 
 I think the best proposal we can do is to delete such boundaries from
 OSM. That's what I will do If I find one in my working area.

If that's your serious opinion, you can start deleting the 
ways/relations now. Robert postet the link to the data.

Regards
Werner

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

[Tagging] Proposal - Draft: key=osm for aerial imagery and internel objects

[Werner Hoch]

Hello,

I've created a proposal for imagery objects and other objects that are 
only used internaly in osm.
  http://wiki.openstreetmap.org/wiki/Proposed_features/osm

Aerial Imagery:
---
With the new Bing images many new relations have been created that 
contain boundaries of hires images. I think it would be cool to have a 
uniq tagging for such objects.
Examples without unified tagging:
  http://www.openstreetmap.org/browse/relation/1291579
  http://www.openstreetmap.org/browse/relation/396170


Worksets, Experimental Tagging, ...
-
Sometimes mappers are creating objects with experimental tagging or 
collections of objects for personal use.

Mappers that do QA work sometimes delete or change that objects.
Thus the experimental mappers try to tell those QA mappers not to delete 
that objects with additional tags. e.g.
note=this is a test relation, please do not delete it, 

These messages can only be read by human mappers, not by bots. To make 
it easier for the QA mapper, the bots and the mappers that are working 
on new things it would be nice to have a uniq tagging for such objects.
The proposed tags are:
  osm=experimental; osm=test; osm=temporary; osm=workset


Comments and additional ideas are welcome.

Regards
Werner (werner2101)

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