Re: [Tagging] Urbex

On January 8, 2018 11:39:51 PM GMT+00:00, Kevin Kenny wrote: >On Mon, Jan 8, 2018 at 6:31 PM, Martin Koppenhoefer > >wrote: > >> are we encouraging / supporting / recommending something because we >map >> it? >> > >Some seem to think so. Witness municipalities asking us to remove their >streets

Re: [Tagging] Why is this building not rendered?

On 16 April 2017 11:54:19 IST, Warin <61sundow...@gmail.com> wrote: >However on the information available to me ... I could not reliably map >the extent of the school .. so I would map it as a node only. >I think this is not regression but removes an assumption (from the >present tagging) that t

Re: [Tagging] Amphitheatre or outdoor non-sports venue

On 14 September 2016 09:42:59 GMT+01:00, johnw wrote: >after searching the wiki for the correct spelling of amphitheatre >(oops), I found: > >https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dtheatre > > >"For tagging amphitheatres >

Re: [Tagging] leisure=track on areas?

On 4 August 2016 11:55:05 GMT+01:00, Tom Pfeifer wrote: >Warin wrote on 2016/08/04 08:14: >> On 8/4/2016 3:42 PM, Daniel Koć wrote: >>> but it appears we don't know how should we treat leisure=track: is >it a linear object or maybe kind of area? >> >> I have seen it both ways. > >Yes exactly. Th

Re: [Tagging] How to tag: public lands that are accessed by permit?

On 21 July 2016 12:31:42 GMT+01:00, m...@chrisfleming.org wrote: > >In my view access=permit seems like they way to go. Having >access=private with permit=something adds to the complexity without >adding value. Keep it simple. Joining this discussion late, but just as another datapoint, this use

Re: [Tagging] Draft of proposal tag 'sells' for shops..

On 6 March 2016 08:47:36 GMT+00:00, Ralph Aytoun wrote: >My personal opinion is that this is getting totally out of hand. >Shops pay a lot of money to advertise their wares and you are stepping >in >and trying to do commercial marketing for free. >Not only that but who is going to maintain thi

Re: [Tagging] Proposal to Change Road Classification, Road Surface, Road Condition, and Add Number of Lanes

On 5 March 2016 21:13:48 GMT+00:00, Martin Koppenhoefer wrote: >> Am 05.03.2016 um 15:25 schrieb Alberto : >> >> OSM does not establish the difference between inter-urban (rural) >roads and urban roads (comprising mostly avenues and streets). > > >there are tags in use that allow to make this

Re: [Tagging] Proposal about suffixed tags has been approved

On 03/03/2016, Martin Koppenhoefer wrote: >> Am 03.03.2016 um 03:57 schrieb moltonel 3x Combo : >> >> The fact that we don't know wether the extra name is an old_name or a >> loc_name or something else is independant of how the extra name was >> taged. The

Re: [Tagging] Proposal about suffixed tags has been approved

r (value like '%;%' and (key='name' or key='alt_name')) group by 1; name_1|250686|810490 name_2|29521|65868 name|15211|29136 alt_name|7975|10897 You can argue about the flaws of this simplistic query, but this won't change the general result. On 25/02/2016, Hak

Re: [Tagging] Proposal about suffixed tags has been approved

On 25/02/2016, Hakuch wrote: > On 24.02.2016 23:40, moltonel 3x Combo wrote: >> Just like you 1) marked the proposal as approved 2) enacted the >> proposal 3) emailed the list all in one session a few days ago, I >> edited the wiki and emailed the list in one session today. &

Re: [Tagging] Proposal about suffixed tags has been approved

On 24/02/2016, Hakuch wrote: > On 24.02.2016 22:57, moltonel 3x Combo wrote: >> The opinions were varied, but there was clear support in keeping the >> name_N documentation, both for the basic principle of documenting >> current practices, and because some contributors beli

Re: [Tagging] Proposal about suffixed tags has been approved

On 24/02/2016, Matthijs Melissen wrote: > Moltonel, could you please refrain from making changes that go against > the community wishes? I know you have good intentions (and you might > even be right), but the community has discussed this topic in depth > and decided on the outcome

Re: [Tagging] Proposal about suffixed tags has been approved

On 24/02/2016, Hakuch wrote: > hey, I didnt want to start an edit war, but I just didnt see that you > wrote on the tagging list. > > i will write more later, I even informed you just by message, but the > proposal was very clear, you were not allowed to just change the pages. > You even should ha

Re: [Tagging] Proposal about suffixed tags has been approved

y like you to discuss things. On 24/02/2016, moltonel 3x Combo wrote: > http://wiki.openstreetmap.org/w/index.php?title=Key:name&diff=next&oldid=1275952 > > Hakuch, please do not start an edit war. I took the time to avoid a > knee-jerk "revert this edit" reaction, a

Re: [Tagging] Proposal about suffixed tags has been approved

http://wiki.openstreetmap.org/w/index.php?title=Key:name&diff=next&oldid=1275952 Hakuch, please do not start an edit war. I took the time to avoid a knee-jerk "revert this edit" reaction, and so should you. I've explained how the approval of the proposal was IMHO a poor reading of the discussion

Re: [Tagging] Proposal about suffixed tags has been approved

On 12/02/2016, Hakuch wrote: > https://wiki.openstreetmap.org/wiki/Proposed_features/Remove_suffixed_name-tags_from_wiki > > It was approved with 38 votes for, 10 votes against and 1 abstention. > > Approved due to >74% approval (79.167%). Wikipages has been changed > https://wiki.openstreetmap.or

Re: [Tagging] Discussion about Multivalued Keys

On 28/01/2016, Warin <61sundow...@gmail.com> wrote: > On 28/01/2016 8:51 PM, Martin Koppenhoefer wrote: >> >> 2016-01-27 18:00 GMT+01:00 moltonel 3x Combo > <mailto:molto...@gmail.com>>: >> >> You barely broach the subject of how MV and namespaces

Re: [Tagging] Discussion about Multivalued Keys

On 28/01/2016, Martin Koppenhoefer wrote: > 2016-01-27 18:00 GMT+01:00 moltonel 3x Combo : > >> You barely broach the subject of how MV and namespaces combine. For >> example if an object has multiple refs with sources, it should be >> clear wether an MV tag corresponds

Re: [Tagging] Discussion about Multivalued Keys

On 27/01/2016, Colin Smale wrote: > On 2016-01-27 22:54, moltonel 3x Combo wrote: >> Concerning foo_1 vs foo[1] vs foo:1, I this the last one can be safely >> thrown to the idea bin (despite being used by seamarks) because ':' >> clashes with namespacing, which is f

Re: [Tagging] Discussion about Multivalued Keys

On 27/01/2016, Colin Smale wrote: > One way, using a "subscript syntax" with a "data structure" construct > using a "." as a separator": > lane[1].destination=Paris > lane[2].destination[1]=Rome > lane[2].destination[2]=Milan > lane[3].destination[1]=Berlin > lane[3].destination[2]=Munich > > Alte

Re: [Tagging] Discussion about Multivalued Keys

On 27/01/2016, Marc Gemis wrote: > The main problem is that the lane tagging is established tagging with > several 10.000's of mapped ways. Do you really want to change that ? > It will take years before they are all converted to whatever new > syntax we come up with. Not to mention data consumers

Re: [Tagging] Discussion about Multivalued Keys

Thanks Colin, this proposal makes some good points. Some comments : For completeness, you should mention the possibility of an API-level implementation[1]. Even if this'll be met with a "patches welcome" and if we need a pragmatic solution in the meantime, supporting MV at the API level has some i

Re: [Tagging] Feature Proposal - Voting - (Remove name_1 and alt_name_1 from wiki)

On 27 January 2016 09:15:10 GMT+00:00, Martin Koppenhoefer wrote: >the current tagging definitely is >improvable (because you cannot see which is this official > name by looking at the current tags). If I were to add a tag for the official name, we'd end up with name=x official_name=x name_1=

Re: [Tagging] Feature Proposal - Voting - (Remove name_1 and alt_name_1 from wiki)

On 27 January 2016 10:09:51 GMT+00:00, Martin Koppenhoefer wrote: >2016-01-27 10:39 GMT+01:00 Marc Gemis : > >> France ? The example boundary is in Ireland >> > > >;-) >anyway, s/France/Ireland/ and the statement remains. I bet also the >Irish >have official names for their administrative u

Re: [Tagging] Feature Proposal - Voting - (Remove name_1 and alt_name_1 from wiki)

tOn 26/01/2016, Mateusz Konieczny wrote: > In my experience name, name:en, old_name, alt_name, alt_name:ru etc etc > etc were always sufficient. An example where multivalue names are > truly necessary would be interesting. Andy has already given some good answers and I've rambled for too long on

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

Taped "send" to early, here's the rest of my email: On 23 January 2016 15:14:22 GMT+00:00, "Lauri Kytömaa" wrote: >I believe this is a good point to make, the origin for many of those >tags. >While the number of uses is reason to keep them as-is, if a major slice >of them comes from an import, t

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

On 23 January 2016 15:14:22 GMT+00:00, "Lauri Kytömaa" wrote: >I believe this is a good point to make, the origin for many of those >tags. >While the number of uses is reason to keep them as-is, if a major slice >of them comes from an import, the ratio isn't a good reason to >*recommend* >enter

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

On 21/01/2016, Hakuch wrote: > I just want to mention again: this proposal is about the wiki, that > name_1 and alt_name_1 should not be suggested there for good tagging. > Its not about the existing data in OSM. And the ongoing discussion in this thread just explains in lenghty details why the p

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

On 20/01/2016, Mike N wrote: > On 1/20/2016 3:39 PM, Dominic Coletti wrote: >> I see 808,000 uses of name_1 and 65,000 of name_2. And 609,505 alt_name and 6,013 alt_name_1. These approximate figues have already been mentioned in this thread. Does Anybody have stats on how many "*name*" tags have

Re: [Tagging] Please don't think name_1 tags are errors.

On 17/01/2016, Hakuch wrote: > for me the use of alt_name_1 is more logical than the name_1, because > alt_name is the meaning of name_1! So, if you have a second name and you > dont know where to put it (loc_name, old_name...) you can use alt_name. > And if you have a third name you SHOULD use al

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

On 19/01/2016, Andy Townsend wrote: > It's not used by anyone as far as I can see: > > http://taginfo.openstreetmap.org/search?q=%3B%3B > > (unless taginfo is doing some special filtering) http://taginfo.openstreetmap.org/search?q=%3B (a single ";") doesn't find any value either, so taginfo can't

Re: [Tagging] Please don't think name_1 tags are errors.

On 15/01/2016, Martin Koppenhoefer wrote: >> Am 15.01.2016 um 18:03 schrieb moltonel 3x Combo : >> To get back to my http://www.openstreetmap.org/relation/5257865 >> example, I've got 3 names to tag. One of them distinguishes itself by >> also appearing on an out-of

Re: [Tagging] Please don't think name_1 tags are errors.

outright banning *_N for the sake of (what ?) would cause a lot of headaches. On 15/01/2016, Martin Koppenhoefer wrote: > 2016-01-15 15:26 GMT+01:00 moltonel 3x Combo : > also shop_1 tags are created that way. I wonder why you would want to add > these tags on purpose. E.g. for shops the

[Tagging] Please don't think name_1 tags are errors.

Hi, I've just reverted http://www.openstreetmap.org/changeset/36573638 where the mapper thought that name_1 tags were typos. That user is on a key typo fixing spree, which is a good thing in itself, even if mistakes happen. But I wonder if some people know about the iD editor behavior below, and a

Re: [Tagging] Removing name_1 and alt_name_1 from Wiki

On 9 January 2016 at 18:50, Hakuch wrote: > I propose, to remove the tagging of name_1 and alt_name_1 from the wiki. I disagree. > **better use diverse name-tags** Diverse name tags are a good thing when there is some semantic difference between names, but often enough there's no semantic diffe

Re: [Tagging] Specifying maxweight, when different weight limits are signed

On 30 December 2015 18:58:38 GMT+00:00, Marcos Oliveira wrote: >Do you know if this is a legal limit or if being smaller makes the >weight >less spread out which can structurally damage the bridge? > >If the first then I'd map the highest value, if the latter then the >smallest one. I dont thi

Re: [Tagging] Wi-Fi or internet access at Stores

On 13 December 2015 12:02:22 GMT+00:00, Richard wrote: >On Sun, Dec 13, 2015 at 11:22:53AM +0000, moltonel wrote: >> Customer-only and non-gratis wifi are arguably not "public" but they >are mapworthy. And the subtags to express these are >internet_access:access and

Re: [Tagging] Wi-Fi or internet access at Stores

On 13 December 2015 00:08:16 GMT+00:00, Hans De Kryger wrote: >> What would be the point of tagging non-public Wi-Fi? >> >> Do you mean Wi-Fi for customer use only? >> ​ ​ >My bad i meant ​(wifi_public=yes​) >​ and i'm not sure that tag would be necessary at all. Public wifi >should only be ta

Re: [Tagging] amenity=bicycle_repair_station

On 10/11/2015, Martin Koppenhoefer wrote: >> What ambiguity of repair_station would be cleared by tool_stand or >> tool_station ? > > it is the word "station" that could be interpreted as a shop / service > station. "stand" does not bear this risk (for me). "tool_station" would be > similarly ambi

Re: [Tagging] amenity=bicycle_repair_station

On 10/11/2015, Martin Koppenhoefer wrote: > 2015-11-10 9:38 GMT+01:00 Mateusz Konieczny : > >> I like amenity=bicycle_tool_stand, > > +1, "repair_station" is ambigous / can easily be misunderstood. Even though > "amenity=self_serve_bicycle_tool_stand" looks like an overkill on first > sight, it is

Re: [Tagging] amenity=bicycle_repair_station

On 10/11/2015, Andrew Guertin wrote: > On 11/09/2015 09:41 PM, Bryce Nesbitt wrote: >> amenity=bicycle_repair_station has a problem: it's attracting lots of >> active tagging >> of shops offering bicycle repair. For example: >> http://www.openstreetmap.org/node/3772809894 >> and http://www.openst

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

On 08/11/2015, Dave Swarthout wrote: > In that section the author, sk53, says, "Creating a whole set of boundaries > encompassing one country and part of another is not a light undertaking on > OSM. It is fiddly work, and involves manipulating objects with many > dependencies. In practice I find i

Re: [Tagging] Feature Proposal - Voting - Motorway link no default oneway

On 29/10/2015, Joachim wrote: > I invite you to vote on the proposal "Motorway link no default > oneway". The following is proposed: > > Strongly recommend explicit tagging of oneway=* on highway=motorway_link. No need for a proposal and a vote to do that. Just go ahead and recommend it. > Defin

Re: [Tagging] Credit Recharge in Argentina

On 27 October 2015 14:50:10 GMT+00:00, Philip Barnes wrote: >Sounds a lot like oyster cards used in London, probably something in >use there. Similarly in Ireland we''ve got recharging machines for prepay phones, and I don't know how to tag them. In a way, they are very much like ATMs; it'd

Re: [Tagging] Handle with care

On 27/09/2015, Marc Gemis wrote: > My fear is that some overzealous mappers will start adding those tags to > all objects in their neighborhood, just to "protect' their area and scare > away newbies. > > Since we suppose that all data is mean to be correct and everybody makes > edits to improve th

Re: [Tagging] Handle with care

On 27/09/2015, André Pirard wrote: > But I'm afraid that the correct namespace order is name:edit_warning=*. > edit_warning is a qualifier of name and not the opposite. > It is the edit warning of (for) name and not the name of the edit warning. > It's just like the order of the words in an Englis

Re: [Tagging] Handle with care

On 26 September 2015 19:05:09 GMT+01:00, "André Pirard" wrote: >It is >:warning= >which acts only when that key is changed. >geometry:warning= to protect the coordinates of the element >name:warning= to protect its name. >Those tags do not warn against changing other tags. May I suggest 'edi

Re: [Tagging] Delete not marked walking routes?

On 20/09/2015, Martin Koppenhoefer wrote: > what about a map that shows the route and is placed on the ground, eg at the > start of the route (let's say the map is in the public domain)? To me that's a (partially) waymarked trail and is absolutely fine. > Or signposted QR codes? This has recentl

Re: [Tagging] Delete not marked walking routes?

On 20 September 2015 11:54:00 GMT+01:00, Mateusz Konieczny wrote: >> Case b) Frequent use and 'the best' route. This would be contentious. > >So every mapper may add his favourite route? That bothers me as well. Even if we restricted ourselves to only published routes, we'd open ourselves to

Re: [Tagging] Semi-detached houses: undocumented iD preset

On 18/09/2015, Frederik Ramm wrote: > I'd say the same applies to houses. Whether something is one half of a > double house, or semi-detached, or terraced, or free-standing - isn't > that something that I can automatically determine by looking at the > nearby mapped buildings? +1 I've always tagg

Re: [Tagging] New proposal: Obligatory tagging of oneway on motorway_link

On 11/09/2015, Mateusz Konieczny wrote: > On Fri, 11 Sep 2015 12:41:36 + > moltonel wrote: > >> Consumers (routers, renderers, whatever) will not be swayed by a wiki >> page. They might look at stats and decide themselves what the absence >> of a oneway tag me

Re: [Tagging] New proposal: Obligatory tagging of oneway on motorway_link

On 10 September 2015 13:20:43 GMT+01:00, Joachim wrote: >Proposal: >Define on the wiki page of highway=motorway_link that oneway=* must >also be tagged for every motorway_link. Sounds fair. > If not tagged, the oneway=* >status of this way is undefined. You wont gain anything by de-defining t

Re: [Tagging] Handle with care (was: Accuracy of survey)

On 9 September 2015 21:46:54 GMT+01:00, "André Pirard" wrote: >There are various reasons for warning other mappers to be careful about >their updates. >I once temporarily overlaid two walking routes to show the effect of >displaying two sorts of icons. >Or I left in for a while drawing errors o

Re: [Tagging] Drafting proposal: use oneway=reversible or create tag?

On 7 September 2015 17:38:45 GMT+01:00, Volker Schmidt wrote: >tidal >up to London, depending on tides (and wind). But I would be reluctant >to >tag the river's water flow from London downwards as flow_direction=both Yes, rivers can be tidal without their flow reversing. The water level can ri

Re: [Tagging] Drafting proposal: use oneway=reversible or create tag?

On 07/09/2015, David Marchal wrote: > I'm drafting a proposal concerning some waterways whose flow regularly > changes direction, which happens near some sinkholes named estavelles, which > drain or feed water according to the aquifer level. I would consequently > propose a way to map it, but it s

Re: [Tagging] [OSM-talk] Proposed mechanical edit: surface=soil to surface=dirt

On 02/09/2015, Friedrich Volkmann wrote: > On 01.09.2015 10:13, moltonel 3x Combo wrote: >> But as a user of surface=soil, could you tell me what difference you >> see between soil and earth (from an osm POV) ? To me, those two are >> actual osm synonyms, but 'earth&#

Re: [Tagging] Proposed mechanical edit: surface=soil to surface=dirt (history (authors of changesets))

On 02/09/2015, Mateusz Konieczny wrote: > On Tue, 01 Sep 2015 23:55:14 +0200 > "André Pirard" wrote: >> http://www.openstreetmap.org/api/0.6/node/3157502486/history >> >> will return the complete list (history) of authors, changesets and >> dates for a given element. > > Yes, this would work (som

Re: [Tagging] [OSM-talk] Proposed mechanical edit: surface=soil to surface=dirt

On 01/09/2015, Friedrich Volkmann wrote: > Soil is not dirt. That's why I have used surface=soil myself, and I > will revert any automated edit of such kind. I agree that soil and dirt are different, and that the mechanical edit should not proceed as originaly planned. But as a user of surface=s

Re: [Tagging] Trolltags

On 31/08/2015, Mateusz Konieczny wrote: > Good > luck with filtering out proposed=yes, abandoned=yes, vacant=yes, > demolished=yes, construction=yes, empty=yes, ruins=yes, parsing > start_date and end_date etc etc. Case in point: have a look at https://github.com/gravitystorm/openstreetmap-carto/

Re: [Tagging] Proposed mechanical edit: surface=soil to surface=dirt

On 31/08/2015, Mateusz Konieczny wrote: > Is there some method to automate finding who introduced tags? Doing it > manually would not be worth the effort. On the other hand - running > script to detect users (and/or relevant changesets) may be a good idea. curl -s 'http://overpass-api.de/api/int

Re: [Tagging] [OSM-talk] Proposed mechanical edit: surface=soil to surface=dirt

On 31/08/2015, Christoph Hormann wrote: > I would be careful here - 'dirt' is essentially a very vague term which > probably originates from the concept of 'dirt roads' here. 'Soil' in > the other hand is fairly precise, see > > https://en.wikipedia.org/wiki/Soil > > Only parts of the earth surfa

Re: [Tagging] works_as_highway=primary

On 29/07/2015, Marc Gemis wrote: > On Tue, Jul 28, 2015 at 5:29 PM, moltonel 3x Combo > wrote: > >> A router won't care about classification differences between far away >> places like Germany to Ethiopia. They just care about taking the best >> road in the are

Re: [Tagging] works_as_highway=primary

On 28/07/2015, Pavel Zbytovský wrote: > Since nobody objected much, i would probably go with > works_as_highway=primary - i think it reflects the state of reality, so its > useful to be added in OSM dataset. FWIW, I'm not a big fan of this, because it is just a variation of tagging for the render

Re: [Tagging] works_as_highway=primary

On 28/07/2015, Marc Gemis wrote: > On Tue, Jul 28, 2015 at 4:14 PM, moltonel 3x Combo > wrote: > >> That ideal doesn't match the practical reality. highway=primary has a >> very different definition between Ethiopia and Germany, by necessity. > > While they can be

Re: [Tagging] works_as_highway=primary

On 28/07/2015, Martin Koppenhoefer wrote: >> Am 28.07.2015 um 11:02 schrieb Pavel Zbytovský : >> >> 1) technically the small secondary roads part works as primary road >> network. So we would suggest a tag similar to works_as_highway=primary. Do >> you think its ok? Any suggestions? > > > from wha

Re: [Tagging] Disputed area

On 20/07/2015, Greg Troxel wrote: > > Warin <61sundow...@gmail.com> writes: > >> On 20/07/2015 1:08 AM, Greg Troxel wrote: >>> So perhaps a relation that carries the border tag with two ways as >>> members. The relation would have the boundary tags, and also a disputed >>> tag of some sort listin

Re: [Tagging] Highway proposed/planned distinction

On 16/07/2015, jonat...@bigfatfrog67.me wrote: > I would say it depends if the untouched land is still in its original use or > not. If it is then mark it as planned, if it’s cordoned off waiting for the > construction to get there then I would mark it as under construction. Agreed. My understan

Re: [Tagging] Highway proposed/planned distinction

On 16/07/2015, johnw wrote: > Ran into this issue today. They are constructing a new trunk road in an > area I’m mapping, an as is usual for Japan, they build the road in stages, > completing one stage before they go to the next. I know, down to about 20m, > the alignment of the sections to be bu

Re: [Tagging] Highway proposed/planned distinction

On 14 July 2015 19:57:30 GMT+01:00, jonat...@bigfatfrog67.me wrote: >Linguistically I would say proposed comes before planned. Planning >your wedding is not the same as proposing marriage! +1 >Personally I don't think we should routinely display proposed routes, >because they may never come

Re: [Tagging] Rural Alley?

On 08/07/2015, johnw wrote: > https://www.google.com/maps/@36.431238,139.246753,3a,78y,233.04h,65.44t/data=!3m6!1e1!3m4!1sqk2OIIDRfkCjb8uqWNbkhw!2e0!7i13312!8i6656!6m1!1e1 To me this (along with the description) is highway=track tracktype=grade1. You can add surface, lanes, maxspeed, width, etc f

Re: [Tagging] Changes + additions: shop= photo, hobby, model

On 05/06/2015, Warin <61sundow...@gmail.com> wrote: > shop=hobby No documentation present so added > > * text to suggest a more detailed tag be used. > * link to the wiki shop= hobby area. shop=hobby is a terrible tag. Every activity is a hobby to somebody, so shop=hobby gives no clue as to wh

Re: [Tagging] SHAPE_Leng, SHAPE_Area, GIS_ACRES

On 04/06/2015, Jean-Marc Liotier wrote: > Nothing wrong there - in Europe, people have been improving on CORINE > Land Cover polygons since the dawn of time. CORINE landuse in Europe is a bit like TIGER highways in USA : great as an initial map-filler, but requires a *lot* of fixing and tweaking.

Re: [Tagging] Deprecating wikipedia Tag

On 26/05/2015, Martin Koppenhoefer wrote: > My main concern with wikidata for the moment: it's mostly as fuzzy as > Wikipedia is - because the objects are not created by humans but conversions > of articles. Using only wikidata would mean we are sure that wikidata will > be a success. Agreed. I i

Re: [Tagging] Deprecating wikipedia Tag

On 26/05/2015, Andy Mabbett wrote: > You don't "link to a Wikidata label", you link to a Wikidata item. QED, you can only use wikidata IDs such as "Q936" in OSM tags, which is much less userfriendly than the wikipedia equivalent. You brought wikidata labels to the discussion; they're nice but the

Re: [Tagging] Deprecating wikipedia Tag

On 25/05/2015, Andy Mabbett wrote: > "On 25 May 2015 at 22:18, moltonel 3x Combo wrote: > >> How do you link to a wikidata label in an OSM tag ? One that never >> suffers from renaming ? As far as I know, we can/should only use >> wikidata ids, which are stable bu

Re: [Tagging] Deprecating wikipedia Tag

On 25/05/2015, Andy Mabbett wrote: > On 25 May 2015 at 17:13, moltonel 3x Combo wrote: > >> * wikipedia names are friendlyer to mappers, and generally more well-known > > Wikidata labels should be more useful, contain less redundancy, and be > no less well-known. For

Re: [Tagging] Deprecating wikipedia Tag

On 25/05/2015, Andreas Goss wrote: >> ikidata will always be playing catch-up to wikipedia, to >> some extent. > > Can you just show me a single Wikipedia entry without a Wikidata object. https://en.wikipedia.org/wiki/List_of_map_projections Ok, maybe that one doesn't count because it's kind of m

Re: [Tagging] Deprecating wikipedia Tag

On 25/05/2015, Martin Koppenhoefer wrote: > 2015-05-25 16:24 GMT+02:00 moltonel 3x Combo : >> Also, a lot of wikipedia articles do not (yet) have a wikidata >> counterpart. > > I thought all wikipedia articles had been transformed into wikidata > entities (that's wh

Re: [Tagging] Deprecating wikipedia Tag

On 25/05/2015, Guillaume Allegre wrote: >> I already replied that I wonder what's the idea behind that enforcement. >> Why wouldn't Wikidata be used "also" rather than "instead"? Is it >> really a goal of OSM insisting to destroy Wikipedia? > > Wikidata has one more advantage : sometimes, Wikiped

Re: [Tagging] Wiki: Key:level: proposed rewrite

On 25/05/2015, pmailkeey . wrote: > Also knowing the street elevation would give the clue as to which floor was > 'ground level' - as would a highway linking internal routes to external. You shouldn't focus on trying to determine the "ground level", as there are many many buildings that have no r

Re: [Tagging] Deprecating wikipedia Tag

On 25/05/2015, p...@trigpoint.me.uk wrote: > I think a lot of us mappers are going to need a lot of convincing, > wikipedia tags, in common with other osm tags, are human readable. > When reviewing changes I do not see a number that is meaningless without > following the link, and even then the w

Re: [Tagging] Wiki: Key:level: proposed rewrite

On 25/05/2015, pmailkeey . wrote: >> There are two distinct needs : enabling software to sort levels >> for rendering and navigation purposes, and the need to show the >> textual name that humans expect. The "level=*" key is currently used >> for the fist case (otherwise you'd see a lot more text

Re: [Tagging] Wiki: Key:level: proposed rewrite

On 25/05/2015, Michael Reichert wrote: > I oppose. Numeric level values can be used to display a building plan > layer by layer where higher floors lay over lower floors. Most software > which uses level=* at the moment expects that it is a numeric value. > > Example: https://youtu.be/qcB5CP-IkLg?

Re: [Tagging] Long Tail ( was Removal of "amenity" from OSM tagging)

On 19/05/2015, Simon Poole wrote: > On 19. Mai 2015 03:18:14 MESZ, johnw wrote: > >> >>there’s no preset “I want to add a business” or “I want to add a park” >>tutorials that walk through the basics and hold your hand, bring up >>options and ask you natural language questions to help you lea

Re: [Tagging] shop=confectionery / pastry / candy / sweets

TL;DR: off-topic, rant, noise On 12/05/2015, pmailkeey . wrote: > On 12 May 2015 at 03:26, John F. Eldredge wrote: > >> Minor nitpick: desserts are sweet foods, usually eaten at the end of a >> meal. Deserts are areas with little rainfall, and sparse or no >> vegetation. > > Bearing in mind thi

Re: [Tagging] shop=confectionery / pastry / candy / sweets

On 11/05/2015, Daniel Koć wrote: > W dniu 11.05.2015 18:18, Andreas Goss napisał(a): >>> Pastry-only shops are >>> quite rare. See also shop=patisserie (62 uses). >> >> But is pastry = patisserie ? > > Yet another item just for sugar?... =} Blaspheme ! :p You shouldn't compare Haribo-type sweets

Re: [Tagging] shop=confectionery / pastry / candy / sweets

On 11/05/2015, Andreas Goss wrote: >> Pastry-only shops are >> quite rare. See also shop=patisserie (62 uses). > > But is pastry = patisserie ? To me it is, but deserts are very tied to the local culture, so I'm sure opinions will differ. > http://media-cdn.tripadvisor.com/media/photo-s/03/de/f

Re: [Tagging] shop=confectionery / pastry / candy / sweets

On 11/05/2015, Martin Koppenhoefer wrote: > I believe there is some overlap between the shop values > > confectionery > pastry > candy > sweets > > shop=confectionery is used much more often than the other 3 (10K vs. 300 > vs. 100 vs. 50) and is likely covering all of these, but is quite generic.

Re: [Tagging] Colour coding of wiki description boxes

On 06/05/2015, Andy Mabbett wrote: > On 6 May 2015 at 17:41, moltonel 3x Combo wrote: >> On 05/05/2015, Andy Mabbett wrote: > >>> If people choose not to (or are "not bothered to") comment, that's an >>> abstention. >>> >>> Indeed,

Re: [Tagging] Colour coding of wiki description boxes

On 05/05/2015, Andy Mabbett wrote: > If people choose not to (or are "not bothered to") comment, that's an > abstention. > > Indeed, it may reasonably be argued that of they choose not to comment > on a proposal to do something, then they are content with the > proposal. It'd only be reasonable i

Re: [Tagging] electric zigarrettes

On 24/04/2015, Thorsten Alge wrote: > >> I fear at this stage we can only agree to disagree : to me using >> e-cigarettes *is* smoking. I don't care much for the physicist's >> definition of "smoke". It's the social/medical definition that matters >> here, the one that gets turned into laws and ul

Re: [Tagging] electric zigarrettes

On 23/04/2015, Martin Koppenhoefer wrote: > you're suggesting "smoking" as a single namespace, which doesn't apply to > vaporizers. Maybe "inhaling"? > On the other hand, smoking is also forbidden when not inhaling... ;-) > I think different namespaces make sense here, because they are different >

Re: [Tagging] electric zigarrettes

On 22/04/2015, Bryce Nesbitt wrote: > On Wed, Apr 22, 2015 at 9:34 AM, moltonel 3x Combo > wrote: >> smoking=yes/no/outside/etc for the general value >> smoking:=yes/no/etc for exceptions >> With being any of cigarette, e-cigarette, hooka, marijuana, opium, >> e

Re: [Tagging] electric zigarrettes

On 22/04/2015, Martin Koppenhoefer wrote: > 2015-04-22 9:19 GMT+02:00 Paul Johnson : > >> Well, electronic cigarettes aren't really smoking in the first place, >> unless you want to claim that a teapot boiling is "smoking", which is >> something most people realize isn't the case by the time they'

Re: [Tagging] electric zigarrettes

On 21/04/2015, Thorsten Alge wrote: > is there a tag to express that the use of electronic cigarettes is > permitted at a location? If not I'd like to suggest the use ecigarette=* > or vaporizing=* with the same values as smoking=*. I've never seen a place that permitted one type of smoking but n

Re: [Tagging] inuse, defacto

On 17/04/2015, Marc Gemis wrote: > It will be hard to come up with a number to distinguish between the two. As > others have pointed out on this mailing list before, the actual number of > items that can be tagged with a certain tag matters. > So in case there are only 600 items in the whole world

Re: [Tagging] Ambiguous translations of waterway=dam - should be moved to man_made=dam

On 16/04/2015, Nelson A. de Oliveira wrote: > On Thu, Apr 16, 2015 at 7:41 AM, Richard Z. wrote: >> not all of the dams are man_made, beavers are busy builders. > > I want to be the first one tagging a beaver_made=dam :-) Seems like you could be the first, but then you'd be introducing yet anoth

Re: [Tagging] Way inside riverbank

On 14/04/2015, Christoph Hormann wrote: > It is the other way round - the riverbank polygon is optional and 'nice > to have'. The waterway line is what actually defines a river in OSM, > it also gets the name tag and other attributes. Yes, this is the same principle that gives us highway=* vs ar

Re: [Tagging] Proposal: Rename wiki status "Approved" to "Published"

On 05/04/2015, Frederik Ramm wrote: > I really see two paths - either continue what I did, let the Wiki use > terms like "approved" but make it clear enough to everyone that the Wiki > isn't the OSM bible but just what a very small number of people think > about OSM; or try to increase the standin

Re: [Tagging] Proposal: Rename wiki status "Approved" to "Published"

On 04/04/2015, Warin <61sundow...@gmail.com> wrote: > On 4/04/2015 8:58 AM, Bryce Nesbitt wrote: > > It is a 'No' vote. Not an abstain. > > . > For an English definition see > http://www.oed.com/view/Entry/154075?redirectedFrom=published#eid That's behind a paywall. Wou

  1   2   >