Thanks Steve, good to know about the wiki, I had a hunch that was how
it's meant but wasn't really sure. Certainly descriptive for this tag. I
guess I could "take over" the fell tag but starting massively use it for
bare mountain landcover, but I shall look more closely into
alternatives.
Jus
Nice, Anders. You can use taginfo to get "the raw numbers" (quantity) of a
particular kind of tagging. What might work specifically for you in this case
is to use some well-crafted Overpass Turbo queries (over a specific area at
first, you can use the "bbox" method of "what you see on-screen"
I just discovered a strange(?) thing with the "natural=fell" tag which I
missed at first: on the wiki page there's two purposes defined of this
single tag, the first is landcover of bare mountain as discussed, and
the other purpose is, quote from the wiki:
"In the north of England, and probabl
On Dec 21, 2020, at 7:10 AM, Tomas Straupis wrote:
> 2020-12-21, pr, 16:52 Anders Torger rašė:
>> But what to do if the things you want doesn't
>> really fit into what OSM currently is and strives to be...
>
> We are ALL OSM community. If somebody tells you that "I am OSM and
> only A is right"
2020-12-21, pr, 16:52 Anders Torger rašė:
> But what to do if the things you want doesn't
> really fit into what OSM currently is and strives to be...
We are ALL OSM community. If somebody tells you that "I am OSM and
only A is right" - do not believe them.
YOU define what OSM is and where it
Good points.
I think Norway and Sweden is quite well-known for good maps for hikers
in the mountains (at least we think so ourselves :-) ), but indeed those
do not require as quick updates as there's not much changing out there
and so far no craftbeer on the top of Kebnekaise mountain. But may
2020-12-21, pr, 15:54 Anders Torger rašė:
> A local renderer would be limited in use <...>
Not necessarily ;-)
1. It could be a practical/visual proof of a "better way".
2. It could be a testing ground for finding solutions to some
international (wider than OSM, say ICA) cartographic problem
Thanks Tomas, much appreciated.
I guess you are right, but if local country cartography is the only way,
that lowers motivation to contribute a lot here locally. We have great
local maps already. To me the attraction of providing to OSM is that the
data gets broadly available in any end produc
2020-12-21, pr, 14:42 Anders Torger rašė:
> I personally want to see that the community work for a more defined
> mapping baseline with OSM-Carto as a strong reference, used as a
> motivational tool for crowd-sourcing, and as it is with the current
> provider landscape -- also work as an end produc
(Sorry if I missed a private message. I have a generic filter that
throws all emails that match tagging in some way to one mailbox and
sometimes I miss things.)
Anyway, I'm talking about globally distributed open source projects,
where you communicate in text over email and forums. Not a workp
On Dec 21, 2020, at 2:10 AM, Anders Torger wrote:
> I'm sorry if you experience it as that. Maybe I'm a bit too confrontational,
> and maybe I should express myself with a softer tone, I guess my style has
> become a bit shaped by to how we communicate engineer to engineer in
> programming proj
Thanks, good points and information.
Indeed, the fell tag seems to be a bit misused. I would guess it could
be because there are things actually named "Fell" there, and then
inexperienced mappers may use the Fell tag as that seems appropriate.
Incorrect use can be cleaned up in time though (fe
Steve,
I'm sorry if you experience it as that. Maybe I'm a bit too
confrontational, and maybe I should express myself with a softer tone, I
guess my style has become a bit shaped by to how we communicate engineer
to engineer in programming projects. That is the jargon can be quite
"hard" with
On 21/12/2020 07:39, Anders Torger wrote:
Hello,
I'm doing further mapping of Swedish national parks, now in the
mountains, and I have noted that natural=fell (habitat over tree line)
is not rendered.
Looking into why it seems that OSM-Carto implementors want more
specific landcover tags to
On Dec 20, 2020, at 11:39 PM, Anders Torger wrote:
> I'm doing further mapping of Swedish national parks, now in the mountains,
> and I have noted that natural=fell (habitat over tree line) is not rendered.
>
> Looking into why it seems that OSM-Carto implementors want more specific
> landcover
Hello,
I'm doing further mapping of Swedish national parks, now in the
mountains, and I have noted that natural=fell (habitat over tree line)
is not rendered.
Looking into why it seems that OSM-Carto implementors want more specific
landcover tags to be used. I don't think that (somewhat rand
On 5/1/20 12:12 PM, John Willis via Tagging wrote:
There is often overlap where I am where a wetland lives permanently in
the bottom of a basin, and the surrounding area is a park or sports
field. When there is a storm the basin fills up and wetland, pitch,
and parking lot end up under 3m of wa
If you are talking about a simple wetland you may find in a small pond or lake,
It’s easy, but natural formations are often very messy and complicated -
especially when a wetland covers an area larger than most villages.
There is often overlap where I am where a wetland lives permanently in the
> Vast areas of Australia are used to raise cattle, no tillage yet they are
'used' for farm land. And they are natural scrub...
These areas are considered "rangeland" in North American English. I would
not tag them as landuse=farmland, because they are only lightly touched by
human intervention, i
On 1/5/20 9:14 am, Graeme Fitzpatrick wrote:
On Fri, 1 May 2020 at 01:25, Florian Lohoff mailto:f...@zz.de>>
wrote:
I also do consider overlapping natural and landuses to be a bug,
either its a natural=scrub or a landuse=farmland. It cant be both.
Sorry, Florian, but why do you sa
On Fri, 1 May 2020 at 01:25, Florian Lohoff wrote:
I also do consider overlapping natural and landuses to be a bug,
> either its a natural=scrub or a landuse=farmland. It cant be both.
>
Sorry, Florian, but why do you say that?
I've seen a lot of farms with scrub on them!
Thanks
Graeme
__
On 30/04/2020 19:09, Paul Allen wrote:
On Thu, 30 Apr 2020 at 18:45, Andy Townsend via Tagging
mailto:tagging@openstreetmap.org>> wrote:
There are always going to be edge cases that aren't easy to
categorise. There's an area just up the road from where I am
currently that started o
On Thu, 30 Apr 2020 at 18:45, Andy Townsend via Tagging <
tagging@openstreetmap.org> wrote:
There are always going to be edge cases that aren't easy to categorise.
> There's an area just up the road from where I am currently that started out
> as https://www.openstreetmap.org/way/13866095
>
That'
On 30/04/2020 16:29, Joseph Eisenberg wrote:
> wetland area within a forest where trees are growing also within the wetland
area
That’s a “swamp”: natural=wetland + wetland=swamp
https://wiki.openstreetmap.org/wiki/Tag:wetland%3Dswamp
... or it might be seasonal or intermittent, depending on
> wetland area within a forest where trees are growing also within the
wetland area
That’s a “swamp”: natural=wetland + wetland=swamp
https://wiki.openstreetmap.org/wiki/Tag:wetland%3Dswamp
https://en.m.wikipedia.org/wiki/Swamp#Differences_between_marshes_and_swamps
_
On Thu, Apr 30, 2020 at 04:36:31PM +0200, Jean-Marc Liotier wrote:
> Consider a wetland that contains a water body. I'm used to map that as
> natural=water inside natural=wetland - no multipolygon fanciness, just one
> on top of the other. JOSM validator complains about it, which irks me, so I
> op
Hi,
I would create a multipolygon for that. Wetland is something different
than a lake/pond.
For wetland the wiki says, that wetland areas contain "characteristic
vegetation that is adapted to its unique soil conditions" [0]. A lake
obviously doesn't (at least no land-vegetation like grass and bu
Consider a wetland that contains a water body. I'm used to map that as
natural=water inside natural=wetland - no multipolygon fanciness, just
one on top of the other. JOSM validator complains about it, which irks
me, so I opened a ticket at https://josm.openstreetmap.de/ticket/19171 -
where mdk
sent from a phone
> On 30 Mar 2017, at 22:22, Juan Pablo Tolosa Sanzana
> wrote:
>
> Vice versa, the practice is mapping the baseline along the coastline.
in Italy there's a law with actual coordinates for the baseline, but AFAIK we
are generally using EU data in Europe for the maritime bor
I didn't know about the practice of mapping the coastline along the baseline,
AFAIK we don't map the baseline, only their 12nm offset (maritime borders)
Vice versa, the practice is mapping the baseline along the coastline.
But I think this is no a good idea, because baseline extend up a bit
On 30 March 2017 at 07:41, Juan Pablo Tolosa Sanzana
wrote:
> An exact limit between the open ocean and a sheltered coast is too arbitrary
> as natural feature. It seems a political issue. You can use
> boundary=maritime + border_type=baseline for excluding internal waters from
> the open ocean, a
sent from a phone
> On 30 Mar 2017, at 01:06, Eugene Alvin Villar wrote:
>
> because UNCLOS allows countries to specify a baseline separate from the
> coastline that encloses parts of the sea/ocean (thereby making those parts
> internal waters of the country) .
I thought the baseline was g
By default baselines match with mean low water spring, meanwhile
natural=coastline is tagged at mean high water spring.
It would be good define some rules related to maritime boundaries don't
agree with UNCLOS, .e.g. peruvian boundary extends up 200 miles away the
coastline.
I don't know the Australian baseline, this is only an example. Sometimes
the countries define a straight baseline that close a bay. Of course,
Andrew have the freedoom to use, e.g. the tag description=* to do the
mentioned difference.
> No, it is not a political issue, the position of the base
On Thu, Mar 30, 2017 at 4:41 AM, Juan Pablo Tolosa Sanzana <
jptolosanz...@gmail.com> wrote:
> An exact limit between the open ocean and a sheltered coast is too
> arbitrary as natural feature. It seems a political issue. You can use
> boundary=maritime + border_type=baseline for excluding interna
On Wednesday 29 March 2017, Juan Pablo Tolosa Sanzana wrote:
> An exact limit between the open ocean and a sheltered coast is too
> arbitrary as natural feature. It seems a political issue. [...]
No, it is not a political issue, the position of the baseline is not in
doubt here. If Andrew wants
An exact limit between the open ocean and a sheltered coast is too
arbitrary as natural feature. It seems a political issue. You can use
boundary=maritime + border_type=baseline for excluding internal waters
from the open ocean, according of laws of the country. Check the article
https://en.wik
sent from a phone
> On 29 Mar 2017, at 14:00, Andrew Harvey wrote:
>
> I'd also like to consider how to tag rias, so we can differentiate
> between a ria and the open ocean.
the tag is natural=ria
cheers,
Martin
___
Tagging mailing list
Tagg
I've learned a lot from the comments here, based on others comments I
think the solution to my issue is to use a tag like like
coastline=pelagic (from wikipedia "A pelagic coast refers to a coast
which fronts the open ocean, as opposed to a more sheltered coast in a
gulf or bay.") on the oceanic co
No, I just tagged the edge of the bay as natural=coastline because this
is the top of the tidal range. Even being more rigorous the
natural=coastline must be shifted far away towards west of current
position. The lower part of Georges River is a typical ria: an
unglaciated valley submerged into
On Tuesday 28 March 2017, Andrew Harvey wrote:
> >
> > A waterbody where plant and animal life matches or is close to that
> > of the sea rather to that of a river or lake.
>
> I think it's a grey area, it's not completely like a river, nor that
> of the sea. But in this case, I'm not sure, what in
Initially I was concerned that by changing the tagging from
natural=water, water=bay to natural=bay that the whole bay would be
rendered as land since that's what the wiki suggests. I now see that
the same user changed the edges of the bay to be natural=coastline to
prevent this.
I'm agree now tha
El 27/03/17 a las 16:48, Juan Pablo Tolosa Sanzana escribió:
>>/It is a bay of the Tasman Sea/Pacific Ocean. Ecologically it is a fully />
maritime waterbody.
>
> What do you mean by "maritime waterbody"?
A maritime waterbody are all those waters under the influence of the tides. You can
rev
/It is a bay of the Tasman Sea/Pacific Ocean. Ecologically it is a fully />
maritime waterbody.
What do you mean by "maritime waterbody"?
A maritime waterbody are all those waters under the influence of the tides. You can
review article for natural=coastline. The coastline should be placed i
I don't think it does to be too fussy about what is 'river' and what is
'sea' and what is 'estuary'.
Near where I live, a hydrologist would classify the Hudson River as
'estuary' as far as http://www.openstreetmap.org/way/90929525 because it
has a measurable tide right up to that point. Neverthele
On Monday 27 March 2017, Andrew Harvey wrote:
> > It is a bay of the Tasman Sea/Pacific Ocean. Ecologically it is a
> > fully
>
> maritime waterbody.
>
> What do you mean by "maritime waterbody"?
A waterbody where plant and animal life matches or is close to that of
the sea rather to that of a r
bay and its connection to the sea compared to the discharge of the
> river.
>
> More elaborate discussion of the matter can be found on the wiki:
>
> http://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement
>
> As said a bay is not a separate waterbody in OS
found on the wiki:
http://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement
As said a bay is not a separate waterbody in OSM so if you consider
something a bay you need to decide what it is a bay of. Tagging
natural=water + water=bay is always factually
On 27 March 2017 at 21:35, Martin Koppenhoefer wrote:
> as there's the coastline as well, it shouldn't produce any problem to remove
> natural=water from the bay. We generally don't add natural=water to the sea:
> https://www.openstreetmap.org/way/148455492#map=13/-33.9809/151.2086
> because they'
On Monday 27 March 2017, Andrew Harvey wrote:
> The wiki for natural=bay says "Since bays are generally part of a
> larger waterbody, either a lake or the ocean, they should not be
> rendered in solid color indicating water themselves."
>
> This creates a conflict with a recent change to Botany Bay
2017-03-27 12:29 GMT+02:00 Andrew Harvey :
>
> What should we do to fix this? Change the wiki to note that it should
> be rendered as water and fix renders?
as there's the coastline as well, it shouldn't produce any problem to
remove natural=water from the bay. We generally don't add natural=w
The wiki for natural=bay says "Since bays are generally part of a
larger waterbody, either a lake or the ocean, they should not be
rendered in solid color indicating water themselves."
This creates a conflict with a recent change to Botany Bay
https://www.openstreetmap.org/relation/1214649 in
http
I have been tagging a big bunch of natural=river_terrace in eastern
Senegal. The features that I have been tagging are ridges that follow
the course of a river in rocky terrain - not quite a canyon, but more
abrupt than a valley... I could have tagged them as natural=ridge but I
stumbled upon natur
Others gave opinions, I agree with a lot of statements.
So let me give a round of personnal agreement (+1's) to these:
> Personally I would prefer an approximate polygon to a node.
> I don't like boundary=informal though. It should be something more verbose
> regarding what kind of region this
Am 28.03.2016 um 08:28 schrieb Martin Koppenhoefer:
Am 27.03.2016 um 21:59 schrieb Colin Smale :
If we can't mark polygons as fuzzy, then we can only allow 'accurate' polygons
well, as was proposed above, we could introduce a way to store fuzzy areas
without using polygons, or by using more th
sent from a phone
> Am 27.03.2016 um 21:59 schrieb Colin Smale :
>
> If we can't mark polygons as fuzzy, then we can only allow 'accurate' polygons
well, as was proposed above, we could introduce a way to store fuzzy areas
without using polygons, or by using more than one polygon as one obje
The precision/accuracy is not only limited by the instruments used but
also the knowledge used.
For some things OSM has access to very precise data. In other instances
it is fuzzy. For some things .. the past entries has been much improved
by new data from other sources (sometimes opening of
This sort of object is common in Thailand. We have many gated communities
here whose boundaries are not exactly known although they are sometimes
fairly obvious in aerial imagery because of being surrounded by a wall or
fence of some sort. I create a polygon using Bing imagery, tag it as
place=neig
Fuzzy boundaries do have their place. Currently we use sharp boundaries for
landuse, but often the boundary is really fuzzy. A wooded area would be a
good example of a where a fuzzy boundary might be employed. But the
fuzziness of a wooded area may only be a few meters. The fuzziness
of "Shakespear
If we can't mark polygons as fuzzy, then we can only allow 'accurate'
polygons. Then we are back to square one, with no way of accommodating
these regions except for a simple node.
I think the problem is clear (how do we represent regions whose
boundaries are not precisely defined). Time to talk
Den 27. mars 2016 21.36.01 CEST, skrev Martin Koppenhoefer
:
>
>
>sent from a phone
>
>> Am 27.03.2016 um 21:16 schrieb Anders Fougner
>:
>>
>> Did you already consider a fuzzy tag (such as fuzzy=yes or
>boundary_fuzzy=yes)?
>
>
>that's a makeshift which isn't quite elegant and still has simila
sent from a phone
> Am 27.03.2016 um 21:16 schrieb Anders Fougner :
>
> Did you already consider a fuzzy tag (such as fuzzy=yes or
> boundary_fuzzy=yes)?
that's a makeshift which isn't quite elegant and still has similar problems
(things that seem to be in might be out and vice versa).
ch
sent from a phone
> Am 27.03.2016 um 20:50 schrieb Clifford Snow :
>
> I agree using polygons is far superior to nodes. The question I'm raising is
> do these fuzzy areas belong in OSM.
agreed, adding fuzzy areas in a way that suggests they are well delimited areas
(polygons) is questionabl
>I agree using polygons is far superior to nodes. The question I'm
>raising
>is do these fuzzy areas belong in OSM. Using my example for the
>Cascadia
>(Independence Area) a polygon with the boundary could be used to search
>for
>features in the OSM database.
>
>Clifford
Did you already consider
On Sun, Mar 27, 2016 at 11:20 AM, Martin Koppenhoefer <
dieterdre...@gmail.com> wrote:
> well, this didn't prevent 12% of mappers to add neighborhoods as areas
> anyway: http://taginfo.osm.org/tags/place=neighbourhood
>
The discussion was around neighborhoods that did not have a clear boundary,
n
sent from a phone
> Am 27.03.2016 um 19:00 schrieb Mateusz Konieczny :
>
> Areas with completely undefined borders should not be stored in OSM.
who if not the crowd would be able to iteratively come to approximations of
these borders. As long as the existence of the area is not disputed all
sent from a phone
> Am 27.03.2016 um 18:50 schrieb Clifford Snow :
>
> A while back one of the conversations on the mailing list was about adding
> neighborhood boundaries. There was a lot of concern that many neighborhood
> boundaries are not clearly define which would result in boundary dis
boundary for an
> >> informal area any different?
> >>
> >> Worse, if we start adding informal boundaries I can see someone
> >> wanting to add the Cascadia [1] (Independance Movement) boundary.
> >>
> >>
> >>
> >> [1]
> >https://e
not clearly define which would result in
>> boundary disputes. How is adding a rough boundary for an informal
>> area any different?
>>
>> Worse, if we start adding informal boundaries I can see someone
>> wanting to add the Cascadia [1] (Independance Movement) boundary.
>&
start adding informal boundaries I can see someone
> wanting to add the Cascadia [1] (Independance Movement) boundary.
>
>
>
> [1] https://en.wikipedia.org/wiki/Cascadia_%28independence_movement%29
>
> Clifford
>
Given that idea of tagging natural=ba
On Sun, Mar 27, 2016 at 9:18 AM, Martin Koppenhoefer wrote:
> I agree that a rough polygon seems better than a node because it allows to
> estimate the size (a new relation datatype would even be better, like a
> collection of (existing/already mapped) things inside (role) and outside
> (role) th
sent from a phone
> Am 27.03.2016 um 11:47 schrieb Colin Smale :
>
> In the UK the word "country" is also used in that context, for example
> "Shakespeare Country", "White Cliffs Country", "Black Country".
>
> I would suggest a relation with type=boundary and boundary=informal, plus an
> ind
On Sunday 27 March 2016, David Marchal wrote:
> Hello, there.
> At least here, in France, there are numerous regions, whose unity is
> based either on a common historical background, for example as a
> medieval county or duchy like the Barrois, or on a uniform natural
> landscape, as the Bauges mou
Good question.
In the UK the word "country" is also used in that context, for example
"Shakespeare Country", "White Cliffs Country", "Black Country".
As to whether a node or a polygon should be used... Personally I would
prefer an approximate polygon to a node. A node may indicate location,
but
Hello, there.
At least here, in France, there are numerous regions, whose unity is based
either on a common historical background, for example as a medieval county or
duchy like the Barrois, or on a uniform natural landscape, as the Bauges
mountains or the Mont Blanc massif. These regions are of
Am 07.02.2016 19:03, schrieb Martin Koppenhoefer:
> I'm not very familiar with how the proposed templates work (which ones are
> actually in use) but it doesn't seem as if defacto was a valid status now:
> http://wiki.openstreetmap.org/w/index.php?title=Template:Proposal_Status
The status "defac
sent from a phone
> Am 07.02.2016 um 17:51 schrieb Tobias Knerr :
>
> The "approved" setting isn't about usage reality, though, but about the
> proposal process. As this tag has, as far as I know, never been formally
> approved (not that it needs to), "defacto" would be preferable.
yes, you'r
Am 07.02.2016 09:20, schrieb Martin Koppenhoefer:
> in this particular case I'd say that setting the wiki docu to approved seems
> consistent with the atual usage reality.
The "approved" setting isn't about usage reality, though, but about the
proposal process. As this tag has, as far as I know,
sent from a phone
> Am 06.02.2016 um 22:43 schrieb Warin <61sundow...@gmail.com>:
>
> The key 'natural' was marked status approved in 2014 ... nothing on the tag
> list
I'm participating in OSM since early 2008 and can assure you that natural=wood
already was an established tag by that time
On 7/02/2016 3:22 AM, Lauri Kytömaa wrote:
On Thu, Feb 4, 2016 Warin wrote:
The wiki page for natural=wood has the status shown as 'approved'.
This was set to 'approved' on 20th May 2010.
Many major basic tags were included in a list written in I-believe-it-was
2006, i.e. on the original Map
On Thu, Feb 4, 2016 Warin wrote:
> The wiki page for natural=wood has the status shown as 'approved'.
> This was set to 'approved' on 20th May 2010.
Many major basic tags were included in a list written in I-believe-it-was
2006, i.e. on the original Map Features page. The tag status templates,
ta
Hi,
The wiki page for natural=wood has the status shown as 'approved'.
http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwood
This was set to 'approved' on 20th May 2010.
I have gone back through the tagging list archives (starts October 2009)
and seen no discussion on natural=wood, cannot find
"where you want renderers to display arete signatures" - Tagging for
renderer/geocoder
is a poor idea.
Anyway, way would be splitted both with [natural=arete] and [natural=ridge;
ridge=arete].
2014-11-06 7:02 GMT+01:00 Friedrich Volkmann :
> On 05.11.2014 12:23, Richard Z. wrote:
> > Another re
"This doesn't matter in this particular case, because natural=ridge and
natural=arete were approved at the same time."
It is about futureproof solution - new values may appear and break existing
data consumers. Adding subtags would not cause problems like this.
"That's why we have a wiki with de
On 05.11.2014 12:23, Richard Z. wrote:
> Another reason I don't like current arete/ridge state is that some ridges are
> very long - and they may be partially arete and ridge in different segments.
> Having a way that is tagged partially as natural=ridge and partially as
> natural=arete seems like
On 05.11.2014 07:19, Mateusz Konieczny wrote:
> And it is not just because with the second solution new values
> for main tag will quickly appear (see building=*).
This doesn't matter in this particular case, because natural=ridge and
natural=arete were approved at the same time.
> With second
>
On 05.11.2014 10:01, Martin Koppenhoefer wrote:
> arguably it is not too late, there are only 450 uses of arete by now (and
> 17K+ ridges).
450 uses are quite a lot for a feature that is constantly ignored by renderers.
For the same reason, I suppose that some of the 17K+ ridges were created by
Mateusz: "arête" is usually spelled "arete" in my experience (reading
climbing websites).
I don't like natural=arete much, partly for the reasons mateusz outlines,
and partly because of ambiguity in the meaning of the term. My familiarity
with the term comes from being a mountaineer in western Can
2014-11-05 12:23 GMT+01:00 Richard Z. :
> after two years in the wiki where it was marked as approved and active it
> would not appear as a great idea to declare the vote for invalid based on
> nitpicking formalities, how many votes were missing for approval?
>
it was 50% missing (5 people)
A
On Wed, Nov 05, 2014 at 10:01:47AM +0100, Martin Koppenhoefer wrote:
> 2014-11-04 22:56 GMT+01:00 Friedrich Volkmann :
>
> > This discussion comes late. Both natural=ridge and natural=arete have been
> > approved by voting just 2 years ago.
> >
>
>
> arguably it is not too late, there are only 4
2014-11-04 22:56 GMT+01:00 Friedrich Volkmann :
> This discussion comes late. Both natural=ridge and natural=arete have been
> approved by voting just 2 years ago.
>
arguably it is not too late, there are only 450 uses of arete by now (and
17K+ ridges). Please also note that the tag "natural=are
"Whether to use subtags is mainly a matter of taste."
No. Lets say that there is something with four main values that are
noticeable for general public and several subtypes, important for
specialists.
For data consumers interested in just four values version with subtags
is vastly easier to use c
On 04.11.2014 14:04, Mateusz Konieczny wrote:
> I think that natural=arete should be rather subtag of natural=ridge
> (natural=ridge; ridge=arete).
This discussion comes late. Both natural=ridge and natural=arete have been
approved by voting just 2 years ago. And I think that there's nothing wrong
2014-11-04 13:58 GMT+01:00 Richard Z. :
> personaly I would prefer a single ridge
> key with additional subkeys denoting properties such as gentle,sharp, cliff
> ridges.
>
+1
or the subkey variant Mateusz has offered.
cheers,
Martin
___
Tagging mailin
I think that natural=arete should be rather subtag of natural=ridge
(natural=ridge; ridge=arete).
It is opening way for next specialized tags - what will make using data
significantly harder.
2014-11-04 13:58 GMT+01:00 Richard Z. :
> Hi,
>
> following some discussions on github (1) and talk-at (2
Hi,
following some discussions on github (1) and talk-at (2) I have tried
to clarify the definition of natural=ridge in the wiki
http://wiki.openstreetmap.org/w/index.php?title=Tag:natural%3Dridge&diff=1104725&oldid=998905
Not sure if this is good enough, personaly I would prefer a single ridg
I think this appears to be the reference Richard mentioned:
http://www.iho-ohi.net/iho_pubs/standard/S-23/S23_1953.pdf
On Thu, Oct 30, 2014 at 6:51 AM, Richard Z. wrote:
> On Thu, Oct 30, 2014 at 08:41:18AM +0100, Marc Gemis wrote:
> > Could we try an example to see whether mappers agree on bay
On Thu, 30 Oct 2014, Marc Gemis wrote:
> Could we try an example to see whether mappers agree on bay areas ? could
> you draw the Gulf of Biscay on a map ?
> This guy did it:
> http://1.bp.blogspot.com/_-9_Y031ZiZQ/THowBMn81dI/Ci8/inSvDDa1DC4
> /s1600/Golf+van+Biskaje.jpg
> I might have
On 30.10.2014 12:51, Richard Z. wrote:
their definition of gulf of mexico is obviously
not compatible with our definition of bay
IMHO: this has some similarities to definition of regions like "the
Alps" or "the Rocky Mountains"...
Cheers,
Michael.
___
On Thu, Oct 30, 2014 at 08:41:18AM +0100, Marc Gemis wrote:
> Could we try an example to see whether mappers agree on bay areas ? could
> you draw the Gulf of Biscay on a map ?
>
> This guy did it :
> http://1.bp.blogspot.com/_-9_Y031ZiZQ/THowBMn81dI/Ci8/inSvDDa1DC4/s1600/Golf+van+Biskaje.
1 - 100 of 200 matches
Mail list logo