A few people continue to add unused tags and properties to feature
definitions, e.g. looking at the page for tourism=guesthouse, which is
quite long in the meantime, you can find "proposed" values with names like
"fridge"
"stove"
"drying:room"
"dinner"
which all hardly reach a 2 digit number of
I agree. The wiki is a point of entry for inexperienced contributors and
should therefore document established practices rather than serve as a
way to make marginal ideas appear established.
That said, the subjectivity of what constitutes "established practices"
guarantees controversy...
sent from a phone
> On 26. Apr 2019, at 11:52, Michael Brandtner via Tagging
> wrote:
>
> I’m against the tag baby_changing_table. As I have already written,
> changing_table is unambiguous and the most common word for this thing. No
> need for such a long key.
I’m not insisting, but I
I now splited the table into two parts so you can see how the wiki will look like (not equal)Seehttps://wiki.openstreetmap.org/wiki/Proposed_features/baby_changing_tables#Tagging Original Message Subject: Re: [Tagging] Feature Proposal - RFC - Baby changing tableFrom: Valor Naram
Hi everyone,
after some comments in which we found that there was a misunderstanding in the
definition, we rewrote partially it to be more clear, also with some images. So
we start a new vote phase, here the new link
On Thu, Apr 25, 2019 at 02:06:27PM +0200, Tobias Zwick wrote:
> Even shorter, because if there are conflicting rules in the conditional, the
> last one is taken, says the wiki. (Not sure if this is really implemented in
> applications that work with that data though):
just wondering, does
On 26/04/19 11:48, Joseph Eisenberg wrote:
I have created 2 proposal pages for natural=mesa and natural=butte
A mesa is defined as "A flat-topped elevated landform surrounded by
cliffs". A mesa may also be known as a table or tableland, potrero or
tepui. See http://en.wikipedia.org/wiki/en:mesa
I've already made a suggestion to split the wiki pages into two parts:The first one describes the key "changing_table" as a replacement for "diaper". This section will compare the old tagging with the new tagging without introducing new subkeys.The second one describes the extensions (adding of
On Thu, Apr 18, 2019 at 5:13 PM Joseph Eisenberg
wrote:
> Fri, Apr 19, 2019 at 7:.
>
>> I was wondering about leaving them all under peak?
>>
>> natural=peak
>> peak=hill/mountain/plateau/butte/mesa
>>
>> Would that work?
>>
>
> A peak is well defined as the local high point. A Mesa or butte
On Friday 26 April 2019, Joseph Eisenberg wrote:
> I have created 2 proposal pages for natural=mesa and natural=butte
>
> A mesa is defined as "A flat-topped elevated landform surrounded by
> cliffs". A mesa may also be known as a table or tableland, potrero or
> tepui. See
I think the whole problem cannot be solved in general as it depends from
case to case.
A nice example of where the clear distinction between "natural river"
and "artificial canal" is hard to tell is the river Altmühl: Its most
downstream part has been built into a canal, which later leaves the
sent from a phone
> On 26. Apr 2019, at 07:06, Warin <61sundow...@gmail.com> wrote:
>
> Flat topped area with sudden elevation, wider or longer than it is high
> but horizontal dimension less than 1.6 km.
or maybe 1.609344 kilometers? Seriously, if we use a definition based on
imperial
I’m against the tag baby_changing_table. As I have already written,
changing_table is unambiguous and the most common word for this thing. No need
for such a long key.
Am Donnerstag, April 25, 2019, 10:52 PM schrieb Martin Koppenhoefer
:
sent from a phone
> On 22. Apr 2019, at 01:49, marc
Volker Schmidt wrote:
> Going back to the original example, I would say, not only the lock but
> the entire cut, in particular way
> https://www.openstreetmap.org/way/24335
> should be tagged as waterway=canal. This scheme applies to most river-lock
> arrangements, the "cuts" are nearly
25 Apr 2019, 23:49 by 61sundow...@gmail.com:
>
> Communities have drawn together to keep a bank, a supermarket and a garage
> going locally. They have also drawn together to keep a doctor.
> They don't draw together for a church.
>
Depends on a community. The last one
certainly is not true for
sent from a phone
> On 26. Apr 2019, at 04:08, Joseph Eisenberg
> wrote:
>
> Then we would need to retag all of the other "camp_site=camp_pitch"
> objects
yes, my suggestion would be to retag all* 7000 camp_site=camp_pitch to a pitch
tag and keep the camp_site values that refer to
On Fri, Apr 26, 2019 at 5:47 AM Mateusz Konieczny
wrote:
> 25 Apr 2019, 23:49 by 61sundow...@gmail.com:
>> Communities have drawn together to keep a bank, a supermarket and a garage
>> going locally. They have also drawn together to keep a doctor.
>> They don't draw together for a church.
>
>
On Fri, Apr 26, 2019 at 3:44 AM Richard Fairhurst wrote:
> On some of the larger American river navigations the lock structures are
> built right within the main river channel - such as this new $3bn (!) lock
> on the Ohio River: https://en.wikipedia.org/wiki/Olmsted_Locks_and_Dam - so
> similar
18 matches
Mail list logo
