Re: [Tagging] Updating definition and description of place=square

W dniu 27.03.2020 o 23:30, Paul Allen pisze: > The first words of the first sentence of the first paragraph of that > WP article: > "Piccadilly Circus is a road junction and public space..."  Public > space, so > as far as OSM tagging based upon British English goes, place=square. And later in

Re: [Tagging] Updating definition and description of place=square

W dniu 24.03.2020 o 13:11, Martin Koppenhoefer pisze: > We did not so far define the words "street" or "road". It is taken as > granted in the highway tag definitions that you know what it is. That is close to the grassroot style of OSM - people use the tags they think apply the best in their

Re: [Tagging] Updating definition and description of place=square

W dniu 22.03.2020 o 20:20, Martin Koppenhoefer pisze: > squares can be of all shapes, triangular, rectangular, poligonal > (regular or not), elliptical, round, etc. In other languages than English this might not be even related to geometry, like in Polish ("plac, skwer", not a "kwadrat"), and I

Re: [Tagging] Feature Proposal - RFC - Tag:amenity=motorcycle_taxi

W dniu 20.02.2020 o 08:48, Joseph Eisenberg pisze: > I would like to formally request comments on the proposal for > amenity=motorcycle_taxi: > > "A place where motorcycle taxis wait for passengers" > > https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:amenity%3Dmotorcycle_taxi I propose

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

W dniu 06.02.2020 o 17:25, Christoph Hormann pisze: > Rendering such in OSM-Carto would not be mapper support, it would be > sabotage. As much as I disagree with you on what should be rendered or not (and why), I understand how sure you are of you about your opinions. But the thing that bothered

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

W dniu 03.08.2019 o 02:28, Joseph Eisenberg pisze: > Consider also how you would route someone from a amenity=cafe node in > a building to a shop=* area in another building across the city, by > car. You have to jump from the node to the nearest highway, follow the > highways to the other side of

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

W dniu 02.08.2019 o 17:07, Markus pisze: > On Friday, August 2, 2019, Daniel Koć <mailto:daniel@ko%C4%87.pl>> wrote: > > Without using stop_positions, updating public transport routes in > a (semi-)automated way in a big city (like Warsaw) would be > i

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

W dniu 02.08.2019 o 15:53, Janko Mihelić pisze: > If we removed stop_positions, that makes creating public transport > relations much easier. I'm not involved in this detailed discussion, so I apologise if I don't get everyting, but better be safe than sorry... Without using stop_positions,

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

W dniu 01.08.2019 o 02:56, Joseph Eisenberg pisze: > I’m not certain if any database users actually manage stop_area > relations for public transit? I'm not sure if you ask if stop_area tag is useful at all or you ask only about such relation. In Warsaw there are like 300 lines, if I remember

Re: [Tagging] Verifiability of geometry

W dniu 16.06.2019 o 21:20, Christoph Hormann pisze: > You have stated disagreement with several of these statements but you > have not challenged them in any way by pointing out a logical error or > by arguing why the suggested approach how mappers should decide on how > to map things is of

[Tagging] Verifiability of geometry

Hi, There are still some problems with verifiability of objects geometry. This has been discussed lately here: https://github.com/gravitystorm/openstreetmap-carto/pull/3750 but we came to the conclusion that this is not the best place to go with fundamental problems, so I come here to talk

Re: [Tagging] Verifiability wiki page: "Geometry" section added

W dniu 28.04.2019 o 11:43, Joseph Eisenberg pisze: > "Linear ways and areas can be non-verifiable if the geometry cannot be > demonstrated to be true or false by another mapper. It sounds like for some reason nodes are more verifiable. I believe this does not work that way. I see an assumption

Re: [Tagging] Stop the large feature madness

W dniu 17.04.2019 o 21:47, Mateusz Konieczny pisze: > Apr 17, 2019, 7:34 PM by geodes...@gmail.com: > > If everyone on Earth joined OSM and limited their mapping > to their own local knowledge using that rule of thumb, our map > would look like this :-)   http://bit.ly/2IGkgoj > Nice

Re: [Tagging] Waterway length

W dniu 16.02.2019 o 15:00, Sergio Manzi pisze: > On 2019-02-16 14:46, Eugene Podshivalov wrote: >> Calculated value may differ from the official one ... > > Official according to whom? > Good question - who can we trust? The question is also how to calculate them? If a river has a fork (or even

Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)

W dniu 10.01.2019 o 22:29, Christoph Hormann pisze: > On Thursday 10 January 2019, Markus wrote: >> I've replaced *nearly surrounded by water* with *surrounded by water >> on the majority of its border*, but i'm unsure whether this is >> clearer. If you or someone has a better idea, please tell

Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)

W dniu 05.01.2019 o 13:06, Christoph Hormann pisze: > natural=cape means what it is used for in OSM > and this - at least until > > https://github.com/gravitystorm/openstreetmap-carto/pull/3452 > > had nothing even remotely to do with peninsulas. This meaning is > described on the wiki (and

Re: [Tagging] emergency=control_centre

W dniu 10.12.2018 o 00:33, EthnicFood IsGreat pisze: > That is an unrealistic, pie-in-the-sky goal.  As long as mappers are > free to use any tag they like, and OSM is a mishmash of tags, how > could anyone rely on it for anything very important? Good question. And the answer is - don't

Re: [Tagging] Can OSM become a geospacial database?

W dniu 09.12.2018 o 12:34, Eugene Podshivalov pisze: > How would you map American "streamlet", "brook", "creek" and "river" > to the two generic "stream" and "river" in OSM? > Currently they are just putting in the name field, so the only ways to > fide all "brooks" is by searching the name fields

Re: [Tagging] emergency=control_centre

W dniu 09.12.2018 o 19:54, dktue pisze: > By the way: We're currently using amenity=fire_station und > emergency=ambulance_station -- which is confusing in my opinion. Maybe it would be good to use emergency=police_station scheme (and maybe something else for other police-related objects, like

Re: [Tagging] Tourism=attraction: feature or secondary tag?

W dniu 07.12.2018 o 12:23, Christoph Hormann pisze: > The changes i refer to with my comment are in particular the > inflationary addition of new POI symbols many of which have been chosen > without considering the applicability to represent the feature type in > question across different

Re: [Tagging] Tourism=attraction: feature or secondary tag?

W dniu 06.12.2018 o 10:47, Christoph Hormann pisze: > On Thursday 06 December 2018, Yves wrote: >> tourism=attraction can be added to a lot of features indeed, that's >> why I think the label rendering in OSM-carto is a good idea because >> you will probably never find a common rendering to

Re: [Tagging] Tourism=attraction: feature or secondary tag?

W dniu 05.12.2018 o 11:40, Christoph Hormann pisze: > It would certainly be good to stop rendering it to incentivize mappers > to choose more meaningful tags instead but it also should be said that > this is essentially a case of 'damage done' - the tag is already > meaningless, stopping to

Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

W dniu 29.11.2018 o 22:48, Doug Hembry pisze: > Would  you also render boundary=protected_area if protect_class=* is > absent entirely? I think this would be a good idea. They are too general conceptually, so I try to stay on the safe side. As you can see with current topic, even this specific

Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

W dniu 29.11.2018 o 11:38, Martin Koppenhoefer pisze: > I am also not sure any more whether we should put all kinds of > protected areas in the same bucket, maybe there could already be a > first class distinction between natural protection, resource > protection and social protection. I was

Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

W dniu 28.11.2018 o 17:23, Doug Hembry pisze: > The point is taken about the workload and lack of coders. It has > always amazed me that the team manages to produce a robust, attractive > and coherent map from the disparate tagging styles and sometime > slightly weird practices that can be found

Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

W dniu 28.11.2018 o 03:49, Joseph Eisenberg pisze: > Re “Have we found the covert reason why carto still doesn't render > [Protected areas]” > > No need for conspiracy theories. We simply need more contributors at > openstreetmap-carto who are willing to volunteer their time to fix > these issues.

Re: [Tagging] Feature Proposal - RFC - Mapping disputed boundaries

W dniu 27.11.2018 o 03:21, Johnparis pisze: > A general proposal to address mapping disputed borders at the national > level. What is the link to this RFC? This one seems to be old and abandoned: https://wiki.openstreetmap.org/wiki/Proposed_features/DisputedTerritories -- "Excuse me, I have

Re: [Tagging] Feature Proposal - RFC - landuse=governmental

W dniu 24.11.2018 o 16:20, Allan Mustard pisze: > > I don't think OSM should be in the business of writing its own > dictionary and defining terms independently of the rest of society.  > That's a slippery slope. > We should not diverge too far from common meaning, but sometimes it needs some

Re: [Tagging] Using multipolygons to map bays in Alaska

W dniu 17.11.2018 o 12:27, Frederik Ramm pisze: > But I felt in this situation, they had overstepped their mandate, > *especially* because they were not reacting to something that people > were doing, but actively creating a new feature ("hey, you can now have > huge named bays") and at the same

Re: [Tagging] Using multipolygons to map bays in Alaska

W dniu 17.11.2018 o 02:00, Christoph Hormann pisze: > On Saturday 17 November 2018, Daniel Koc4� wrote: >> The problem is that I have asked you how to draw verifiable node, >> [...] > No, you have not, you have asked: > >> It would be much more useful if you tell now how to verify position >> of

Re: [Tagging] Using multipolygons to map bays in Alaska

W dniu 16.11.2018 o 14:31, Christoph Hormann pisze: > Quoting from: Thanks, that was really helpful answer. The problem is that I have asked you how to draw verifiable node, not "what is a good practice for drawing a node using verifiable operations". Let's look closer: > in the middle

Re: [Tagging] Using multipolygons to map bays in Alaska

W dniu 16.11.2018 o 12:24, Christoph Hormann pisze: > Yes, as already said i understand that and this is why i do not > primarily blame you or other mappers for using non-verifiable drawings > to map bays and straits but Daniel for incentivizing that for > ultimately selfish reasons. Using

Re: [Tagging] Using multipolygons to map bays in Alaska

W dniu 15.11.2018 o 12:08, Christoph Hormann pisze: > The 'polygons is universally the preferred way of mapping no matter if > verifiable or not' and 'way_area equals cartographic importance' > concepts have been meanwhile extended to natural=strait in OSM-Carto - > thereby not only

[Tagging] Petroleum extraction

Hi, We are trying to make rendering for petroleum wells in OSM Carto, but it seems to be twisted: https://github.com/gravitystorm/openstreetmap-carto/issues/3494 There are two different, probably overlapping tags for that, and both have some problems:

Re: [Tagging] Feature Proposal - RFC - (consulate)

W dniu 01.11.2018 o 09:12, Warin pisze: > A problem will be the lack of rendering for some time. Speaking of rendering - it might be useful to know that there is a map service called OpenDiplomaticMap, which is also a quality assurance tool: https://anders.hamburg/osm/diplomatic -- "Excuse

Re: [Tagging] Area with restaurants, hotels, cinemas - is it landuse=commercial?

W dniu 28.10.2018 o 23:14, Graeme Fitzpatrick pisze: > On Mon, 29 Oct 2018 at 07:32, Mateusz Konieczny > mailto:matkoni...@tutanota.com>> wrote: > > Based on my understanding of term "commercial ara" and how landuse > tagging is used in OSM > I think that area with restaurants, hotels,

Re: [Tagging] Feature Proposal - RFC - (consulate)

W dniu 26.10.2018 o 22:08, Eugene Alvin Villar pisze: > > On the other hand. diplomatic offices and services encompass a range > that is much too narrow such that I don't think having diplomatic=* as > a primary key seems appropriate. I would prefer if we just have the > office=diplomatic +

Re: [Tagging] Feature Proposal - RFC - (consulate)

W dniu 26.10.2018 o 21:27, Allan Mustard pisze: > > Regarding the question of using office=* as the primary key or > diplomatic=* I note that the Key:diplomatic wiki article admonishes: > > Note > Do not use diplomatic=* without amenity=embassy since it is not > independently

Re: [Tagging] Feature Proposal - RFC - (consulate)

W dniu 26.10.2018 o 20:52, Paul Allen pisze: > > If you can come up with a better value than "diplomatic" then do so.  > If you don't like it being under > the office key, maybe have diplomatic=* as the primary key rather than > a secondary key under > office (although that may well contravene OSM

Re: [Tagging] Radio telescopes

W dniu 25.10.2018 o 13:30, Andrew Harvey pisze: > What's the recommended tagging for radio telescopes like > https://en.wikipedia.org/wiki/Canberra_Deep_Space_Communication_Complex > which are parabolic dishes which are used for two way communication? I am not interested in the subject, but from

Re: [Tagging] Radio telescopes

W dniu 25.10.2018 o 12:37, Andrew Harvey pisze: > On Thu, 25 Oct 2018 at 21:08, Joseph Eisenberg > wrote: >> Please don’t tag radio telescopes with tower:communication. Telescopes >> observe, they do not communicate or send information. > https://en.wikipedia.org/wiki/List_of_radio_telescopes

Re: [Tagging] Upcoming removal of power=station and power=sub_station in the standard style

W dniu 22.10.2018 o 18:17, Mateusz Konieczny pisze: > I agree that manual review  of anything improbes map, but I am not sure > > why mistagged power=sub_station is better or worse than mistagged > > power=substation > I think that in this case automatic update is a victim of general thinking

Re: [Tagging] Upcoming removal of power=station and power=sub_station in the standard style

W dniu 22.10.2018 o 13:07, Volker Schmidt pisze: > Regarding sub_station, there seems to have been  a  revert three month > ago of the results of a maproulette task Thanks for the info - I have asked who complained, so we could talk. I also asked the author of the wiki warning against

Re: [Tagging] Upcoming removal of power=station and power=sub_station in the standard style

W dniu 22.10.2018 o 05:06, Dave Swarthout pisze: > It would seem an easy fix to change all power=sub_station tags to > power=substation without an individual inspection. I'm surprised that automated conversion is discouraged on the wiki page in this case. Seems like simple 1:1 objects mapping.

[Tagging] Upcoming removal of power=station and power=sub_station in the standard style

Hi, It has been noted that we still render power=station and power=sub_station in OSM Carto, even if they are both deprecated and replacement tags are much more popular by now: https://github.com/gravitystorm/openstreetmap-carto/issues/3305#issuecomment-414058220 I would be happy to get rid of

Re: [Tagging] Greengrocer vs grocery vs shop=food?

W dniu 11.10.2018 o 05:08, John Willis pisze: > the definition of shop=food is way way way to vague to have meaning. > it needs to be much narrower.  > > it is like shop=goods. we don’t need that either.  It's much more precise than shop=yes (which is used a lot) and I know what food is, even if

Re: [Tagging] Greengrocer vs grocery vs shop=food?

W dniu 08.10.2018 o 23:00, Martin Koppenhoefer pisze: > +1 to a dedicated tag, e.g. deli=pierogi > Maybe you’d want to distinguish deli from ordinary pierogi though. > What about shop=food food=pierogi for the „usual“ pierogi shop? I have tagged similar shops. They sell typical Polish cuisine,

Re: [Tagging] Stolpersteine tagging scheme problem

W dniu 25.08.2018 o 02:49, Paul Allen pisze: > I did some searching pretty much at random and found > https://www.openstreetmap.org/node/4892971695 which has > memorial=stoperstein + memorial:type=stolperstein, which is one way of > handling the problem. Dual tagging of a single feature is just

Re: [Tagging] Stolpersteine tagging scheme problem

W dniu 25.08.2018 o 02:38, Martin Koppenhoefer pisze: > there are a few other tags that also use the memorial:type key, e.g. > “plate”, flood_mark It would be good to have uniform tagging scheme and I encourage to do it. Stolpersteine is the biggest cause for this subkey to exist and is very

[Tagging] Stolpersteine tagging scheme problem

Hi, We're currently discussing special rendering of memorials on OSM Carto and Stolpersteine looks like a problematic case, because all other types seem to embrace memorial=* notation, while Stolpersteine are usually using memorial:type=* notation. Here is a link to German forum where I started

Re: [Tagging] Points instead of areas

W dniu 09.08.2018 o 08:40, Christoph Hormann pisze: > No, as i have written and explained this is fundamentally wrong. But it > is a nice summary of the base dogma of the "everything is a polygon" > fraction in OSM. To be honest, the world is 4D, not just 2D, but OSM is not well-suited to

Re: [Tagging] Points instead of areas

W dniu 07.08.2018 o 15:24, Christoph Hormann pisze: > I think you have not understood the difference between measurement > tolerance and convergence here. I'm not sure what do you mean by "convergence", but there's no measurement tolerance problem, because without accepting area as a base and

[Tagging] Points instead of areas

A continents discussion spin-off: W dniu 07.08.2018 o 11:31, Christoph Hormann pisze: > A word regarding tolerance of coordinates and the implication that they > should be or have to be within the tolerance of measuring devices - i > don't think this is or should be the case. The point of

Re: [Tagging] public_transport=platform rendering on osm-carto

W dniu 19.06.2018 o 17:40, osm.tagg...@thorsten.engler.id.au pisze: > But I do not think that it is reasonable to add rendering for it, and at the > same moment drop rendering for highway=platform, railway=platform, > highway=bus_stop, railway=tram_stop and everything else that >

Re: [Tagging] public_transport=platform rendering on osm-carto

W dniu 19.06.2018 o 18:16, Paul Allen pisze: > I find the documentation confusing.  But I can sort of see why it > wants a tag on the highway and a tag nearby. (cut...) > It would be nice to clear all this up, although that could mean a lot > of work making existing stuff conform. > > PTv3

Re: [Tagging] public_transport=platform rendering on osm-carto

W dniu 20.06.2018 o 02:06, Martin Koppenhoefer pisze: > the main question when speaking about the old pt scheme is about > highway=bus_stop, not? That was my initial impression. Now I wouldn't like to touch it and instead just replace other *=platform schemes. -- "My method is uncertain/ It's

[Tagging] public_transport=platform rendering on osm-carto

Hi, When discussing rendering public_transport=platform on default OSM.org map style (osm-carto): https://github.com/gravitystorm/openstreetmap-carto/pull/3232 I realized that highway=platform is not only marked on wiki as much less popular, but is also really 10 times less popular in the

Re: [Tagging] How about a Fork? Re: The endless debate about "landcover" as a top-level tag

W dniu 08.06.2018 o 11:34, Rory McCann pisze: > Yes it takes a lot of work, but what you're proposing is going to take > work anyway, so why not try? Well, you've said it - because it's a lot of work. :-) It would be much easier to set up an alternative rendering server with an trivial osm-carto

Re: [Tagging] Feature Proposal - RFC - key:spacing=*

W dniu 06.05.2018 o 04:36, osm.tagg...@thorsten.engler.id.au pisze: > I very much see this as a valid intermediate solution. Getting an > estimate of the average spacing between trees along a tree row takes > seconds. I also think it's better to have something like this. We use address

Re: [Tagging] waterway=derelict_canal

W dniu 09.04.2018 o 20:38, Christoph Hormann pisze: > By the way the wiki page > > https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dderelict_canal > > is a great demonstration of how dysfunctional the tag documentation on > the wiki has become - in this case with the attempt to encourage >

[Tagging] waterway=derelict_canal

When deciding about rendering change of waterway=derelict_canal on osm-carto we are not sure what to do, because meaning of the tag is not clear for us: https://github.com/gravitystorm/openstreetmap-carto/issues/1003 https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dderelict_canal What would

Re: [Tagging] Flower fields as tourism attraction

W dniu 09.04.2018 o 14:15, Martin Koppenhoefer pisze: > maybe it could be tagged as garden with fee and a (new) subtype? For > reference, see https://wiki.openstreetmap.org/wiki/Key:garden:type > e.g. garden:type=garden_show or flower_show There's also another property of gardens and it sounds

Re: [Tagging] Flower fields as tourism attraction

W dniu 09.04.2018 o 02:28, John Willis pisze: > Flowerbed? seems a little weird to tag 3000m2 as a flowerbed. But if > it is approved I will use it. Maybe it sounds strange, but when analyzing the meaning of "garden" in OSM to make osm-carto rendering sane, I have found that size can vary a lot.

Re: [Tagging] Still RFC — Drop stop positions and platforms

n my opinion. > The last issue, raised by kocio-pl, who I assume is Daniel Koć of this > thread, is that someone needs to write the code. Yes, that's me. We are looking for coders (of all the types of features, including simple cleaning), because at the moment it's our scarcest resource - on

Re: [Tagging] Still RFC — Drop stop positions and platforms

W dniu 28.03.2018 o 18:42, Jo pisze: > I've tried to accomplish that many years ago already, it failed. The > people at the helm of the rendering stack consider the 'old' tags good > enough and the new scheme somehow not explicit enough, hence the > double tagging. I'm not sure who do you mean,

Re: [Tagging] Manor tagging

W dniu 19.03.2018 o 02:40, Martin Koppenhoefer pisze: actually castle_type=manor is in the 300-2400 range, while historic=manor in the 2400-19200 range, and it has more than double the usage ;-) :-D I meant the same order of magnitude. I don’t follow the 2 tags are easier than 1 tag

Re: [Tagging] Manor tagging

W dniu 17.03.2018 o 12:51, Christoph Hormann pisze: I have mentioned this many times in different situations before: The purpose of the tag documentation on the wiki is to document actual use of tags. This derives from https://wiki.openstreetmap.org/wiki/Any_tags_you_like. This page says

Re: [Tagging] Manor tagging

W dniu 17.03.2018 o 11:27, Andy Townsend pisze: Also "castle:type=manor" hasn't exactly troubled the scorers so far, has it?   https://taginfo.openstreetmap.org/tags/castle:type=manor shows a grand total of _3_. Yes, that would be easy. =} But I was talking about castle_type=manor (with an

Re: [Tagging] Manor tagging

Since there was no response so far, may I propose to deprecate using historic=manor and suggest on the wiki page to use only historic=castle + castle_type=manor instead. The reasons: 1. I can't see the difference in what both schemes try to symbolize. 2. There's a section on historic=manor

[Tagging] Manor tagging

Hi, I'm confused about manor tagging - we have two pages currently: - https://wiki.openstreetmap.org/wiki/Tag%3Acastle_type%3Dmanor - https://wiki.openstreetmap.org/wiki/Tag%3Ahistoric%3Dmanor and the second one has the inscription: * historic

Re: [Tagging] Tagging request: missing admin_level tags

W dniu 11.03.2018 o 23:50, Kevin Kenny pisze: A fair number of users here - including me - render our own maps, and are giving feedback based on our own experience with trying to render them. I know that in discussions on 'tagging' I try to hide the fact that wanting to render something is

Re: [Tagging] Tagging request: missing admin_level tags

Thanks for writing this summary! It's short, but made me realize a few fundamental points: W dniu 11.03.2018 o 01:31, Matthijs Melissen pisze: > Just something I'd like to clarify: many of you seem to assume this > introduces a new tagging paradigm. The opposite is true: the proposal > uses a

Re: [Tagging] Public art definition

W dniu 31.01.2018 o 09:51, Janko Mihelić pisze: On Sun, Jan 28, 2018, 10:50 Tom Pfeifer > wrote: So, how does "exhibit=artwork" work for you? +1 I like that key because it could have lots of useful values, like exhibit=animal,

[Tagging] Public art definition

During discussing rendering of artwork in Louvre: https://github.com/gravitystorm/openstreetmap-carto/issues/3031 it became non obvious to me what is the "public art" and what should be definition on the wiki: https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dartwork Currently it's defined

Re: [Tagging] Water source types

W dniu 10.01.2018 o 02:02, Martin Koppenhoefer pisze: Still, I wouldn’t consider these sufficiently important to merit rendering of every water tap on osm carto, especially as water taps aren’t particularly rare in gardens or at petrol stations. In cases when objects that are important

Re: [Tagging] Water source types

W dniu 09.01.2018 o 21:45, Mateusz Konieczny pisze: My interpretation is that: amenity=water_point amenity=drinking_water mark place used to get water, synonymous for most purposes - but amenity=water_point may be used also to supply large volume of water. I don't think they are

Re: [Tagging] Water source types

W dniu 09.01.2018 o 22:50, Martin Koppenhoefer pisze: We also show amenity=fountain. there’s also waterway=water_point and there are the drinking_water and drinkable properties. And man_made=water_tank, landuse=reservoir and there’s bottled water of course. Yeah, I know that one can catch a

Re: [Tagging] Water source types

W dniu 09.01.2018 o 23:28, Graeme Fitzpatrick pisze: Carrying on from that, it would actually be a vending machine=water as well, not a water_point, because it's selling water, not providing it for free? It's a generic "key with multiple values" problem, which is as bad as with any other

Re: [Tagging] Water source types

This looks like a vending machine to me in the first place: https://wiki.openstreetmap.org/wiki/Tag:vending%3Dice_cubes W dniu 09.01.2018 o 22:57, Graeme Fitzpatrick pisze: Would the same, or similar, tags apply to provision of ice? We have a number of these kiosks in our area:

[Tagging] Water source types

Hi, We're currently trying to add new icons for water sources on osm-carto and this time it seems that proposed shapes are nice in my opinion, but we're not sure what's the difference between some popular tagging schemes. Currently we show only amenity=drinking_water, but there are also: -

Re: [Tagging] shop - clothing_repair

Dnia 17 grudnia 2017 11:30:01 CET, Martin Koppenhoefer napisał(a): >2017-12-17 1:32 GMT+01:00 Thilo Haug OSM : >> I think this statement isn't true : >> " It's impossible to cover all types of shops."' > >+1, why would it be impossible? We should remove

Re: [Tagging] Deprecating of leisure=common and leisure=village_green

W dniu 05.12.2017 o 18:38, Martin Koppenhoefer pisze: so you want to tag the vegetation? Because both, common and village green are mostly about (permissive) access and or usage rights, and ownership (in my perception). You talk about core definition, but these tags are heavily misused for

Re: [Tagging] Deprecating of leisure=common and leisure=village_green

W dniu 05.12.2017 o 18:23, Martin Koppenhoefer pisze: What areas would you want to use these tags on? grass areas between carriageways, on crossings, etc.? Uncultivated land inside settlements (i.e. nature conquering the area)? Flowerbeds alongside the road or sidewalk? Etc. In case of

Re: [Tagging] Deprecating of leisure=common and leisure=village_green

W dniu 03.12.2017 o 00:28, Warin pisze: landuse=grass?!!! No. City planed 'open area' might be better? The surface is a land cover, not a land use issue. An 'open space' could be concrete and still used for recreation, eating lunch or enjoying the sun. Huumm example? Some 'town squares' are

Re: [Tagging] Planned rendering changes of protected areas

W dniu 03.12.2017 o 10:04, Martin Koppenhoefer pisze: I’m against both proposals (for the current situation, but with more changes to the whole system it might change), for 1 it was demonstrated that there are cases of nature reserves which aren’t protected areas according to osm tag

[Tagging] Planned rendering changes of protected areas

I wrote the summary of the thread I started on Talk list regarding protected areas and nature reserves: http://www.openstreetmap.org/user/kocio/diary/42861 It's sometimes hard to tell which list is proper, because both tagging and rendering are discussed, so I guess such summary might be

Re: [Tagging] Deprecating of leisure=common and leisure=village_green

W dniu 03.12.2017 o 00:15, Adam Snape pisze:  Yes, OSM is a global database, but that is not to say that country-specific feaures ought not to be explicitly tagged. OSm is - I think - a great means of recording such diversity. I don't particularly see a problem with tags being used to mean

Re: [Tagging] Deprecating of leisure=common and leisure=village_green

W dniu 02.12.2017 o 23:12, Warin pisze: To me, "urban_green" is not a land use. I don't see "urban_green" as a good value. What use is it put to? Park, recreation, something else? The use of "green" implies a land cover .. not a good thing in a land use key. I guess it's used in a city

Re: [Tagging] Deprecating of leisure=common and leisure=village_green

W dniu 02.12.2017 o 22:05, Pierre Béland pisze: OSM-Carto is to often thought for Western Europe and only the developpers that contribute to the github project make decisions. I would not base the Tagging decisions on what the various styles are rendering. It's a systematic bias we try to

Re: [Tagging] Deprecating of leisure=common and leisure=village_green

W dniu 02.12.2017 o 21:40, Warin pisze: Mixed vegetation or vegetation of any type is a landcover, not a landuse. The use of landcover and landuse tags would help mappers and consumers separate these features correctly. So what do you think about: Function tag (which might represent a lot

Re: [Tagging] Deprecating of leisure=common and leisure=village_green

W dniu 02.12.2017 o 12:19, Jo pisze: a far better tag would have been: landuse=GreenAndHardToClassify_HelicoptersMightLandHere I guess landuse/landcover=urban_green would be much closer to reality for mixed vegetation - in fact, mixed_vegetation sounds sane too. Helicopters can land on many

Re: [Tagging] Deprecating of leisure=common and leisure=village_green

W dniu 02.12.2017 o 10:39, Marc Zoutendijk pisze: Let’s keep it simple and stick with one tag (village_green), keep the way is is rendered and explain the different uses in the wiki. It sounds rather strange for me and this is not really simple. Please also note that I’m the one that added

Re: [Tagging] Deprecating of leisure=common and leisure=village_green

W dniu 01.12.2017 o 02:19, Warin pisze: Were not 'commons' used for more than 'recreation'? I think they were used for grazing and camping too? "Historically these rights typically included the right to graze livestock, collect firewood, or cut turf. Today they include the rights to use the

Re: [Tagging] Deprecating of leisure=common and leisure=village_green

(It's about landuse=village_green, not leisure=village_green, of course...) W dniu 01.12.2017 o 00:47, ajt1...@gmail.com pisze: This sounds like a severe case of the tail wagging the dog - the fact that one particular renderer might not want to render a certain tag in the future is not a

[Tagging] Deprecating of leisure=common and leisure=village_green

While making some cleaning in osm-carto we have found that leisure=common and leisure=village_green are probably not clear enough to show them any more. They both have deep roots in British law and history and are frequently misused, as far as I can tell. Both are very popular - 57k and 86k

[Tagging] Park vs national park

It looks like some people tag national parks and similar natural protection areas as parks. There are some examples, like few parks in the north California: https://www.openstreetmap.org/#map=10/41.2097/-123.9581 What do you think about it - is it a proper tagging, people are just plain

Re: [Tagging] Nicknames

W dniu 25.10.2017 o 09:53, Martin Koppenhoefer pisze: +1, loc_name, nat_name, reg_name, alt_name, there are quite some established tags to put alternative names on objects. They are also well defined and I believe this name doesn't fit there. "Big Apple" is not local/regional/national and

[Tagging] Nicknames

I think it'd be good to add "Big Apple" nickname as a popular (and searchable) kind of placename for a New York: http://www.openstreetmap.org/node/61785451 However nicknames are not defined on the wiki nor used too much as "nickname" (just 44 objects):

Re: [Tagging] Feature Proposal - Street_furniture

W dniu 18.10.2017 o 01:59, Warin pisze: On 18. Oct 2017, at 01:26, Graeme Fitzpatrick wrote: IMHO not, as they’re underground, not on the street. layer=-1 "The layer=* tag is one of several methods used to describe vertical relationships between crossing or

Re: [Tagging] Mapping metro interchanges

W dniu 04.10.2017 o 23:23, Ilya Zverev pisze: So, should it be one railway=station + station=subway or four? I'm not too much into this, I just wanted you to know, that Warsaw metro interchange (which I was asking about lately) has been retagged as just one station by someone. I've talked to

  1   2   3   >