Re: [Tagging] Feature Proposal - RFC - addr:interpolation on closed ways and nodes

On Mon, Dec 21, 2020 at 2:15 PM ipswichmapper--- via Tagging < tagging@openstreetmap.org> wrote: > What do you mean by this? You would have to tag with addr:range=no, as > that is not a default value. > > However, don't see this as a downside. Currently, software such as OSMand > interprets

Re: [Tagging] Definition of lake/pond as applied to stream/plunge pools

On Mon, 21 Dec 2020 at 21:50, Kevin Kenny wrote: I don't think I've had the situation come up, but if it did, I'd probably > map the riverbank only once, and split the river at the fall and at the > outlet of the pool. Do the ordinary waterway=riverbank or water=river > mapping for the river as

Re: [Tagging] Fuzzy areas again: should we have them or not?

On Mon, Dec 21, 2020 at 1:56 PM Anders Torger wrote: > Do you think there is a valid use for fuzzy areas in outdoor/rural areas, > or would you rather see them not being used there either? > I've mentioned before that I, at least, have fuzzy administrative boundaries to deal with.

Re: [Tagging] Feature Proposal - RFC - addr:interpolation on closed ways and nodes

How would this break routing and navigation? As far as I know, geocoders currently read hypenated addresses as ranges anyway (correct me if I'm wrong) so this proposal won't change what happens to hypenated addresses without addr:range tag. (Ime. Navigation is already broken in NYC)

Re: [Tagging] Feature proposal - Voting - guard stone

C) Freestanding guardstone-like objects are often found independently of buildings. Those look like barrier=bollard perhaps? On Mon, Dec 21, 2020 at 9:33 AM Volker Schmidt wrote: > I forgot to follow up on two other aspects of this, sorry. > > A) how are they tagged when two of them are on

Re: [Tagging] Fuzzy areas again: should we have them or not?

On Mon, Dec 21, 2020 at 3:38 PM Anders Torger wrote: > I think it's more about that most OSMers are interested in urban areas, > street routing and stuff like that, and outdoor maps haven't really been > much of a thing other than for simple illustrative purposes. > Most OSM'ers are

Re: [Tagging] Fuzzy areas again: should we have them or not?

Sorry, forgot to add that an alternative to fuzzy areas would be to do like hamlet/village/town/city etc and have a bunch of these point names for various natural features that we could place out instead of fuzzy areas. Do you think that is better? That combined with an external database for

Re: [Tagging] Feature proposal - Voting - guard stone

On Tue, 22 Dec 2020, 01:02 Paul Allen, wrote: > On Mon, 21 Dec 2020 at 23:34, Volker Schmidt wrote: > > (perhaps the duck principle could be applied: it looks like a guardstone, >> it keeps the wheels on the road like a guard stone, hence it can tagged as >> a guard stone) >> > > Guardstones

Re: [Tagging] Feature Proposal - RFC - Reservoirs, lakes, and ponds

Yep. I know that. But for the tag to be on the deprecated tag list, it has to be deprecated in the wiki, I presume at least. That is my point. I don't think that JOSM will flag it deprecated because ID deprecated it, while the wiki still has it as a valid tag. That we will have to live with two

Re: [Tagging] Fuzzy areas again: should we have them or not?

Yeah I know of that github project and I'm thinking of that an approach of having small fuzzy areas in the main database, and huge ones in a separate might be the way to go. One reason to have big names separate and not the small ones could be that the big names will be "completely" mapped

Re: [Tagging] natural=fell not rendered, alternatives?

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

[Tagging] Feature proposal - Voting - guard stone

Hi, there haven't been any comments on it in a while, so I think it is safe to start the voting process on https://wiki.openstreetmap.org/wiki/Proposed_features/guard_stone Voting ends on January 4th. Thanks to everyone who contributed to the discussion and proposal page! Happy holidays,

Re: [Tagging] Fuzzy areas again: should we have them or not?

Hi, On 21.12.20 10:20, Anders Torger wrote: > In the mountains we have an number of named plateaus. There is a tag > proposal for natural=plateau, but just like with natural=peninsula and > similar tags there is an underlying question that we really need an > answer to first: should we have fuzzy

Re: [Tagging] Feature Proposal - RFC - Reservoirs, lakes, and ponds

2020-12-21, pr, 11:02 Volker Schmidt rašė: > Mass deprecations are counter-productive in general and independently of > whether they the new tagging is better in some way.. +1 ___ Tagging mailing list Tagging@openstreetmap.org

Re: [Tagging] natural=fell not rendered, alternatives?

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

Re: [Tagging] natural=fell not rendered, alternatives?

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"

Re: [Tagging] Proposed feature - RFC - Military Bases

Am Mo., 21. Dez. 2020 um 08:40 Uhr schrieb Mateusz Konieczny via Tagging < tagging@openstreetmap.org>: > Mapping military bases in Israel, Russia, mapping anything in China/North > Korea > etc should be welcomed in OSM if someone is doing this and wants that. > Mateusz, this is a quite

Re: [Tagging] Proposed feature - RFC - Military Bases

Dec 21, 2020, 13:01 by dieterdre...@gmail.com: > Am Mo., 21. Dez. 2020 um 08:40 Uhr schrieb Mateusz Konieczny via Tagging <> > tagging@openstreetmap.org> >: > >> >> Mapping military bases in Israel, Russia, mapping anything in China/North >> Korea >> etc should be welcomed in OSM if someone

Re: [Tagging] Feature Proposal - RFC - Emergency=Rescue Stations

Dec 20, 2020, 23:29 by graemefi...@gmail.com: > On Sun, 20 Dec 2020 at 17:55, Mateusz Konieczny via Tagging <> > tagging@openstreetmap.org> > wrote: > >> >> How objects tagged now with amenity=lifeboat_station should be tagged after >> this proposal passes? >> > > They were a late addition

Re: [Tagging] Feature Proposal - RFC - Reservoirs, lakes, and ponds

On Mon, 21 Dec 2020 at 09:02, Volker Schmidt wrote: > > That we will have to live with two tags, or more, for the same thing is > nothing new, what I don't like is to be pestered continuously to do things > to objects that happen to be in my downloaded area, and which I had no > intention even

Re: [Tagging] natural=fell not rendered, alternatives?

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

Re: [Tagging] natural=fell not rendered, alternatives?

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

Re: [Tagging] natural=fell not rendered, alternatives?

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

Re: [Tagging] Feature Proposal - RFC - addr:interpolation on closed ways and nodes

On Mon, Dec 21, 2020 at 02:37:08PM +0100, ipswichmapper--- via Tagging wrote: > https://wiki.openstreetmap.org/wiki/Proposed_features/addr:interpolation_on_closed_ways_and_nodes > > Quick proposal I just created to accept this form of tagging. This follows > from a discussion on the Talk-GB

Re: [Tagging] Fuzzy areas again: should we have them or not?

Thanks Frederik, if I interpret your answer correctly it is that we should not map these names at all (at least not within the scope of OSM database and OSM-Carto rendering), is that correct? As a mapper I would like to know what the strategy is so I don't waste my effort on dead ends. A

[Tagging] Feature Proposal - RFC - addr:interpolation on closed ways and nodes

https://wiki.openstreetmap.org/wiki/Proposed_features/addr:interpolation_on_closed_ways_and_nodes Quick proposal I just created to accept this form of tagging. This follows from a discussion on the Talk-GB mailing list. https://lists.openstreetmap.org/pipermail/talk-gb/2020-December/025553.html

Re: [Tagging] natural=fell not rendered, alternatives?

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

Re: [Tagging] natural=fell not rendered, alternatives?

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

Re: [Tagging] Feature Proposal - RFC - Reservoirs, lakes, and ponds

Thanks for the pointer, but It does not help. I'm an iD occasional basic user only. I am talking about the behaviour of JOSM. Maybe I am also JOSM ignorant regarding its functionalities. Virus-free.

Re: [Tagging] Fuzzy areas again: should we have them or not?

I forgot to comment this. Just want to make sure that there is no misunderstanding: this is not primarily about labeling the Alps or the Atlantic or the Sahara desert. It's mainly about making rural and outdoor maps useful for a local context. Maps that hikers, mountaineers and hunters use

[Tagging] Fuzzy areas again: should we have them or not?

Next question. In the mountains we have an number of named plateaus. There is a tag proposal for natural=plateau, but just like with natural=peninsula and similar tags there is an underlying question that we really need an answer to first: should we have fuzzy areas or should we not?

Re: [Tagging] natural=fell not rendered, alternatives?

(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

Re: [Tagging] natural=fell not rendered, alternatives?

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

Re: [Tagging] Feature Proposal - RFC - addr:interpolation on closed ways and nodes

Okay. In this case I can rename to proposal page to "addr:range". This new tag: - applies to nodes and closed ways that have addr:housenumber - "addr:range=n" means every nth house is counted in a range - "addr:range=even/odd" means every even/odd house is counted - "addr:range=all" means every

Re: [Tagging] Feature Proposal - RFC - crossing=priority

On 20/12/2020 08.54, ipswichmapper--- via Tagging wrote: - What should be considered a crossing? If it is unmarked, is it a crossing at all? (Should all intersections be tagged as "unmarked crossings"? Are places with traffic islands (no kerbs) where people frequently cross considered as

[Tagging] Definition of lake/pond as applied to stream/plunge pools

Discussion on the current reservoir proposal[1] (which seeks to define the distinction between reservoirs, lakes, and ponds) has brought up the question of stream/plunge pools[2,3], and how they fit into the lake/pond definitions. I've come up with the following text: "Occasionally a river or

Re: [Tagging] natural=fell not rendered, alternatives?

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"

Re: [Tagging] Feature Proposal - RFC - addr:interpolation on closed ways and nodes

I like this new tag. I had proposing something like that on my TODO list. I added it in https://www.openstreetmap.org/changeset/96211869 to mark addr:housenumber=1-3 as a single address, not a range (based on survey

Re: [Tagging] natural=fell not rendered, alternatives?

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.

Re: [Tagging] Fuzzy areas again: should we have them or not?

Dec 21, 2020, 16:42 by zelonew...@gmail.com: > > > On Mon, Dec 21, 2020 at 8:01 AM Frederik Ramm <> frede...@remote.org> > wrote: >   > >> Our current data model is not suitable for mapping fuzzy areas. We can >> only do "precise". Also, as you correctly pointed out, or basic tenet of >>

Re: [Tagging] Definition of lake/pond as applied to stream/plunge pools

On Mon, 21 Dec 2020 at 18:13, Brian M. Sperlongano wrote: > > "Occasionally a river or stream will form a stream pool or plunge pool, > which are bodies of water that naturally occur along the course of the > waterway. These waterbodies may either be tagged as a lake or (usually) > pond if they

Re: [Tagging] Fuzzy areas again: should we have them or not?

Thanks for the feedback Frederik, appreciate it. I don't think it's entirely fair though. I certainly don't write every day. Indeed I can write a lot as I'm quick on the keyboard, and I should probably try to be more on the point, that's fair. I have a tendency to get into sidetracks when

Re: [Tagging] Feature Proposal - RFC - addr:interpolation on closed ways and nodes

Would this work for addressing schemes that use a hyphenated prefix? In Hawaii, addresses outside of the city of Honolulu use a two-digit prefix in addresses to determine which sector of the island an address is located. So an address might be something like "99-123 Kamehameha Highway". Would

Re: [Tagging] Definition of lake/pond as applied to stream/plunge pools

> I think you need to expand a little on how to "conflate" a pool with a > river. The > disadvantage of doing so is that the pool then cannot have a name assigned. > Sorry, my words were not clear enough here. By "conflate" I mean that the pool would simply be part of the river polygon. See

Re: [Tagging] Fuzzy areas again: should we have them or not?

Cluttering could be a problem, but is an easy thing to solve with filters. As I edit i national parks now I have this huge national park polygon covering all work, which renders as a flat although half-transparent color in JOSM. It's easy to remove with a filter though, but actually I'm not

Re: [Tagging] Definition of lake/pond as applied to stream/plunge pools

On Mon, Dec 21, 2020 at 1:41 PM Paul Allen wrote: > On Mon, 21 Dec 2020 at 18:13, Brian M. Sperlongano > wrote: > >> >> "Occasionally a river or stream will form a stream pool or plunge pool, >> which are bodies of water that naturally occur along the course of the >> waterway. These

Re: [Tagging] Definition of lake/pond as applied to stream/plunge pools

On Mon, 21 Dec 2020 at 18:51, Brian M. Sperlongano wrote: > > >> I think you need to expand a little on how to "conflate" a pool with a >> river. The >> disadvantage of doing so is that the pool then cannot have a name >> assigned. >> > > Sorry, my words were not clear enough here. By

Re: [Tagging] Feature Proposal - RFC - addr:interpolation on closed ways and nodes

What do you mean by this? You would have to tag with addr:range=no, as that is not a default value. However, don't see this as a downside. Currently, software such as OSMand interprets hypenated addresses as a range anyway, so requirement to  tag addr:range=no would be a benefit.

Re: [Tagging] Fuzzy areas again: should we have them or not?

On Dec 21, 2020, at 10:53 AM, Anders Torger wrote: > Cluttering could be a problem, but is an easy thing to solve with filters. As > I edit i national parks now I have this huge national park polygon covering > all work, which renders as a flat although half-transparent color in JOSM. > It's

Re: [Tagging] natural=fell not rendered, alternatives?

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 >

Re: [Tagging] Fuzzy areas again: should we have them or not?

The fifth alternative is move the big areas to an outside repository: https://github.com/dieterdreist/OpenGeographyRegions This might be a great alternative until we find a better solution. And there might not be a better solution. Janko pon, 21. pro 2020. u 10:22 Anders Torger napisao je: >

Re: [Tagging] natural=fell not rendered, alternatives?

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

Re: [Tagging] Fuzzy areas again: should we have them or not?

Maybe we need to split "small" and "large" fuzzy areas into different concepts. Or at least different discussions, as they are quite different in terms of how they affect the map and what needs they fulfill. I do see a risk of edit wars of large fuzzy areas that make great impact on overview

Re: [Tagging] natural=fell not rendered, alternatives?

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"

Re: [Tagging] Feature proposal - Voting - guard stone

I forgot to follow up on two other aspects of this, sorry. A) how are they tagged when two of them are on both sides of a gate ? B) There are occasionally also rows of them in historic towns

Re: [Tagging] Fuzzy areas again: should we have them or not?

On Mon, Dec 21, 2020 at 8:01 AM Frederik Ramm wrote: > Our current data model is not suitable for mapping fuzzy areas. We can > only do "precise". Also, as you correctly pointed out, or basic tenet of > verifiability doesn't work well with fuzzy data. > The current data model works just fine

Re: [Tagging] Feature Proposal - RFC - Reservoirs, lakes, and ponds

On Mon, 21 Dec 2020 at 15:25, Volker Schmidt wrote: > Thanks for the pointer, but It does not help. I'm an iD occasional basic > user only. > Ah. I thought one of your main gripes was the iD was warning you about stuff you weren't editing. I am talking about the behaviour of JOSM. > I'm in

Re: [Tagging] Fuzzy areas again: should we have them or not?

2020-12-21, pr, 17:47 Brian M. Sperlongano rašė: > The current data model works just fine for fuzzy areas: it requires a polygon > combined with tagging that indicates that the area is "fuzzy". Since the > current > data model allows both polygons and tags, fuzzy areas could be mapped just >

Re: [Tagging] Fuzzy areas again: should we have them or not?

On Mon, 21 Dec 2020 at 15:47, Brian M. Sperlongano wrote: The current data model works just fine for fuzzy areas: it requires a > polygon combined with tagging that indicates that the area is "fuzzy". > Since the current data model allows both polygons and tags, fuzzy areas > could be mapped