[OSM-talk] Deprecated feature template in the wiki

[Tigerfell via talk]

Hi Martin,

The icon for "deprecated" template was discussed at 
https://wiki.openstreetmap.org/wiki/Template_talk:Deprecated#Image . Citing 
myself: "I would suggest to change the image to an icon that symbolizes the 
word 'deprecated' more. This would help those mappers who use data items 
<https://wiki.openstreetmap.org/wiki/Data_items> like the tag information 
included in iD."

Cheers,
Tigerfell


Jun. 11, 2020, 13:00 by talk-requ...@openstreetmap.org:

> On 10. Jun 2020, at 14:58, Mateusz Konieczny via talk <
>
>> talk@openstreetmap.org> wrote:
>> "Why is the definition for the tag removed" it never had a good definition.
>>
>>
>
> the former definition was
>
>> A large water tank, typically cylindrical
>>
>
>
>
> personally I would also have suggested a different definition based on
> function (sth like container for storing water, or actually go for liquids
> and storage tank), not on size and shape (large, cylindrical), nonetheless
> it is a valid definition. And in general, if the definition is constructed
> in an ambiguous or otherwise unfortunate manner (or absent), it still
> mustn’t be removed, it still serves mappers to form a decision whether they
> want to follow the suggested alternative tags or apply this tag.
>
>
> Why should someone not " (semi-)automatically change “deprecated” tags to
>
>> something else in the database""
>>
>> https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
>>
>>
> it was rhetorical, how can you decide without knowing the meaning of all
> the alternatives, in particular the tag you were looking up?
>
>
>
>> "I also believe replacing the tag image with this one"
>> From looking through history this page never had an image anyway.
>>
>>
> no need to replace or put a picture like this, excessive. There is already
> a red box with a deprecation warning throning above, the Hand says: STAY
> AWAY!!!
> while the formerly used exclamation mark was calling for your attention. It
> is quite a change in paradigm.
>
>
> Cheers Martin
>

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

[OSM-talk] Proposed new favicons for OSM's subdomains

[Tigerfell]

Dear mappers,

There is currently a ticket [1] in the GitHub repository of the Operations 
Working Group proposing to change the favicons (the little icons displayed next 
to the browser tabs) of multiple subdomains of osm.org (forum, wiki, help, 
...). Please feel free to join in or comment via the list!

Short explanation: It is proposed to choose one mono-coloured icon for all 
subdomains and assign a distinct colour for each subdomain, so the users can 
discriminate between multiple tabs in their browsers, but they would still see 
that they are somehow related to each other. The main webpage openstreetmap.org 
would keep its current icon. 

Cheers,
Tigerfell

[1] https://github.com/openstreetmap/operations/issues/248 
<https://github.com/openstreetmap/operations/issues/248>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-transit] Old Railways

[Tigerfell]

Maybe, the OpenRailwayMap mailing list openrailway...@openrailwaymap.org 
 might be helpful? I can not access 
their archives so I do not know if it is active, but it might be worth a try.


May 18, 2019, 10:55 p.m. by nice...@att.net:

> Tim,
>  This is a good point, but what if OpenRailwayMap were able to pull from 
> OpenHistoricalMap to generate a complete picture of the network? I say 
> 'picture' because it wouldn't be connected for routing purposes, but it 
> should appear connected on a map tile.   I have no idea how much additional 
> work that would be for OpenRailwayMap to show.
>
> On 5/18/2019 11:40 AM, Tim Saunders wrote:
>
>> I suspect I am a lone voice but I don't agree.� The thing that 
>> differentiates railways from a lot of historical features is they form a 
>> network, some if which is still an operating railway and a lot of which is 
>> still visible in the ground.� Having the extant sections in one database 
>> and the razed/dismantled sections in another is just making it unnecessarily 
>> complex to form a picture of the entire network, which for the sake of a few 
>> additional ways on OSM (which I agree would not generally be rendered) can 
>> be easily solved.
>>
>> Regards,
>>
>> Tim Saunders
>>
>
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-transit 
> 
>

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

[OSM-talk] [Wiki] Proposed wiki policy - Voting - Deletion policy

[Tigerfell]

Dear fellow mappers,

We would like to invite you to voting in the case of the proposed Deletion 
policy for wiki pages and files [1]. 

As you might have noticed, there were conflicts based on requests to delete 
wiki pages and especially drafts of proposals. One of the arguments in favour 
of deletion was avoiding confusion and clutter. The other side argued basically 
that they wanted to keep everything as all of the fragments ensemble 
OpenStreetMap's history. Based on the input of several contributors, we drafted 
a deletion policy over the span of two and a half months. 

Among other things, the policy proposes a centralised discussion page for all 
cases which are not mentioned explicitly. 

Kind regards,
Tigerfell

[1] https://wiki.openstreetmap.org/wiki/OpenStreetMap:Deletion_policy 
<https://wiki.openstreetmap.org/wiki/OpenStreetMap:Deletion_policy>
 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Software configuration | Re: iD influencing tagging

[Tigerfell]

I am pretty sure you can protect data items.

The cited template is transcluded into more than 380,000 pages. The most often 
transcluded template in the OSM wiki is used on about 78,000 pages. I do not 
think that a full protection was considered necessary, because we wanted to 
keep the wiki open and I can not recall an incident yet.

Of course we can discuss about locking everything down that could cause 
problems, but that would oppose the idea of an openly editable OpenStreetMap 
and it would be hard to explain that the docs are protected while everyone can 
just delete some area in the map.

I think the general move of Yuri is right (generalising and opening the machine 
readable docs for the community) and I appreciate that. Doing so also prevents 
accusations against developers as discussed initially.

Tigerfell


Apr. 11, 2019, 11:30 a.m. by mark+...@carnildo.com:

> On Thu, 11 Apr 2019 03:17:27 -0400
> Yuri Astrakhan <> yuriastrak...@gmail.com <mailto:yuriastrak...@gmail.com>> > 
> wrote:
>
>> On Thu, Apr 11, 2019 at 2:10 AM Mateusz Konieczny
>> <>> matkoni...@tutanota.com <mailto:matkoni...@tutanota.com>>> > wrote:
>>
>> > * easy to edit by community
>> >
>> > I am dubious whatever "anybody can
>> > edit any preset stored as wikidata
>> > items" will be considered as benefit
>> > 
>>
>> One could also doubt that allowing direct OSM and Wikipedia edits by
>> anyone would be considered as a benefit... But it does, doesn't it?
>> Worst case scenario: someone breaks a preset - with so many eyes on
>> them (exposed via wiki pages, used by all editors, monitored via
>> numerous tools, cross-checked by validation queries, etc etc etc), it
>> will be fixed within minutes.
>>
>
> Wikipedia is a good comparison, but not in the way you intended it.
>
> Wikipedia has special permissions for changing widely-used
> templates or the website interface itself: the "template editor" and
> "interface administrator" permissions.  An ordinary editor can only
> mess up one article at a time, while a template editor can mess up a
> half-million articles in a single go, and an interface administrator
> can vandalize every page on Wikipedia at once.
>
> If someone breaks the preset for something like "building=yes", then
> sure, it'll be spotted and fixed in a matter of minutes.  But in the
> meantime, there'll be hundreds of mis-tagged buildings, many of them in
> places that nobody will review for years.
>
> -- 
> Mark
>
> ___
> talk mailing list
> talk@openstreetmap.org <mailto:talk@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk 
> <https://lists.openstreetmap.org/listinfo/talk>
>

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

Re: [OSM-talk] Congratulations everyone!

[Tigerfell]

Yes, there is https://wiki.openstreetmap.org/wiki/Awards_for_OpenStreetMap 



Mar. 25, 2019, 1:18 p.m. by a...@pigsonthewing.org.uk:

> On Sun, 24 Mar 2019 at 06:49, Kate Chapman <> k...@maploser.com 
> > > wrote:
>
>> Today the OpenStreetMap project won the Award for Projects of
>> Social Benefit from the Free Software Foundation. This was
>> awarded at LibrePlanet.
>>
>
> That's great news.
>
> Do we have a page on the wiki to record such things? The page at:
>
>  > https://wiki.openstreetmap.org/wiki/Awards 
> 
>
> is used for something else (and should perhaps be usurped).
>
> -- 
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk 
>
> ___
> talk mailing list
> talk@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk 
> 
>

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

[OSM-talk] [Wiki] RFC - Deletion policy

[Tigerfell]

Dear fellow mappers,
 We would like to invite you to participate in drafting a deletion policy for 
wiki pages. As you might have noticed, there were conflicts based on requests 
to delete wiki pages and especially drafts of proposals. One of the arguments 
in favour of deletion was avoiding confusion and clutter. The other side argued 
basically that they wanted to keep everything as all of the fragments ensemble 
OpenStreetMap's history. Based on the input of several contributors, we drafted 
a deletion policy over the span of one and a half months. 
 Even though it is not absolutely complete yet, we would appreciate your 
feedback. 
The draft is currently located at 
https://wiki.openstreetmap.org/wiki/User:Tigerfell/Crafting 
<https://wiki.openstreetmap.org/wiki/User:Tigerfell/Crafting>
 
Kind regards,
Tigerfell
(on behalf of all participants of the discussion)

PS: You can find the previous process for deleting at 
https://wiki.openstreetmap.org/wiki/Delete 
<https://wiki.openstreetmap.org/wiki/Delete> if you want to compare them. 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-transit] Updating wiki with new keys (was: Re: New Key "Interval")

[Tigerfell]

Thank you for updating. I think the page 
https://wiki.openstreetmap.org/wiki/Public_transport 
<https://wiki.openstreetmap.org/wiki/Public_transport> was missed however. 
Tigerfell

Jan. 4, 2019, 4:33 p.m. by 354...@gmail.com:

> Thanks for suggestion this!  
> I have updated all of the wiki pages you sent to include the key "interval".  
> I also added "duration" as an option to some of the pages missing that key.
> Leif Rasmussen
>
> On Thu, Jan 3, 2019 at 7:59 AM Noémie Lehuby <> noemie.leh...@zaclys.net 
> <mailto:noemie.leh...@zaclys.net>> > wrote:
>
>>
>>
>> Hi,
>>
>> Before we move on to the next proprosal, can you please also update the 
>> according pages in the wiki in English so we can start translating the doc 
>> about this new tag ?
>>
>> I think we need to mention the new key in these pages at least:
>> https://wiki.openstreetmap.org/wiki/Relation:route#Tags 
>> <https://wiki.openstreetmap.org/wiki/Relation:route#Tags>
>> https://wiki.openstreetmap.org/wiki/Relation:route_master#Other_useful_tags 
>> <https://wiki.openstreetmap.org/wiki/Relation:route_master#Other_useful_tags>
>> https://wiki.openstreetmap.org/wiki/Tag:route%3Dferry#Tags_to_use_in_combination
>>  
>> <https://wiki.openstreetmap.org/wiki/Tag:route%3Dferry#Tags_to_use_in_combination>
>> https://wiki.openstreetmap.org/wiki/Tag:route%3Dbus 
>> <https://wiki.openstreetmap.org/wiki/Tag:route%3Dbus>
>> https://wiki.openstreetmap.org/wiki/Buses#Step_2_-_Create_the_new_bus_relations
>>  
>> <https://wiki.openstreetmap.org/wiki/Buses#Step_2_-_Create_the_new_bus_relations>>>
>>  https://wiki.openstreetmap.org/wiki/Tag:route%3Dsubway 
>> <https://wiki.openstreetmap.org/wiki/Tag:route%3Dsubway>
>> https://wiki.openstreetmap.org/wiki/Tag:route%3Dtram 
>> <https://wiki.openstreetmap.org/wiki/Tag:route%3Dtram>
>> https://wiki.openstreetmap.org/wiki/Tag:route%3Dtrain#How_to_tag_a_train_relation_.3F
>>  
>> <https://wiki.openstreetmap.org/wiki/Tag:route%3Dtrain#How_to_tag_a_train_relation_.3F>
>>
>> nlehuby
>>
>>
>>
>>> Date: Wed, 2 Jan 2019 19:49:08 -0500
>>>  From: Leif Rasmussen <>>> 354...@gmail.com <mailto:354...@gmail.com>>>> >
>>>  To: >>> talk-transit@openstreetmap.org 
>>> <mailto:talk-transit@openstreetmap.org>
>>>  Subject: [Talk-transit] New Key "Departures"
>>>  Message-ID:
>>>  <>>> 
>>> CADcEzcbxxu5=g3hkzkokarp-1bpndgrrov1pa_vs1grm6o0...@mail.gmail.com 
>>> <mailto:CADcEzcbxxu5=g3hkzkokarp-1bpndgrrov1pa_vs1grm6o0...@mail.gmail.com>>>>
>>>  >
>>>  Content-Type: text/plain; charset="utf-8"
>>>  
>>>  The new key "interval" for adding the departure times interval of a public
>>>  transport route was recently approved after two weeks of voting.
>>>  I have created a new wiki page to document this key:
>>>  >>> https://wiki.openstreetmap.org/wiki/Key:interval 
>>> <https://wiki.openstreetmap.org/wiki/Key:interval>
>>>  
>>>  Full schedule information, however, is still impossible.  I originally
>>>  proposed using "timetable relations" to add full schedule information to
>>>  routes.  I have since realized that this would be a disaster just waiting
>>>  to happen.
>>>  I have now simplified the proposal to be easier to add and maintain, while
>>>  still keeping most of the same information in the database.
>>>  
>>>  The key "departures" is my solution to keeping timetables simple and easy
>>>  to maintain.
>>>  
>>>  >>> 
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_schedules/Departures
>>>  
>>> <https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_schedules/Departures>
>>>  
>>>  I would love feedback to help make this proposal work for everyone.  I
>>>  know that for many bus routes, it would be impossibly difficult to add (and
>>>  maintain) full schedule information.  Those routes should therefore only
>>>  include the tag "interval".  Others, however, including many ferry routes,
>>>  would be very easy to add schedule information to.
>>>  
>>>  Thanks,
>>>  Leif Rasmussen
>>>

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

[Talk-de] Abstimmung verlängert: "Empfehlung zur Verwendung von Multipolygonen"

[Tigerfell]

Hallo,

auch in den letzten Tagen haben noch viele Mitstreiter ihre Stimmen zu diesem 
Proposal abgegeben. Ich sehe eine Zustimmung von über 60%, aber auch starke 
Gegenargumente und möchte deshalb alle, die sich für dieses Thema auch nur 
ansatzweise interessieren können, bitten ihre Meinung abzugeben, sodass ein 
möglichst repräsentatives Stimmungsbild entsteht. Folglich werde ich den 
Abstimmungszeitraum bis zum 1. Januar 2019 (einschließlich) verlängern.

Das Proposal findet sich im Wiki: 
https://wiki.openstreetmap.org/wiki/DE:Proposed_features/Empfehlung_zur_Verwendung_von_Multipolygonen
 
<https://wiki.openstreetmap.org/wiki/DE:Proposed_features/Empfehlung_zur_Verwendung_von_Multipolygonen>

Dieses Proposal weist zwei Besonderheiten auf: zum einen bezieht es sich 
ausschließlich auf Deutschland und zum anderen ist es als Empfehlung 
formuliert. Das bedeutet, dass es unter Umständen in Einzelfällen sinnvoll sein 
kann, nicht diesem Proposal zu folgen. Ein solches Vorgehen sollte aber 
begründet werden können.

Eine sehr umfangreiche Diskussion findet sich im Forum: 
https://forum.openstreetmap.org/viewtopic.php?id=64439 
<https://forum.openstreetmap.org/viewtopic.php?id=64439>

Wesentliche Diskussionspunkte im Forum:
Motivation: https://forum.openstreetmap.org/viewtopic.php?pid=725141#p725141 
<https://forum.openstreetmap.org/viewtopic.php?pid=725141#p725141>
möglicher Konflikt mit "on the groud mapping": 
https://forum.openstreetmap.org/viewtopic.php?pid=729026#p729026 
<https://forum.openstreetmap.org/viewtopic.php?pid=729026#p729026>
"Verklebte" Multipolygone schädlich?: 
https://forum.openstreetmap.org/viewtopic.php?pid=729019#p729019 
<https://forum.openstreetmap.org/viewtopic.php?pid=729019#p729019>
Von der Empfehlung abweichende Einzelfälle: 
https://forum.openstreetmap.org/viewtopic.php?pid=727561#p727561 
<https://forum.openstreetmap.org/viewtopic.php?pid=727561#p727561>
Nicht zusammenhängende Teile von Multipolygonen: 
https://forum.openstreetmap.org/viewtopic.php?pid=729828#p729828 
<https://forum.openstreetmap.org/viewtopic.php?pid=729828#p729828>
Das sind sicher nicht alle Punkte...

Viele Grüße
Tigerfell
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Feature Proposal - Abstimmung von "Empfehlung zur Verwendung von Multipolygonen"

[Tigerfell]

Ich werde in dieser E-Mail versuchen auf viele Punkte einzugehen:
Christoph Hormann (23.11.):
> "Vielleicht als Ratschlag für die Verfasser dieser Vorschläge:  Versucht
das einfach so zu formulieren, dass für Norbert Neumapper klar ist, was
ihr von ihm möchtet - ohne sich Gedanken über die genaue Bedeutung von
Wörtern wie 'nötig' und 'überschaubar', Wortneuschöpfungen
wie 'MP-Teppiche' oder pseudo-englische Begriffe wie 'Outer-Way'
oder 'Inner-Ringe' zu machen."
Man kann darüber sicherlich diskutieren, ich sage dazu aber nichts und verweise 
in diesem Fall auf die Nutzer "Nakaner" und "Pfad-Finder", von denen ich diese 
Textabschnitte übernommen habe. 

Christoph Hormann (27.11.):
> "Ich denke insbesondere, dass das Konzept von Punkt 2 und 3 (Regel und 
Ausnahme) sehr verwirrend sein kann, denn es gibt in OSM relativ klare 
Konventionen, was für Arten von Geometrien geteilt werden dürfen und 
welche nicht.  Diese Konventionen haben nur sehr begrenzt etwas 
mit "One feature, one OSM element" zu tun." 
Nun, da diese mir diese Konventionen nicht bekannt sind, konnte ich sie nicht 
einfügen (das klingt dreist, entspricht aber tatsächlich der Wahrheit).

Wikiuser Flohoff (4.12.):
> "Es fehlt der Nachweis das dieses ein weit verbreitetes Problem ist. Ja - es 
> gibt regionale Häufungen die von einigen wenigen Mappern verursacht worden 
> sind. Es ist aber kein "Massenphänomen". Diesewenigen Mapper wird man auch 
> nicht "bekehren" können."
Die Tatsache, dass etwas möglicherweise nicht weit verbreitet ist, schließt 
eine Regelung nicht aus. Durch die vielen Kommentare habe ich den Eindruck, 
dass die Angelegenheit vielen Beitragenden am Herzen liegt und das ist für mich 
bereits ausreichend. 

Volker (19.12.):
> "Auch meine frühzeitig zum zweiten Satz in Punkt 4 geäußerten Bedenken hier 
> und im Forum wurden schlichtweg ignoriert. Im Forum wurde zwar darüber 
> diskutiert. Letzten Endes hat  aber die Meinung der "Mapper für Renderer" die 
> Oberhand gewonnen."
Ich sehe in diesen Aussagen einen Widerspruch. Irgendwie habe ich auch das 
Gefühl, dass der Benutzer sich nicht an der Diskussion im Forum beteiligt hat. 
Schade...

Michael Reichert (19.12.):
> "Ich selbst finde die Regeln in ihrer derzeit zur Abstimmung stehenden
Form ebenfalls schlecht geschrieben und habe nur zähneknirschend
zugestimmt." 
Die Aussage verwundert mich. Trotz einiger Änderungen geht die Fassung des 
Textes doch auf einen Entwurf von diesem Benutzer zurück (s. 
https://forum.openstreetmap.org/viewtopic.php?pid=727019#p727019 
<https://forum.openstreetmap.org/viewtopic.php?pid=727019#p727019>). 

Falk Zscheile (19.12.):
> "Es ist in der Regel immer zu wenig Zeit für ein perfektes Proposal.
Entweder man stimmt zeitnah ab oder es verläuft sich im Sande, bis
eine neue Diskussion los brandet, weil alle mit dem Istzustand
unzufrieden sind. Das Proposal ist ein WEg weg vom Istzustand."
Das entspricht auch meiner Wahrnehmung. Die Diskussion im Forum habe ich des 
Öfteren als weitschweifig empfunden, aber letztendlich blieben offene Punkte.

Christoph Hormann (19.12.):
> "Was das Abstimmungsverfahren angeht - der eigentliche Sinn der 
Abstimmung bei Proposals ist, die Entstehung eines Konsenses formal zu 
bestätigen.  Wenn man das Ganze als Mehrheitsentscheidung (mit 74% 
statt 50% Mehrheit) auffasst, dann ist das halt kein Konsens.  Das kann 
man gut oder schlecht finden, das ändert aber nichts an den Tatsachen."
Folgend der Beschreibung auf 
https://wiki.openstreetmap.org/w/index.php?title=Proposal_process=1602301#Approved
 
<https://wiki.openstreetmap.org/w/index.php?title=Proposal_process=1602301#Approved>
 sehe ich das als Mehrheitsentscheidung (ich beziehe mich absichtlich auf die 
englischsprachige Fassung, weil diese nie von mir bearbeitet wurde) mit 
besonderer Betrachtung von Minderheitenmeinungen. Ich habe nicht den Eindruck, 
dass ein Konsens möglich ist, weil die Meinungen zu verschieden sind. In 
Bezugnahme auf "All suggestions should be taken into account before a proposal 
is approved or rejected." kann ich nur sagen, dass ich zu manchen Einwänden 
nichts sagen kann, weil mir diese Situation noch nicht untergekommen ist (bspw. 
Erfassung von Feldern), ich sie für destruktiv halte oder ich denke, dass 
Andere dazu mehr sagen können (bspw. übereinanderliegende Linien). 

Ich hoffe, dass ich den Wünschen nach Klarstellung, zumindest in Bereichen, wo 
ich mich fähig fühle zu urteilen, nachkommen konnte. 

Zuletzt möchte ich noch sagen, dass ich mich weder als Autor noch als Initiator 
sehe, sondern schlicht als Wiki-Benutzer, der die Konventionen der Gemeinschaft 
dokumentieren möchte, so sie dann auch angewendet werden. 
Ich halte es persönlich für ungünstig, dass die Diskussion über drei Medien 
separat verläuft. Liest man nur im Forum mit, erh

[Talk-de] Feature Proposal - Abstimmung von "Empfehlung zur Verwendung von Multipolygonen"

[Tigerfell]

Hallo,

nach längerer Diskussion steht nun ein Proposal, welches sich mit der 
Verwendung von Multipolygonen ausschließlich in Deutschland beschäftigt, im 
Wiki zur Abstimmung . Dieses folgt im Wesentlichen der Diskussion im Forum 
(https://forum.openstreetmap.org/viewtopic.php?id=64439 
<https://forum.openstreetmap.org/viewtopic.php?id=64439>).

Das Proposal befindet sich im Wiki unter 
https://wiki.openstreetmap.org/wiki/DE:Proposed_features/Empfehlung_zur_Verwendung_von_Multipolygonen
 
<https://wiki.openstreetmap.org/wiki/DE:Proposed_features/Empfehlung_zur_Verwendung_von_Multipolygonen>

Ich möchte darauf hinweisen, dass wir uns auf die Bezeichnung "Empfehlung" 
geeinigt haben. Damit ist gemeint, dass die Erfassung gemäß der "Empfehlung" 
durchgeführt werden sollte, andere Vorschläge aber auch zukünftig nicht 
verhindert werden sollen, vielmehr soll eine einheitliche Vorgehensweise 
vorgeschlagen werden. 

Viele Grüße
Tigerfell

PS: Wesentliche Diskussionspunkte im Forum:
Motivation: https://forum.openstreetmap.org/viewtopic.php?pid=725141#p725141 
<https://forum.openstreetmap.org/viewtopic.php?pid=725141#p725141>
möglicher Konflikt mit "on the groud mapping": 
https://forum.openstreetmap.org/viewtopic.php?pid=729026#p729026 
<https://forum.openstreetmap.org/viewtopic.php?pid=729026#p729026>
"Verklebte" Multipolygone schädlich?: 
https://forum.openstreetmap.org/viewtopic.php?pid=729019#p729019 
<https://forum.openstreetmap.org/viewtopic.php?pid=729019#p729019>
Von der Empfehlung abweichende Einzelfälle: 
https://forum.openstreetmap.org/viewtopic.php?pid=727561#p727561 
<https://forum.openstreetmap.org/viewtopic.php?pid=727561#p727561>
Nicht zusammenhängende Teile von Multipolygonen: 
https://forum.openstreetmap.org/viewtopic.php?pid=729828#p729828 
<https://forum.openstreetmap.org/viewtopic.php?pid=729828#p729828>
Das sind sicher nicht alle Punkte...
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Feature Proposal - RFC - Empfehlung zur Verwendung von Multipolygonen

[Tigerfell]

Hallo,

ich würde gern auf ein Proposal aufmerksam machen, welches sich mit der 
Verwendung von Multipolygonen beschäftigt. Dieses folgt im Wesentlichen der 
Diskussion im Forum (https://forum.openstreetmap.org/viewtopic.php?id=64439 
<https://forum.openstreetmap.org/viewtopic.php?id=64439>).
Das Proposal: 
https://wiki.openstreetmap.org/wiki/DE:Proposed_features/Empfehlung_zur_Verwendung_von_Multipolygonen
 
<https://wiki.openstreetmap.org/wiki/DE:Proposed_features/Empfehlung_zur_Verwendung_von_Multipolygonen>

Ich möchte darauf hinweisen, dass wir uns auf die Bezeichnung "Empfehlung" 
geeinigt haben. Damit ist gemeint, dass die Erfassung gemäß der "Empfehlung" 
durchgeführt werden sollte, andere Vorschläge aber auch zukünftig nicht 
verhindert werden sollen. 

Um die Diskussion zusammenzuhalten, empfehle ich die Diskussion über das oben 
verlinkte Forum. 

Viele Grüße
Tigerfell
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[OSM-talk] [Wiki] Rewriting node/area/way templates and proposed automated edit

[tigerfell-688]

I would like to cross post my change of three wiki templates and (more 
importantly) a request for an automated wiki edit here:

Following my previous change of Template:Relation, I would like to align the 
appearance of these templates with it. I am planning to change the templates in 
a way that they use partially the same Lua code as Template:Relation. I would 
therefore propose to drop the same features as in the relation template.

As there were some pages that used the option to not specify a relation number 
and I am planning to drop this feature from the other templates as well, I 
would like to request a community approval for an automated change that 
replaces these template calls with static text which was shown in the old 
version. The full request is available at 
https://wiki.openstreetmap.org/wiki/User:TigerfellBot 
<https://wiki.openstreetmap.org/wiki/User:TigerfellBot>.




Kind regards,
Tigerfell




PS: If possible, please comment on the wiki discussion page, that helps keeping 
this documentation together. Thanks.



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