On 03/03/2016, Martin Koppenhoefer <dieterdre...@gmail.com> wrote:
>> Am 03.03.2016 um 03:57 schrieb moltonel 3x Combo <molto...@gmail.com>:
>>
>> The fact that we don't know wether the extra name is an old_name or a
>> loc_name or something else is independan
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, Hakuch <hak...@posteo.de> wrote:
> On 25.02.2016 01:37, molto
On 25/02/2016, Hakuch <hak...@posteo.de> 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 th
On 24/02/2016, Hakuch <hak...@posteo.de> 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 becaus
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
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.
>
.
On 24/02/2016, moltonel 3x Combo <molto...@gmail.com> wrote:
> http://wiki.openstreetmap.org/w/index.php?title=Key:name=next=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
&
http://wiki.openstreetmap.org/w/index.php?title=Key:name=next=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
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
>
On 27/01/2016, Colin Smale <colin.sm...@xs4all.nl> 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 n
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
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
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
>
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
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
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
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
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
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
etimes do the trick, but outright banning *_N
for the sake of (what ?) would cause a lot of headaches.
On 15/01/2016, Martin Koppenhoefer <dieterdre...@gmail.com> wrote:
> 2016-01-15 15:26 GMT+01:00 moltonel 3x Combo <molto...@gmail.com>:
> also shop_1 tags are created that way.
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
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"
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
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"
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
>
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
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
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
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
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
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
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
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
On 02/09/2015, Friedrich Volkmann <b...@volki.at> 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
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
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
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
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
On 29/07/2015, Marc Gemis marc.ge...@gmail.com wrote:
On Tue, Jul 28, 2015 at 5:29 PM, moltonel 3x Combo molto...@gmail.com
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 area
On 28/07/2015, Martin Koppenhoefer dieterdre...@gmail.com wrote:
Am 28.07.2015 um 11:02 schrieb Pavel Zbytovský zbytov...@gmail.com:
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?
On 28/07/2015, Pavel Zbytovský zbytov...@gmail.com 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
On 28/07/2015, Marc Gemis marc.ge...@gmail.com wrote:
On Tue, Jul 28, 2015 at 4:14 PM, moltonel 3x Combo molto...@gmail.com
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
On 20/07/2015, Greg Troxel g...@ir.bbn.com 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
On 16/07/2015, jonat...@bigfatfrog67.me 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.
On 08/07/2015, johnw jo...@mac.com 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,
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 what
On 04/06/2015, Jean-Marc Liotier j...@liotier.org 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
On 26/05/2015, Martin Koppenhoefer dieterdre...@gmail.com 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
On 26/05/2015, Andy Mabbett a...@pigsonthewing.org.uk 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;
On 25/05/2015, Michael Reichert naka...@gmx.net 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:
On 25/05/2015, pmailkeey . pmailk...@googlemail.com 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
On 25/05/2015, p...@trigpoint.me.uk 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,
On 25/05/2015, pmailkeey . pmailk...@googlemail.com 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
On 25/05/2015, Guillaume Allegre allegre.guilla...@free.fr 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 :
On 25/05/2015, Martin Koppenhoefer dieterdre...@gmail.com wrote:
2015-05-25 16:24 GMT+02:00 moltonel 3x Combo molto...@gmail.com:
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
On 25/05/2015, Andy Mabbett a...@pigsonthewing.org.uk wrote:
On 25 May 2015 at 17:13, moltonel 3x Combo molto...@gmail.com 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
On 25/05/2015, Andreas Goss andi...@t-online.de 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
On 25/05/2015, Andy Mabbett a...@pigsonthewing.org.uk wrote:
On 25 May 2015 at 22:18, moltonel 3x Combo molto...@gmail.com 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
On 19/05/2015, Simon Poole si...@poole.ch wrote:
On 19. Mai 2015 03:18:14 MESZ, johnw jo...@mac.com 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
TL;DR: off-topic, rant, noise
On 12/05/2015, pmailkeey . pmailk...@googlemail.com wrote:
On 12 May 2015 at 03:26, John F. Eldredge j...@jfeldredge.com 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
On 11/05/2015, Martin Koppenhoefer dieterdre...@gmail.com 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
On 11/05/2015, Daniel Koć daniel@koć.pl 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 andi...@t-online.de 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.
On 06/05/2015, Andy Mabbett a...@pigsonthewing.org.uk wrote:
On 6 May 2015 at 17:41, moltonel 3x Combo molto...@gmail.com wrote:
On 05/05/2015, Andy Mabbett a...@pigsonthewing.org.uk wrote:
If people choose not to (or are not bothered to) comment, that's an
abstention.
Indeed, it may
On 05/05/2015, Andy Mabbett a...@pigsonthewing.org.uk 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
On 24/04/2015, Thorsten Alge li...@thorsten-alge.de 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
On 23/04/2015, Martin Koppenhoefer dieterdre...@gmail.com 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
On 22/04/2015, Martin Koppenhoefer dieterdre...@gmail.com wrote:
2015-04-22 9:19 GMT+02:00 Paul Johnson ba...@ursamundi.org:
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
On 22/04/2015, Bryce Nesbitt bry...@obviously.com wrote:
On Wed, Apr 22, 2015 at 9:34 AM, moltonel 3x Combo molto...@gmail.com
wrote:
smoking=yes/no/outside/etc for the general value
smoking:type=yes/no/etc for exceptions
With type being any of cigarette, e-cigarette, hooka, marijuana, opium
On 21/04/2015, Thorsten Alge li...@thorsten-alge.de 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
On 14/04/2015, Christoph Hormann chris_horm...@gmx.de 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
On 05/04/2015, Frederik Ramm frede...@remote.org 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
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. Would you
On 18/03/2015, Kotya Karapetyan kotya.li...@gmail.com wrote:
On Wed, Mar 18, 2015 at 11:00 PM, moltonel 3x Combo molto...@gmail.com
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-old feature
On 18/03/2015, Kotya Karapetyan kotya.li...@gmail.com wrote:
On Wed, Mar 18, 2015 at 11:00 PM, moltonel 3x Combo molto...@gmail.com
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-old feature
On 18/03/2015, David Bannon dban...@internode.on.net 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.
On 18/03/2015, Martin Koppenhoefer dieterdre...@gmail.com 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
On 18/03/2015, Christopher Hoess caho...@gmail.com 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
On 18/03/2015, Kotya Karapetyan kotya.li...@gmail.com 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)
On 11/03/2015, johnw jo...@mac.com 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
On 11/03/2015, Malcolm Herring malcolm.herr...@btinternet.com 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
On 11/03/2015, Richard Fairhurst rich...@systemed.net 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 genuinely trying to show both
sides
On 11/03/2015, Malcolm Herring malcolm.herr...@btinternet.com 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
On 11/03/2015, Martin Koppenhoefer dieterdre...@gmail.com wrote:
2015-03-11 12:49 GMT+01:00 John Willis jo...@mac.com:
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
On 10/03/2015, Bryce Nesbitt bry...@obviously.com wrote:
On Mon, Mar 9, 2015 at 5:53 PM, moltonel 3x Combo molto...@gmail.com
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
On 10/03/2015, ael law_ence@ntlworld.com 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
On 09/03/2015, Tom Pfeifer t.pfei...@computer.org 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 :
On 09/03/2015, ael law_ence@ntlworld.com 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
On 09/03/2015, Bryce Nesbitt bry...@obviously.com 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
On 09/03/2015, Bryce Nesbitt bry...@obviously.com 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
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.
Not
On 01/03/2015, fly lowfligh...@googlemail.com 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
On 18/02/2015, Colin Smale colin.sm...@xs4all.nl wrote:
As lots of people frequently point out, what about emergency vehicles?
They can (often) ignore legal restrictions, but not physical ones:
if(i_am_an_emergency_vehicle)
maxfoo = min(maxfoo:physical, maxfoo:legal)
else
maxfoo =
On 18/02/2015, Martin Koppenhoefer dieterdre...@gmail.com wrote:
Am 17.02.2015 um 19:57 schrieb moltonel 3x Combo molto...@gmail.com:
maxfoo = min(maxfoo:physical, maxfoo:legal)
-1, maxfoo was always defined as a legal restriction so this function should
go into your data evaluator
On 18/02/2015, Tobias Knerr o...@tobias-knerr.de wrote:
On 18.02.2015 10:39, moltonel 3x Combo wrote:
Allow me to disagree:
* maxheight is defined this way. Having maxwidth defined differently
is asking for trouble.
I agree with you that we should define all the max* keys in the same
way
On 16/02/2015, Kytömaa Lauri lauri.kyto...@aalto.fi wrote:
The width of the vehicle that could use the way can be wider than the way
itself [...]
Another example where width != maxwidth:physical is a twisty tunnel.
The longer a vehicle is, the more margin it requires to be able to
pass. So a
On 16/02/2015, Martin Koppenhoefer dieterdre...@gmail.com wrote:
2015-02-16 10:42 GMT+01:00 Martin Vonwald imagic@gmail.com:
* maxwidth: this is a legal limitation; nothing wider than the given
value may use the feature
+1, there is also the synonym maxwidth:legal (IMHO not advisable,
On 01/02/2015, Tac Tacelosky tac...@gmail.com wrote:
Another legitimate terms for these shops is a vape shop, and the practice
of using any sort of electronic cigarette is now referred to as vaping.
This is a better term than smoking, as the product emits vapors, not
smoke.
We are
On 24/01/2015, Dave Swarthout daveswarth...@gmail.com wrote:
Nobody votes because it's a borderline pointless endeavor.
I'd like to defend the voting system a bit. In my opinion it's working
fine. The only issue is that people have wrong expectations as to what
voting provides.
As has already
On 25/01/2015, Marc Gemis marc.ge...@gmail.com wrote:
My experience is that it is very hard to place every house in the right
relation before you know the actual address. Especially with corner houses
and in rural areas where the driveways to the farms do not always connect
to the street with
1 - 100 of 151 matches
Mail list logo