Re: [Tagging] Giant river multipolygons
2013/2/1 Masi Master masi-mas...@gmx.de: IMO the riverbank is similar to landuse, natural or landcover but explicit for rivers. The wiki say the same: Common tagging: type=multipolygon + waterway=riverbank + name=* + ... New tagging: type=multipolygon + NATURAL=WATER + water=river + name=* + ... Yes, (currently it seems as if the new tagging cannot establish itself, according to taginfo not even 1% of all rivers mapped as areas use this scheme) Can we split a large lake (or forest) with the same name into several (Mulit-)Polygons? I think no, because they have all the same name(?), but it would be nice. There is the problem that they might have several names (with different, potentially overlapping boundaries). How could we manage this? (Often also a very small piece of forest has its own name, but together with other forest parts they form a named forest, which itself might be part of yet another bigger named area of forest). IMHO one idea would be to have distinct tags for * landuse - (an area where trees are grown and cut) use of the land * landcover - (an area covered with trees) physical description of the vegetation (or possibly absence of vegetation) * natural - geographical features (e.g. a named forest) abstract The natural=wood / landuse=forest distinction is flawed and creates useless (IMHO) debates how to distinguish them, and which level of human intervention still justifies the predicate (in this reading of the key) natural. In practise some mappers prefer natural=wood where other mappers would set landuse=forest (for the exact same situation). One solution could be a super-relation, that collect the smaller (sub) relations. yes, this is also already done (at least with routes), but it creates new problems, because it might not be clear, which of the tags get inherited and which don't. Would you only set the name-tag to the superrelation containing smaller forests, or also the forest-tag? If you added also the forest tag: wouldn't that duplicate the forest? If you don't do it, how would you know which tags to inherit from the sub-relations? I changed it to examlpe [1] and the multipolygon-relation goes to an collection-relation, which collect all polygons and outers from the riverbank. But this is not good, because relations are not categorys. not sure if this applies here, relations are not categories implies you don't have to group stuff into relations which is already grouped by their attributes (or defined by a polygon, e.g. all pharmacies in Austria), but in the case of a river you are actually creating a distinct object (the river) which wouldn't be clear otherwise (because you cannot simply add all adjacent riverbanks, they might belong to affluent rivers) Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Giant river multipolygons
On Fri, Feb 1, 2013 at 11:52 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: The natural=wood / landuse=forest distinction is flawed and creates useless (IMHO) debates how to distinguish them, and which level of human intervention still justifies the predicate (in this reading of the key) natural. In practise some mappers prefer natural=wood where other mappers would set landuse=forest (for the exact same situation). I see this as being the same distinction of landuse=farm versus natural=grassland. In both cases, there's human intervention on the landuse part, whereas natural=* would be unmanaged. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Giant river multipolygons
Martin Koppenhoefer wrote: * natural - geographical features (e.g. a named forest) abstract IMO there's no need to limit the key natural to geographical features only, and never has there been such a distinction. The natural=wood / landuse=forest distinction is flawed and creates In practise some mappers prefer natural=wood where other mappers would set landuse=forest (for the exact same situation). Even some mappers prefer to do it as it was done initially: * natural=wood: here be trees * landuse=forest: this area is used for forestry These are often coexisting, but e.g. the landuse does not imply it's necessarily filled with trees. It's a shame somebody ran a bot edit years back to remove natural=wood as redundant from landuse=forest ways. After clearcutting an area can be both landuse=forest + natural=scrub, or even natural=grassland for some years. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Giant river multipolygons
2013/2/1 Kytömaa Lauri lauri.kyto...@aalto.fi: It's a shame somebody ran a bot edit years back to remove natural=wood as redundant from landuse=forest ways. +1, fully agree, bots, mechanical edits and imports tend to distort the usefulness of services like taginfo. After clearcutting an area can be both landuse=forest + natural=scrub, or even natural=grassland for some years. ok for scrub, but natural=grassland (another tag I suspect comes originally from an import of CLC) is about grassland which is more then just grass growing (it is a complex ecosystem). If you cut down a forest it will usually not become grassland for some years and then forest again, it will remain a cut down forest. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Giant river multipolygons
Am 01.02.2013, 18:52 Uhr, schrieb Martin Koppenhoefer dieterdre...@gmail.com: 2013/2/1 Masi Master masi-mas...@gmx.de: IMO the riverbank is similar to landuse, natural or landcover but explicit for rivers. The wiki say the same: Common tagging: type=multipolygon + waterway=riverbank + name=* + ... New tagging: type=multipolygon + NATURAL=WATER + water=river + name=* + ... Yes, (currently it seems as if the new tagging cannot establish itself, according to taginfo not even 1% of all rivers mapped as areas use this scheme) I think this is because there is no retagging the old style to the new. Can we split a large lake (or forest) with the same name into several (Mulit-)Polygons? I think no, because they have all the same name(?), but it would be nice. One solution could be a super-relation, that collect the smaller (sub) relations. yes, this is also already done (at least with routes), but it creates new problems, because it might not be clear, which of the tags get inherited and which don't. Would you only set the name-tag to the superrelation containing smaller forests, or also the forest-tag? If you added also the forest tag: wouldn't that duplicate the forest? If you don't do it, how would you know which tags to inherit from the sub-relations? A good example is the Lake Constance (de:Bodensee): http://commons.wikimedia.org/wiki/File:Bodenseebezp.png The whole Lake contains 3 parts: Untersee, Seerhein and Obersee The first and last part contains another parts. In my opinion, we can tag all sub-parts with natural=water and their names. Then, if we don't like to tag natural=water again, we need to put this multipolygon into another, to keep the connection to the object. So the whole lake is a construct of three parts, which contains the other sub-parts. And if the sub-parts (child-parts) all are natural=water, so the whole lake know, it is water, too. But, a multipolygon is created by the outer-line, not an area. So areas (like child multipolygons) are not allowed (without changing this piont of view)... ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Giant river multipolygons
On Tue, Jan 29, 2013 at 11:28 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: My opinion is your opinion: if there is no good reason for gigantic areas, don't use them. +1, We already have gigantic areas for USA, Russia, India, China... So just explain me why what you accept for administrative boundaries is suddenly not good for rivers Btw, I never edited waterway relations myself but huge admin boundaries, yes ;-) Pieren ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Giant river multipolygons
On 29/01/2013 10:42, Pieren wrote: So just explain me why what you accept for administrative boundaries is suddenly not good for rivers It is the relation type that is at issue. The problems arise when the relation type is a multipolygon with all the outers inners of the entire river as members rather than a separate relation (e.g., type=waterway) with all the riverbank multipolygons as members. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Giant river multipolygons
At the moment the no big relations and no big areas rules go directly against the one feature in osm for one real world feature. I think those first two rules should be solved with more code. Maybe get a feature to osm api to crop the gigantic areas and other relations when downloading, defined by a bbox. Until then we have to cut them up and ignore the one feature rule. Janko ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Giant river multipolygons
On 29.01.2013 11:42, Pieren wrote: On Tue, Jan 29, 2013 at 11:28 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: My opinion is your opinion: if there is no good reason for gigantic areas, don't use them. +1, We already have gigantic areas for USA, Russia, India, China... So just explain me why what you accept for administrative boundaries is suddenly not good for rivers In my case the answer is straightforward: I simply do not care for mapping administrative boundaries, as I personally prefer mapping stuff that is visible on the ground. As a developer, boundaries are the first thing I throw out when filtering the data. Luckily that's quite easy because they have their own relation type (except for some deprecated cases which still use multipolygons, but even those usually have tags like boundary=*). Ignoring rivers is not an option for my use case, though. Likewise, boundaries may still be a problem for those who cannot ignore them, I wouldn't know. Tobias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Giant river multipolygons
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. Janko ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Giant river multipolygons
It's crowd-sourced data. Of course it's not reliable. You won't make it more reliable by trying to get people to impose mega-structures. Better to add further information which you can use intelligently to improve reliability (and which might well be useful for some other purpose) On Tue, Jan 29, 2013 at 12:25 PM, Janko Mihelić jan...@gmail.com wrote: 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. Janko ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Giant river multipolygons
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
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
On 28/01/2013 16:26, Tobias Knerr wrote: I'd like to hear your opinions. +1 As a developer of both editing and rendering software, such data structures are troublesome. I dislike multipolygons with multiple disjunct outers both as a mapper as a developer. I have had to abandon edits when warned that I was about to break a multipolygon with 999 other members. How can one know what that structure is if one cannot see it all in a feasible JOSM download? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Giant river multipolygons
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] Giant river multipolygons
On 28/01/2013 17:53, Toby Murray wrote: But being able to do a search for Danube River and getting back a single object from nominatim would be nice. Here is a conflict. Creating a tagging convenience for one tool can have negative impacts on other tools. At least nested relations separate the entities into logical hierarchies. Tools that are only concerned with multipolygons as geometric constructs can ignore the higher level relations. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Giant river multipolygons
On Monday, January 28, 2013, Werner Hoch wrote: 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. What's wrong with http://wiki.openstreetmap.org/wiki/Relation:waterway? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
