Re: [Tagging] [OSM-talk] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

2020-01-06 Thread Maarten Deen

On 2020-01-07 08:27, Mateusz Konieczny wrote:

6 Jan 2020, 16:35 by dieterdre...@gmail.com:


sent from a phone

On 6. Jan 2020, at 07:29, Maarten Deen  wrote:

Baltic Sea to be the "Baltic Sea" or for South America to be "South

America" - this is an example of English imperialism.

This "imperialism" idea of yours is just your idea. It is not
something that is widely felt.


regarding imperialism, I think it’s hard to reject the reasoning
that English is in widespread use because of imperialism.

Yes, but using it for a pragmatic reasons
for an international communication is
usually not imperialism.


I am also not a fan of blaming history for the current situation and 
taking the long road because you don't like that history.
It would mean that I couldn't speak dutch with my Surinam friends just 
because 400 years ago the ideas of how we should conduct ourselves were 
different.


That is just counterproductive.

Regards,
Maarten

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] addresses on buildings

2020-01-06 Thread Marc Gemis
On Tue, Jan 7, 2020 at 1:32 AM Jarek Piórkowski  wrote:
>
> On Mon, 6 Jan 2020 at 18:23, Dave F via Tagging
>  wrote:
> > On 05/01/2020 18:37, Marc Gemis wrote:
> > > This depends on the country.
> > > It is "forbidden" to put the address on the building in Denmark,
> >
> > Hi
> >
> > Where does it say that? Where does it say it's forbidden to add address
> > data to building polygons in OSM?
>
> Of course nothing is truly forbidden in OSM as long as you are mapping
> in good faith ("any tags you like" spirit) but local community
> consensus can discourage some tagging schemes (such as separate ways
> for sidewalks in Germany) and this is likely what Marc had in mind
> when writing "forbidden" in quotation marks.

indeed, that's why I used quotation marks.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] addresses on buildings

2020-01-06 Thread Marc Gemis
On Mon, Jan 6, 2020 at 7:21 PM Markus  wrote:
>
> On Sun, 5 Jan 2020 at 19:39, Marc Gemis  wrote:
> >
> > This depends on the country.
> > It is "forbidden" to put the address on the building in Denmark,
>
> Says who? And why?

The Danish community, as the address nodes were automatically
imported, see https://wiki.openstreetmap.org/wiki/Addresses#Denmark

Dave F wrote a longer explanation.

regards

m.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

2020-01-06 Thread Mateusz Konieczny
6 Jan 2020, 16:35 by dieterdre...@gmail.com:

>
>
> sent from a phone
>
>> On 6. Jan 2020, at 07:29, Maarten Deen  wrote:
>>
>>> Baltic Sea to be the "Baltic Sea" or for South America to be "South
>>> America" - this is an example of English imperialism.
>>>
>>
>> This "imperialism" idea of yours is just your idea. It is not something that 
>> is widely felt.
>>
>
>
>
> regarding imperialism, I think it’s hard to reject the reasoning that English 
> is in widespread use because of imperialism. 
>
Yes, but using it for a pragmatic reasons
for an international communication is
usually not imperialism.
I can try to communicate with group of  people
from different countries in Polish,
Latin, Sindarin or Esperanto.
But except rare cases using English is likely
to result in more efficient communication.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Incomplete addresses

2020-01-06 Thread Mateusz Konieczny

7 Jan 2020, 02:58 by graemefi...@gmail.com:
> I kept finding places with the street number & name entered, often together 
> with the post code!, but with no suburb listed?
>
> Obviously, I have no idea which editor was used to map them, but shouldn't 
> this sort of thing error to say "Incomplete address entered" or words to that 
> effect?
>
In many places, for example in villages
and small towns there are no defined
suburbs (at least in Poland).

Also, in Poland, this is either very subjective
or can be generated from mapped boundaries.

And anyway is not used for addressing anyway.

So in some places you are unable to tag it,
in some places there is no good reason to tag this.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Incomplete addresses

2020-01-06 Thread Graeme Fitzpatrick
On Tue, 7 Jan 2020 at 12:06, Jarek Piórkowski  wrote:

>
> In Ontario we don't always map city and province in cases where that
> can be easily computed from other OSM data. Province is outright
> discouraged. When the administrative boundaries of municipalities and
> regions/states/provinces are fully mapped in OSM, requiring them also
> on every address node seems a bit pedantic


On Tue, 7 Jan 2020 at 12:33, Andrew Harvey  wrote:

> I agree, it's pedantic to add the suburb and state since these can easily
> be derived from the admin boundaries
>

Guess that makes me pedantic then! :-)


> That said, it can still be useful to tag the suburb on the address node,
> especially for properties near the border of two suburbs as the node might
> end up falling on the other side of the admin boundary
>

Yep, this is something I've often seen in OSMAND, which stubbornly tells me
that this street doesn't exist, despite it being in OSM :-(

OK then, I won't worry too much about it (but will still "fix" them when I
spot them! :-))

  Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] addresses on buildings

2020-01-06 Thread Rob Savoye
On 1/6/20 6:04 PM, Paul Allen wrote:
> As I understand it, in some countries the emergency services use
> OSM. Knowing the building they can figure out which gate to use. 
> Knowing the gate may not tell them which of several buildings they
> need to get to.
  We use OSM for emergency response since Google has poor data in my
area. Since the OSM data here is now quite detailed and accurate, it
literally dropped our response time in half. All our fire trucks have a
10" tablet mounted on the dash that works as a dedicated mapping device.
Our district covers several hundred square kilometers of mostly obscure
dirt roads left from the mining era.

> Then again, as long as people don't force me to put addresses at the
> end of driveways, I'm not going to put much effort into arguing the
> point.
  I think there is confusion as to a real building's address sign, which
may be at the end of the driveway, but in an OSM file, the address node
should be on the building. Or part of the building way's tags.

- rob -

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Incomplete addresses

2020-01-06 Thread Andrew Harvey
I agree, it's pedantic to add the suburb and state since these can easily
be derived from the admin boundaries, and often from a ground survey you
won't be able to know the suburb anyway so best to just enter the data that
you can survey.

That said, it can still be useful to tag the suburb on the address node,
especially for properties near the border of two suburbs as the node might
end up falling on the other side of the admin boundary so you can't just
inherit it.

On Tue, 7 Jan 2020 at 13:06, Jarek Piórkowski  wrote:

> On Mon, 6 Jan 2020 at 20:59, Graeme Fitzpatrick 
> wrote:
> >
> > Was wondering about how to bring this up when the ongoing discussion
> about building addresses started ...
> >
> > I've recently been working on Map Roulette errors, & while doing so,
> have come across quite a few cases where addresses haven't been completely
> entered.
> >
> > In Australia, the format for entering addresses (at least in iD!) is
> Unit (number); (Street) Number; Street name; Suburb; State & Postcode.
> >
> > I kept finding places with the street number & name entered, often
> together with the post code!, but with no suburb listed?
> >
> > Obviously, I have no idea which editor was used to map them, but
> shouldn't this sort of thing error to say "Incomplete address entered" or
> words to that effect?
>
> In Ontario we don't always map city and province in cases where that
> can be easily computed from other OSM data. Province is outright
> discouraged. When the administrative boundaries of municipalities and
> regions/states/provinces are fully mapped in OSM, requiring them also
> on every address node seems a bit pedantic (unless of course the
> address is computed wrongly otherwise).
>
> Though I'm sure local practice will vary across the world.
>
> --Jarek
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Incomplete addresses

2020-01-06 Thread Jarek Piórkowski
On Mon, 6 Jan 2020 at 20:59, Graeme Fitzpatrick  wrote:
>
> Was wondering about how to bring this up when the ongoing discussion about 
> building addresses started ...
>
> I've recently been working on Map Roulette errors, & while doing so, have 
> come across quite a few cases where addresses haven't been completely entered.
>
> In Australia, the format for entering addresses (at least in iD!) is Unit 
> (number); (Street) Number; Street name; Suburb; State & Postcode.
>
> I kept finding places with the street number & name entered, often together 
> with the post code!, but with no suburb listed?
>
> Obviously, I have no idea which editor was used to map them, but shouldn't 
> this sort of thing error to say "Incomplete address entered" or words to that 
> effect?

In Ontario we don't always map city and province in cases where that
can be easily computed from other OSM data. Province is outright
discouraged. When the administrative boundaries of municipalities and
regions/states/provinces are fully mapped in OSM, requiring them also
on every address node seems a bit pedantic (unless of course the
address is computed wrongly otherwise).

Though I'm sure local practice will vary across the world.

--Jarek

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Incomplete addresses

2020-01-06 Thread Graeme Fitzpatrick
Was wondering about how to bring this up when the ongoing discussion about
building addresses started ...

I've recently been working on Map Roulette errors, & while doing so, have
come across quite a few cases where addresses haven't been completely
entered.

In Australia, the format for entering addresses (at least in iD!) is Unit
(number); (Street) Number; Street name; Suburb; State & Postcode.

I kept finding places with the street number & name entered, often together
with the post code!, but with no suburb listed?

Obviously, I have no idea which editor was used to map them, but shouldn't
this sort of thing error to say "Incomplete address entered" or words to
that effect?

Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

2020-01-06 Thread Joseph Eisenberg
> YES, so let's use the planned language! Either Esperanto (because of
> popularity) or Interlingua (because it is understood without learning
> for Romance language users).

This is not an improvement for native speakers of any of the Han
Chinese languages, or Arabic, or any of the other languages which is
not Indo-European and does not use the Latin script. Over 2 billion
people speak such languages as their primary tongue.

I do not see any support from the OSM community for using invented
languages in the name=* tag for any features.


> I've been suggesting
> to create a renderrer that just uses "name: eo" if present ... just to
> be told right away that this is not a good solution as it would
> basically chooses the Esperanto name for everything instead of just
> these places where there is no default language. I think that having an
> empty "name" tag or not having a "name" tag would be a nice indication
> that there is not best "name" tag, and leave each renderrer use their
> heuristics (or just display no name).

This will not work, because local mappers will constantly be adding
back "name=*" tags to get the feature to appear in their favorite map
style. If you want to define that a feature has no default language,
it would be good to use a new tag like "default:language=none" or
something similar, but it will be hard to determine when to use such a
tag.

> On 01/20-06 at 15:45, Joseph Eisenberg writes:
>> (Note that Openstreetmap-carto does not render the names of oceans,
>> continents and seas, but does render the names of some large bays and
>> straits and islands which are relevant to this discussion)

> Only relations with the tag, e.g. natural = bay or water = sea are
> rendered on the map.

That is incorrect, though I understand why it appears this way*.

All natural=water features, which should be lakes or similar inland
waters, are rendered in the Openstreetmap-carto style at high zoom
levels (low scale) when tagged as a node, or at a zoom level
appropriate to their size if mapped as an area, whether a multipolygon
relation or a closed way. The same is true for natural=bay and
natural=strait features found in the oceans.  For straits and bays
like fjords which are mapped as lines, the name is also rendered along
the line from moderately high zoom levels.

Seas are not yet rendered (place=sea) and probably will not get
rendered anytime soon due to several issues, includin this one about
the appropriateness of the name=* tag for seas that border multiple
countries, and the verifiability issues with mapping them as areas.

(Rendering seas and peninsulas properly when tagged as nodes could be
done but requires someone to work on a technical solution)

Joseph Eisenberg
*See issue #3634 for a heated discussion at Openstreetmap-carto -
https://github.com/gravitystorm/openstreetmap-carto/issues/3634 - also
PR #3750 https://github.com/gravitystorm/openstreetmap-carto/pull/3750

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] addresses on buildings

2020-01-06 Thread Dave F via Tagging



On 07/01/2020 00:30, Jarek Piórkowski wrote:

Hi,
https://wiki.openstreetmap.org/wiki/Addresses#Denmark and
https://wiki.openstreetmap.org/wiki/Da:Adresser seem like a good place
to start.


Hi Jarek
Yes I had read the first link previously.


Of course nothing is truly forbidden in OSM as long as you are mapping
in good faith ("any tags you like" spirit) but local community
consensus can discourage some tagging schemes (such as separate ways
for sidewalks in Germany) and this is likely what Marc had in mind
when writing "forbidden" in quotation marks.


Again, no valid reason has been given by other local community as to why 
addresses can't be added to buildings to make the data useful. Being 
unable to create software to check buildings for addresses is not a 
valid argument.


Cheers
DaveF


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] addresses on buildings

2020-01-06 Thread Paul Allen
On Tue, 7 Jan 2020 at 00:57, Martin Koppenhoefer 
wrote:

>
> > On 7. Jan 2020, at 01:17, Paul Allen  wrote:
> >
> > The question is, are we mapping an address or the location of a house
> name/number
> > plate associated with the address?  I'd say the address.
>
> both, we are mapping both, using the same tags: housenumbers and addresses
>

I'd say that mapping the same address both ways is confusing.

I'd also say that, in an example that appeared here earlier, where several
properties
can be accessed by any of several gates, the correct way to handle it would
not be
to put addresses on gates but by footpaths or pedestrian areas or similar
and apply
the addresses to the buildings.

As I understand it, in some countries the emergency services use OSM.
Knowing
the building they can figure out which gate to use.  Knowing the gate may
not tell
them which of several buildings they need to get to.

Then again, as long as people don't force me to put addresses at the end of
driveways, I'm not going to put much effort into arguing the point.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] addresses on buildings

2020-01-06 Thread Martin Koppenhoefer


sent from a phone

> On 7. Jan 2020, at 01:17, Paul Allen  wrote:
> 
> The question is, are we mapping an address or the location of a house 
> name/number
> plate associated with the address?  I'd say the address.



both, we are mapping both, using the same tags: housenumbers and addresses 


Cheers Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] addresses on buildings

2020-01-06 Thread Martin Koppenhoefer


sent from a phone

> On 7. Jan 2020, at 00:32, Dave F via Tagging  
> wrote:
> 
> but can you show us rule where it says address data can't be added to 
> buildings if there's only one entrance?


this is also what I have been arguing for in Italy, use addr tags on the whole 
area when there’s only one number through which it is accessible.


> or do even individual domestic properties which have both front & back doors 
> have two postal addresses?


back doors don’t, but gates in the fence do, so often a property is accessible 
through several different numbers. Also windows may get numbers.

Cheers Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] addresses on buildings

2020-01-06 Thread Jarek Piórkowski
On Mon, 6 Jan 2020 at 18:23, Dave F via Tagging
 wrote:
> On 05/01/2020 18:37, Marc Gemis wrote:
> > This depends on the country.
> > It is "forbidden" to put the address on the building in Denmark,
>
> Hi
>
> Where does it say that? Where does it say it's forbidden to add address
> data to building polygons in OSM?

Hi,

https://wiki.openstreetmap.org/wiki/Addresses#Denmark and
https://wiki.openstreetmap.org/wiki/Da:Adresser seem like a good place
to start.

Of course nothing is truly forbidden in OSM as long as you are mapping
in good faith ("any tags you like" spirit) but local community
consensus can discourage some tagging schemes (such as separate ways
for sidewalks in Germany) and this is likely what Marc had in mind
when writing "forbidden" in quotation marks.

[...]
> This was provided by another user & I suspect is getting close to the
> real reason:
>
> "Transferring the data to buildings will mess up the maintenance"
>
> I asked JKHougaard why his bot couldn't be updated to check ways. "that
> is beyond my coding skills" was his reply.
>
> I may be wrong, but given the responses I can only conclude it's a smoke
> screen to cover up the limitations of the bot.

Local community consensus are a thing in OSM. If you disagree you can
of course try convincing the Danish mapper community that they've been
doing it wrong for 10 years.

BTW how would you map an address of a lot that currently has no building on it?

Cheers,
Jarek

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] addresses on buildings

2020-01-06 Thread Paul Allen
On Mon, 6 Jan 2020 at 23:56, Rob Savoye  wrote:

> On 1/6/20 4:38 PM, Volker Schmidt wrote:
>
> > the buildings, where he can ring the bell. In many case this is not on
> > the building but on the entrance to the property.. I have a real case
>
>   Here that's very common. Physical address signs are on the end of the
> driveway where they can be seen. Course many driveways around here are
> long, and you can't see the house from the road.
>

There are a few of each type near me.  House at the end of a long drive,
can't
be seen from the road, house name is marked at entrance to driveway.  Block
of apartments with an entry gate with buzzers.

I am not convinced marking the location of the house name number, rather
than the house itself, is useful.  The people with the long drive live in
the house,
not at the entrance to the drive.  They don't have a letterbox at the end
of the drive,
but even if they did the address belongs to the house.  Yes, delivery
people would
have to stop at the entrance gate to the block of flats, but that would be
apparent
from inspection of the map or on arrival at the place.

The question is, are we mapping an address or the location of a house
name/number
plate associated with the address?  I'd say the address.

Consider a long driveway shared between several houses.  Letterboxes at the
start
of the driveway, and that's where the house names/numbers are marked.  If
you're
delivering a pizza, you need to know which house to go to after going along
the drive.

For many purposes, marking the location of the sign, rather than the actual
building,
seems to me to be perverse.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] addresses on buildings

2020-01-06 Thread Rob Savoye
On 1/6/20 4:38 PM, Volker Schmidt wrote:

> the buildings, where he can ring the bell. In many case this is not on
> the building but on the entrance to the property.. I have a real case

  Here that's very common. Physical address signs are on the end of the
driveway where they can be seen. Course many driveways around here are
long, and you can't see the house from the road.

- rob -

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Givebox

2020-01-06 Thread Eric Theise
People's Park in Berkeley was known for, among other things, its "free box".
https://www.peoplespark.org/wp/free-clothing-box/

Might be a less encumbered term than "givebox" given the trademark issue
Paul raises.

Eric


On Mon, Jan 6, 2020 at 3:38 PM Jmapb via Tagging 
wrote:

> On 1/6/2020 5:41 PM, Markus Peloso wrote:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Givebox
>
>
>
> A facility where people drop off and pick up various types of goods in the
> sense of free sharing.
>
>
>
> Hi
>
>
>
> Based on the https://wiki.openstreetmap.org/wiki/Proposed_features/Reuse
> and the  https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpublic_bookcase
> tag I describe a tag for facilities similar to public bookcases but with
> all kinds of (none food) goods.
>
>
>
>
>
> Hi Markus, why not just "reuse" amenity=reuse? It already has some small
> measure of adoption. (Taginfo shows 68 uses.)
>
> J
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Givebox

2020-01-06 Thread Volker Schmidt
The company with the same name is not related to the objects we are talking
about. In any case it's a company' name for a product or service they
provide. In addition it is not a GB-English term, so we need to find
something which describes the concept.

On Tue, 7 Jan 2020 at 00:38, Jmapb via Tagging 
wrote:

> On 1/6/2020 5:41 PM, Markus Peloso wrote:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Givebox
>
>
>
> A facility where people drop off and pick up various types of goods in the
> sense of free sharing.
>
>
>
> Hi
>
>
>
> Based on the https://wiki.openstreetmap.org/wiki/Proposed_features/Reuse
> and the  https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpublic_bookcase
> tag I describe a tag for facilities similar to public bookcases but with
> all kinds of (none food) goods.
>
>
>
>
>
> Hi Markus, why not just "reuse" amenity=reuse? It already has some small
> measure of adoption. (Taginfo shows 68 uses.)
>
> J
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] addresses on buildings

2020-01-06 Thread Volker Schmidt
I would assume that the routing/navigation argument is a valid one. The
delivery van wants to stop as close as possible to the real entrance  of
the buildings, where he can ring the bell. In many case this is not on the
building but on the entrance to the property.. I have a real case
nearby (Mapillary
image ).
This entrance gate has the house number 20, and  the people live in the
condominiums that are partially visible behind. Below the number-20 plate
are the door bells and to the left the letter boxes. It is at this gate
where the delivery van has to stop to ting the door bell.

On Tue, 7 Jan 2020 at 00:25, Dave F via Tagging 
wrote:

> On 05/01/2020 18:37, Marc Gemis wrote:
> > This depends on the country.
> > It is "forbidden" to put the address on the building in Denmark,
>
> Hi
>
> Where does it say that? Where does it say it's forbidden to add address
> data to building polygons in OSM?
>
> Keeping address data separate from buildings (which contain the primary
> tags) reduces the usefulness of the data. It prevents mail-sort
> compilations for residential houses. or locating all hairdressers in
> Randers.
>
>
> Recently, I asked a few people, including JKHougaard,  the creator of
> https://www.openstreetmap.org/user/autoAWS, but the all failed to confirm.
>
> He gave this as an explanation:
>
> "The reason we treat addresses in Denmark nodes is because that is how
> an address is legally defined here."
>
>   However, he failed to say how this Danish opendata licence prevents it
> from being transferred to buildings within OSM
>
> This was given to me by another user as justification:
>
> "The house number in the address shall refer to the exterior entrance
> door or similar to a building or part of a building which the address
> identifies." https://w2l.dk/file/661441/The_Danish_Adress_act.pdf
>
> But that says nothing about it relating to OSM
>
> This was provided by another user & I suspect is getting close to the
> real reason:
>
> "Transferring the data to buildings will mess up the maintenance"
>
> I asked JKHougaard why his bot couldn't be updated to check ways. "that
> is beyond my coding skills" was his reply.
>
> I may be wrong, but given the responses I can only conclude it's a smoke
> screen to cover up the limitations of the bot.
>
> DaveF
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Givebox

2020-01-06 Thread Jmapb via Tagging

On 1/6/2020 5:41 PM, Markus Peloso wrote:


https://wiki.openstreetmap.org/wiki/Proposed_features/Givebox

A facility where people drop off and pick up various types of goods in
the sense of free sharing.

Hi

Based on the
https://wiki.openstreetmap.org/wiki/Proposed_features/Reuse
 and the
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpublic_bookcase tag
I describe a tag for facilities similar to public bookcases but with
all kinds of (none food) goods.


Hi Markus, why not just "reuse" amenity=reuse? It already has some small
measure of adoption. (Taginfo shows 68 uses.)

J

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] addresses on buildings

2020-01-06 Thread Dave F via Tagging

On 06/01/2020 21:55, Volker Schmidt wrote:

This depends on the country.

It is "forbidden" to put the address on the building in Denmark,

A similar rule exist in Italy: the number has to be put where the actual
entrance is,


Well, this is slightly better than floating nodes as in Denmark, but can 
you show us rule where it says address data can't be added to buildings 
if there's only one entrance? or do even individual domestic properties 
which have both front & back doors have two postal addresses?


Cheers
DaveF



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] addresses on buildings

2020-01-06 Thread Simon Poole

Am 06.01.2020 um 22:55 schrieb Volker Schmidt:
>
>
>
> > This depends on the country.
> > It is "forbidden" to put the address on the building in Denmark,
>
> A similar rule exist in Italy: the number has to be put where the
> actual entrance is, as the number identifies an entrance and not a
> building.
> Thai also helps navigation devices to get you to the actual entrance
> and not only near the building.
> But this is Italy-specific.

Switzerland is similar (the national address dataset is a bit hit and
miss if the location is actually usable, but that's life).



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] addresses on buildings

2020-01-06 Thread Dave F via Tagging

On 05/01/2020 18:37, Marc Gemis wrote:

This depends on the country.
It is "forbidden" to put the address on the building in Denmark,


Hi

Where does it say that? Where does it say it's forbidden to add address 
data to building polygons in OSM?


Keeping address data separate from buildings (which contain the primary 
tags) reduces the usefulness of the data. It prevents mail-sort 
compilations for residential houses. or locating all hairdressers in 
Randers.



Recently, I asked a few people, including JKHougaard,  the creator of 
https://www.openstreetmap.org/user/autoAWS, but the all failed to confirm.


He gave this as an explanation:

"The reason we treat addresses in Denmark nodes is because that is how 
an address is legally defined here."


 However, he failed to say how this Danish opendata licence prevents it 
from being transferred to buildings within OSM


This was given to me by another user as justification:

"The house number in the address shall refer to the exterior entrance 
door or similar to a building or part of a building which the address 
identifies." https://w2l.dk/file/661441/The_Danish_Adress_act.pdf


But that says nothing about it relating to OSM

This was provided by another user & I suspect is getting close to the 
real reason:


"Transferring the data to buildings will mess up the maintenance"

I asked JKHougaard why his bot couldn't be updated to check ways. "that 
is beyond my coding skills" was his reply.


I may be wrong, but given the responses I can only conclude it's a smoke 
screen to cover up the limitations of the bot.


DaveF


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Givebox

2020-01-06 Thread Hauke Stieler
Hi,

I also came along those boxes and love the idea to have a separate tag
for them.

Just some small things:

- There should be an icon on the map. Maybe something like the
shop=charity icon [0] but with a box? Just an idea.

- I think a German "Umsonstladen" is more like a store and less like a
box (even though giveboxes are mentioned on the wikipedia page). However
I also know the term "Tausch-Box" for an actual givebox.

Apart from this, your proposal looks very good to me and so far I don't
have anything to add.

Hauke

[0] https://wiki.openstreetmap.org/wiki/File:Charity-14.svg

On 06.01.20 23:41, Markus Peloso wrote:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Givebox
> 
>  
> 
> A facility where people drop off and pick up various types of goods in
> the sense of free sharing.
> 
>  
> 
> Hi
> 
>  
> 
> Based on the https://wiki.openstreetmap.org/wiki/Proposed_features/Reuse
> and the
>  https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpublic_bookcase tag I
> describe a tag for facilities similar to public bookcases but with all
> kinds of (none food) goods.
> 
>  
> 
>  
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Givebox

2020-01-06 Thread Paul Allen
On Mon, 6 Jan 2020 at 22:43, Markus Peloso  wrote:

> https://wiki.openstreetmap.org/wiki/Proposed_features/Givebox
>
>
> Your proposal states that "Givebox" is the name of such a facility in
Germany
and links to its Facebook page.  "Givebox" is therefore a trademark, and you
know it's a trademark, so should not be used as a tag.  There are legal
implications to trademarks and the organization would be likely to take
legal action against OSM if we used it as a tag.

It's also not a name that conveys to at least one British English speaker
(me)
what it is.  I would assume a box of some sort, not a room in a building.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Tagging for emojis names

2020-01-06 Thread Hauke Stieler
> I could sort of understand if a business name was an emoji, rather than
> real words, but I'm not aware of any cases of this?

But I would tag a pure emoji-name of a company using the normal "name"
key. However I'm also not aware of any case.

Hauke



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Feature Proposal - RFC - Givebox

2020-01-06 Thread Markus Peloso
https://wiki.openstreetmap.org/wiki/Proposed_features/Givebox

A facility where people drop off and pick up various types of goods in the 
sense of free sharing.

Hi

Based on the https://wiki.openstreetmap.org/wiki/Proposed_features/Reuse and 
the  https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpublic_bookcase tag I 
describe a tag for facilities similar to public bookcases but with all kinds of 
(none food) goods.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Tagging for emojis names

2020-01-06 Thread Graeme Fitzpatrick
On Tue, 7 Jan 2020 at 08:26, Paul Allen  wrote:

>
> There are few, if any, use cases where the cosmetic enhancement of the few
> relevant emojis would make sense or improve the map in any meaningful way.
>

I could sort of understand if a business name was an emoji, rather than
real words, but I'm not aware of any cases of this?

  Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Tagging for emojis names

2020-01-06 Thread Paul Allen
On Mon, 6 Jan 2020 at 22:11,  wrote:

> I have now added a rationale part.
>

I don't see searches as relevant.  There are far more emojis than most
people
can remember.  Many emojis are indecipherable unless you're already familiar
with them.  So this is how the search would actually go...

Do a search to see if a Mount Everest emoji exists.  If it does, copy and
paste
it into the OSM search box.  It is far easier and quicker to just type
"mount
everest" into OSM than type "mount everest emoji" into google so you can
copy and paste the result, if there is one, into OSM.

There are few, if any, use cases where the cosmetic enhancement of the few
relevant emojis would make sense or improve the map in any meaningful way.

I remain firmly unconvinced.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Tagging for emojis names

2020-01-06 Thread ferdi98701
I have now added a rationale part.From: Paul AllenSent: Montag, 6. Januar 2020 23:00To: Tag discussion, strategy and related toolsSubject: Re: [Tagging] Tagging for emojis names On Mon, 6 Jan 2020 at 21:49,  wrote:I have made this drafthttps://wiki.openstreetmap.org/wiki/Proposed_features/Emoji_names for this Topic and I would like feedback and improvement The proposal needs a rationale explaining why it is necessary, or at least whyit serves a useful purpose, to specify emojis for objects. Either only a very limited number of such emojis exists (such as for the Statueof Liberty) in which case the ordinary name is better or every possible toponymwill get its own emoji (which would be unworkable). Oh, and one of the emojis in your proposal is for the US flag, not the US. It all seems kind of pointless to me.  I await your rationale... -- Paul  

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

2020-01-06 Thread Markus
On Sun, 5 Jan 2020 at 23:27, Tomek  wrote:
>
> I plan to remove the "name" and "wikipedia" tags from places that are not 
> associated with a specific nation or language:
> * continents
> * north and south poles
> * seas and bays, but exceptionally leaving the "name" tag for seas with a 
> maximum of two (or three) languages of neighboring countries, so for example 
> "Белое море" will not change.
> The purpose of this edition is to make the OSM map more neutral and not 
> humiliate people from any country. There is no reason for the Baltic Sea to 
> be the "Baltic Sea" or for South America to be "South America" - this is an 
> example of English imperialism.

I support removing the name=* tag from these places, but for a different reason:

The name=* tag is used to store the local name: "Note that OSM follows
the On the Ground Rule. Names recorded in name=* tag are ones that are
locally used, especially ones typically signposted." [1]

For places where it's impossible to identify a local name, the name
tag should not have been filled out (or at least not set to a single
language).

[1]: https://wiki.openstreetmap.org/wiki/Key:name

Regards

Markus

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

2020-01-06 Thread Tom Pfeifer

On 06.01.2020 21:32, Tomek wrote:
Exactly, does a buoy with the inscription "Baltic Sea" swim at 56° N18° E? No, there is simply water 
that Poles call the "Morze Bałtyckie", Germans "Ostsee", etc.


Hey, if that solves the conflict, let's check OSMF's budget, charter the OSMbow-Warrior and plant 
such a buoy! Funds can probably be claimed back from Wikimedia as a community building project.


> Please support (vote) my proposal or write a reason why not.

For the count, +1 against.

tom

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Tagging for emojis names

2020-01-06 Thread Paul Allen
On Mon, 6 Jan 2020 at 21:49,  wrote:

> I have made this draft
> https://wiki.openstreetmap.org/wiki/Proposed_features/Emoji_names
> for this Topic and I would like feedback and improvement
>

The proposal needs a rationale explaining why it is necessary, or at least
why
it serves a useful purpose, to specify emojis for objects.

Either only a very limited number of such emojis exists (such as for the
Statue
of Liberty) in which case the ordinary name is better or every possible
toponym
will get its own emoji (which would be unworkable).

Oh, and one of the emojis in your proposal is for the US flag, not the US.

It all seems kind of pointless to me.  I await your rationale...

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] addresses on buildings

2020-01-06 Thread Volker Schmidt
> This depends on the country.
> > It is "forbidden" to put the address on the building in Denmark,
>
A similar rule exist in Italy: the number has to be put where the actual
entrance is, as the number identifies an entrance and not a building.
Thai also helps navigation devices to get you to the actual entrance and
not only near the building.
But this is Italy-specific.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Tagging for emojis names

2020-01-06 Thread ferdi98701
I have made this drafthttps://wiki.openstreetmap.org/wiki/Proposed_features/Emoji_names for this Topic and I would like feedback and improvementBest regards Ferdinand0101

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

2020-01-06 Thread Tomek
EO
W dniu 20-01-06 o 09:59, Michael Patrick pisze:
> There is a 'reason'. Toponyms at all levels are established
> by naming authorities and conventions at from the village
> to the international level, for all sorts of domains. The
> key point is, the locality decides, not outsiders - there
> is no rationalization for you to give any name preference
> until you have consulted with them and documented that
> cooperation. Otherwise you are just using OSM as a
> platform for your own flavor of 'techno-imperialism'.
Vi rajtas, ke toponimoj (nomoj de lokoj) estas nomataj de lokuloj, ne de
eksteruloj. Problemo estas, ke tiu ĉi diskuto rilatas al nomoj de
INTERNACIAJ OBJEKTOJ, do kiu laŭ vi havas rajton por nomi marojn de ekz.
Suda Oceano?

W dniu 20-01-06 o 09:59, Michael Patrick pisze:
> There aren't any 'neutral' natural languages. They
> have many roots, continually incorporate words
> from other languages, and some die off.
JES, do ni uzu planitan lingvon! Mi proponas Esperanton (pro ĝia
populareco) aŭ Interlingvaon (pro ĝi estas komprenata sen lerni por
uzantoj de latindiaj lingvoj).

W dniu 20-01-06 o 13:45, Mario Frasca pisze:
>
> Hi Tomek, and everybody.
>
> being this an English list, I'll write in English, I'm tempted to use
> Spanish, or Italian.  my written Latin is poor.
>
Mi pensis ke tio ĉi estas internacia listo…

W dniu 20-01-06 o 13:45, Mario Frasca pisze:
> I disagree that the tag 'name' should be removed
> I'm aware of one place in the world where they have three national
> languages: Morocco, and what happens there is that the map uses the
> three national languages for all names, and the map looks so clumsy
> this way, in particular with the Amazigh name included (I have tested
> some locals on their knowledge of the written language, and I am
> fairly sure that 95% of Amazigh people can't even read it).  quite
> regularly, you see people editing the 'name' tag to make it less
> clumsy, by removing two of the languages (those they don't like, I guess).
Kial mi eblas fari la samon por maroj? “Baltijas jūra / Baltijos jūra /
Itämeri / Läänemeri / Morze Bałtyckie / Östersjön / Østersøen / Ostsee /
Балтийское море” - neniu estos diskriminaciita.

W dniu 20-01-06 o 15:12, Martin Constantino–Bodin pisze:
> The reason why I believe the “name” tag should not be placed in such
> place is semantic: there is no best local name, so let’s not put any.
> This then enables any renderrer to default to a language of their
> choice (or to check for other, possibly more adequate tags, like
> “name:UN:*”). If you put a “name” tag here, I can’t do that. I’ve been
> suggesting to create a renderrer that just uses “name:eo” if present…
> just to be told right away that this is not a good solution as it
> would basically chooses the Esperanto name for everything instead of
> just these places where there is no default language. I think that
> having an empty “name” tag or not having a “name” tag would be a nice
> indication that there is not best “name” tag, and leave each renderrer
> use their heuristics (or just display no name).
Ekzakte, ĉu en 56°N18°E flosas buo kun teksto ”Baltic Sea“? Ne, tie
estas nur akvo, kiu estas nomata fare de poloj kiel “Morze Bałtyckie”,
fare de germanoj kiel ”Ostsee“, ktp.

W dniu 20-01-06 o 15:45, Joseph Eisenberg pisze:
> (Note that Openstreetmap-carto does not render the names of oceans,
> continents and seas, but does render the names of some large bays and
> straits and islands which are relevant to this discussion)
Nur rilatoj kun etikedoj ekz. natural=bay aŭ water=sea estas bildigataj
sur la mapo.

W dniu 20-01-06 o 16:35, Martin Koppenhoefer pisze:
> Not sure this has to be discussed, in OpenStreetMap we’re trying to represent 
> the current state of things
La nuna situacio en la reala mondo estas ke la menciitaj objektoj ne
havas iun ajn nomon “sur la tero”.

W dniu 20-01-06 o 16:35, Martin Koppenhoefer pisze:
> Esperanto, which you personally seem to prefer, and which is around for 133 
> years, is only understood by, with most favorable estimates, 2 Million people 
> (compared to billions for English) and while remaining susceptible for 
> criticism of eurocentrism similar to English and not being  “neutral” in any 
> way, it is completely artificial so that the “names” in Esperanto are used by 
> nobody. Choosing Esperanto would be a loose-loose situation, from my point of 
> view.
Kiom da tempo necesas por lerni Esperanton kaj kiom da tempo necesas por
lerni la anglan? Se vi volas nomojn komprenataj de kiel eble plej multa
da homoj, mi proponas Interlingvaon.



PL
W dniu 20-01-06 o 09:59, Michael Patrick pisze:
>
> There is a 'reason'. Toponyms at all levels are established
> by naming authorities and conventions at from the village
> to the international level, for all sorts of domains. The
> key point is, the locality decides, not outsiders - there
> is no rationalization for you to give any name preference
> until you have consulted with them and documented that
> 

Re: [Tagging] amenity=tourist_bus_parking

2020-01-06 Thread Martin Koppenhoefer
Am Mo., 6. Jan. 2020 um 03:25 Uhr schrieb John Willis via Tagging <
tagging@openstreetmap.org>:

>
>
> On Jan 6, 2020, at 1:27 AM, Florimond Berthoux <
> florimond.berth...@gmail.com> wrote:
>
> I have just detected the wiki page "amenity=tourist_bus_parking"
>
>
> Why is this it’s own amenity, instead of
>
> amenity=parking
> bus=designated
> access=customers
>


"bus" is about a bus acting as public service vehicle. *=designated does
not exclude other means of transport:
https://wiki.openstreetmap.org/wiki/Tag:access%3Ddesignated
"The value designated is not meant to imply that OpenStreetMap access
=* permissions have been
automatically "designated" *only* to that transport mode! If an element is
meant *only* to be used by specific designated transport methods
(overriding whatever defaults may exist for that way), use access
=no
 in addition of the *
=designated value."

For a municipal tourist bus parking, who is "customers" referring to?
Customers of what?

Cheers
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [Talk-us] Trunk VS primary,

2020-01-06 Thread Martin Koppenhoefer
Am Mo., 6. Jan. 2020 um 06:45 Uhr schrieb Julien djakk <
djakk.geograp...@gmail.com>:

> I would vote for an importance tag, values from 1 to 6 : for some roads or
> path we could reach a cool level of details : example :
>  car:importance:commute=1, bike:importance:long-distance=3
>
> We can merge : importance=6 is for cars, bikes ... and commuting and
> long-distance (usually it is for a dead-end),
>
> Importance=5 could still be called highway=unclassified.
>


It's not the first time this is proposed ;-)
It will save you some time not to pursue the idea, rather look for former
discussion about it.

Cheers
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] addresses on buildings

2020-01-06 Thread Markus
On Sun, 5 Jan 2020 at 19:39, Marc Gemis  wrote:
>
> This depends on the country.
> It is "forbidden" to put the address on the building in Denmark,

Says who? And why?

I agree with Martin and others: if every building has an own number,
it makes the most sense to tag it on the building=* way (also because
of inheritance to objects within), if entrances have their own
numbers, tag it on the entrance=* node.

Regards

Markus

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] depreciate recycling:metal in favor of recycling:scrap_metal

2020-01-06 Thread Martin Koppenhoefer


sent from a phone

> On 6. Jan 2020, at 04:52, Paul Johnson  wrote:
> 
> As opposed to scrap metal, which is pretty much everything from car hulks to 
> household appliances to copper wiring and plumbing, etc...


household appliances are not (only) scrap metal but contain typically a fair 
amount of other substances that require special taking care of.


Cheers Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

2020-01-06 Thread Martin Koppenhoefer


sent from a phone

> On 6. Jan 2020, at 07:29, Maarten Deen  wrote:
> 
>> Baltic Sea to be the "Baltic Sea" or for South America to be "South
>> America" - this is an example of English imperialism.
> 
> This "imperialism" idea of yours is just your idea. It is not something that 
> is widely felt.



regarding imperialism, I think it’s hard to reject the reasoning that English 
is in widespread use because of imperialism. We’re all used to it (at least in 
the western world) and internet and the tech economy have further diffused its 
use, so currently it is the defacto standard for most international contexts 
(in other regions and for some specific context it may be Russian or Chinese, 
Spanish, French etc. all mostly because of imperialism). 

Not sure this has to be discussed, in OpenStreetMap we’re trying to represent 
the current state of things, rather than trying to campaign for a state we 
would prefer (with the exception of Crimea, which is this, an exception, simply 
because last year the majority of the 5 people that made up the board wasn’t 
interested in seeing a bigger picture or striving for consistency). English is 
(shortly before Chinese) the language which most people in the world are able 
to understand, so there is good reason for using it in international context as 
a fallback. As OpenStreetMap is not popular in China (AFAIK it’s even forbidden 
to use it), the logical alternative IMHO isn’t relevant for our context. 
Esperanto, which you personally seem to prefer, and which is around for 133 
years, is only understood by, with most favorable estimates, 2 Million people 
(compared to billions for English) and while remaining susceptible for 
criticism of eurocentrism similar to English and not being  “neutral” in any 
way, it is completely artificial so that the “names” in Esperanto are used by 
nobody. Choosing Esperanto would be a loose-loose situation, from my point of 
view.

Cheers Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

2020-01-06 Thread Steve Doerr

On 05/01/2020 22:25, Tomek wrote:
I plan to remove the "name" and "wikipedia" tags from places that are 
not associated with a specific nation or language


Please don't do that. It would be vandalism and disrespectful of 
previous mappers.



Please support (vote) my proposal or write a reason why not.



How do I go about opposing your proposal?

--
Steve

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

2020-01-06 Thread Paul Allen
On Mon, 6 Jan 2020 at 06:29, Maarten Deen  wrote:

>
> I vote against it, if not only because your stance on this is flawed,
> but also because this might remove correct and valuable information.
>

+1

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] leisure=firepit vs fireplace=Yes

2020-01-06 Thread Jake Edmonds via Tagging
> Note that it may mean that wiki is incomplete and should be edited.
Understood, but I wanted to get some other opinions before making any changes


> On 6 Jan 2020, at 12:18, Mateusz Konieczny  wrote:
> 
> 
> 
> 
> 4 Jan 2020, 18:30 by tagging@openstreetmap.org:
> The pages for leisure=picnic_table and amenity=shelter do not mention 
> fireplace=*.
> Note that it may mean that wiki is incomplete and should be edited.
> 
> Wiki is an useful documentation but not some sort of a final authority.
> I don’t think it makes sense to use fireplace=yes as an additional tag and 
> they should be mapped separately as leisure=firepit. If I understand 
> correctly, additional tags should be used to describe the object itself, but 
> fire pits and tables/shelters can be used independently. If I’m planning a 
> trip and I want to make a fire, I am going to search for fire pits.
> 
> Is there something I haven’t considered? 
> Apparently at least some people considered situation as "this is a shelter 
> with/with nearby firepit"
> 
> See also toilets=yes vs separately mapped toilet for restaurants, fuel 
> stations etc.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] depreciate recycling:metal in favor of recycling:scrap_metal

2020-01-06 Thread Mateusz Konieczny
6 Jan 2020, 12:37 by jerome.seigneu...@gmail.com:

> > recycling:metal_packaging ?
> If we go to that you use also carton_packaging, glass_packaging,  
> metal_packaging, wood_packaging, paper_packaging, plastic_packaging 
>
There are
recycling:paper_packaging
recycling:plastic_packaging
with some noticeable usage
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] depreciate recycling:metal in favor of recycling:scrap_metal

2020-01-06 Thread Jérôme Seigneuret
I work in recycling society and there is 2 differents flux

domestic packaging "metal, plastic, carton, paper, glass" and other
(scrap_metal, concrate, green, produit chimique, oil,...).

this is 2 differents waste collection types and sites collection are
differents.

metal is for me a material. scrap_metal is for an object we need transform
to give them a second life.

recycling:metal_packaging ?
If we go to that you use also carton_packaging, glass_packaging,
metal_packaging, wood_packaging, paper_packaging, plastic_packaging



Le lun. 6 janv. 2020 à 10:47, Mateusz Konieczny  a
écrit :

> recycling:metal_packaging ?
>
> There is some use - 31 uses
> Far less ambiguous.
>
> 6 Jan 2020, 04:48 by ba...@ursamundi.org:
>
>
>
> On Tue, Dec 31, 2019 at 10:50 AM Mateusz Konieczny <
> matkoni...@tutanota.com> wrote:
>
> There is no useful difference
> therefore it is pointless to have two
> separate tags for that.
>
>
> Domestic refuse metals like metal packaging from consumer products (think
> like, food and beverage cans), something that you can typically drop off at
> your average grocery store parking lot recycling center.  As opposed to
> scrap metal, which is pretty much everything from car hulks to household
> appliances to copper wiring and plumbing, etc...
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Cordialement,
Jérôme Seigneuret
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] leisure=firepit vs fireplace=Yes

2020-01-06 Thread Mateusz Konieczny



4 Jan 2020, 18:30 by tagging@openstreetmap.org:

> The pages for leisure=picnic_table and amenity=shelter do not mention 
> fireplace=*.
>
Note that it may mean that wiki is incomplete and should be edited.

Wiki is an useful documentation but not some sort of a final authority.

> I don’t think it makes sense to use fireplace=yes as an additional tag and 
> they should be mapped separately as leisure=firepit. If I understand 
> correctly, additional tags should be used to describe the object itself, but 
> fire pits and tables/shelters can be used independently. If I’m planning a 
> trip and I want to make a fire, I am going to search for fire pits.
>
> Is there something I haven’t considered? 
>
Apparently at least some people considered situation as "this is a shelter 
with/with nearby firepit"

See also toilets=yes vs separately mapped toilet for restaurants, fuel stations 
etc.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Fwd: amenity=vending_machine/vending=bottle_return - operator=

2020-01-06 Thread Jake Edmonds via Tagging
On third thought, breweries isn’t appropriate because not all reverse vending 
machine is for beer bottles, or even bottles at all. 

If something like brands_accepted existed, that would be fine. I’d rather not 
create something new. 


amenity=reverse_vending_machine
reverse_vending=bottle_return
 
Machines may take more than one type of item. Some here take bottles and bottle 
creates. Some take metal cans. 

Reverse vending machines are not the only vending machine type that’s not 
technically a vending machine, although you are exchanging one thing for 
another. 

I propose
amenity=vending_machine
vending=reverse_vending (or keep bottle_return as its already in use)
recycling:glass_bottles=yes/no (already is use)
recycling:=yes/no
Plus another optional tag to dictate which brands the machine takes
Sent from Jake Edmonds' iPhone

Begin forwarded message:

> From: Jake Edmonds via Tagging 
> Date: 6 January 2020 at 07:36:52 CET
> To: "Tag discussion, strategy and related tools" 
> Cc: Jake Edmonds 
> Subject: Re:  [Tagging] amenity=vending_machine/vending=bottle_return - 
> operator=
> Reply-To: "Tag discussion, strategy and related tools" 
> 
> 
> Regardless of whether the main tag should be changed or not, on second 
> thought, I think the following tags should be used:
> 
> brand= To indicate how the service is branded, for example, a 
> recycling/bottle return company or the name of the super market where the 
> machine is located
>   
> https://commons.wikimedia.org/wiki/File:Reverse_Vending_Machine_-_Fresh_Plus_-_Pod_šiancom_-_Kosice.jpg
>  
>   Located inside and branded as Fresh (a supermarket), the 
> receipt can only be exchanged in Fresh.
>   
> https://commons.wikimedia.org/wiki/File:Reverse_vending_machine_for_the_NSW_Container_Deposit_Scheme_at_the_Kooringal_Mall_2.jpg
>  
>   Located outside and branded as Return and Earn (a government 
> scheme), retail vouchers, PayPal an e-vouchers are available.
> operator= To indicate who maintains/services the machine, possibly the same 
> as the brand, maybe hard to find out.
> breweries= To indicate the brands of containers that the machine accepts 
> 
>> On 5 Jan 2020, at 21:43, Colin Smale  wrote:
>> 
>>> On 2020-01-05 21:02, Martin Koppenhoefer wrote:
>>> 
>>> 
>>> sent from a phone
>>> 
 On 5. Jan 2020, at 16:46, Colin Smale  wrote:
 
 The term vending machine is misrepresenting these machines and should not 
 be used.
 
 They are frequently called "reverse vending" machines - instead of the 
 customer trading money for goods, they trade goods for money.
 https://en.wikipedia.org/wiki/Reverse_vending_machine
>>> 
>>>  
>>> clearly „reverse vending machine" is a completely different term/concept 
>>> than „vending machine", although it plays with the idea of using the same 
>>> words and change the meaning by adding „reverse" to it
>>>  
>> It is also a clearly related concept. I hereby propose:
>>   amenity=reverse_vending_machine
>>reverse_vending=bottle_return
>> Problem solved.
>>  
>>  
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] depreciate recycling:metal in favor of recycling:scrap_metal

2020-01-06 Thread Mateusz Konieczny
recycling:metal_packaging ?
There is some use - 31 uses
Far less ambiguous.
6 Jan 2020, 04:48 by ba...@ursamundi.org:

>
>
> On Tue, Dec 31, 2019 at 10:50 AM Mateusz Konieczny <> 
> matkoni...@tutanota.com> > wrote:
>
>> There is no useful difference 
>> therefore it is pointless to have two
>> separate tags for that.
>>
>
> Domestic refuse metals like metal packaging from consumer products (think 
> like, food and beverage cans), something that you can typically drop off at 
> your average grocery store parking lot recycling center.  As opposed to scrap 
> metal, which is pretty much everything from car hulks to household appliances 
> to copper wiring and plumbing, etc...
>___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] depreciate recycling:metal in favor of recycling:scrap_metal

2020-01-06 Thread marc marc
Le 06.01.20 à 04:48, Paul Johnson a écrit :
> Domestic refuse metals like metal packaging from consumer products
> (think like, food and beverage cans), something that you can typically
> drop off at your average grocery store parking lot recycling center.  As
> opposed to scrap metal, which is pretty much everything from car hulks
> to household appliances to copper wiring and plumbing, etc...

how is this usage currently tagged ?
if it's with recycling:metal and if it's common, then we have to change
the wiki documentation to describe the actual usage (currently the wiki
informs that recycling:metal is about scrap metal).
but given the ambiguity of recycling:metal, I think it's better to
depreciate it in favor of a few precise values (scrap_metal, domestic
packaging, etc.).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

2020-01-06 Thread Michael Patrick
> There is no reason for the Baltic Sea to be the "Baltic Sea"
or for South America to be "South America" - this is an example
of English imperialism.

Mostly British Imperialism, almost every town in the U.S. has
a namesake in the UK - if you look at nautical charts, Spanish
dominates. History has happened. But I digress.

There is a 'reason'. Toponyms at all levels are established
by naming authorities and conventions at from the village
to the international level, for all sorts of domains. The
key point is, the locality decides, not outsiders - there
is no rationalization for you to give any name preference
until you have consulted with them and documented that
cooperation. Otherwise you are just using OSM as a
platform for your own flavor of 'techno-imperialism'.

Fluent bilingual persons are 43% of world population,
and trilingual are13% of world population - and many,
many more have a minimal ability, less than fluent. You
should do some serious study of the geography of
languages. Notably, administrative boundaries have
almost no relation to language prevalence areas.

Also, you seem to have a deep fundamental misconception
about what a 'tag' really is. OSM is a *software* system. While
a tag and it's values superficially resembles a piece of
natural language, and can appear as a label, that is a
coincidence. In the software system they are no different
than commands in a computer language - 'forest' causes
green shade in an area. The effect of your suggestion is
essentially the same as having a unique Polish version
of Python and expecting every other developer to 'look it
up and translate' when encountering your code:

dla xw zakresie(0, 3):
wydrukować("Jesteśmy na czas",xw ))
Without at least one common lexicon to crosswalk from,
whether it's English or Chinese, the whole thing breaks.

> Any data will not be lost - programs will be able to extract the
desired name from the tags name:en, name:pl, etc., Wikipedia
links will be available via Wikidata.

Data is lost. You are making a huge assumption that
all transformations are equivalent and reversible. With
toponyms, they are absolutely not. Before you under
take this project read https://tinyurl.com/yhdph2cn and,
( why not? ) the Toponymy Training Manual From the
United Nations Group of Experts on Geographical
Names, Department of Economic and Social Affairs.
https://tinyurl.com/yjhpgsqa  If you don't read these, I
assume the proposal is just 'theater'.

Your Wikidata suggestion is fails on the basis of
synchronization. What mechanism alerts an
OSM consumer that a Wikidata entry has changed?

There aren't any 'neutral' natural languages. They
have many roots, continually incorporate words
from other languages, and some die off.

Michael Patrick
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] addresses on buildings

2020-01-06 Thread Shawn K. Quinn
On 1/6/20 01:47, Florian Lohoff wrote:
> Then there are buildings which is a single building with no seperation
> inbetween but multiple entrances with individual housenumbers. I
> use nodes on those.

I had a weird case locally (within walking distance of me) where one
business in a building had an address on a different street than the
other three. I could have maybe split the building outline but decided
to just use nodes instead.

-- 
Shawn K. Quinn 
http://www.rantroulette.com
http://www.skqrecordquest.com

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging