Re: [Tagging] Feature Proposal - RFC - natural=bare_rock
2011/1/29 John Smith deltafoxtrot...@gmail.com: On 30 January 2011 03:34, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: even though this creates some problems: if you tag a polygon with natural=beach, surface=sand, doesn't this imply a the polygon is sand? The beach could often include also bars, restaurants, parking space, paths and other. surface on a polygon should IMHO imply that this polygon has this surface. In this optic the landcover-values is more generalizing while surface shouldn't. I'm still failing to see the relevance here, after all wouldn't those other locations have their own POI or polygon? yes, they would result in overlapping polygons with different surface values. You could not tell which one is valid. That makes no sense, assuming good faith, why would someone intentionally upload an invalid polygon? (other than by accident) broken by design... There won't be an invalid polygon, there would be 2 valid but contradicting polygons. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - natural=bare_rock
On 30 January 2011 21:05, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: broken by design... There won't be an invalid polygon, there would be 2 valid but contradicting polygons. Which are sorted by smallest first usually so they render on top of the larger ones. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - natural=bare_rock
2011/1/30 John Smith deltafoxtrot...@gmail.com: On 30 January 2011 21:05, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: broken by design... There won't be an invalid polygon, there would be 2 valid but contradicting polygons. Which are sorted by smallest first usually so they render on top of the larger ones. This is a method of trying to extract useful data from an undefined state making assumptions, but it is IMHO not how we should design our data model. This would also mean that even with complete data for the whole world, you would need endless processing if you wanted to estimate the area covered by sand: for every area tagged surface=sand you would only know it's real extension after subtracting all other polygons with different surface-values (or with an assumed different surface). You also seem to reduce this to a rendering problem. There can also be cases where a bigger polygon overlaps for a small part a smaller polygon. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - natural=bare_rock
On 30 January 2011 21:52, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: This is a method of trying to extract useful data from an undefined state making assumptions, but it is IMHO not how we should design our data model. This would also mean that even with complete data for the whole world, you would need endless processing if you wanted to estimate the area covered by sand: for every area tagged surface=sand you would only know it's real extension after subtracting all other polygons with different surface-values (or with an assumed different surface). You also seem to reduce this to a rendering problem. There can also be cases where a bigger polygon overlaps for a small part a smaller polygon. None of which is an issue, you can sort and display the information however you like, however in general it is a rendering problem and the way that was solved was to put the smaller polygons on top of the bigger ones which seems like a reasonable way to handle things to me. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - natural=bare_rock
2011/1/30 John Smith deltafoxtrot...@gmail.com: None of which is an issue, you can sort and display the information however you like, all of them are issues. To recall: My statement was, that a polygon tagged with surface=xy should have this surface. If there are parts inside this polygon, that don't have this surface, they should be excluded (multipolygon). This is different to e.g. landuse, where we map the predominant landuse (i.e. there can be small areas within with different landuse). This behaviour should IMHO not apply to surface. If there are different polygons tagged with different surface values that cover the same area, you will have to interpret a non-clear situation, that's why we should try to avoid these situations. In case of the beach you could tag the beach-way as natural=beach, name=xy then create a multipolygon, insert the non-sand surfaces as inners and tag the relation with surface=sand. In my reading you wouldn't have to exclude them with landcover (or say beach:type) sand, as these are less explicit then surface (they implicitly take a more generalized view). cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - natural=bare_rock
Johan Jönsson johan.j@... writes: This is an old proposal, that have been discussed before. It lead to a rewriting and instead of natural=rock it is proposed natural=bare_rock. http://wiki.openstreetmap.org/wiki/Proposed_features/bare_rock It is supposed to be a tag for land cover. A summary so far. There seem to be a need for a tag for areas of solid rock, bedrock, with visible rock surface. bare_rock could be used. It is then obvious that there also is a need for areas covered by loose rocks. The naming of the popular natural=scree suggest a particulate definition of a slope with rubble of different sizes. More distinct tags needed or a general tag. There have been a vivid discussion, one idea is to use natural=* for special named features, like scree, but use a land_cover=* for general tagging of the nature of an area. /Johan Jönsson ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Specific natural-tags for rock and stone.
In the discussion of natural=bare_rock I have found that there is need for a couple of different specific natural-tags for stone and rock land forms. for instance the boulder fields and other areas of lose rock that are not scree. It would be nice if we could find a hierachical tagging system in the same way as natural=wetland + wetland=bog see http://wiki.openstreetmap.org/wiki/Wetland and in natural=desert + desert=hammada see http://wiki.openstreetmap.org/wiki/Proposed_features/Deserts /Johan Jönsson ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - natural=bare_rock
Johan Jönsson johan.j@... writes: A summary so far. There seem to be a need for a tag for areas of solid rock, bedrock, with visible rock surface. bare_rock could be used. It is then obvious that there also is a need for areas covered by loose rocks. The naming of the popular natural=scree suggest a particulate definition of a slope with rubble of different sizes. More distinct tags needed or a general tag. There have been a vivid discussion, one idea is to use natural=* for special named features, like scree, but use a land_cover=* for general tagging of the nature of an area. I have some concerns on my proposal. I am taking the proposal back to status=draft if that is OK. It should be better off as a landcover=bare_rock instead, but that key is not really accepted. If used with the natural-key then it should at least be possible to use the same way as natural=wetland with subtags of wetland=.. natural=rockland :-) I started a new thread on that. Another concern is that the tag is only supposed to be used for solid rock, I am not sure how people are supposed to know that. And what to use for loose rock. /Johan Jönsson ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - natural=bare_rock
2011/1/31 Johan Jönsson joha...@goteborg.cc: If used with the natural-key then it should at least be possible to use the same way as natural=wetland with subtags of wetland=.. natural=rockland :-) I started a new thread on that. Not all rocky surfaces are natural, just like sand being used on golf courses and beach volley ball courts, even if they are not within 100s of km of an actual beach... Another concern is that the tag is only supposed to be used for solid rock, I am not sure how people are supposed to know that. And what to use for loose rock. Real world examples off the top of my head. Ayres Rock/Uluru is supposed to be 1 big lump of sand stone. http://upload.wikimedia.org/wikipedia/commons/f/fc/Uluru_%28Helicopter_view%29-crop.jpg You also have the cores of what were volcanoes, the outer dirt layer has eroded away completely over time http://lh3.ggpht.com/_PBYeriHIc4k/SfT3VgN4yvI/A0A/GKwEHYMKEcI/P1010343.JPG Just to throw a spanner in the works, both of which are natural formations :) As for loose rock, isn't that scree? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
