[Tagging] Default access for service=driveway?

2020-12-22 Thread Frederik Ramm
Hi,

A property owner in Germany has complained that several routing engines
- crucially also the one used by the local transport authority - route
pedestrians trough their private residential property as a "shortcut"
for accessing a bus stop.

The private residential property has two driveways (highway=service,
service=driveway) entering it from different sides, thereby enabling
people to save a few metres by walking through, rather than around, the
property.

These driveways do not have an access=private (or access=destination)
tag or anything like that.

Questions:

1. Should a routing engine automatically assume that something tagged a
"driveway" is not suitable for through traffic?

2. If you map such driveways, would you add access=private (or
access=destination) in OSM...

2a. ... even if there is no specific signage locally?
2b. ... if there is a sign that says "access to houses X,Y,Z" without
saying that other access is forbidden?
2c. ... if there is a sign that says "private driveway"?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Fuzzy areas again: should we have them or not?

2020-12-21 Thread Frederik Ramm
Hi,

On 21.12.20 10:20, Anders Torger wrote:
> In the mountains we have an number of named plateaus. There is a tag
> proposal for natural=plateau, but just like with natural=peninsula and
> similar tags there is an underlying question that we really need an
> answer to first: should we have fuzzy areas or should we not?

I think I have laid out my point in
https://lists.openstreetmap.org/pipermail/tagging/2020-December/056823.html

Our current data model is not suitable for mapping fuzzy areas. We can
only do "precise". Also, as you correctly pointed out, or basic tenet of
verifiability doesn't work well with fuzzy data.

So the one questions is, do we want fuzzy areas, the other is, if we
want them, how can they be established - because in our current database
they cannot.

I think fuzzy areas make a lot of sense for cartography, but I strongly
object to people adding hand-wavy polygons to OSM for fuzzy areas.

> We know there are disadvantages and no solution is 100%
> perfect, but sometimes there's a higher goal to fulfill.

Having a nice lettering across the Alps is certainly not a "higher goal"
for OSM as a whole; forcing fuzzy polygons for that into OSM is
irrelevant for most and outright damaging for some use cases, and the
advantage it would have for the one single use case of map rendering
does not justify it.

Please stop trying to frame this as "cartographers have a right to abuse
the data model, and if someone doesn't want that, they need to present a
viable alternative". We've come very far in OSM without such abuse and I
don't see why it should suddenly be introduced.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-14 Thread Frederik Ramm
Hi,

On 14.12.20 12:20, Anders Torger wrote:
> My sense is that OSM community do want naming in nature as well, but
> only if it can be made very simple. Unfortunately that is not always
> compatible with reality, and here we are...

Personally I think naming is desirable for clear features. This mountain
peak, this protected tree, this lake.

What I don't like in OSM is naming for large geographic areas, like "the
Alps", "the Black Forest", or "the Bay of Biscay", for two reasons:

First, there can be any number of such areas. Anyone can invent
something. I can speak of the Alps, or the French Alps, or the Northern
French Alps, or the Vanoise Massif, I can group some regions at will and
make up a new name. These are not administrative boundaries where it is
clear which of them exist "as a region" and and which don't. Of course
everyone knows what I mean when I say "Germany north of Oldenburg" but
that doesn't mean that "Germany north of Oldenburg" is a name that
should be on the map, or a polygon we need in OSM. If I issue a tourist
guide for, say, "Vanoise et Maurienna", does that then make "Vanoise et
Maurienna" a region? How many people need to issue a tourist guide for
this to happen?

Second, these areas are usually ill-defined: There are some places that
are clearly in the Black Forest, and some that are clearly not in the
Black Forest, but there's not one boundary line - there's fuzziness. OSM
is not good with fuzziness; OSM forces us to have an exact point or line
or polygon for something. For fuzzy labels, you need a different system
that should exist outside of OSM's current data types. Either by adding
a new fuzzy data type to OSM (no need to assemble 1000 ways with a total
of 20,000 points to exactly describe the outline of the Alps if all you
want is a nice big lettering in approximately the right spot), or by
keeping these cartography options in a separate system altogether.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] coastline v. water

2020-11-23 Thread Frederik Ramm
Hi,

I would like to make one point that has been touched on but not said
clearly, I think.

Some proponents of the recent changes to Chesapeake bay have used
reasoning like: "Only by mapping the bay as a polygon can $SOFTWARE
properly determine that a given location is in the bay, as opposed to in
some undfined part of the sea."

To this, Jochen has even replied along the lines of "create a polygon if
you want but additionally use the natural=coastline tag".

I want to issue a stern warning here: This line of thinking will not
stop with Chesapeake bay. People are already creating giant
multipolygons for the Strait of X and the Gulf of Y all over OSM. Before
too long, a desire to have $SOFTWARE properly decide that a given
location is, say, in the Atlantic Ocean, will give rise to demands that
the Atlantic Ocean be mapped as a giant, named water polygon.

Our current tooling makes this impractical (that's the very reason why
we handle the coastline like we do). Even the 2000+ member "gulfs" and
"bays" and "straits" that some people seem to derive endless pleasure
from plastering the map with - often using questionable third-party
sources or guesswork to define where exactly you leave the ocean and
enter the gulf - already complicate the delicate community processes of
editing and quality assurance. Splitting a single piece of coastline
anywhere along Chesapeake bay now will, for example, give your changeset
a bounding box that encompasses the whole bay. Anyone monitoring local
edits gets swamped with false positives like that. It will also require
uploading a complete new version of the giant bay polygon, vastly
increasing the likelihood of edit conflicts that might well lead a
hapless novice to abandoning their work, rather than trying to solve the
conflict.

Now, you might smirk and say "let's fix the tools then", but until the
tools are fixed - which might take years -, you've made life a hell of a
lot harder for anyone editing or quality monitoring in the whole area.

And all for what - a nice blue label in the bay?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] coastline v. water

2020-11-23 Thread Frederik Ramm
Hi,

On 23.11.20 15:10, David Groom wrote:
> Using this logic the Mediterranean Sea, the Red Sea, and the Persian
> Gulf should all have the coastline tags removed from their defining ways
> and converted to water areas!   Italy, Greece, Libya, Egypt and a large
> group of other counties would find they had no coastline, which might
> come as a surprise to anyone lining there.

I'll probably have to inform the tourism guys in Annapolis too and tell
them to stop calling themselves a "coastal place"
https://patch.com/maryland/annapolis/annapolis-among-20-best-coastal-places-live-magazine
;) sorry folks, you're on an inland waterway. Bit like Richmond really!

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Basic cartography features missing, why?

2020-11-07 Thread Frederik Ramm
Hi,

On 11/6/20 19:31, Anders Torger wrote:
> ** Tagging bays and straits as areas work great, as the renderer gets
> and idea how prominent it is and it can make proper text sizing and they
> can be seen even if zoomed out if the area is large. Lots of our lakes,
> even quite small ones have sub-naming, and with these features I can
> make really good mapping of this.

This is an absolute pain for me. We're seeing people define
ultra-precise multipolygons of various sizes with the single purpose of
getting a name rendered somewhere in a bay.

If this infects other areas of cartography, we'll see people build
thousand-node polygons for vaguely defined land areas ("the XY
lowlands", "the XY mountain range", "the XY plateau"). This is a very
sad development that makes editing more complicated and burdens the
database with information of very little value.

What people want to achieve is some lettering on the map, and because
the only way to get that is making huge polygons that purport do
describe the exact extent of something, that's what they do.

I think this needs to be stopped. We've created a
mapping-for-the-renderer mechanism by the back door. This is actually
*worse* than if we were to allow people to place a point somewhere and
annotate it with a desired label font size and orientation. Not that I
would advocate the latter, but what we have now has all the negative
features of the latter *plus* the side effect of creating giant,
unmaintainable polygons.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Update - RFC - Special Economic Zones

2020-11-03 Thread Frederik Ramm
Hi,

my opinion is that stuff that is not visible on the ground and not
meaningfully editable by mappers needs a very strong reason to be mapped
at all.

1. Are SEZ boundaries visible on the ground (signage, physical separation)?

2. If not, do SEZ boundaries usually coincide with existing
administrative boundaries (counties X and Y as well as the city of Z
together form the SEZ)?

3. If not, how would you get your hands on the SEZ boundary?

4. In how far is it useful for mappers to modify the SEZ boundary based
on their knowledge or aerial imagery?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Proposal to change key:man_made to key:human_made

2020-10-18 Thread Frederik Ramm
Hi,

On 10/18/20 23:08, Mateusz Konieczny via Tagging wrote:
> And the same applies to brains of people

It appears to me that the end game in this is precisely that, to change
the brains of people. OSM is just a means to and end in that quest.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Feature Proposal - RFC - (shop=direct marketing)

2020-10-02 Thread Frederik Ramm
Hi,

On 10/2/20 19:56, Wieland Kestler wrote:
> I agree absolutely that somone who makes bread by itself and sells that
> in front of its house, we should tag it by shop=bakery. So the grade of
> „selfmadeness“ does not matter.

We are not a business directory but a geo database. We map what exists,
and not (or at least not primarily) what services might be offered. If
there is a residential house and every now and then the owner puts out a
table in front and sells bread, then I would say we shouldn't map that
at all. (Map the house, yes, but not map the fact that a resident bakes
bread occasionally.) In order to be mapped in OSM, it needs to have a
physical manifestation - at the very least, a sign, or more desirably
some structure that can be recognised as a shop even while not in use.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Benches and hostile architecture

2020-08-24 Thread Frederik Ramm
Hi,

On 24.08.20 02:46, Paul Allen wrote:
> I'm not seriously suggesting we map them this way but speed bumps are
> technically hostile architecture. :)

As are cattle grids if you're a cow!

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


[Tagging] what is the "temp" tag?

2020-08-05 Thread Frederik Ramm
Hi,

https://taginfo.openstreetmap.org/keys/temp#values

any guesses as to what this might mean?

I stumbled across it when reverting some vandalism on
https://www.openstreetmap.org/way/784166844 but that street has been
split so many times by people adding turn restrictions that the "person
creating v1 of something" is just the person who split something and if
I asked them what they meant by temp=tag they'll probably just shrug.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Rio de la Plata edit war

2020-08-04 Thread Frederik Ramm
Hi,

On 8/4/20 18:28, Kevin Kenny wrote:
> In actual practice, in the estuaries of rivers, the 'coastline' is very
> seldom tagged that far upstream.

From my Chesapeake Bay example, in OSM, Havre de Grace (290km inland) is
a "coastal"city

https://www.openstreetmap.org/?mlat=39.5443=-76.0961#map=10/39.5443/-76.0961

though Baltimore (260km inland) is not, due to Patapsco River having its
own polygon:

https://www.openstreetmap.org/?mlat=39.2461=-76.6523#map=10/39.2461/-76.6523

Of course my "xxx km inland" depends on where you define the bay to
begin, I used the US13 crossing at Norfolk.

Not saying that is the measuring stick, and perhaps as a result of this
discussion it needs to be tagged differently, or maybe the physical
geography is different there.

Or maybe we conclude that physical geography doesn't count and what
counts is whether it "feels like" a coastal city ;)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Have our tagging voting rules changed recently?

2020-08-04 Thread Frederik Ramm
Hi,

On 04.08.20 10:06, Andy Mabbett wrote:
>> Have our tagging voting rules changed recently?

> Which rules?

Should I have written "was our voting process changed recently", or what
exactly are you asking? I meant the established way of proposing and
voting for tags as outlined in
https://wiki.openstreetmap.org/wiki/Proposal_process.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


[Tagging] Have our tagging voting rules changed recently?

2020-08-04 Thread Frederik Ramm
Hi,

looking at the "bare_soil" proposal I was surprised to read:

"Any opposition vote without reason or suggestion will not be counted in
the voting process."

Is that something that we have added by consensus?

It sounds like a somewhat sneaky measure to ignore opposition votes, or
discourage those who cannot properly express their opposition in English
from voting in the first place. It also raises the question of what
requirements there are for a "reason or suggestion". If I vote no with a
reason "it stinks", will there then be someone who says "ah, this is not
a valid reason" and strips me of my vote? Who will that person be?

Has this been used in other votes in the past? I'm tempted to say it
would invalidate any vote but maybe it *is* indeed based on consensus
and I missed that.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Rio de la Plata edit war

2020-08-04 Thread Frederik Ramm
Hi,

On 03.08.20 22:41, Joseph Eisenberg wrote:
> I have previously proposed that estuaries should be mapped by extending
> the coastline upstream to the limit of the estuary, and also mapping the
> area of the estuary as water with water=estuary

I wonder if we're not becoming too theoretical by thinking about
scientific definitions. I know that we strive to have something
"verifiable" but at the same time I have a bad feeling about there being
a "coastline" in OSM where there is definitely no "coast" within dozens
of kilometers.

Sure, I can say "don't be too literal, natural=coastline doesn't mean
there has to be a coast, it's just for closing ocean polygons" but that
doesn't make it better really.

Sure, with current ocean drawing technology we need a "coastline" across
every river estuary at some point... but perhaps we should think beyond
that?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Rio de la Plata edit war

2020-07-31 Thread Frederik Ramm
Hi,

I don't know the region myself so I am limited to anecdotal evidence as
found on the web:

* Montevideo clearly brands itself as having "a coast" (from
welcomeuruguay.com: "Costa de Oro" (Gold Coast) is the name given to the
great variety of beaches stretching from La Barra de Carrasco, in
Montevideo, to Solís Grande Creek, ...)

* next city east is called "Ciudad de la Costa"

* Buenos Aires, on the other hand, seems to be mainly referred to as
being "on the SHORE of Rio de la Plata"

* Wikipedia entry on Montevideo calls Rio de la Plata an "arm of the
Atlantic ocean"

It is obvious that, regarding the official definition, both countries
have a shared interest of defining the coast as far out on the sea as
legally possible. Therefore, I am not sure if our usual approach of
"letting the locals decide" will work here. Our other usual approach is
that of "truth on the ground" and the 200km+ straight line from Punte
del Este to Cabo San Antonio certainly stretches *anybody's* definiotion
of a coastline!

The largest estuary in the United States, Chesapeake Bay, is almost
completely mapped as coastline, only changing to a natural=river polygon
very far inland - though I haven't researched currents or salinity.

Are there other examples of large bays/estuaries?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Should admin_level=1 tag be applied to EU?

2020-07-30 Thread Frederik Ramm
Hi,

On 30.07.20 13:32, Colin Smale wrote:
> The EU is «composed-of» whole member states. It has all the attributes
> of a governmental administrative body - with the executive, parliament
> and justicial branches impacting citizens directly.

To me as a citizen of a EU country it does not feel like the EU is a
higher-level administrative body than the country. Yes, countries have
decided to contractually transfer some rights and responsibilities to
the EU but that doesn't (in my mind) mean the EU is some form of
super-state. Quitting the EU if you don't like it is much easier than
seceding from a country.

I would prefer to map the EU as a contract than as an administrative
boundary. There are many such contracts around the world, where smaller
countries pool their defense or other typically national capabilities,
and I would not be surprised if there were situations where countries
pool their defense with one group, and their currency with another.
Mapping these things as "areas on the map" is old-style cartographic
thinking. We can do better than that.

Even *if* a boundary was mapped, it would probably more pragmatic to map
the outer boundary of the Schengen region than the outer boundary of the
EU states.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Should admin_level=1 tag be applied to EU?

2020-07-30 Thread Frederik Ramm
Hi,

On 30.07.20 11:19, Mateusz Konieczny via Tagging wrote:
> Unlike such objects EU has (AFAIK) well defined border, matching
> existing administrative boundaries, so problems inherent in
> mapping fuzzy objects are not present.

I'm not an expert on international treaties but I believe that if France
bought Alaska from the US tomorrow, then Alaska would become part of the
EU, without the EU having much of a say in it, isn't that so?

This is of course a very hypothetical example but little swaps of
un-inhabited land happen between neighbouring countries from time to
time. The "EU boundary" is the sum of whatever national boundaries its
member states have. Same with the "Schengen area" which is guarded by
Frontex which you linked to; it's a construct that is the result of a
contract but not an administrative area.

> I am not opposing it and it seems defensible.

Anything is, on this mailing list ;)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Should admin_level=1 tag be applied to EU?

2020-07-30 Thread Frederik Ramm
Hi,

in my view, the EU is not an administrative body with a border and many
parts (countries), but instead the countries have made a contract to
form the EU.

I would therefore object to mapping the EU as an entity with a boundary;
instead, if it were mapped, I would expect it to be a relation of
yet-to-be-defined type and having the individual member states as
relation members.

I know there's a tendency among some mappers to try and map
multipolygons or administrative boundaries for anything that has a name,
but that practice is not helpful. I don't even dare to look but I
wouldn't be surprised if some helpful soul has meanwhile decided to map
"the Atlantic", "the Pacific", or "Eurasia", assembling thousands of
little coastline pieces into giant relations in painstaking, week-long
work... sigh.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Automated edit of image tags suggestion

2020-06-25 Thread Frederik Ramm
Hi pangoSE,

On 6/25/20 19:57, pangoSE wrote:
> I recently started discussing the problems related to urls and
> File:filename.* that links to wikimedia_commons using the tag. See
> Talk:Key:image#Discourage_linking_to_commons_files_and_migrate_all_File:filename..2A_values_and_direct_urls_to_wikimedia_commons
> and tagging.

I'm afraid I do not follow.

> Algorithm 1Edit image=File:* -> wikimedia_commons=File:*
> image=Category:* -> wikimedia_commons=Category:*
> image=https://commons.wikimedia.org/wiki/File:* ->
> wikimedia_commons=File:*
> image=https://commons.wikimedia.org/wiki/Category:* ->
> wikimedia_commons=Category:*

I don't understand why this is necessary. Would you, before changing an
"image=File:x" into "wikimedia_commons=File:x", even check whether the
file exists there?

There are currently 28k objects with wikimedia_commons in the database.
Your edit would treble that. I'm not convinced that automatic edits that
massively boost a niche tag are a good idea.

> There are some image= tags that link to multiple images separated by
> ";". These will be manually migrated to contain only one image that is
> not linking to commons and the rest in a note, note1, noteX if multiple
> urls.

Why on earth would you do that?

> image=File:* -> commons_file=File:* image=Category:* ->
> commons_category=Category:*
> image=https://commons.wikimedia.org/wiki/File:* -> commons_file=File:*
> image=https://commons.wikimedia.org/wiki/Category:* ->
> commons_category=Category:*

I am not comfortable with inventing new tags to better match Wikimedia
Commons' namespace model. Remember, Wikimedia commons is, for us, just
one of many potential image providers. Would we want to introduce
various extra tags for each?

> There are some image= tags that link to multiple images separated by
> ";". These will be manually migrated to contain only one image that is
> not linking to commons and the rest in a note, note1, noteX if multiple
> urls.

Again, moving valid information into note tags which are free-form human
language is the worst idea of all. Parsing a semi-colon should be much
easier than parsing a note tag!

I am against the edit, and I also find the style of dumping an
unformatted wiki page onto the mailing list for discussion a bit
disrespectful.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Adding mapillary tags to every building

2020-06-04 Thread Frederik Ramm
Hi,

On 2020-06-04 14:54, Janko Mihelić wrote:
> I think having a photo of every building, as well as other features like
> public sculptures, memorials, bus stations would be very useful. You
> would be able to click a building, and know what it looks like.

I would not want us to encourage and support the widespread
photographing of private residences. I think that's a privacy nightmare.
If it is only for commercial or public buildings, then it could probably
be done.

In addition, I would not like to rely on a third-party service like
Mapillary since they can shut down their service at any time and then
what becomes of all the work?

Furthermore, adding tons of external IDs to OSM seems unnecessary; I'd
rather have the imagery service store the coordinates and then you can
query the service "which of your photos show this location" and thereby
find photos that show a particular building.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

2020-05-21 Thread Frederik Ramm
Hi,

On 21.05.20 10:33, Ture Pålsson via Tagging wrote:
> What I suppose that I wish to say with all this is that in practice, I
> have seen highway=path used to mean anything from something that is not
> even visible on the ground,

An interesting side thread to this is not about the visibility but about
the accessibility - at DWG we've recently received a plea from a member
of a volunteer mountain rescue team to remove the highway=path attribute
from a dangerous approach to a mountain that was only suitable for
experienced mountaineers with appropriate gear. The way *did* have a
"sac_scale" to indicate difficult alpine hiking but apparently that was
not good enough, or too many clients were just ignoring that (in a post
on talk-gb recently, Andy Allan wrote: "I've seen maps from a
multi-billion-dollar-revenue organisation that were rendering anything
with a highway tag the same as their most minor road style"). It is not
proven that the many people having required rescue services on that path
came there because of OSM - could be any other source too - but this is
one aspect of the general "path" problem.

If we map "highway=path" + "danger=you will be shot" and then someone
gets shot because their Android app only looked at highway=path, can we
*really* sit back and say "their fault, we don't map for the Android app"?

Sorry if this is somewhere on the Wiki, I love the Wiki for
documentation but I hate Wiki discussions with all my heart and cannot
bring myself to read them, much less participate in them.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] insurance health

2020-04-15 Thread Frederik Ramm
Hi,

On 15.04.20 03:16, Joseph Eisenberg wrote:
> OK, but are there any countries in the world where you can would
> normally buy health insurance in the same place as car or home or life
> insurance?

Yes, sure. Many big German insurers offer health insurance and other
insurances (e.g. life, car, home) too, and they will often have sales
representatives tied to one insurer operating out of anything between a
more or less private residence with a sticker outside in the countryside
and a proper staffed office in a city. These sales representatives are
usually self-employed and get a kickback from every contract they sell.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Rarely verified and third-party data staleness in OpenStreetMap

2020-04-06 Thread Frederik Ramm
Hi,

On 06.04.20 17:25, Paul Allen wrote:
> Expecting mappers to wander around checking refill points
> is expecting far too much.  Expecting people looking for refill points
> to tap a "this place still does refills" is expecting far too much.

Only way I would see this working is a "gamification" thing where - a
bit like the "Kort game" of days past
(https://wiki.openstreetmap.org/wiki/Kort_Game) and a bit like
"StreetComplete" - people who happen to be in a specific location and
who have signed up to the game/system are nudged to go check something -
"hey since you're standing in front of restaurant X, please check if it
still has the property Y". But that would require people to sign up, and
of course a server-side application to track contributions, leaderboards
and so on. Whether or not the back-end storage is then OpenStreetMap or
a separate database is actually a smaller question.

Simply establishing a tag and hoping that you have to develop and run
neither a backend (because OSM will do it) nor a frontend (because
people can use Vespucci) is extremely optimistic.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Rarely verified and third-party data staleness in OpenStreetMap

2020-04-06 Thread Frederik Ramm
Hello Stuart,

may I suggest that you choose a personal email address for participating
in mailing lists. It feels really strange to address a message to
"europeanwaterproject". I don't want to talk with "a project", I want to
talk with a person.

On 06.04.20 09:31, European Water Project wrote:
> Please find attached a draft note for a feature proposal, which I have
> no idea if is even technically possible, for automatically adding a last
> verified date/creation date to specific keys.  Maybe there is a
> better/more efficient way ?

There are several issues here.

Firstly, I don't know what you mean by "automatically adding". After all
you need a person to manually confirm that the object is unchanged
before a tag is added, so which part of this is automatic? Surely you
are not saying that you want to add a tag to every object that simply
duplicates the last-edit timestamp already stored?

Secondly, this is a problem shared by all the "last survey" approaches:
You're standing the logic on its head. You're essentially saying: "If
the object has NOT changed in reality, please DO change it in OSM" (by
updating the last-checked tag). This means that we're being asked to
switch from mapping changes to mapping non-changes, with a potentially
huge data inflation in OSM (in theory I could update the "last survey"
of my local supermarket every time I shop there...). Your idea to
identify potentially fast-changing things and concentrate on these
softens the impact but still, we'd be churning out new versions of
objects like crazy just to confirm they are still there. (Everytime you
make a little change to one of the object's 10 tags, a full copy of the
object is created in OSM.)

Thirdly, also shared by many "last survey" approaches: If you tag a
restaurant with a last survey date then exactly what have you surveyed?
Just that it is still there? That is still has these opening hours? Or
that it still gives you free water? There's potential from confusion here.

The topic of staleness has been attacked by scientists in the past,
trying statistical approaches along the lines of "if there's a decent
number of detailed edits by different people in this area, then there is
a high probability of data being up to date". This of course doesn't
give you the same reliability but perhaps it delivers some results
without being the massively invasive concept you're proposing.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Which languages are admissible for name:xx tags?

2020-03-25 Thread Frederik Ramm
Hi,

On 25.03.20 11:19, Phake Nick wrote:
> My guess is that about 5% of name:xx tags in OSM actually represent a
> unique name in its own right; all others are either copies of the name
> tag ("this city does not have its own name in language XX but I want
> every city to have a name:xx tag so I'll just copy the name tag"), or
> transliterations (or, worst case, even literal translations).
> 
> Isn't that the function of the key?

Unsure which of my list items you mean - copying the original name is
not the function of the key; a data user can simply fall back to the
name tag if no name:xx is given. Making a transliteration is also not
the the function of the key, since transliterations can be automated.
Making a translation is *certainly* not wanted!

> Adding Klingon name would not cause copyright issue since vocabularies
> are not copyrightable.

If someone adds a name and specifies a source web page, and the source
web page says "all rights reserved", then I will not start a legal
discussion.

> That is just the same problem with TIGER map data. I don't think anyone
> have ever proposed removing United States data from the OpenStreetMap
> database due to lack of maintainers back then?

Thank you for this comparison. People certainly use TIGER as an example
for not adding more of the same, and a lot of thought has gone into
identifying "TIGER deserts" and how to handle the stale data. If we can
start seeing the name inflation as a problem, stop adding "more of the
same", and develop strategies to deal with stale and possibly incorrect
names, that would already be a huge gain!

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Which languages are admissible for name:xx tags?

2020-03-25 Thread Frederik Ramm
Hi,

On 25.03.20 10:45, Andrew Hain wrote:
> Why on earth would we not (excluding exceptional copyright issues) want
> to have lots of different name:XX tags?

I thought I had given a couple of reasons in my post.

If you have not understood them, I'm happy to rephrase.

If you *have* understood them but think that there is a desirable value
that outweighs my reasons, it would be nice if you could state more
explicitly what you perceive that value to be and where *you* would draw
the line!

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


[Tagging] Which languages are admissible for name:xx tags?

2020-03-25 Thread Frederik Ramm
Hi,

the "name:xx" tags are something of an exception in OSM because while we
defer to "local knowledge" as the highest-ranking source normally, this
is not being done for name:xx tags. It is possible for no single citizen
of the city of Karlsruhe to know its Russian name, but still a Russian
name could exist. Who is the highest-ranking source for that?

My guess is that about 5% of name:xx tags in OSM actually represent a
unique name in its own right; all others are either copies of the name
tag ("this city does not have its own name in language XX but I want
every city to have a name:xx tag so I'll just copy the name tag"), or
transliterations (or, worst case, even literal translations).

A while ago we had a longer discussion about Esperanto names; in that
discussion, it was questioned whether Esperanto could be in the name tag
but nobody disputed that adding name:eo tags is ok, even though
Esperanto is an invented (or "constructed") language.

Yesterday someone added a few dozen Klingon names to countries in OSM. I
have reverted that because of a copyright issue, but I think we also
need to discuss which languages we want to accept for name:xx tags.

In my opinion, a name:xx tag should only be added if you can demonstrate
that people natively speaking the living language xx are actually using
this name for this entity. I think we have a very unhealthy inflation of
names in OSM that are added by "single-purpose mappers" - they come in,
stick a name:my-favourite-language tag onto everything, and go away
again. Nobody knows if these names are even correct, and nobody cares
for their maintenance. The country North Macedonia changed its name
almost one year ago, yet roughly half of its ~ 170 name tags are still
what they were before this change. Nobody cares; these names suggest a
data richness that is not backed up by an actual living community that
cares for them.

What are your opinions on which languages should be accepted in name
tags? What do you think about

* niche constructed languages (say, FredLang which has 2 words I
invented just now)
* popular constructed languages (Klingon, Elvish) - note place names in
these languages will often be algorithmically derived from the English
or local name
* "serious" constructed languages (Esperanto)
* languages that once existed but are not natively spoken any more (Roman)
* languages that are natively spoken but their speakers do not have
their own name for the entity in question (instead they use the same
name the locals use, possibly transcribed into a different alphabet)
* ...

Or if you don't have the time to think about this in detail, just answer
the question: tlhIngan Hol - Hlja' or ghobe'?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] URL tracking parameters

2020-02-25 Thread Frederik Ramm
Hi,

On 25.02.20 11:59, Richard Fairhurst wrote:
> Yes. And we don't even need to do that: we can verify it with about 30
> seconds' Googling.

Ok ok you're right.

The URL does contain a tracking token but it does not exclusively track
OSM usage.

I have overreacted because I have in the past dealt with advertisers who
had added an OSM-specific "campaign" ID the the links which was clearly
out of line, and suspected the same here.

This leads to the interesting question of what the correct URL for a
business is and who decides that. If the business owner says "but the
correct URL for my business is ...?wdycf=openstreetmap", what do we do?
In theory they could configure their web site to only accept a few
well-defined wdycf values.

(Apparently in this particular case, not only the WT.mc_id parameter is
decorative, the whole hotel name is; even
https://www.hilton.com/en/hotels/bhxsadi-camping-in-the-woods/ directs
you to
https://www.hilton.com/en/hotels/bhxsadi-doubletree-stratford-upon-avon/...)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] URL tracking parameters

2020-02-25 Thread Frederik Ramm
Hi,

On 25.02.20 11:27, Richard Fairhurst wrote:
> But more broadly, we value data for its correctness

True. (There's a few other things we value too, but correctness
definitely is nice.)

> You are inventing a suspected rationale ("an
> advertising campaign")

Tracking components in an URL are usually a sign for an advertising
campaign. (They are often even called "campaign_ref=...".) If this is
*not* and advertising campaign but they give the outward appearance of
being one, is it then really me who is "suspecting" and "inventing"?

> on the part of the contributor; judging them by your
> own standards which aren't the agreed/stated values of OSM anywhere I can
> see

I don't follow. You said above that correctness is valued. The fact that
advertising and correctness do not usually go hand in hand certainly
needs no discussion. When I then say that we cannot trust data added as
part of an advertising campaign - is that "judging by my own standards"?

> I mean, isn't it also possible that, now we've all made such an outstanding
> success of OSM and it's used in approximately eight gazillion mapping apps,
> Hilton Hotels think it would be useful if their customers could use their
> favourite mapping app to find a hotel they're staying in?

Sure, I'm happy to compromise on "let's remove just those tags that do
not contribute to finding the hotel someone is staying in".

> Anyway, brb, got to delete https://www.openstreetmap.org/node/312915889 from
> the map.

Clearly added in an advertising campaign. The business owner hoped to
attract more business by creating that node 11 years ago with
"addr:housenumber=17".

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] URL tracking parameters

2020-02-25 Thread Frederik Ramm
Hi,

On 25.02.20 11:01, Philip Barnes wrote:
> Another issue I have with Hilton Hotels is all edits are made either made by 
> a single user, or the account is being shared between multiple users.

Has someone contacted them about the issue already? If they're a single
person we could request that they remove the tracking information,
rather than us having to deal with it.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] URL tracking parameters

2020-02-25 Thread Frederik Ramm
Hi,

On 25.02.20 11:08, Richard Fairhurst wrote:
> Frederik Ramm wrote:
>> Since OSM is not the place for marketing, I would in these 
>> situations remove the whole POI, and not just the tracking
>> parameters.
> 
> ¿Que? You'd remove an entire hotel from the map because... ok, I'm having
> trouble finishing that sentence: because what exactly?

I'd remove things from OSM that have been clearly added as part of an
advertising campaign, because that means the information is not
trustworthy. The purpose of an advertising campaign is not to provide
unbiased, factual information, hence OSM cannot be the vehicle for an
advertising campaign.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] URL tracking parameters

2020-02-25 Thread Frederik Ramm
Hi,

On 25.02.20 04:36, Jonathon Rossi wrote:
> Ignoring they've just added an incorrect "website:" key when there is
> already a "website" one, Hilton Hotels appear to be adding URLs with
> WT.mc_id parameters to all their web site links.

The presence of such tracking parameters is an indication of the author
considering OSM to be a "campaign" in some marketing scenario where the
success of different "campaigns" is measured.

Since OSM is not the place for marketing, I would in these situations
remove the whole POI, and not just the tracking parameters.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] All European Union countries use E5/E10/B7 instead of gasoline 98/95, Diesel 10S respectively

2020-01-25 Thread Frederik Ramm
Hi,

On 1/25/20 08:26, Thibault Molleman wrote:
> Back in 2018 all countries in the European Union were forced to switch
> their naming scheme 

That may well be but the fuel stations in my vicinity still advertise
"Diesel" and not "e10", so at least for the part of Germany where I
live, "fuel:b7" would be definitely wrong.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] RFC free_water

2020-01-21 Thread Frederik Ramm
Hi,

On 17.01.20 07:37, European Water Project wrote:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Free_Water

My opinion on this is:

1. It is not something that should be mapped in OSM at all; this is a
volatile property like mapping menu items for a restaurant or product
offers for a supermarket and may change at any time.

2. Even if we wanted to map this property, insofar as a whole chain has
been signed up ("all XYZ outlets in ABC country offer free water"), it
is wasteful to add the tag to every single outlet and it should just be
recorded centrally (i.e. an app displaying free water options should
simply highlight all outlets with operator=X or brand=X).

3. When we're talking about non-chain restaurants, the decision whether
a random traveller will be offered a free refill for their water bottle
can very well depend on the day of week, how politely the traveller
asks, or how busy the place is - just because you've been given free
water doesn't mean you should claim everybody gets it every time.

4. Even if all of the above were ignored, I think "free=yes" is too
limited, and would concur with those who have suggested a "fee=no"
approach, because if you are charged a dollar for your refill you can
simply put "fee=$1".

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


[Tagging] Rio de la Plata edit war

2020-01-13 Thread Frederik Ramm
Hi,

it appears that once again mappers are in diasgreement about how to map
the Rio de la Plata, here

https://www.openstreetmap.org/#map=8/-35.154/-56.310

This is a disagreement that had already flared up three years ago, and
is now coming back.

According to Wikipedia, the International Hydrographic Organization
defines the eastern boundary of the Río de la Plata as "a line joining
Punta del Este, Uruguay and Cabo San Antonio, Argentina", which is what
has been the case in OSM until now:

https://www.openstreetmap.org/way/186710973 (the coastline across the
"mouth" of the "river")

and

https://www.openstreetmap.org/relation/3474227 (the "river")

This current representation in OSM leads to a few strange situations
especially in toolchains/map styles that use different colours for
inland water and oceans, or that draw sea depths, or just highlight the
coastline. Buenos Aires, according to OSM, is currently not a coastal city.

One of the involved mappers who aligned the coastline more closely with
the coast wrote (https://www.openstreetmap.org/changeset/79201390) "I
believe this is inline with guidance
(https://wiki.openstreetmap.org/wiki/Tag:natural=coastline)".

I'm not so clear about how to interpret the wiki page myself when it
comes to river mouths. There's a clarifying proposal here
https://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement
but this is still at the proposal stage.

Opinions?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Business names in capital letters

2019-12-14 Thread Frederik Ramm
Hi,

On 14.12.19 01:57, Paul Allen wrote:
> How does the company itself capitalize its own name?  Paint the label. 
> Even if it's an ugly label.

I tend to view capitalisation as a design element not a part of the
name. If they write their name in Comic Sans then I won't try to copy
that either, so why copy funny capitalisation that is only intended to
attract attention.

On the wider topic of writing names as they are on the sign, I would
agree with this up to a certain point. It is entirely possible for a
business to name itself "Fred's Bagels the BEST Bagels in Northern
California Inc", at which point I would say they are starting to game
our rules, hoping to be put on the map with exactly that name - and I'd
reduce the name to "Fred's Bagels", putting the rest in "offical_name"
or something.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] the nature of large-scale paid edits (was Re: Service road)

2019-11-07 Thread Frederik Ramm
Hi,

On 11/7/19 18:19, Greg Troxel wrote:
> My point is that we have a lot of mappers and a set of norms (which are
> pretty fuzzy and/or a bit contradictory).  We have rules about
> mechanical edits (including imports), since they change things in a
> large-scale systematic way.

Yes. If you are a programmer and instruct your code to change all A's to
B's in OSM then it's a mechanical edit and rules apply (because much can
go wrong, aka "with great power comes great responsibility" etc).

And if you are a boss and instruct your 5000 employees to change all A's
to B's that should be treated similarly. That's why we have the
organised editing guidelines:
https://wiki.osmfoundation.org/wiki/Organised_Editing_Guidelines

> So I'm not opposed to large-scale paid editing; i just think it needs
> some caution and that the guidance to paid mapeprs needs to be
> published to the OSM community.

The guidelines request that, among other things, "if participants will
receive training material or written instructions, a copy of, or link
to, these materials" should be published.

Generally, if an organisation does not follow the guidelines and this
leads to problems, they should be held accountable & their edits are
liable to being reverted. Of course one would start with a friendly
pointer...

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Deprecating mini_roundabout

2019-10-24 Thread Frederik Ramm
Hi,

On 23.10.19 14:54, Richard Fairhurst wrote:
> I think the best suggestion in this case would be to update the
> documentation, particularly in translated pages, clarifying that the tag is
> intended for the formal mini-roundabout design as found in the UK, Ireland,
> France etc., and not for any flat roundabout.

The wiki is a bit conflicting here.

https://wiki.openstreetmap.org/wiki/Tag:highway%3Dmini_roundabout says

If there is only a single vehicle, or two vehicles traveling in opposite
directions, it is common – but not necessary legal in all countries – to
drive straight across the middle rather than going around.

Whereas the German translation only said that you "can" go over the
centre, not that you usually would. I adapted the German translation to
more closely follow the English text.

Further down, the same page says

A roundabout is a one-way street with right-of-way and a non-traversable
centre island.

Which if taken at face value would make any roundabout, however big and
however many roads join there, a "mini roundabout" if the centre is
traversable.

The roundabout in the Mapillary images that Paul Johnson posted seems to
be one with a traversable centre. At the same time, I would not expect
my satnav to ask me to "turn left" here, but rather to take the nth exit
at the roundabout...

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


[Tagging] Divided highways, and not so divided highways, one way or two

2019-10-10 Thread Frederik Ramm
Hi,

DWG has been asked to mediate in a user dispute in Germany where a local
mapper has chosen to represent a busy four-lane primary highway (two
lanes in each direction, and a double continuous line painted in the
middle which is physically possible but legally not allowed to cross).

Other mappers object to this saying that it violates the rule that there
must be some sort of physical division to allow that form of mapping.

The original mapper claims that using two separate oneway=yes ways is
clearer and easier, as it does away with the need for turn restrictions
at junctions. Other mappers claim that the two-separate-way mapping is
violating rules and that OSM will soon become unusable if everyone maps
how they want.

The question is basically two-fold; one, what are the established
standards and rules concerning this situation, and two, in how far is it
acceptable to deviate from these standards if a local mapper thinks it
is a good idea.

Personally I believe that "physical division => separate ways; no
physical division => shared way" is the standard in OSM, or perhaps at
least the "rule of thumb". But (since people in the German discussion
have more or less claimed that the world is going to end if local
mappers are allowed to treat this differently) I'd like to hear from
mappers in other countries how rigidly this standard is applied. Is it
something where local mappers have some freedom of judgment (like when
choosing which highway=* category to apply to a road) or do you have
strict standards and definitions?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Feature Proposal - RFC - Reusable packaging

2019-09-12 Thread Frederik Ramm
Hi,

I am generally skeptical of us becoming more and more a business directory.

I think that objects in the real world have some real-world, observable
properties, like a house that has a certain form and height, or a sign
that has been put up, or a bench, and while these properties can change,
it will usually involve some construction and not happen willy-nilly. I
am in favour of mapping such things.

On the other hand, there are commercial and policy things, like: Does
this shop accept credit cards, does this shop sell vegan food, or how
many varieties of chocolate bars does this shop stock, and does this
museum open on Sundays? While I can see that this information is
interesting in some situations, these properties can change on a whim. A
supermarket chain can introduce paper bags today, discontinue them next
week, and re-introduce plastic bags next month. Do we really want to go
into that effort of trying to actively represent what products are sold
and under what conditions? Do we even have a remote hope of achieving a
level of completeness and timeliness that makes this usable? Where does
it stop?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Open Defecation Areas

2019-09-09 Thread Frederik Ramm
Hi,

On 09.09.19 02:37, Warin wrote:
> Quote: "Open Defecation, people going to the toilet in the open,
> specially in dense urban areas. Open defecation areas ODA are use by
> about 850 million people. If they each use 10 different areas a year
> then that is 8.5 billion areas."

I don't follow that logic. If the 300k inhabitants of my city each use a
bus stop 100 times per year, then that means our city has 30 million bus
stops?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] building typology vs usage

2019-09-07 Thread Frederik Ramm
Hi,

On 07.09.2019 09:16, Joseph Eisenberg wrote:
>> While in theory building=school could be reused as a hotel/pub (See
>> https://www.mcmenamins.com/kennedy-school) in that case the building
>> will be inside of a tourism=hotel polygon 

Why would it - a standalone former school in a city that now houses
something else doesn't necessarily have to acquire a surrounding polygon.

On 9/7/19 10:40, Tom Pfeifer wrote:
> Please understand that the building typology is orthogonal to the usage
> of the building.
> Thus having both a building=X and leisure/amenity=X on the same polygon
> is not redundant.

It is true that this is the canonical way of dealing with things,
however it would be interesting to check how mappers and editing tools
actually use this. We might well find that everyone is confused about this.

When we say "a cafe in an old church" we think of a building that has
certain properties that make it discernible as a church even long after
it ceased to be one; however, depending on location and denomination,
you might also build a church using a blueprint for a plain community
centre. In that case would it still be building=church becasue that was
the original, intended use? What if apartments are put into an old
factory building - building=industrial and ...?

I think we cannot simply throw the distinction over board and therefore
I do not agree with Josh, but I also think the distinction is not really
well thought out/well implemented in OSM and needs clarification.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Document personal tags in Proposed_features/ space, User: space, or Tag:/Key: space?

2019-08-15 Thread Frederik Ramm
Hi,

On 15.08.19 04:18, Joseph Eisenberg wrote:
> In contrast, the current text of the wiki page "Any tags you like
> suggests creating a new tag for bird nests (as an example) with
> Key:endangered_nest=Siberian_flying_squirrel - besides suggesting
> using non-standard capitalization in the value, this suggests creating
> a new Key: / Tag: page directly, rather than using User:username/ or
> Proposed_features/.
> 
> Is this a good idea?  Occasionally new wiki pages are created in these
> standard spaces for tags with only a few uses or no uses in the
> database.

We have occasionally complained when someone did that, and forcibly
moved their tags to their private space.

(N.B. there used to be a time when we encouraged people to create
private tags of the kind "username:key=value", a practice we have since
stopped.)

(N.B. do you know the watch:username key...?)

> I would encourage mappers not to create new feature pages for tags
> which are not yet in use, or have only been used a handful of times by
> one mapper.

Yes, I think it would be wrong to say it is "generally forbidden" but it
is likely only right in exceptional circumstances. It is one of these
"you can do it but you should be very sure that you're doing the right
thing" kind of things!

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Use of tag "import=yes" on objects, not changesets?

2019-08-09 Thread Frederik Ramm
Hi,

On 09.08.19 15:32, Joseph Eisenberg wrote:
> Or perhaps there is a simple way they could check changesets to find
> out how many roads they have added? I'd like to suggest how they could
> do this, to avoid adding extra tags.

f.s.v.o. "simple", a relatively foolproof method on a Linux machine is

1. download indonesia history pbf,
2. run osmium command line tool to convert into ASCII "opl" format,
3. grep how many ways with highway=* and v=1 are mapped by their team.

Steps 2 and 3 combined could look like

osmium cat indonesia-internal.osh.pbf -f opl | grep "^w" | grep highway=
| grep -e " uxybot " -e " uArjanO "| wc -l
[==]
100%
7413

(for a sample count of all highways created by users xybot and ArjanO).

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Deprecate access=public (synonym for access=yes)

2019-07-31 Thread Frederik Ramm
Hi,

On 31.07.19 09:22, Joseph Eisenberg wrote:
> I'd like to deprecate access=public. 

Can you explain what concrete actions you mean by that? What exactly
would you do if everyone said "yeah, go ahaead"?

Bye
Frderik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Are disused=yes and abandoned=yes deprecated by disused:key=value & abandoned:key=value?

2019-07-29 Thread Frederik Ramm
Hi,

On 29.07.19 08:23, Joseph Eisenberg wrote:
> I was going to fix the status of abandoned=yes which is currently
> incorrectly listed as "obsolete". I thought it was probably
> deprecated, since the wiki page was deleted when Key:abandoned:*
> (namespaced) was made in 2015, but it's still used 40,000 times.
> 
> The key disused (mainly disused=yes) is also used 60,000 times, even
> though the situation is the same: no wiki page, and the Key:disused:
> page suggests it is deprecated.

Frankly, I am worried about the obsession with tag "statuses". I
couldn't care less whether "abandoned=yes" was obsolete, deprecated, in
use, or even voted on; "negating tags" like this is are dangerous and
problematic and the wiki should educate people about this, full stop.

If we explain to people why negating tags are problematic then they will
understand and not use them; this is far better than telling them "uh-oh
you've used a tag that is classified as a type-X tag under section Y of
the tag classification regulations, don't do it!"

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] My ban by user Woodpeck = Frederik Ramm

2019-06-29 Thread Frederik Ramm
Hi,

On 6/29/19 08:05, "Christian Müller" via Tagging wrote:
> The intriguing question is:

Please (again!), move this to legal-talk or elsewhere. It has no place
on the tagging list.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Which global OSM mailing list for the "community index"?

2019-06-28 Thread Frederik Ramm
Hi,

On 28.06.19 04:14, Graeme Fitzpatrick wrote:
> Thoughts?

Very bad idea, is my thought. Copying old threads to forums swamps the
forums, and gives people there old discussions to look at but in which
they cannot participate any more, as the authors of whatever arguments
you post will not be reading the forum. In my eyes, this plan treats the
forum as second-class and is disrespectful to its users.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] My ban by user Woodpeck = Frederik Ramm

2019-06-26 Thread Frederik Ramm
At this point the discussion should really be continued

(a) under another subject and
(b) on a different mailing list (maybe legal-talk?)

Bye
Frederik

On 26.06.19 07:16, Mateusz Konieczny wrote:
> 26 Jun 2019, 00:01 by tagging@openstreetmap.org:
> 
> in particular for non-commercial and scientific use
> 
> This are not relevant at all, OSM data is not restricted in how it can
> be used.
> 
> I don't know to what extent this is applicable for an international
> project such as OSM, but there are fair-use and non-commercial ex-
> ceptions in the copyright statutes of many countries
> 
> Both have limitations that make incompatible with OSM licensing
> requirements.
> 
> Merely reusing names of watercourses is not a breach of copyright, if
> you research them in non-database publications
> 
> OSM is a database
> 
> _or_ if you do copy
> few excerpts
> 
> This way lies madness, as there is  no way to ensure that only one user
> copied
> something. Multiple users copying only few excerpts each is not allowed.
> 
> (UrhG speaks of 15% for scientific, non-commercial use)
> 
> How many for commercial use?
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] My ban by user Woodpeck = Frederik Ramm

2019-06-25 Thread Frederik Ramm
Hello Ulrich,

this is offtopic here but I'd like to say something anyway since you
started the discussion here.

Your are blocked from editing until we can trust you to respect our
rules. This is a process that has to happen in your head. I would have
hoped that you understood the issue but time and time again you have
demonstrated that you did not.

You cannot continue to use one inadmissible source and then when you're
told this is wrong, use a different inadmissible source and so on ad
infinitum. This is not a contest of who finds a loophole. Use your own
knowledge, or use public domain (or suitably licensed) sources; and
always add a source tag that lets people verify your source. All these
relations you're adding about complex waterway systems and their names -
these can impossibly all be your knowledge so you're copying them from
somewhere and if you don't say where from then we must assume it's an
inadmissible source.

Since all your mapping is in Germany, please go to the German mailing
list or German forum to discuss what exactly you are doing with your
waterway mapping and what your data sources and processes are, and then
if we find a way forward that will not lead to lots of complaints to DWG
about your work, we can lift the ban on your account and let you
continue. But simply letting you continue after a couple days, like we
did in the past, has sadly not helped.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] kerb regulations: moving towards a tagging schema?

2019-06-21 Thread Frederik Ramm
Hi,

On 21.06.19 04:38, Emily Eros wrote:
> I'd love to hear from people about what they think about this as a
> general approach. 

It is rare to see a suggestion from someone who is new to the game that
is so well thought out.

I am impressed that you did not, like so many others who want to scratch
their particular itch with OSM, opt for whatever is easiest for you and
not care about mapping. Everyone else on the planet would likely have
said something like "ah let's just draw a line next to the road and add
kerbside regs to that", or worse still, "let's just split up the road"
which would, as you rightly point out in your example, lead to very
fractioned ways indeed.

For this idea to be really successful, I believe that your logic of
snapping points to the road and deriving linear information from it
might have to be added to editors, so that mappers can get direct
feedback on how the interpretation changes when they add markers.

I'm not 100% clear on some aspects, e.g. what if your on-the-ground
markers are linear (double vs. single yellow line indicating no
stopping/no parking etc.) but it is possible that you've covered that
somewhere without me noticing.

I'm sure practical application will lead to all sorts of questions or
follow-on problems but the approach sounds promising.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


[Tagging] Which global OSM mailing list for the "community index"?

2019-06-20 Thread Frederik Ramm
Hi,

in parts of the world for which no particular national/regional
resources have been defined, the "id" editor will suggest to get in
touch with "us" and/or other mappers through:

* Reddit
* Facebook
* Telegram
* Discord
* Twitter
* OSM help
* OSM IRC channel
* OSMF website

(this list is defined in from
https://github.com/osmlab/osm-community-index/tree/master/resources/world)

Clearly one of the global mailing lists is missing here; I wonder which
one it should be. "talk" has had participation from ~ 160 different
community members in 2019 so far, "tagging" even ~ 200. Though maybe
tagging is too specific and talk a better starting point for someone who
wants to get in touch?

For comparison, I would be interested in how many people have
participated in the global venues that id currently links to. Are there
public archives that would allow me to count that?

I tried to gauge participation in help.osm in all of 2019 and came up
with ~ 620 different people who either asked or answered at least one
question. But help is a less "egalitarian" landscape than the mailing
lists; a very large part of those 620 just ask one question and don't
participate further, and a very small number of these 620 answer all the
questions. The mailing lists have fewer people participating but those
that do are more likely to engage in a bidirectional fashion.

It would be interesting to quantify this in a more scientific manner.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Deprecation of non-approved values for diplomatic=?

2019-06-15 Thread Frederik Ramm
Hi,

On 6/14/19 5:49 PM, marc marc wrote:
> I think the proposals for a new tag should clearly say:
> - add such tag
> - edit the old tag description to point the new tag
> - write to editors to adapt presets
> - propose a mecanical edit, if necessary by splitting it up
> to avoid a global opponent blocking everything
> - propose the depreciation of the old tag

Such proposals would need to clear a much higher bar than we currently
have. I'm thinking "at least 500 votes of which 75% in favour" or so.

You cannot have 15 people decide on such wide-ranging changes.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Deprecation of non-approved values for diplomatic=?

2019-06-14 Thread Frederik Ramm
Hi,

in general, I try to avoid marking anything as deprecated. I think the
term only gives people wrong ideas. If anything, try to find wording
that says "today, most mappers prefer the X tag", but don't say "this
tag is deprecated" except in very clear circumstances, where an
overwhelming majority has actually decided that this tag should be
listed as "deprecated".

Claiming something is "deprecated" should never be a silent side-effect
of some other vote.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Mismatched tag status

2019-06-11 Thread Frederik Ramm
Hi,

On 11.06.19 02:29, Warin wrote:
>> Here's the thing.  In terms of OSM statuses, "de facto" means that the
>> tag is in use. 
> 
> Err I thought
> 'de facto' = "approved" but before the formal approval process was in place
> 'in use' = widely used and in large numbers, sufficient to be recognised
> by renders
> ' undefined' = low numbers, or restricted use .. some incorrectly place
> these as 'in use'

I think it has become clear in a short time that there is no
hard-and-fast definition of any of this.

The idea that tags even *have* a status was introduced by someone
writing wiki templates at some time in the distant past; it's not
something that was even discussed as far as I remember, because it never
was of any importance. We have never discussed or decided that

(a) every tag should have a documented status
(b) the status should be the same in all langauages
(c) what status values there are and what they mean

So your opinion is as good as mine. I'd be tempted to side with Warin
here; if "in use" only meant "used anywhere at least once" then taginfo
can be used to determine that; only if there's *some* human factor in it
would it even make sense. And it could certainly differ across regions.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] A modest proposal to increase the usefulness of the tagging list

2019-06-02 Thread Frederik Ramm
Hi,

On 6/2/19 13:17, Christoph Hormann wrote:
> Note there have been in the past opinions that documenting a new tag 
> without creating a proposal is not desirable

That is also my opinion, however, I don't see anything wrong with
someone just "trying out" a tag in the "any tags you like" spirit
without documenting it. (Or, if desperately needed, documenting it only
on their private user page.)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] A modest proposal to increase the usefulness of the tagging list

2019-06-02 Thread Frederik Ramm
Hi,

On 6/2/19 10:47, Simon Poole wrote:
> In the interest of keeping the list at least half usable, I would
> suggest that we all, starting now, voluntarily submit to:
> 
> - not posting more than 30 times per month (the 30 comes from the WMF
> mailing lists, where it seems to work quite well)
> 
> - not more than one proposal per person per month
> 
> - not more than 4 new proposals per month in total

- propose tags only if you, personally, have solid demand for it (i.e.
you have already mapped, or intend to map, the feature intensively).
This puts a practical limit to idle tag fantasising. Everyone can think
of something that doesn't have a tag yet - that is the cheap part...

Bye
Frederik
-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"



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


Re: [Tagging] Filter bubbles in OSM

2019-05-24 Thread Frederik Ramm
Hi,

On 25.05.19 01:12, Silent Spike wrote:
> In support of Nick's points above, reading many of the discussions on
> this mailing list today has me just about ready to unsubscribe.

There are many reasons why someone could be disappointed by this mailing
list, or by tagging discussions in general, and decide to stop
participating.

The way you write it above, however, sounds like you're assigning blame,
in precisely the disparaging way that Andy has pointed to in his other
message - you seem to be saying "I'm done with this lot, I don't like
the people here".

It would be helpful if people could refrain from making general
hand-wavy statements about mailing lists somehow being unworthy of their
time.

For example, if you have a complex idea like e.g. the "disputed
boundaries" that we discussed a while ago, you need to bring a
combination of skills to the table to succeed:

* You need the understanding and experience in OSM to create a workable
proposal.

* You need clarity of thought and the ability to express your idea
clearly, even to people who are not native speakers of English (or you
might yourself not be).

* You need diplomatic or political skills to find compromise, to get
others to support your idea, and the willingness to iterate again and
again.

* and a lot of patience!

This can be a demanding process and not everyone is cut out for it. Of
10 who attempt it, perhaps one succeeds and the others throw in the
towel and even stop participating altogether. It would be sad, and a
little disingenuous, if these people were then running around telling
everyone how shite the tagging list is just because they didn't get
their proposal through on the first attempt.

And the same happens on smaller scales of course. You could be
suggesting something and be faced with the opinions of people from the
other side of the globe, for whom what you suggest is outlandish, or of
people who live nearby but whose vision of OSM could not be more
different than your own.

I'm sure the communications can be improved in many ways, but even if
everyone were super respectful, all this would still be *hard* and
taxing and many people would leave because they just don't have the
patience that decision making in a large, international group of
volunteers with minimal authoritarianism takes. Ask anyone who's working
at the EU or the UN...

I think OSM on the whole should be welcoming for everyone, in that
everyone can find a place where they can make a useful contribution. But
I doubt that this mailing list, or any body that discusses tagging, can
ever be built in a way that everyone feels happy to contribute.

So please, if you feel your talent is better applied to other areas of
OSM, just do it - that's great. There's no need for a "sour grapes"
approach because you found that tagging discussions were not for you.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Filter bubbles in OSM

2019-05-24 Thread Frederik Ramm
Hi,

On 25.05.19 00:11, Florian Lohoff wrote:
> Its just a matter of
> defining whom to exclude not if.

True.

My son attends a school that favours being inclusive, and this means
that there's one student in the class who has a form of autism that lets
him often loudly protest against assignments, throw stuff on the ground
and leave the room in a huff. You'll find quite a few parents at this
school saying "well I'm all for inclusion but this is starting to impact
my child's education negatively..."

It's easy to rattle off a catalogue of behaviours we will all agree on
that they have no place here. Threats of violence, racist or sexist
abuse would get someone kicked out whether or not we have codified rules
or processes. These are extremely rare, though, and are certainly not
the problem people refer to when they say that the lists are not welcoming.

The problems that people often cite are softer in nature: The "culture"
was not "welcoming", they felt "attacked" or not treated respectfully
enough. These are much, much harder to codify, and I know quite a few
proponents of strict code-of-conduct rules who are against any soft
rules like that.

People have a right to be treated with respect, but that does not mean
that we need to extend US American style courtesy to everyone because US
Americans have the narrowest definition of what counts as respectful. We
want and need passionate debate about issues in this grassroots project;
if someone offers a very bad idea, then nobody benefits if people say
"this is a GREAT idea, I'd just like to suggest a small change" -
tearing the idea apart in public is totally ok and if people can't stand
that kind of (intellectual) heat then they cannot be part of that aspect
of the project in which such ideas are debated. There ought to be a safe
space for people, but there cannot be a safe space in which bad ideas
are allowed to live just because nobody dares to call them out.

Sometimes people attack the person presenting an idea, instead of
attacking the idea. This is something that we can work on and improve.
On the other hand, sometimes people feel attacked or "not welcomed" when
you tell them that their idea is not a good one, or that they have made
a mistake. If in this situation people are allowed to invoke some rule
that demands everyone be welcoming all the time, then we can probably
stop discussing anything right away, because the person with the
thinnest skin will be the last one left standing.

This, however, is leading us far off topic.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] solving iD conflict (was: pointlessly inflamatory title)

2019-05-23 Thread Frederik Ramm
Hi,

On 5/23/19 21:58, Nick Bolten wrote:
> OSM needs an alternative for community tagging discussions outside of
> these mailing lists.

It might; that doesn't invalidate points made on these mailing lists though!

> # My experiences with OSMers in other contexts:
> - Very friendly, all focused on making maps better, highly motivated to
> donate their time to help others via the map.
> - Disagreements are pleasant. Both sides acknowledge the other point of
> view and usually come around to a compromise.
> - There is interest in knowing more: lots of questions back and forth.
> - Objections are qualified and polite.
> - 10s-100s of people giving feedback on a single idea.

Every person on this mailing list participates in many of these kinds of
discussions, in addition to being on the mailing list (just in case you
were thinking there were two different kinds of people, the friendly
people and the mailing list people; this is not the case).

> When I was mentoring a group of students a few years ago, several were
> offended by the condescending and insulting responses they received on
> this mailing list, all because they suggested making a coherent way of
> combining existing tags into a pedestrian schema and doing a
> carefully-vetted import. 

I think you should attempt to apply a little of that "acknowledging the
other point of view" that you lauded above to such situations. Every day
brings new broken imports to OpenStreetMap. All of them are done with
the best intentions. Very many of them are done by people with little
prior experience. Therefore, when a group of students pops up and
suggests to do an import, this already sets some alarm bells ringing
(carefully vetted or not). Your project is to be applauded to even come
here - as you rightly say, the lists are not necessarily easy to
discover and a large percentage of problematic imports have never been
discussed with anyone before they are attempted.

Everyone on this mailing list has likely seen many buggy imports.
Imagine being at a party and someone steps on your shoe. They say sorry,
you say no problem. Five minutes later another person steps on your
shoe. Again, a friendly sorry, a friendly no problem. By the time the
10th person steps on your shoe you might shout out "WHAT THE FUCK IS
WRONG WITH THIS PARTY" even if that person is totally innocent. It's not
right, it's not polite, but it is somewhat understandable.

> I think
> it's probably a good thing that it's so hard to even know that there is
> a mailing list, as users have a negative experience.

That is often repeated and I guess most people can confirm that people
act differently in person than on mailing lists. However, many mailing
lists in OSM are vibrant meeting places for many more than 8 community
members, and spreading negative opinions about mailing lists reinforces
problems instead of solving them - if you go around telling everyone
what a snake pit "the mailing lists" are then people will either not
join them, or join them just waiting to see their expectations confirmed.

In general, our project isn't a top-down strictly managed project with a
controlled decision-making process. This means that many things have to
be discussed over and over, and the community generally doesn't speak
with one voice. But this also gives us some resilience; there's no one
"tag central command" that someone could take over and dictate what we
are to do.

> - Terrible security practices. Passwords sent in plain text over email.
> No encryption. I was almost put off the mailing list entirely when I saw
> this. Completely unacceptable.

Now you're going off on a tangent. Passwords are not required at all to
use the mailing list. Of course, email in general is not a secure medium
since you can easily impersonate others. Then again, if we judge the
merit of contributions by their content and not by who wrote them,
impersonating someone doesn't even give you much of an advantage.

> Gripes aside, I have a suggestion: move these discussions to a real
> forum system, properly organized around regional/topic-specific/tagging
> discussions. It could be a revamped https://forum.openstreetmap.org/ or
> something fancier and slack-like (like riot chat). Have actual
> moderators and code of conduct.

The current forum system works and has moderators and etiquette
guidelines (this depends on each sub-forum, they are not global).
Discoverability isn't much better than mailing lists IMHO. In my country
(Germany), OSMers are neatly split between forum and mailing list, most
using just one or just the other, some using both. Nothing wrong with
that IMHO; smaller groups form better bonds.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


[Tagging] Stop the large feature madness (was: Tag for a plateau or tableland?)

2019-04-17 Thread Frederik Ramm
Josh & others,

I think we need to take a break here from making OSM into a map of
large-scale geographic features.

This is getting out of hand. I vividly remember the endless discussions
about bays and peninsulae. Drainage basins. Now plateaus. I don't
remember mountain ranges in the recent past but if they weren't
discussed then they surely are next.

The way OSM usually works is someone stumbles over something in reality,
with a discernible name or property, and adds it to OSM. We are, first
and foremost, surveyors.

The larger a feature becomes, the less suitable OSM is for mapping it.
And in the case of the several large-scale objects I have mentioned,
most contributors don't even have surveying in mind, but just writing
down existing conventions. I haven't checked, but I would be very
surprised if *anyone* actually used the natural=peninsula tag for
something they happen to identify as a peninsula - no, natural=peninsula
is just a method of putting existing geographical names into OSM
(because the fact that something is a peninsula can be auto-detected).
Same with your plateaus and tablelands now - do you really envisage
someone looking at the landscape around them and saying "why, there's a
hard layer of rock here on top of softer layers, and a couple cliffs at
the sides, I guess I'll map this as a plateau"? No, again this is a
situation where you have third-party information about a plateau (and
likely its name) and are looking for ways to get that into OSM.

All these requests are born from a desire to write down existing
large-scale geological/geographical knowledge. But OSM is ill suited for
that; OSM cannot accommodate imprecise features. If you want to map a
mesa well in OSM then it has to be detectable on the ground, and it has
to have a clearly delineated boundary. What you are trying to do here is
adding large-scale features that come in handy when you want to make a
map ata  1:10m or maybe 1:50m scale. Projects like naturalearthdata.com
are ideally suited for that kind of data. OpenStreetMap is not.

I think we all should stop seeking out one large-scale feature type
after the other that is "missing" from OSM and think about how to best
add them. In my view, the fact that these are underrepresented in OSM is
not an opportunity to "improve" OSM but a sign that OSM isn't the right
place for that kind of data.

Instead, let us find a way of recording such imprecise information
outside of OSM's data model, and make it easy to access it e.g. when
rendering maps.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] [OSM-talk] Tagging disputed boundaries

2019-03-15 Thread Frederik Ramm
Sergio,

and others who might be reading this and thinking it is "normal",

On 15.03.19 12:41, Sergio Manzi wrote:
> Another tasteless and vile joke.

It is ok to say that, even though I'd hope it is rarely necessary.

But it is definitely not ok to say

> Not that I was expecting anything better from you, Martin: tastless jokes are 
> a clear sign of a lower IQ and a troubled personality by someone with the 
> delusion of being superior to others.

Please keep such personal attacks to yourself, they have no place on our
mailing lists. You can frame your criticism as a criticism of opinions
or behaviour, but singling out an individual and making judgements about
their IQ our psyche is totally out of line.

> I have decided to unsubscribe from the mailing list and leave the community: 
> too much noise and bitching

Well thank you for adding on top of that. Great help.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Dykes

2019-02-25 Thread Frederik Ramm
Hi,

On 2/22/19 13:29, Frederik Ramm wrote:
>> if you map a dyke, ID-editor recently gives a warning that a dyke ought to 
>> be a closed (circular) line.
> 
> I put this into an id ticket:
> https://github.com/openstreetmap/iD/issues/5933

The bug has been fixed in ID and the fix will likely deployed when ID is
next updated on the OSM main web page.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] start_date variants

2019-02-22 Thread Frederik Ramm
Hi,

On 21.02.19 21:46, Yuri Astrakhan wrote:
> Does this essentially mean that data consumers should treat
> architect:wikidata as an overriding tag?

I wouldn't want to tell data consumers that they should. Depending on
who contributed it, "architect" might have better or worse information
than "architect:wikidata".

> I would like to somehow get rid of the "us vs them" (osm vs wikidata)

Both projects have different cultures and we can work and thrive
together if we understand and respect that, in a "good fences make good
neighbours" kind of way.

For OSM, my main concern is that it must remain usable independent of
wikidata, and that the OSM community must not be lured into spending
their time to further wikidata integration if they don't have that
personal interest.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Dykes

2019-02-22 Thread Frederik Ramm
Hi,


On 22.02.19 12:46, Ulrich Lamm wrote:
> if you map a dyke, ID-editor recently gives a warning that a dyke ought to be 
> a closed (circular) line.

I put this into an id ticket:

https://github.com/openstreetmap/iD/issues/5933

Bye
Frederik
-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] transaction parameters for ATMs

2019-02-13 Thread Frederik Ramm
Hi,

On 14.02.19 08:17, Colin Smale wrote:
> Problem is, it will probably require data from multiple transactions
> from small to large to work out the mix

That's what I see as an issue too. Something that is only verifiable if
you are a customer and can make a large number of withdrawals to test,
stretches our concept of verifiable. If I don't get a specific
denomination from the machine, or if I am set an upper limit for my
withdrawal, will another person experience the same on the next day,
when they have more money on their account and the machine has been
refilled in the mean time?

I'd say we stick to stuff that is explicitly signposted on the machine -
if the machine says what the limit is or what the network is or what
currencies it has, then map that, but don't map data gathered by
interacting with the machine.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] motorcycle:scale

2019-02-03 Thread Frederik Ramm
Hi,

On 04.02.19 00:07, Christoph Hormann wrote:
> Just to avoid misunderstandings - it is in principle completely all 
> right to invent tags and document them on tag/key pages without 
> creating a proposal.

* invent keys - ok

* document widely used/established keys that never went through a
proposal process - ok

* invent keys and document them as if they were widely used or
established - questionable

* the whole thing done by someone who has in the past unilaterally
documented their personal preferred tagging on the wiki, then made
mechanical edits to push it through, and when challenged in changeset
comments, cited the wiki pages they had edited themselves as an
authority - ...

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


[Tagging] motorcycle:scale

2019-02-03 Thread Frederik Ramm
Hi,

I noticed today that a wiki page for the rarely used key
"motorcycle:scale" had been accidentally created as
"Key:motorcycle:scale", and moved it to "Proposed
features/motorcycle:scale". I haven't made any further edits to it though.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)

2019-01-09 Thread Frederik Ramm
Hi,

on second thought, if the Iberian Peninsula is already a Peninsula, does
that invalidate all Peninsula claims on land masses protruding from it,
or can there be cascading Peninsulas?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)

2019-01-09 Thread Frederik Ramm
Hi,

On 09.01.19 14:09, Martin Koppenhoefer wrote:
> The only reasons I see for
> approving "small" peninsulas" but not big ones, are of technical nature

Yes. People will create a new "multipolygon" or "boundary" relation
containing each and every way of the Spanish coastline for every
geographic feature they can think of. Ah, surely this is part of
"Eurasia". And of "Europe". And of "Spain". And of the "Iberian
Peninsula". And the water is the "Mediterranean Sea". And ... then when
you split a piece of coastline in Spain, you've edited 25 relations
spanning half the globe.

Granted, it's a technical shortcoming, but while this exists people
should respect it.

> On a sidenote: the Iberian Peninsula is already mapped in OSM as a
> relation, and it is in Version 848 ;-)

Must...resist...urge...to...delete...

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)

2019-01-09 Thread Frederik Ramm
Hi,

On 01.01.19 16:59, Markus wrote:
> Thanks for your comments so far! I've changed the proposed tag to
> natural=peninsula:

It would be great if you could make it clear that the tag should be used
for *small* peninsulas (peninsulae?) only, and is not intended as a
vehicle to catalogue everything that technically is a peninsula.

I fear that people will otherwise with great diligence and fun tag
things like the "Iberian Peninsula" which will not be of any use and
just lead to more relation clutter. (Cf. discussion about bays.)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


[Tagging] motorcycle tagging

2019-01-04 Thread Frederik Ramm
Hi,

the DWG has received a complaint about user ti-lo/Rtfm's introduction of
motorcycle tags.

Until 03 April, the shop=motorcycle wiki page contained this:

> The following is a proposal to put this service variety into tags:
> 
> sale=yes/brand/used/no/... - sells whole motorcycles
> rental=yes/brand/no/... - motorcycle rental
> repair=yes/brand/oldtimer/no/... - repairs / maintains motorcycles
> safety_inspection=yes/no - inspection of safety/emission regulation 
> conformance
> parts=yes/brand/oldtimer/no/... - sells motorcycle parts
> clothes=yes/brand/no/... - sells motorcycle clothes / equipment
> scooters=yes/no/only - to distinguish scooter shops, very useful in Asia
> services=... - other services this shop offers

Rtfm (which is ti-lo's account on the wiki) then removed any mention of
these tags and the word "proposal", instead added a table

> Optional (compare with "Additional keys" in shop=bicycle)
> key   values  description taginfo
> motorcycle:sales  yes/no/used sells motorbikes / used=only second 
> hand / yes;used=both new and used   
> motorcycle:rental yes/no/trailer  motorbike rental / motorbike trailer 
> rental (Both: yes;trailer) 
> motorcycle:repair yes/no  motorbike repair
> motorcycle:parts  yes/no  sells parts 
> motorcycle:tyres  yes/no  sells tyres (may also be used in combination 
> with shop=tyres)   
> motorcycle:clothesyes/no  sells clothes   
> motorcycle:type   

Rtfm proceeded to execute an undiscussed mass edit on the OSM database
which was reverted here:

https://www.openstreetmap.org/changeset/47664678

However:

* The wiki page has never been changed back
* Rtfm/ti-lo has continued to edit motorcycle shops around the world,
and whenever he touched one e.g. to change the spelling from "Harley
Davidson" to "Harley-Davidson", at the same time also replaced *all* the
old-style tags with his new-style tags again.
* ti-lo hismelf seems to be by far the most prolific user of these tags.

What we have here is not really a classical mechanical edit, but a
one-man crusade to push through their tagging scheme.

I'm not sure how to best deal with this. Normally we don't want to
over-emphasize the proposal and tag voting process and we often say "you
can just use a tag and it'll eventually be used by others too". But that
doesn't really apply to changing established tags. Even if it is for the
better - the complaint we have is really not so much about the new
tagging scheme but about the way in which it was established.

Opinions?

Should we revert the wiki page to the old version and revert all the
motorcycle:* tags that ti-lo changed from old-style to motorcycle:*?

Or ask him to run a proper proposal process until $DEADLINE under threat
of doing the above?

Or just shrug and let him have his way?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] A fool with a tool ... Vehicle service tags

2019-01-04 Thread Frederik Ramm
Hi,

I agree there seems to be a problem here that needs careful discussion &
consideration, but:

On 03.01.19 16:47, Thilo Haug OSM wrote:
> So which ACTION should we take now ?
> At least those who introduced it should be in charge.

The ACTION should definitely not be you mass-editing things back to how
you think they should be tagged. This can be discussed here and we can
make a change AFTER that, not while.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

2018-11-26 Thread Frederik Ramm
Hi,

On 11/26/18 17:00, Mateusz Konieczny wrote:
>> and I fail to see how much more
>> difficult it is to tag "boundary=protected area" and "protect_class=24" 
> 
> Because "24" is a completely random code, unlike boundary=aboriginal_lands

We generally *try* and make our data human-readable. If archaeologists
dig up an old planet file in 1000 years, then finding a tag
boundary=aboriginal_lands is more useful to them than protect_class=24.

Of course it's a far-fetched image but I find it helps making the right
decisions.

And yes, there are established things in OSM that would puzzle those
archaeolologists, like sac_scale or tracktype. Or maybe how to read a
PBF file. But we can't do all of their job for them ;)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Using multipolygons to map bays in Alaska

2018-11-17 Thread Frederik Ramm
Hi,

On 11/17/18 19:36, Kevin Kenny wrote:
> You're welcome to this particular opinion in your personal capacity and
> are free to argue the point as passionately as you care to.

Why, thank you ;)

> When you have your DWG hat on

I don't, and never had in this whole discussion.

> A minority of
> users (including myself), whose number appears to be growing, find that
> sharing boundary ways among multipolygons creates a structure that
> actually is easier to enter, edit and maintain than the one that appears
> from multiple retraced ways over the same nodes, or worse, independently
> traced ways that are approximating the same boundary in the field.

Oh yes, certainly. Of course, in the concrete example at hand,
re-tracing the whole boundary of the Gulf of Bothnia as a new way would
have been worse (and impossible due to the 2000 node limit), and not
even re-using the nodes would have been unspeakably worse.

My argument was that if you can get away with using a single node for
labelling, then you don't have to burden all those 1,400 coastline ways
with one (or two or three) extra relation memberships and that would be
preferable.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Using multipolygons to map bays in Alaska

2018-11-17 Thread Frederik Ramm
Hi,

On 11/17/18 01:51, Paul Allen wrote:
> I'd find that bad enough even had he been right in his interpretation. 
> Given how he has explained
> it so far,

...

Jumping back in here after a while, and assuming that the "he" here is
talking about me, let me offer a bit of backstory and explain why I am
unhappy about all this.

I'm doing a fair bit of map rendering myself, using a wide array of
different map styles, either self-made or made by others, and including
OSM-Carto.

OSM-Carto does two particular things with water rendering that not every
map necessarily does:

1. They use the same colour for the sea as for inland water areas.

2. They don't actually draw sea polygons; they have a blue map
background and then draw the land mass in grey on top of it.

While the wiki has been advising against rendering natural=bay in a
solid blue fill for a while (actually since Chris Hormann added a note
to that regard in January 2016), it used to make sense to disregard this
advice because you'd have many natural=bay areas that were not on the
sea but adjacent (e.g. Botany Bay used to be like that for a long time)
giving you white spots on your map otherwise. (OSM-Carto wouldn't have
this issue because their background was blue, but if you chose to have a
white map with sea polygons drawn you'd see it.)

So, long story short, a couple of "my" maps suddenly started to show
ugly dark-blue patches e.g. across the bay of Biscay, or the Gulf of
Bothnia. That's how I noticed and investigated what was happening, and I
found that Daniel had added the Gulf of Bothnia polygon to accompany the
newly-introduced OSM-Carto feature of rendering bay names depending on
the size of the area.

Of course I can adapt my map styles, and have indeed done so, as I often
have to do when mappers change their behaviour. But I was pissed off
nonetheless; I felt that OSM-Carto is just one rendering project and
does not (and should not) have the authority to steer what mappers do.
There are many other people interpreting our data and they should not be
forced to jump whenever OSM-Carto decides they want to change something.

I do agree that while we should not "map for the renderer" it is good to
have a central map that provides valuable feedback, and keeps mappers
from, say, introducing random highway types by simply not rendering
them. But I felt in this situation, they had overstepped their mandate,
*especially* because they were not reacting to something that people
were doing, but actively creating a new feature ("hey, you can now have
huge named bays") and at the same time adding the data to OSM to
illustrate their new feature.

Another pet peeve of mine is a dislike of what I call "relation mania",
where we have land boundaries that can easily be part of 20 different
relations on different admin levels and other boundary types. It's bad
enough on land, and makes editing harder for everyone; when I saw the
Gulf of Bothnia polygon (which *already* is large enough for the web
site to time out when you want to show the history) I thought: Is this
*really* necessary if all you want is a nice label written on the sea?
And let's be totally clear here: A nice label on the sea is all that
Daniel wanted. He's not a maritime scientist who for some reason needs
the exact extent of Bothninan Bay - he went through the time-consuming
exercise of combining more than 1600 coastline pieces into one huge
polygon which is difficult to handle for data processors and editors
alike JUST TO PLACE A LABEL.

It is only a matter of time until they start labelling natural=sea
polygons and people then create relations with 100,000 members for the
Atlantic.

If you are not interested in labels, then this is wrong because of the
side effects.

If you *are* interested in labels, then this is wrong because (a) it
means that you have to go through this huge exercise just to place a
label, and (b) the label will vanish as soon as someone breaks the
polygon by e.g. creating a small self-intersection along one of the 1600
coastline bits. It will probably be gone more often that it is there.

Summing up, my opinion is

(1) the OSM-Carto project and Daniel have overstepped their mandate as
the maintainers of our style, and should have sought a wider consensus
on this before acting;

(2) the decision they have made is not a good solution for the
cartographic problem they wanted to solve;

(3) the decision they have made will lead to people creating huge
polygons that will often break, make coastline editing harder, and have
at least one totally made-up edge.

And, I have to admit,

(4) Frederik has been an utter dick to try and start the discussion by
deleting the Bothany Bay polygon, instead of simply raising it here. It
was wrong, I'm sorry.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
Tagging mailing li

Re: [Tagging] Using multipolygons to map bays in Alaska

2018-11-15 Thread Frederik Ramm
Hi,

On 15.11.2018 12:08, Christoph Hormann wrote:
> I think it is good you bring this up because many mappers have been 
> doing exactly that without asking - See for example:
> 
> https://www.openstreetmap.org/way/548210592
> https://www.openstreetmap.org/way/544856564

Frankly, while I share your overall criticism of 'polygons is
universally the preferred way of mapping no matter if verifiable or not'
and 'way_area equals cartographic importance', I recently found that
someone had added a huge natural=bay relation for the Bay of Bothnia,
meticuously including every coastline way.

I deleted it here

https://www.openstreetmap.org/changeset/63455985

but not without attracting questions as you can see, and I fear that
with osm-carto as it is, this object will rise from the dead sooner or
later.

I still think that it is ridiculous to slap a ton of multipolygons onto
the coastlines (since, as I write in that discussion, many bits of water
are actually part of various bays of different scales), and a coarse
"labelling polygon" like the one discussed here would seem to me to do
*less* harm.

> Long story short:  My suggestion is and has always been to map bays with 
> nodes in those cases where this - together with the coastline - 
> perfectly documents the verifiable information available on the 
> geometry of the bay.

Agree on the node idea, but it would have to include some size signifier
(and I think someone recently tried to add a "sqm" tag to water body
nodes for that purpose which I also criticised...). I don't think you
are recommending a relation that includes the actual coastline and the
label node, but if you do then I am against that because I don't want
every coastline to be part of 10 relations in the end.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Public Transport Timetables

2018-11-07 Thread Frederik Ramm
Hi,

On 07.11.2018 14:35, Jonathon Rossi wrote:
> I've been following along the few threads to better understand this
> topic, however I'm still feeling that mapping complex timetables is a
> bit like mapping the full menu of a cafe or restaurant, or the room
> options at a hotel. These things vary whenever the service business
> chooses and it is close to impossible to keep it up to date.

Yes, that's why I continue to find that it is a very bad idea to try and
start mapping timetables.

At most, I would say let's map in coarse strokes how frequent a service
is (which is still something that is subject to change at the operator's
whim but maybe not as often).

Anything beyond that is madness and should not be in OSM. I just don't
want to say it every time someone enthusiastically posts in this thread,
and of course they can try it out - but as Andy Townsend said, I'd
suggest a serious trial first, and *then* attempts at standardisation,
instead of the other way round.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Public Transport Timetables Proposal RFC

2018-10-31 Thread Frederik Ramm
Hi,

On 31.10.2018 00:54, Leif Rasmussen wrote:
> I recently wrote up a proposal page for public transport schedule data. 
> This information would allow OpenStreetMap to store information about
> when or how often certain buses or trains arrive at a platform. 

Surveying that is hard, and the results only valid for half a year or a
year at best.

Copying the information may violate a third party's database right, and
also burdens OSM with dead data that will not be properly maintained.

Therefore I don't think public transport schedules have a place in OSM.

One thing we could investigate is some sort of indication whether a bus
or train route tagged in OSM is frequent, infrequent, or rarely used -
but we'd have to find a classifier for this that is vague enough to not
change twice a year, and precise enough to still be useful (and e.g.
draw "infrequent" lines with a dashed color on a public transport map or
so).

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Feature Proposal - RFC - (consulate)

2018-10-27 Thread Frederik Ramm
Hi,

On 27.10.2018 11:57, Eugene Alvin Villar wrote:
> Tagging something as office=diplomatic then diplomatic=non-diplomatic
> sounds silly and oxymoronic. Why not simply diplomatic=other? Also we
> should allow diplomatic=yes if the mapper doesn't know the exact type.
> Therefore diplomatic=[embassy, consulate, other, yes].

Would "yes" not be implied already by office=diplomatic? If someone
wasn't sure they could just use office=diplomatic without diplomatic=*.

(Side note, I've seen diplomatic offices that were so cordoned off by
local security forces that you wouldn't even come close enough to
determine whether this is a government facility or a diplomatic one. Of
course you can always ask the guards but maybe that only makes you
suspicious ;)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Out of the bars and onto the map: An lgbtq:*=* tagging scheme?

2018-10-24 Thread Frederik Ramm
Hi,

On 23.10.2018 20:27, Rory McCann wrote:
> So to start off, I'm suggest a simple "lgbtq=yes" tag to
> mean "this thing is a LGBTQ thing". 

Bit difficult perhaps since usually "blah=yes" means that blah is
available or blah is permitted, not that the place is mostly/exclusively
for blah.

(e.g. smoking=yes, bus=yes, vegan=yes)

Conversely, in your definition an "lgbtq=no" would then mean that the
place is *not* specifically an lgbtq place; many users could, however,
misread lgbtq=no (which would be a valid tag for the majority of places
since they don't specifically cater to lgbtq people) as "this place does
not admit lgbtq people" (which is probably/hopefully true only for a
very small number of places).

Sadly I do not have a good suggestion. You don't want "lgbtq=only" since
usually an lgbtq bar *will* admit straight people (unless they're a hen
party maybe). You'd need something like "lgbtq=mainly" - which would
still not be exactly what you were looking for since it talks about who
goes there in practice, not whom the place tries to attract. Perhaps
"lgbtq=designated" combined with "straight=yes" ;)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


[Tagging] Upcoming removal of power=station and power=sub_station in the standard style

2018-10-22 Thread Frederik Ramm
Hi,

On 10/22/18 11:03, François Lacombe wrote:
> Even if sub_station is often 1:1 of substation, this have to be replaced
> carefully since objects can have been mis tagged as power=sub_station.
> In France, last objects where removed this summer. There was about 150
> of them and it was not so hard to review each one.

I think a manual review is certainly better than an automated
conversion. If an object uses a tagging scheme that has long since been
replaced with a new one, maybe the object itself has also ceased to
exist, or demands some kind of change.

Manual review may be slower but yields a higher-quality result.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Opening hours too long for OSM

2018-10-12 Thread Frederik Ramm
Hi,

On 10/12/2018 12:54 PM, Tobias Knerr wrote:
> I agree that this problem calls for a general solution, as it's not
> specific to opening hours.

The "problem" in my eyes is people even wanting to store more than 255
characters in a tag value. Don't do it.

Yes I can see how use cases can be constructed that "need" this but I
think it is perfectly ok that some things cannot be mapped in 100%
detail. Just like we have a limited resolution (of about one
centrimetre) and we're usually happy to approximate a curve with a few
nodes and not 100. Do we *really* need to record when a shop is open
8-18h except on the third Wednesday in even months, if that Wednesday
does not happen to be before or after a public holiday?

Or can we afford to just skip mapping that detail?

> We need to make sure that this can be implemented in a key-agnostic
> manner, though

Why, so that people are free to invent any number of keys to hold
arbitrary length values? Reality check! Tags are supposed to be readable
and writable by human beings. If you find you need > 255 characters to
describe opening hours, then you've left that terrain already. Why not
write Tobias' original example as

H4sIABrJwFsAA/MqzdMNTi2wUvDN1w1OVDA0sDIw0DW0AJLWXF4wueBSmIQRWMIvv0zXN7EIpEkn
pFQnJEPHrQhZhY6CoSmYY46qHGEBxBzHgiKgRCXYcmQTjA10oAZYoKpDNsAYRQLNhf7JJQRNBatB
NxEiiGIaFwARtRivJAEAAA==

then, only takes 179 bytes ;)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Traffic_sign discussion

2018-10-09 Thread Frederik Ramm
Hi,

On 10/09/2018 05:42 PM, yo paseopor wrote:
> It is not the first attempt to do that. Last days, with iD
> implementation and my message I have think it was the solution. Also I
> have waited some days and communicate to this list my intentions to
> adopt the proposed iD scheme. But when I start to do the
> modifications... People complains about it (I am sorry if there was some
> errors "translating" to the new scheme).

Yes, DWG has also received complaints about these edits, and I am in the
process of reverting them.

At the very least you should have established a consensus on this list
for the precise edit you want to perform. You should have said: I am
going to load objects tagged so-and-so, and I am going to apply these
modifications using these tools.  (consensus doesn't mean everyone has
to be in favour, but you simply went ahead and changed things and wrote
in your changeset comment "#fastag #traffic_signs Apply
traffic_sign:direction tag to avoid problems with new iD editor as an
agreement on tagging list" which almost sounds like you were fixing a
bug and there was consensus, neither of which is strictly true.

I'm not saying these edits cannot ever be made, but they can certainly
not be made in a buggy fashion after a half-hearted attempt at
discussion with no discernible outcome.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] My "weirdly unnatural aversion to relations"

2018-09-30 Thread Frederik Ramm
Hi,

On 30.09.2018 05:00, Bryan Housel wrote:
> From my own perspective as the main developer on the main editor for
> OSM, 

... fsvo "main editor" ;)

> I’m willing to bet a black hat
> could design and upload a relation that would destroy OSM.. Or at least,
> crash every piece of software in the stack that we rely on:  mapnik,
> osmium, and any editor that tries to touch it.  

Relation 7066589 came close. (And no, you won't be able to access its
history through the web site, it will time out.) See
https://github.com/openstreetmap/osm2pgsql/issues/713 for background -
osm2pgsql had to be patched as a result.

> Anyway, I’m not totally against them, but every one of them is different
> and I can't spend weeks or months supporting every kind of relation or
> public transport schema people dream up unless it’s super critical for
> building a useful map (like turn restrictions).

The idea that turn restrictions are "super critical" but public
transport relations are not is valid, but subjective; I hope that, as
the ID editor matures, it will attract a healthy and diverse team of
main developers so that decisions about what is important and what isn't
are not a single person's any more!

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Draft Proposal: Default Langauge Format

2018-09-26 Thread Frederik Ramm
Hi,

On 09/26/2018 05:53 PM, Christoph Hormann wrote:
> Names in a non-discernible language have so far not been discussed.  I 
> would need to see some examples for this to form an opinion on the 
> matter.  

I am thinking of retail outlets like

"Tesco"

"Real"

"Saturn"

"Tk-Max"

>> Yes. The unified system goes as follows:
>>
>> "If the default language of the smallest admin boundary enclosing
>> your feature is xx, treat any name tag you encounter as if it was a
>> name:xx tag."
> 
> That would change the meaning of the name tag which is currently "the 
> locally used name or names in some combination" into something 
> different. 

I disagree. My assumption is currently that a name tag in Germany will
be the German name, and I think for all countries or regions with one
prevalent language this will be everyone's assumption (that if the
region has a default language, the name will be the name in the default
language).

But I am willing to extend my definition:

"If the default language of the smallest admin boundary enclosing
your feature is xx, treat any name tag you encounter as if it was a
name:xx tag, unless an explicit name:xx tag exists."

That should pretty much catch everything and give everyone the
flexibility to map all special cases, while not requiring to re-tag
every single named object all over the planet.

(You will only have to re-tag those objects where the name is in a
language different from the prevalent language in the region, and where
you perceive this to be an issue - as you said yourself, the damage done
by assuming that the "O sole mio" assigned to a pizzeria in Germany is a
German rather than an Italian name, is negligible.)

> I see your point but as said this would defeat the whole purpose of the 
> idea

If that is the case, and no workaround can be found because every
workaround would defeat the purpose of the idea, then I would likely
oppose the idea.

I think that generally a more precise recording of languages is
desirable but if this leads to having to duplicate existing name tags
into name:xx for every single named place on earth just in order to "not
defeat the purpose", then I'd like to pass on this idea and wait until a
less intrusive one comes along.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


[Tagging] Draft Proposal: Default Langauge Format

2018-09-26 Thread Frederik Ramm
Hi,

On 26.09.2018 16:14, Christoph Hormann wrote:
> Also in Germany we have features with no German name (most notably 
> probably in regions with significant minority languages but also for 
> example some English shop names, Italian restaurant names etc.)

You are not *really* advocating that when passign an Italian restaurant
called "O sole mio" I am expected to tag this with name:it and not give
it a proper name tag, are you? Because then I'll promptly point you to a
series of places that have a name the language of which is not
discernible...

> The whole point of a concept like the one proposed here is to have a 
> unified system that transparently covers all cases

Yes. The unified system goes as follows:

"If the default language of the smallest admin boundary enclosing your
feature is xx, treat any name tag you encounter as if it was a name:xx tag."

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Draft Proposal: Default Langauge Format

2018-09-26 Thread Frederik Ramm
Hi,

On 26.09.2018 12:00, Christoph Hormann wrote:
> But the good news is that both the proposal of Joseph and my suggestion 
> would allow a simple an reliable fallback to the current tagging scheme 
> so once most data users are capable of interpreting the new scheme you 
> could smoothly convert the tagging feature by feature without  
> duplication and without a negative effect on usability.
> 
> The big problem of this approach however is that you would need to 
> convince data users to implement interpretation of a new tagging system 
> up-front without the database containing significant amounts of data 
> where this would be useful for.  This is not just buying the cat in a 
> sac, it is like building a home for the cat without having seen it yet.

Isn't it so that the new system adds zero usefulness to countries or
areas which have and use just one language, but is useful in regions
that have more than one? Hence, why roll it out in, say, most parts of
Germany *at all*, and just stick to parts where several languages are used?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


[Tagging] Draft Proposal: Default Langauge Format

2018-09-26 Thread Frederik Ramm
Hi,

On 26.09.2018 04:49, Joseph Eisenberg wrote:
> There have been a few small updates to the proposal page based on your
> suggestions in the past week.
> Please comment on the talk page if you have any further ideas or
> criticisms:

I added a comment on avoiding duplication - I would be very unhappy if
every feature on the planet that currently only has a name tag would now
be amended with an identical name:xx tag just because xx is the language
spoken in that country!

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Fwd: OSM Wikibase is now live

2018-09-18 Thread Frederik Ramm
Hi,

On 18.09.2018 11:43, Yuri Astrakhan wrote:
> Key:bridge:movable:    https://wiki.openstreetmap.org/wiki/Item:Q104

Could you make a banner across the top of that page that clarifies that
this is just a copy of information found elsewhere, and that changing
the content of Q104 will not change the wiki?

I fear that people might otherwise start editing there and then the
Wikibase stuff would go out of sync with the rest of the wiki (which
will likely remain the "authoritative" part for quite some time).

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Mapping language borders, tagging offical languages?

2018-09-14 Thread Frederik Ramm
Hi,

On 14.09.2018 04:43, Joseph Eisenberg wrote:
> It would be useful to tag the primary language of wider communication in
> a place, because this information is already implicit in the names of
> places but hard to access.

See also a longer thread on this list from April:

https://lists.openstreetmap.org/pipermail/tagging/2018-April/035855.html

> The most complicated issue would be areas where local languages do not
> relate to existing boundaries. 

Yes, and I would like to avoid introducing tons of new hardly-verifiable
boundary relations for that. OSM suffers from being unable to define
fuzzy boundaries and they would be necessary here.

Hence

> 2) Tag each inhabited place with a language.

seems a more sensible idea to me.

I would like to caution against westerners "helpfully" defining the
"primary" language for any place other than where they live though, we
have too much accidental cultural imperialism already. Let people all
over the world be agents of their own map, and define what *they* think
the locally used languages are, rather than "help" them understand their
own culture.

As you rightly say,
> It is certainly possible for a local mapper to verify the majority
> language spoken in their own community and neighboring settlements

where "local mapper" is the important term. (Also, let us not
accidentally roll out the concept of *one* "primary" language, which
will only cause the same kinds of conflict as the "one primary name" we
already have - many languages could share the first rank of importance.)

> However, it would be more work to add tags to each
> place=hamlet/village/town/neighborhood than to tag a single boundary line.

I'd go for a mixed approach - tag the (largest useful) administrative
boundary first, and then allow lower level admin boundaries and finally,
place nodes, to override the default. Requires a little more brains to
evaluate but we can really do without another world-wide mass edit where
someone adds an obvious "primary language" tag to every settlement.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


[Tagging] building:structure

2018-08-16 Thread Frederik Ramm
Hi,

I accidentally discovered that the little-documented tag
"building:structure" has a significant proportion of misspelled values
(the most common value is "confined_masonary"):

https://taginfo.openstreetmap.org/keys/building%3Astructure#values

However, not being knowledgeable about buildings myself, nor interested
in researching how this issue came about, I'm just dropping this here
for an interested party to pick up, or not.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] place nodes for continents?

2018-08-07 Thread Frederik Ramm
Hi,

On 07.08.2018 10:04, Ilya Zverev wrote:
> It is a strange question, which can be applied to virtually anything in
> OSM. Potholes — are they useful?

Ok, I'll re-word:

How is a continent node verifiable, especially with regards to its
position? What is our plan if two people should start edit-warring about
whether the continent node should be at 51.002, -109.002 (as it
currently is), or rather at 51,-109 or at 50,-108?

Representing a tree or a pothole with a node is not exact either, but
it's more or less within the accuracy of our available measurement
devices. Representing a city with a node is much less accurate, but
people seem to agree for most cities, placing the city node in the heart
of the old city, or where the city hall is, or some such.

Do we really want to approximate whole continents with a point, and if
we do, where is that point to be placed?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


[Tagging] place nodes for continents?

2018-08-07 Thread Frederik Ramm
Hi,

place nodes for continents - are they useful?

https://www.openstreetmap.org/node/36966063

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] psychics (was: tagging religion-based access)

2018-07-05 Thread Frederik Ramm
Hi,

On 07/05/2018 12:59 AM, Jmapb wrote:
> So I was considering changing them to
> shop=fortune_teller. 

But doesn't the average psychic offer more than just fortune telling?
Relationship counselling, crime detection, treasure hunting, mind
reading, supernatural business consulting...

I would have suggested shop=snake_oil but I fear that's a little too
narrow too ;)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] Official OSMF editor (was: emergency=lifeguard)

2018-06-21 Thread Frederik Ramm
Martin:
> The operation of the OSMF editor should not be in conflict with the
> OSMF mission. 

Bryan:
> iD is not an “OSMF editor”.  I literally have nothing to do with OSMF.

Bryan is right; iD is an independent project and not controlled by the OSMF.

iD is, of course, afforded considerable status by the OSMF putting it up
as their main in-browser editor. The OSMF could choose to afford this
status to another editor, or to a forked and community-curated version
of iD that replaces Bryan's tag design decisions by something else, but
I don't currently see anything present itself.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] emergency=lifeguard

2018-06-19 Thread Frederik Ramm
Hi,

On 19.06.2018 14:16, Christoph Hormann wrote:
> seems to be quite the opposite of that approach.  Now i know of course 
> an editor and its presets is not the same as a map style but still it 
> seems important to have some objective goals and criteria for decisions 
> regarding presets, especially if you present addition, change or 
> removal of presets as pre-planned steps in a process to change tagging.

Perhaps it would make sense to treat the iD editor and the tagging
presets it uses as two different projects that are conceptually separate
enough so that the tagging presets as rolled out on osm.org can be
curated by a group that is separate from the editor writers?

I don't think designing tags is what the editor writers should do, that
would clearly be overstepping their mandate.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] New GitHub tagging repo "osmlab/osm-tagging" - was: emergency=lifeguard

2018-06-18 Thread Frederik Ramm
Hi,

On 06/18/2018 03:37 PM, Bryan Housel wrote:
> I think we should continue to make sure that every change
> is raised on the tagging mailing list for WWIC [1] reasons.

Using mailing lists provides no immunity against "WWIC", but it is
certainly safer than Github for the time being (who knows, there might
be a time when people sign up to Github before they do email, and their
friends open an issue when they want to meet up for drinks but we're not
quite there yet).

Jokes aside, there are many serious reasons why good old-fashioned
mailing lists should be the mainstay of important communication in OSM.
For me, the greatest plus is that mailing lists are not controlled by
(and at the whim of) business interests. Others have qualms about
signing up to an American social network platform just to participate in
OSM discussions (remember - if the product is free, you are the
product). Others again might prefer the accessibility offered by email,
where it is relatively straightforward to have a 100% voice based
interface, and so on.

So yes, +1 to keeping the discussion on email - documenting results on
Github is ok, but trying to move the decision-making there would be
problematic.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Tagging] The endless debate about "landcover" as a top-level tag

2018-06-08 Thread Frederik Ramm
Hi,

it is a gut reaction by people when forced with difficult issues to call
for strong leadership to solve them once and for all. OSM is no exception.

On 08.06.2018 01:29, EthnicFood IsGreat wrote:
> I wouldn't mind if all the existing tags were replaced tomorrow with a
> brand new set of "intelligently-designed" keys. 

Designed by... a visionary leader? A board of experts? A random draw?
And if something turns out to be designed wrongly, how will it be
challenged?

> And I wouldn't mind if
> these keys were enforced from now on.

Not having an enforced set of keys and values was definitely a big part
of OSM's success (there *were* competing projects which got stuck trying
to define the one true set of keys and values that would work for
everything).

Some people say that while this may be true, the time has now come to
get rid of the old ways that got us where we are, and change tack to
something more conservative. This is a valid argument but I am not
convinced; a lot of innovation is still going on with tags, and strict
enforcement would run the risk of killing that.

> Someone some time ago on one
> of the OSM mailing lists summed up the current situation by stating, "It
> seems OSM is incapable of moving forward." 

OpenStreetMap is becoming a larger group of more diverse people with
more diverse interests, and since we don't - and don't aim to - have a
dictator at the top, things need to be done by consensus. These people
who take to the internet complaining about how OSM is incapable of
moving forward usually are people who are unwilling, or unable, to
convince the "great unwashed" their idea of "forward" is a good thing.
So they lament the lack of leadership and complain about "gatekeeping",
but it's really just them being unable to do the work required to
establish consensus in a large project.

Because that takes much more than a couple of blog posts (cf. the
license change).

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


  1   2   3   >