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
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
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.
&
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
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 by vote, and yo
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 means, but a wiki proposal is never
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
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&#
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
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
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/
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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.
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,
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
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
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
>
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
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'
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
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
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
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
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
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
On 18/03/2015, David Bannon wrote:
> No, I'm sorry but I don't see how an interested party can be expected to
> objectively determine what the discussion concluded.
> [...]
> No, sorry, but a vote and an outcome may offend some politically correct
> members but it is necessary.
Don't you see the
On 18/03/2015, Kotya Karapetyan wrote:
> On Wed, Mar 18, 2015 at 11:00 PM, moltonel 3x Combo
> wrote:
>> Why should the page be "converted to a feature page" ?
>
> Because I would mark a proposal page as such in some place. Otherwise a
> stable 10 year-ol
On 18/03/2015, Kotya Karapetyan wrote:
> On Wed, Mar 18, 2015 at 11:00 PM, moltonel 3x Combo
> wrote:
>> Why should the page be "converted to a feature page" ?
>
> Because I would mark a proposal page as such in some place. Otherwise a
> stable 10 year-ol
On 18/03/2015, Christopher Hoess wrote:
> That's an interesting idea, but I think it may be a little too heavy on
> coexistence; I think we'd gradually accumulate a cloud of contradictory
> proposals with no incentive to resolve them.
Are you afraid of wiki bloat ? I don't think it'd be much of a
On 18/03/2015, Kotya Karapetyan wrote:
> I think some opposition to a proper voting mechanism is concentrating too
> much on the numbers. Indeed, we can have just 1 person proposing a tag, 20
> people voting about it, and thousands actually using (or miusing) it.
> However:
>
> 1) As mentioned els
On 18/03/2015, Martin Koppenhoefer wrote:
>> * key/tag pages would document the actual use (mainly observed via
>> taginfo)
>
> it is impossible to see from taginfo what a tag is used for, and for what
> it can't be used. You only get statistics how much it is used
>
>> * key/tag pages could be k
On 18/03/2015, Frederik Ramm wrote:
> So please, don't go over board here by trying to force-involve every
> mapper in tag votes; they're simply not important enough, and they
> *should not be*. Don't try to make them important, lasting, or binding.
+1 to all that. While I think that "voting" is
On 11/03/2015, Martin Koppenhoefer wrote:
> 2015-03-11 12:49 GMT+01:00 John Willis :
>
>> I assume a tower on a distant mountain is a survey_reference_object or
>> similar. It certainly isn't a point.
>
> maybe the tower has a point defined (e.g. top of the antenna or a sign or
> similar) which c
On 11/03/2015, Malcolm Herring wrote:
> I took a quick look at these objects & the few that I examined were
> actually created as areas, rather than had been converted from a node.
> The most egregious example is this one:
> http://www.openstreetmap.org/way/199650922. It is a square with sides
> o
On 11/03/2015, johnw wrote:
> Actual physical bridges - which may offer the only way across a ravine, or a
> landmark to where you are on a river sounds like a similar justification -
> so rendering abandoned, yet physically existing bridges seems like exactly
> the kind of thing that would be inc
On 11/03/2015, Richard Fairhurst wrote:
> moltonel 3x Combo wrote:
>> I'm playing the devil's advocate a bit here
>
> I believe the modern day term for that is "trolling", and it wastes
> everyone's time.
Sorry if looked like trolling. I was genuinel
On 11/03/2015, Malcolm Herring wrote:
> OK, the mapper in question did not reply, but silently removed the tags.
> This leaves me none the wiser as to the more widespread usage of this tag.
At least that's reassurance that a buoy, which can drift quite a bit
on the surface, isn't considered as a
On 10/03/2015, Bryce Nesbitt wrote:
> On Mon, Mar 9, 2015 at 5:53 PM, moltonel 3x Combo
> wrote:
> I've also seen the opposite mapping issue, where an abandoned railway was
> deleted from the map,
> when in fact large chunks still exist.
If an osm way represents a railway
On 10/03/2015, ael wrote:
> In passing, I am a little bemused that so many people seem to have missed
> the hint that I normally regard tagging for the renderer as evil by
> using the word "Blatant" in the title of this thread and that it was
> sort of a confession and plea for help on how to avoi
On 09/03/2015, Warin <61sundow...@gmail.com> wrote:
> Possible work around?
>
> Use the tag man_made=bridge to tag the bridge area?
>
> Keeps the railway correctly tagged. And places the bridge correctly.
>
> http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dbridge
>
> Try that and see if it works.
On 09/03/2015, Bryce Nesbitt wrote:
> Somehow I come down on the side that railways have enough footprint on the
> current world that
> they belong in OSM proper, unlike say old buildings or former shops.
>
> A abandoned railway slowly evolves from a mappable way, to a series of
> other things, be
On 09/03/2015, Bryce Nesbitt wrote:
> Ah thanks, I stand corrected. railway=razed would be the tag to discuss.
>
> The broader point is intact.
>
While there is a pretty strong consensus that osm describes the
present (leaving openhistoricalmap for the past), it seems that some
railway contributo
On 09/03/2015, ael wrote:
> On Mon, Mar 09, 2015 at 03:35:19PM +0100, Tom Pfeifer wrote:
>> +1, please tag what is on the ground,
>> and railway=abandoned is not rendered on carto by decision, read here:
>> https://github.com/gravitystorm/openstreetmap-carto/pull/542
>
> Thanks for the link. Inter
On 09/03/2015, Tom Pfeifer wrote:
> +1, please tag what is on the ground,
> and railway=abandoned is not rendered on carto by decision, read here:
> https://github.com/gravitystorm/openstreetmap-carto/pull/542
As for the discussion on rendering standalone bridges :
https://github.com/gravitystorm
On 01/03/2015, fly wrote:
> I just say, that out of the 25,000 objects tagged with route=foot over
> 21,000 have been tagged either network=lwn or network=rwn and would be
> better tagged route=hiking as that is the route type for hiking routes.
>
> In general, I do not like route=foot but I susta
1 - 100 of 166 matches
Mail list logo
