Re: [talk-au] Hello!

[Andrew Harvey]

Yeah it's the one you linked to in your intro on talk-nz,
https://wiki.openstreetmap.org/wiki/Australian_Data_Catalogue

On Sat, 24 Nov 2018 at 06:19, Martijn van Exel  wrote:
>
> Hi Nick,
> We generally focus on the road network and related tags / attributes first, 
> since Telenav tends to source search information (including addressing) from 
> sources other than OSM.
>
> That said, where there is an opportunity to help coordinate adding address 
> information to OSM, we will certainly consider it.
>
> Is there already some coordination going on, like collecting information 
> about datasets and licenses on an OSM wiki page?
> --
>   Martijn van Exel
>   m...@rtijn.org
>
>
>
> On Thu, Nov 22, 2018, at 22:10, Nick Hocking wrote:
>
> Hi Martijn,
>
> In my opinion the biggest improvement to Australian OSM data, to make it 
> usefull for automotive navigation, would be the addition of offline address 
> data.
>
> I believe that most states have address datasets available that are OSM 
> licence compliant and could be used for import. Would your people be 
> interested in helping out with that?
>
>
> Cheers
>
> Nick
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au

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

Re: [Talk-de] Einführung von Regeln für die Verwendung von Relationen mit type=multipolygon

[gmbo]

Am 23.11.18 um 22:34 schrieb Tom Pfeifer:
> On 23.11.2018 21:37, gmbo wrote:
>> Regeln einführen wäre meiner Meinung nach gegen das Prinzip von OSM.
>> Es gibt zwar schon welche wie Urheberrechtsverletzung, 
>
> Es gibt viele Regeln, auch viel grundlegendere:
> "Ein Knoten ist eines der grundlegenden Datenelemente in
> OpenStreetMap. Er besteht aus einem einzelnen georeferenzierten Punkt
> mit Längen- und Breitengrad."
>
ja natürlich gibt es da einige, aber es gibt bisher nicht das du darfst
nicht kleben, oder so.

Das Ausloten der Moglichkeiten der grundlegenden Spielregeln ist aber
gerade das Erfolgsgeheimnis von OSM. Je offener und freunlicher wir
miteinander umgehen, auch mit Fehlern oder lieber gesagt dem gerade
anders tun der Mitmapper, desto weiter kommt das Projekt.

Mein Ansatz ist daher eher Zeige wie es besser geht und warum das besser
ist, dann findet der der trotzig jetzt erst Recht nie von seinem Tun
abläßt und der durch Reverts und andere Repressalien aufhört dabei
natürlich auch mit dem vielen Guten was er einbringt.

>> Waldfläche usw., kann ich mir vorstellen, dass da ein Neumapper von
>> allein in die richtige Richtung läuft und auch erfahrenere Mapper davon
>> profitieren.
>
> Das Problem sind weniger gutwillige Anfänger, sondern durchaus
> erfahrene Mapper,
> die es aber nicht verstehen, im Team zu spielen, sondern eigene
> Vorstellungen von Datenmodellen auf Kosten der Arbeitszeit aller
> durchdrücken wollen.

Ich bin der Meinung, dass wir alle Anfänger mit gewissen Stärken auf
einzelnen Gebieten sind. Lernen kann auch ein erfahrener Mapper von gut
dargestelltem.

Auch ich bin der Meinung je unkomplizierter desto besser.

Wie hier ja schon mehrfach dargestellt wurde, das Problem ist eigentlich
im Gesamtaufkommen der Daten verschwindend gering,

Und ich bin immer noch der Meinung mit Verboten (außer wichtigen
Grundlegenden) schaden wir mehr als es nützt. Mit Vorbildfunktion,
helfen wir allen. (auch den zur Zeit völlig uneinsichtigen.)

Gruß

Gisbert

>
> On 23.11.2018 21:54, Florian Lohoff wrote:
> > 2 Multipolygone die auffällig sind im Regierungsbezirk Detmold. (Mehr
> > als 20 Outer)
> > Dagegen stehen insgesamt 3742 Multipolygone die in Ordnung sind.
> > Das macht 0.05% oder 0.5 Promille. Dafür brauchen wir Regeln?
>
> Deine Statistik geht von der Hypothese aus, dass die Problemfälle
> gleichverteilt sind.
> Sie sind aber eher auf die Stellen konzentriert, an denen sich die
> genannte Kategorie von Mappern gerade aufhält.
>
> Auch sind MPs mit vielen Outern nur das eine Problem; grundlos aus
> Linienstücken zusammengesetzte kleine Objekte das andere.
>
> tom
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de



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

Re: [Talk-de] Einführung von Regeln für die Verwendung von Relationen mit type=multipolygon

[Tom Pfeifer]

On 23.11.2018 21:37, gmbo wrote:

Regeln einführen wäre meiner Meinung nach gegen das Prinzip von OSM.
Es gibt zwar schon welche wie Urheberrechtsverletzung, 


Es gibt viele Regeln, auch viel grundlegendere:
"Ein Knoten ist eines der grundlegenden Datenelemente in OpenStreetMap. Er besteht aus einem 
einzelnen georeferenzierten Punkt mit Längen- und Breitengrad."



Waldfläche usw., kann ich mir vorstellen, dass da ein Neumapper von
allein in die richtige Richtung läuft und auch erfahrenere Mapper davon
profitieren.


Das Problem sind weniger gutwillige Anfänger, sondern durchaus erfahrene Mapper,
die es aber nicht verstehen, im Team zu spielen, sondern eigene Vorstellungen von Datenmodellen auf 
Kosten der Arbeitszeit aller durchdrücken wollen.


On 23.11.2018 21:54, Florian Lohoff wrote:
> 2 Multipolygone die auffällig sind im Regierungsbezirk Detmold. (Mehr
> als 20 Outer)
> Dagegen stehen insgesamt 3742 Multipolygone die in Ordnung sind.
> Das macht 0.05% oder 0.5 Promille. Dafür brauchen wir Regeln?

Deine Statistik geht von der Hypothese aus, dass die Problemfälle 
gleichverteilt sind.
Sie sind aber eher auf die Stellen konzentriert, an denen sich die genannte Kategorie von Mappern 
gerade aufhält.


Auch sind MPs mit vielen Outern nur das eine Problem; grundlos aus Linienstücken zusammengesetzte 
kleine Objekte das andere.


tom

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

[Talk-us] Anyone feel like helping another mapper in New York?

[Andy Townsend]

Hello,

Over the last couple of months there have been edits by a new mapper in 
New York who seems to like changing things but hasn't quite got the hang 
of what they're doing yet.  Some of the smaller edits seem plausible, 
but they seem to be doing a lot of "node drags and merges" which results 
in some very non-grid-pattern street layouts.  Comments can be seen at 
http://resultmaps.neis-one.org/osm-discussion-comments?uid=8356718 .  
I've sent them a couple of "messages that they have to read before 
continuing to edit" as DWG block messages so they'll definitely have 
seen that there are problems, but they haven't been able to translate 
that into them not making the same mistakes again.


It's probably just a schoolkid and It's not necessarily outright 
vandalism (it has none of the messages to teachers or priapic shapes 
that schoolkid vandalism often contains).


My comments haven't worked; maybe someone else could have a go? I'd be 
grateful for any suggestions where to go from here...


Best Regards,

Andy (from the DWG)



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

Re: [OSM-talk] OSMF makes a political decision where should be a technical solution?

[Tomas Straupis]

2018-11-23, pn, 18:57 Andy Townsend rašė:
> Where that best matches the situation on the ground about who has
> control, yes.

  Ok. So do I understand OSMF position is this:

  1. There are no technical problems with having international
boundaries overlapping and representing official position of involved
countries.
  2. International boundaries DO sometimes overlap.
  3. OSMF is aware that overlapping boundaries would have satisfied
more users (especially LOCAL users).
  4. Precedence is taken by "most widely internationally recognised
and best meets realities on the ground" where only second part is
actually important, so this sentence should be changed to "best meets
realities on the ground IRRESPECTIVE OF WIDE INTERNATIONAL
RECOGNITION".

  Is this correct?

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

Re: [Talk-de] Einführung von Regeln für die Verwendung von Relationen mit type=multipolygon

[Florian Lohoff]

On Fri, Nov 23, 2018 at 09:38:53PM +0100, Florian Lohoff wrote:
> Genau - Einige Krasse Beispiele - Wieviel Prozent an den Gesamt
> Multipolygonen macht das denn aus? Das ist genau das was ich sage. Für

Okay - Also ich habe (nach der overpass abfrage im Forum) 
2 Multipolygone die auffällig sind im Regierungsbezirk Detmold. (Mehr
als 20 Outer)

Dagegen stehen insgesamt 3742 Multipolygone die in Ordnung sind.

Das macht 0.05% oder 0.5 Promille. Dafür brauchen wir Regeln?

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung von Regeln für die Verwendung von Relationen mit type=multipolygon

[Florian Lohoff]

On Fri, Nov 23, 2018 at 08:38:35PM +0100, Tom Pfeifer wrote:
> On 23.11.2018 20:14, Florian Lohoff wrote:
> 
> > Mit Problem meine ich: Haben wir community Member die die von dir
> > angesprochenen Dinge bewusst und absichtlich Produzieren obwohl sie sich
> > der Implikationen bewusst sind?
> > 
> > Ich bezweifle das - Nur mal so ein Beispiel.
> > 
> > - Niemand erzeugt Multipolygone von vorneherein mit mehreren Outer
> >rings. Die entstehen erstmal ganz klein.
> Ja, haben wir, und etliche krasse Beispiele sind in dem Forumsthread zitiert.

Genau - Einige Krasse Beispiele - Wieviel Prozent an den Gesamt
Multipolygonen macht das denn aus? Das ist genau das was ich sage. Für
jedes Problem  was du benennst werde ich einen Missbrauch in der
Datenbank finden. Aber die Frage ist wie verbreitet ist das Problem,
und wie entstehen die neu.
Das ist wie mit dem Straßenverkleben - Angeblich ja so verbreitet
aber wenn man mal genau hinsieht ist das ein sub % Problem.
 
> Es gibt die "Teppiche" der bewussten Zusammenfassungen von beziehungslosen
> Teilflächen, um sie im MP einmal zu taggen, und ich bin auch auf Mapper
> gestossen, die ganz bewusst Reihenhäuser aus Legoblöcken einzelner gerader
> Wandstücken zusammensetzen.

Richtig - Es gibt für alles Missbrauch. So wie Sammelrelationen für
Shell Tankstellen oder Netto Märkte.

Ist das ein weit verbreitetes Problem und das hat bisher keiner
beantwortet. Jeder kann jetzt einen besonderen Fall rauskramen 
den er mal gefunden hat. Aber dem gegenüber stehen IMHO jeweils
15000 kleine - saubere - Multipolygone.

Ich finde hier genau 2 Problemfälle in meiner Gegend. Das eine
ist die Boundary für "Ostwestfalen-Lippe" aka Regierungsbezirk Detmold
und das Naturschutzgebiet "Teutoburger Wald".

Beides Verständliche Fälle bei denen das limit eher daher kommt
das man da keine kompletten Ringe draus machen kann weil es
ein "Node per Way" API Limit gibt und die lassen sich auch mit
"Mapper Regeln" nicht lösen.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung von Regeln für die Verwendung von Relationen mit type=multipolygon

[gmbo]

Am 23.11.18 um 20:56 schrieb Christoph Hormann:

> Erstmal ohne die Sache inhaltlich zu betrachten - welcher Art sollen 
> denn diese Regeln sein?  Vorschläge, wie man bestimmte Dinge am besten 
> mappt kann ja im Grunde jeder verfassen (und das sollte eigentlich viel 
> öfter gemacht werden als es de facto der Fall ist).  Aber ich habe den 
> Eindruck, dass Du hier eine darüber hinaus gehende Wirkung 
> beabsichtigst.  Wäre gut, das klar zu stellen.  Du deutest die Idee 
> eines Abstimmungs-Vorganges an - sowas wäre auch international bis 
> jetzt ohne Vorbild so dass völlig unklar ist wie Du dir das vorstellst.
>
> Inhaltlich muss ich nach kurzem Überfliegen sagen, dass ich ziemliche 
> Schwierigkeiten habe, die Bedeutung der Regeln nachzuvollziehen - 
> sowohl durch die sehr häufige Verwendung von vagen, undefinierten 
> Begriffen als auch durch die fehlende innere Logik.  Das sieht mehr 
> nach einer Sammlung von Ideen aus als nach einem zusammenhängendem 
> Konzept.
>
> 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.
>
> Frederiks Empfehlungen zur Flächenverklebung sind da ein gutes 
> Lehrbeispiel, wie man sowas kurz, präzise und logisch stringent 
> formuliert.
>
besser konnte ich das auch nicht fomulieren.

Regeln einführen wäre meiner Meinung nach gegen das Prinzip von OSM.

Es gibt zwar schon welche wie Urheberrechtsverletzung, die ja auch
sinnvoll sind weil sie das System zerstören können, aber auch ich fände
Beschreibungen in einfachen Worten die auch Anfänger gut nachvollziehen
können besser.

Da wären Beschreibungen wie kann ich ein Komplexes Gebilde wie einen
komplizierten Wohnblock am sinnvollsten mappen und dabei auch
Negativbeispiele zu bringen,  mit der Beschreibung was daran schlecht
ist und wie dies in einfacher Form so umgebaut werden kann.

Wenn dann die dazugehörigen Wikiseiten auch in unserer Sprache
existieren und als Einstig da z.B. wie mäppe ich einen Wohnblock, eine
Waldfläche usw., kann ich mir vorstellen, dass da ein Neumapper von
allein in die richtige Richtung läuft und auch erfahrenere Mapper davon
profitieren.

Das ganze sollte dann natürlich die heute verwendeten Editoren mit
einschließen. Also auch berücksichtigen, dass bei bestimmten
Mappingarten nicht mehr alle  Editoren damit klarkommen und dadurch
weitere Fehler hinzukommen.

Daher würde ich nicht Regeln einführen wollen, sondern eher die
Beschreibung verbessen und meine damit würde mindestens das selbe
erreicht und die Community hätte da längerfristig etwas davon.

Gruß Gisbert


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

Re: [Talk-de] Einführung von Regeln für die Verwendung von Relationen mit type=multipolygon

[Martin Koppenhoefer]

sent from a phone

> On 23. Nov 2018, at 20:14, Florian Lohoff  wrote:
> 
> Die Dinger sind gewachsen und es traut sich niemand
> mehr das Zeugs anzufassen


ja, je größer die Fläche ist, um so mehr tendieren diese Relationen dazu, immer 
mehr members zu entwickeln, man muss das richtige Maß finden, m.E. ist es am 
nachhaltigsten, Kleinteilig zu mappen, d.h. additiv kleinere einzelne Flächen 
zu mappen, gerade bei landuse. 

Andererseits sind manche Dinge eben auch groß (Ländergrenzen z.B.) Wobei, in 
Deutschland wundere ich mich gelegentlich, was da alles für Zeug angelegt wird, 
wo es um größere z.T. unscharfe geografische Gebiete geht.

Kleinere Multipolygone finde ich oft sinnvoll, z.B. bei Schulen, öffentlichen 
Gebäuden, Krankenhäusern und so, wenn man Mauern, Zäune und so, wiederverwenden 
kann.

Gruß, Martin 
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung von Regeln für die Verwendung von Relationen mit type=multipolygon

[Christoph Hormann]

Erstmal ohne die Sache inhaltlich zu betrachten - welcher Art sollen 
denn diese Regeln sein?  Vorschläge, wie man bestimmte Dinge am besten 
mappt kann ja im Grunde jeder verfassen (und das sollte eigentlich viel 
öfter gemacht werden als es de facto der Fall ist).  Aber ich habe den 
Eindruck, dass Du hier eine darüber hinaus gehende Wirkung 
beabsichtigst.  Wäre gut, das klar zu stellen.  Du deutest die Idee 
eines Abstimmungs-Vorganges an - sowas wäre auch international bis 
jetzt ohne Vorbild so dass völlig unklar ist wie Du dir das vorstellst.

Inhaltlich muss ich nach kurzem Überfliegen sagen, dass ich ziemliche 
Schwierigkeiten habe, die Bedeutung der Regeln nachzuvollziehen - 
sowohl durch die sehr häufige Verwendung von vagen, undefinierten 
Begriffen als auch durch die fehlende innere Logik.  Das sieht mehr 
nach einer Sammlung von Ideen aus als nach einem zusammenhängendem 
Konzept.

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.

Frederiks Empfehlungen zur Flächenverklebung sind da ein gutes 
Lehrbeispiel, wie man sowas kurz, präzise und logisch stringent 
formuliert.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Talk-de] Einführung von Regeln für die Verwendung von Relationen mit type=multipolygon

[Tom Pfeifer]

On 23.11.2018 20:14, Florian Lohoff wrote:


Mit Problem meine ich: Haben wir community Member die die von dir
angesprochenen Dinge bewusst und absichtlich Produzieren obwohl sie sich
der Implikationen bewusst sind?

Ich bezweifle das - Nur mal so ein Beispiel.

- Niemand erzeugt Multipolygone von vorneherein mit mehreren Outer
   rings. Die entstehen erstmal ganz klein. 

Ja, haben wir, und etliche krasse Beispiele sind in dem Forumsthread zitiert.

Es gibt die "Teppiche" der bewussten Zusammenfassungen von beziehungslosen Teilflächen, um sie im MP 
einmal zu taggen, und ich bin auch auf Mapper gestossen, die ganz bewusst Reihenhäuser aus 
Legoblöcken einzelner gerader Wandstücken zusammensetzen.


tom

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

Re: [talk-au] Hello!

[Martijn van Exel]

Hi Nick,
We generally focus on the road network and related tags / attributes
first, since Telenav tends to source search information (including
addressing) from sources other than OSM.
That said, where there is an opportunity to help coordinate adding
address information to OSM, we will certainly consider it.
Is there already some coordination going on, like collecting information
about datasets and licenses on an OSM wiki page?--
  Martijn van Exel
  m...@rtijn.org



On Thu, Nov 22, 2018, at 22:10, Nick Hocking wrote:
> Hi Martijn,


> In my opinion the biggest improvement to Australian OSM data, to make
> it usefull for automotive navigation, would be the addition of offline
> address data.> I believe that most states have address datasets available 
> that are
> OSM licence compliant and could be used for import. Would your people
> be interested in helping out with that?> 


> Cheers


> Nick


> _
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au

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

Re: [talk-au] Hello!

[Martijn van Exel]

Andrew -- I am very glad to hear it! 
I would be delighted to help promote MapRoulette use more, please do let
me know if you have issues or you want help setting up a particular
challenge.--
  Martijn van Exel
  m...@rtijn.org



On Fri, Nov 23, 2018, at 02:56, Andrew Harvey wrote:
> Hey Martijn, 
> 
> We ran a mapping session at the FOSS4G SotM Oceania Community Day
> today using maproulette. It worked really well spreading tasks out
> among the participants. Lot's of new people getting into using JOSM.> 
> I ran into an error trying to upload one particular GeoJSON files but
> apart from that it went well.> 
> On Thu., 8 Nov. 2018, 5:11 am Martijn van Exel > I’m new on this list. My name is Martijn van Exel. I am Dutch but
>> live in the U.S.A. where I work for Telenav. I already introduced
>> myself on Slack where I talked a bit about Telenav looking at
>> possibly helping improve the map in Australia. I am just not sure if
>> there’s folks here who are not on Slack so I wanted to say hi. We’re
>> not making any improvements yet and we will keep you updated as our
>> plans materialize.>> 
>> We have a page on the OSM wiki that has more about how / what we
>> typically work on in OSM: https://wiki.openstreetmap.org/wiki/Telenav>> 
>> Please do get in touch with any questions!
>> 
>> Happy mapping,
>> Martijn
>> ___
>>  Talk-au mailing list
>> Talk-au@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-au

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

Re: [Talk-de] Einführung von Regeln für die Verwendung von Relationen mit type=multipolygon

[Florian Lohoff]

Hallo Michael,

On Fri, Nov 23, 2018 at 07:14:06PM +0100, Michael Reichert wrote:
> Hallo,
> 
> ich denke, dass es an der Zeit ist, dass wir als deutsche Community
> Regeln einführen, die – das meine ich wirklich so – die übertriebene
> Nutzung von Multipolygon-Relationen für unerwünscht erklären. Deshalb
> habe ich im Forum letzte Woche eine längere Diskussion angestoßen, in
> der jetzt auch die ersten Entwürfe eines Leitfadens bzw. einer
> Richtlinie diskutiert werden.
> 
> Es gibt bestimmte Multipolygon-lastige Mappingmuster, die nur wenig
> Freunde haben, aber die gefühlt viele Nutzer verärgern. Obwohl ich
> selbst gegen Mappingvorschriften bin, bin ich zur Erkenntnis gelangt,
> dass diese ewigen Diskussionen nicht zielführend sind und es einen
> Leitfaden/eine Richtline bedarf, über die abgestimmt wird und dann gilt.
> 
> Die Absichten sind ähnlich wie bei Frederiks Initiative zum
> Landnutzungs-Mapping, nur dass es hier um die Frage
> Multipolygon-Relation vs. geschlossener Way und kleine
> Multipolygon-Relation vs. Multipolygon-Relation mit mehreren äußeren
> Ringen und unzählen inneren Ringen geht.

Ich bin gegen diese Regeln. Das was da drin steht ist entweder
"Common sense" oder aber eben nicht umsetzbar im Sinne von - Es gibt
genau an dieser Stelle einen guten Grund.

Es gibt immer gute Gründe warum dinge so sind wie sie sind und ich
bin selber seit 4 Wochen dabei in meiner Umgebung "Komplexe" und "große"
landuses systematisch zu verkleinern 1). Wenn man sich aber ansieht
warum die dinge so sind wie sie sind ist das oft Überforderung
der mapper. Die Dinger sind gewachsen und es traut sich niemand
mehr das Zeugs anzufassen. Und das ist auch kein Problem von
Multipolygonen sondern insgesamt von Landuses. Die sind über 10 Jahre
und besser werdenden Luftbildern immer komplexer geworden. Jede
Ecke wird noch Rund gemacht und jeder Misthaufen wird ausgenommen (Was
ich - nicht falsch verstehen - richtig finde). Aber das führt
eben dazu das wir 2008 noch den default fall von 4 Nodes je 
landuse hatten. Heute sind das vermutlich im Schnitt eher 30 Nodes.

Die erste Frage ist also: "Haben wir ein Problem". Und mit Problem
meine ich hier nicht "Kaputte oder unhandlebare Daten in der Datenbank" 
denn das ist ein technisches Problem was auch durch eine "Mappingregel"
nicht verschwindet. 
Mit Problem meine ich: Haben wir community Member die die von dir
angesprochenen Dinge bewusst und absichtlich Produzieren obwohl sie sich
der Implikationen bewusst sind?

Ich bezweifle das - Nur mal so ein Beispiel.

- Niemand erzeugt Multipolygone von vorneherein mit mehreren Outer
  rings. Die entstehen erstmal ganz klein. Und dann wird der outer
  ring von jemandem wie mir mal irgendwo gesplittet. Ich merke nicht
  so offensichtlich das das eine komplexe Multipolygon Konstruktion
  ist und schon haben wir 2 outer rings. Das geht ein paar Jahre
  und mit einem mal ist die ganze Stadt mit 50 Polygonen in einem 
  Multipolygon. Niemand traut sich jetzt mehr das aufzusplitten weil
  nicht mehr so klar ist welcher inner wirklich in welchem outer liegt.
  Bedarf das einer mapping Regel? IMHO Nein - Das ist keine Absicht
  sondern "Angst" oder begründete Vorsicht bei Mappern.

- Multipolygone in denen outer und/oder inner Rings aus einzelnen 
  Linien (Nicht geschlossen) zusammengesetzt sind. 
  Hat da jemand Zahlen? Ich behaupte das sind sub 1% der Multipolygone
  denn das macht niemand freiwillig. Das ist so wie Flächen an
  Ways anbinden. Das Probiert jeder mal aus. Findet das vielleicht 
  ein paar Wochen cool weil es geht und irgendwann merkt jeder das das
  eine ganz doofe Idee ist. Bedarf das einer Mapping Regel? Nein.

- Es gibt Waldgebiete die einen Namen haben aber aus mehreren
  Teilstücken bestehen. Da wird dann gerne ein Multipolygon mit
  mehreren outers erzeugt das dann einen Name trägt. Macht
  das Sinn? Weiss ich nicht - Ist halt so ein bisschen Missbrauch
  als Sammelrelation - Haben wir da ein Problem? Sehe ich gerade nicht
  weil das IMHO nur ein Bruchteil der Relationen ausmacht.

- Boundarys sind defakto identisch mit Multipolygonen, arbeiten
  aber intensiv mit Enklaven und Exklaven d.h. hier ist der
  Multi-Outer-Ring eher Regel als Ausnahme und DAS lässt sich nicht lösen.

Also bevor wir hier mit irgendeinem Regelwerk um die Ecke kommen
kann da mal jemand Zahlen Produzieren:

Anzahl Multipolygon Relationen
- Gesamt
- Mehrere outer 
- Mehrere outer in v1
- Mit ringen die aus mehr als einem way bestehen (Hier bitte mit Anzahl
  gesamt nodes, Bayrischer Wald geht nicht in unserem Node API limit)

Ich habe eher das Bedürfnis so Zeugs aufzuräumen - Das ist eben 
in 10 Jahren in die Datenbank gespült worden. Ursprünglich hatte
ein Landuse einer Stadt 6 Nodes und war Kreisrund. Mittlerweile
sind das wenn das keiner gesplittet hat 6000 nodes. Das ist
eben die Pflege der Daten. Jeder guckt nur mit seiner Makroskopischen
Brille da drauf und macht seine Ecke. Wenn man da mal 200ha Daten
laden muss damit man das 

Re: [OSM-talk-fr] internationalisation du wiki

[marc marc]

Le 23. 11. 18 à 19:42, David Crochet a écrit :
> Il faut utiliser le système d'internationalisation de mediawiki ( 
> https://www.mediawiki.org/wiki/Extension:Translate/fr )

mais concrètement, il faut faire quoi ?
l'utilisateur doit utiliser un template ou un url particulière lorsqu'il 
traduit une page en->fr ?
un admin doit faire qlq chose ? (parce qu'il me semble qu'il y a aucun 
admin osm.org ici... donc en remettre un couche ici ne les informe pas)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] internationalisation du wiki

[François Lacombe]

Bonsoir David,

Je suis tout à fait d'accord avec toi.
D'autant que la gestion multi-langue de certaines templates ralentisse
énormément l'affichage des pages.

Il faudrait voir avec les admins, parce que ce sujet est régulièrement
abordé

François

Le ven. 23 nov. 2018 à 19:42, David Crochet  a
écrit :

> Bonjour
>
> Je remet encore une couche sur le sujet :
>
> Il faut utiliser le système d'internationalisation de mediawiki (
> https://www.mediawiki.org/wiki/Extension:Translate/fr ) pour au moins
> internationaliser les pages wiki pour lequel les langues du monde *et*
> les pays du monde sont tout à fait d'accord sur une étiquette et son
> utilisation.
>
> En allant sur cette page :
> https://wiki.openstreetmap.org/wiki/Key:monitoring:water_level je ne voit
> nullement pourquoi il est impossible de l'internationaliser. Ou alors je
> comprend pas.
>
> on a une page source (qui sert de base à toute les langues et la
> modification du texte ne se fait uniquement sur la langue de base) et les
> autres utilisent une " fuzzification " (c'est à dire elle propose et
> signale tous les paragraphes uniquement modifié et uniquement celle-ci à
> re-traduire).
>
> De plus l’internationalisation est en mode d'auto-apprentissage,
> c'est-à-dire que si une expression quasi-identique est déjà traduite dans
> une autre page du wiki, il propose directement la ou les traductions avec
> le taux d'utilisation de l'expression traduite.
>
>
> Cela évite de se retrouver avec une page francophone désuète en
> s'obligeant a aller voir les modifications sur la page anglophone qui ont
> été apporté.
>
>
> Ensuite sur les pages sont l'étiquette est utilisé de façon différents
> selon les langues ou selon les pays, ok, pour l'instant on met de côté
> avant de trouver une solution.
>
>
> Cordialement
>
> --
> David Crochet
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] internationalisation du wiki

[David Crochet]

Bonjour

Je remet encore une couche sur le sujet :

Il faut utiliser le système d'internationalisation de mediawiki ( 
https://www.mediawiki.org/wiki/Extension:Translate/fr ) pour au moins 
internationaliser les pages wiki pour lequel les langues du monde *et* 
les pays du monde sont tout à fait d'accord sur une étiquette et son 
utilisation.


En allant sur cette page : 
https://wiki.openstreetmap.org/wiki/Key:monitoring:water_level je ne 
voit nullement pourquoi il est impossible de l'internationaliser. Ou 
alors je comprend pas.


on a une page source (qui sert de base à toute les langues et la 
modification du texte ne se fait uniquement sur la langue de base) et 
les autres utilisent une " fuzzification " (c'est à dire elle propose et 
signale tous les paragraphes uniquement modifié et uniquement celle-ci à 
re-traduire).


De plus l’internationalisation est en mode d'auto-apprentissage, 
c'est-à-dire que si une expression quasi-identique est déjà traduite 
dans une autre page du wiki, il propose directement la ou les 
traductions avec le taux d'utilisation de l'expression traduite.



Cela évite de se retrouver avec une page francophone désuète en 
s'obligeant a aller voir les modifications sur la page anglophone qui 
ont été apporté.



Ensuite sur les pages sont l'étiquette est utilisé de façon différents 
selon les langues ou selon les pays, ok, pour l'instant on met de côté 
avant de trouver une solution.



Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] Salon "Aujourd'hui pour demain" le 24 novembre à Lyon

[François Lacombe]

Hello Sylvain,

Super que vous ayez trouvé une solution !
Bon salon :)

François

Le ven. 23 nov. 2018 à 11:49, Sylvain Maillard <
local-l...@listes.openstreetmap.fr> a écrit :

> Bonjour,
>
> un petit message pour vous informer que l'équipe d'OSM Lyon sera présente
> aujourd'hui et demain samedi 24 novembre au salon "Aujourd'hui pour demain"
> organisé par la métropole de Lyon.
>
> "Demain se construit dès aujourd’hui. Alors, venez expérimenter et
> débattre des nouveaux modes de consommation écoresponsables. Au programme :
> des conférences pour s’informer, des ateliers-débats pour s’inspirer et
> donner de la voix. Faites le plein de bonnes pratiques pour agir au
> quotidien sur l’alimentation, la mobilité, l’habitat…"
>
> Plus d'infos ici : https://met.grandlyon.com/aujourdhui-pour-demain/
>
>
> Sylvain
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Station hydrographique

[Txo]

Le 23/11/2018 à 12:57, David Crochet a écrit :
> Bonjour
> 
> https://wiki.openstreetmap.org/wiki/Key:monitoring:water_level
> 
> Cordialement
> 
Magnifique. J'avais en effet mal cherché…

Merci.

-- 
-- Dominique Marin http://txodom.free.fr  --
ST: L'intelligence et la connerie ne sont pas incompatibles.
PG: La bêtise et la connerie non plus.
-- in: Guide du Cabaliste Usenet - Des imbéciles heureux  --

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

[Talk-de] Einführung von Regeln für die Verwendung von Relationen mit type=multipolygon

[Michael Reichert]

Hallo,

ich denke, dass es an der Zeit ist, dass wir als deutsche Community
Regeln einführen, die – das meine ich wirklich so – die übertriebene
Nutzung von Multipolygon-Relationen für unerwünscht erklären. Deshalb
habe ich im Forum letzte Woche eine längere Diskussion angestoßen, in
der jetzt auch die ersten Entwürfe eines Leitfadens bzw. einer
Richtlinie diskutiert werden.

Es gibt bestimmte Multipolygon-lastige Mappingmuster, die nur wenig
Freunde haben, aber die gefühlt viele Nutzer verärgern. Obwohl ich
selbst gegen Mappingvorschriften bin, bin ich zur Erkenntnis gelangt,
dass diese ewigen Diskussionen nicht zielführend sind und es einen
Leitfaden/eine Richtline bedarf, über die abgestimmt wird und dann gilt.

Die Absichten sind ähnlich wie bei Frederiks Initiative zum
Landnutzungs-Mapping, nur dass es hier um die Frage
Multipolygon-Relation vs. geschlossener Way und kleine
Multipolygon-Relation vs. Multipolygon-Relation mit mehreren äußeren
Ringen und unzählen inneren Ringen geht.

Initialer Beitrag:
https://forum.openstreetmap.org/viewtopic.php?pid=725141#p725141

Vorschlag von Pfad-Finder:
https://forum.openstreetmap.org/viewtopic.php?pid=726991#p726991

Mein Vorschlag:
https://forum.openstreetmap.org/viewtopic.php?pid=727019#p727019

Viele Grüße

Michael



-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk] OSMF makes a political decision where should be a technical solution?

[Andy Townsend]

On 23/11/2018 16:36, Tomas Straupis wrote:

2018-11-23, pn, 18:23 Andy Townsend rašė:

Yuri, I suspect that literally every statement that the DWG has made
throughout this process has said exactly the opposite of what you've
just suggested that we said.

   You're saying DWG position is that it IS acceptable to have
overlapping country polygons?


Where that best matches the situation on the ground about who has 
control, yes.  I even contributed a couple of examples to a recent 
thread about exactly that - 
https://lists.openstreetmap.org/pipermail/talk/2018-November/081712.html 
(wikipedia has a good summary of that) and 
https://lists.openstreetmap.org/pipermail/talk/2018-November/081717.html 
(read the Dutch thread there for the full story and links).


Best Regards,

Andy


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

Re: [OSM-talk] OSMF makes a political decision where should be a technical solution?

[Tomas Straupis]

2018-11-23, pn, 18:23 Andy Townsend rašė:
> Yuri, I suspect that literally every statement that the DWG has made
> throughout this process has said exactly the opposite of what you've
> just suggested that we said.

  You're saying DWG position is that it IS acceptable to have
overlapping country polygons?

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

Re: [OSM-talk] OSMF makes a political decision where should be a technical solution?

[Andy Townsend]

On 23/11/2018 15:34, Yuri Astrakhan wrote:


I suspect the "default" is what the community took the main issue 
with.  DWG essentially declaring that there must be a single truth for 
non-overlapping country borders is what seems to have caused all 
this.  Simply saying that every country can define their own would 
have averted this whole thing.


Yuri, I suspect that literally every statement that the DWG has made 
throughout this process has said exactly the opposite of what you've 
just suggested that we said.


I've certainly gone on record as saying (some time before these 
discussions) that there are places where overlapping admin levels might 
make sense, and contributed a few examples.


Similarly the first section of "in summary" in 
DisputedTerritoriesInformation.pdf contains 
"You are free to make maps from our data leaving out or 
putting in what you need for harmony with your general usage, culture and legal system.

We encourage you to do this directly or to support one of our many worldwide 
local
OpenStreetMap communities that share your issue", and in most of the 
messages I've sent I've explicitly offered to help people do just that.


It's not the first example of "someone from DWG tries to help someone 
with a problem with a DWG decision" - 
https://www.openstreetmap.org/user/SomeoneElse/diary/42069 was an 
attempt to document an approach to rendering names in a particular 
language based on geographical location and 
https://www.openstreetmap.org/user/SomeoneElse/diary/38613 was designed 
to help someone who was converting all the tracks to roads in a 
particular area "so that they showed on his Garmin".


I've also regularly linked to PlaneMad's 
https://www.openstreetmap.org/user/PlaneMad/diary/38176 which is 
particularly relevant here, especially the "'Fixing' the boundaries of 
India" part.


Best Regards,

Andy


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

Re: [OSM-talk] OSMF makes a political decision where should be a technical solution?

[Gert Gremmen]

This is a boring discussion, and only triggered by what should be out of 
OSM : National Claims.


Borders are almost invisible on the ground either, at least in civilized 
countries.


And if we just decided to leave out all country borders.in a 
utopic effort to re-unite the world ? 


Wouldn't that be inline with the Free Map thought?

Gert

On 23-11-2018 16:34, Yuri Astrakhan wrote:

Frederik,

I suspect the "default" is what the community took the main issue 
with.  DWG essentially declaring that there must be a single truth for 
non-overlapping country borders is what seems to have caused all 
this.  Simply saying that every country can define their own would 
have averted this whole thing.


On Fri, Nov 23, 2018 at 2:24 AM Frederik Ramm > wrote:


Hi,

On 23.11.2018 01:42, Yuri Astrakhan wrote:
> One idea (perhaps this should go into a separete thread):

There already is a separate thread over on the tagging list
started just
a couple of weeks ago. I suggest that would be a good place to
continue
the discussion.

Being able to map different claims is certainly interesting, in so far
as they are verifiable (which surprisingly often is not the case). But
all that's already been mentioned over at
https://lists.openstreetmap.org/pipermail/tagging/2018-October/040333.html

I fear that this is only "kicking the can down the road" though
because
we'd likely have - just as we have with names - one "default" set of
boundaries where we say "that's the one you get if you don't ask
for any
particular one", and the fight would then be on which one that is
going
to be. And judging from how this decision is blown out of proportion
("OMG OSM SUPPORTS TERRORISTS!") I am sure that people would display
exactly the same outrage when discussing which one of a large set of
mapped claims gets the "default" flag.

>  I especially appreciate 4.2 -- the fact that this decision is
very bad for the data users --

I think you have misread Victor's 4.2 which essentially says that data
users currently have to make up their own boundaries anyway and that
therefore this decision does not *help* them. He does not say that
it is
good or bad, just that it does not improve an already-bad situation.

As for whether

> DWG has gone too far into the political landscape - something I
hope it did not intend to do.

let me quote from the DWG statement - again:

"The Data Working Group takes no stance on if Russia's control is
legal
or not, as that is not within our scope."

The DWG has simply applied a policy that has existed in OSM since
before
Crimea's annexation. That policy was written by LWG and approved
by the
OSMF board in 2013 and has been applied many, many times since and it
has generally worked well for OSM. It certainly can be discussed and
improved but that needs to be on a general level, and not tacking
on an
"Ukraine exemption" to the rule.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org

 ##  N49°00'09" E008°23'33"

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


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


--
Independent Expert on CE marking
Harmonised Standards (HAS-) Consultant @ European Commission for RED and EMC
EMC Consultant
Electrical Safety Consultant

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

Re: [OSM-talk] OSMF makes a political decision where should be a technical solution?

[Yuri Astrakhan]

Frederik,

I suspect the "default" is what the community took the main issue with.
DWG essentially declaring that there must be a single truth for
non-overlapping country borders is what seems to have caused all this.
Simply saying that every country can define their own would have averted
this whole thing.

On Fri, Nov 23, 2018 at 2:24 AM Frederik Ramm  wrote:

> Hi,
>
> On 23.11.2018 01:42, Yuri Astrakhan wrote:
> > One idea (perhaps this should go into a separete thread):
>
> There already is a separate thread over on the tagging list started just
> a couple of weeks ago. I suggest that would be a good place to continue
> the discussion.
>
> Being able to map different claims is certainly interesting, in so far
> as they are verifiable (which surprisingly often is not the case). But
> all that's already been mentioned over at
> https://lists.openstreetmap.org/pipermail/tagging/2018-October/040333.html
>
> I fear that this is only "kicking the can down the road" though because
> we'd likely have - just as we have with names - one "default" set of
> boundaries where we say "that's the one you get if you don't ask for any
> particular one", and the fight would then be on which one that is going
> to be. And judging from how this decision is blown out of proportion
> ("OMG OSM SUPPORTS TERRORISTS!") I am sure that people would display
> exactly the same outrage when discussing which one of a large set of
> mapped claims gets the "default" flag.
>
> >  I especially appreciate 4.2 -- the fact that this decision is very bad
> for the data users --
>
> I think you have misread Victor's 4.2 which essentially says that data
> users currently have to make up their own boundaries anyway and that
> therefore this decision does not *help* them. He does not say that it is
> good or bad, just that it does not improve an already-bad situation.
>
> As for whether
>
> > DWG has gone too far into the political landscape - something I hope it
> did not intend to do.
>
> let me quote from the DWG statement - again:
>
> "The Data Working Group takes no stance on if Russia's control is legal
> or not, as that is not within our scope."
>
> The DWG has simply applied a policy that has existed in OSM since before
> Crimea's annexation. That policy was written by LWG and approved by the
> OSMF board in 2013 and has been applied many, many times since and it
> has generally worked well for OSM. It certainly can be discussed and
> improved but that needs to be on a general level, and not tacking on an
> "Ukraine exemption" to the rule.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] B Friuli Venezia Giulia

[Volker Schmidt]

Posso fare la mia solita domanda sui controlli iniziali dei data set e la
manutenzione dati.

1) Vista la discussione sulla qualità dei dataset farmacie, quali parametri
si controllano dei 13 nella tabella
Il dubbio è giustificato:
Ho visto che in tanti casi non c'è il nome nel dataset. Esempio; nel set di
dati che comincia a linea 971 non c''è il campo "name", ma email e web site
indicano "Casa Carbonara".
Inoltre, per lo stesso B, sulla web site parla di tre camere doppie, ma
il daset dice rooms=2, beds=6
Nel secondo esempio che ho preso a caso, il dataset che comincia alla linea
1131, vedo sul sito web le foto di tre camere con  nomi, ma il dataset ne
elenca due.

2) Come è previsto la manutenzione di questi dati. Vedo che viene prodotto
ogni anno una nuova lista. Fate un nuovo import ogni anno?
Ogni anno, quando esce la nuova lista si fa il confronto con la lista del
anno precedente, e poi, che cosa si fa?

Volker




On Fri, 23 Nov 2018 at 13:50, Cascafico Giovanni 
wrote:

> Ciao Listàti,
> scrivo qui, perchè in lista regionale siamo in pochi.
>
> Ho scritto la wiki [1] per l'import all'oggetto e prodotto un primo
> candidato [2]. Qualsiasi commento sulla pagina è benvenuto.
>
> In particolare vorrei capire se ci siano dei vincoli alla generazione di
> un ref namespace per questo dataset, nello specifico "ref:astr". In passato
> ho ricevuto critiche e perplessità sull'uso di namespace applicati al ref,
> per cui vi chiedo in quali condizioni è accettabile.
>
>
>
>
>
>
>
> [1] https://wiki.openstreetmap.org/wiki/Import/Catalogue/BB-RAFVG
> [2]
> https://github.com/cascafico/OSM-RAFVG-BB_import/blob/master/BBconflated.osm
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] made_man=street_cabinet et point de livraison final d'électricité

[François Lacombe]

Bonjour

David => oui

Jérôme,

Le jeu. 22 nov. 2018 à 22:02, Jérôme Seigneuret 
a écrit :

> il me semble que street_cabinet est un élément chez nous que tu ne peut
> géré car propriétaire du fournisseur. (ce qui aussi le cas de la prise
> téléphonique pour le téléphone ou du compteur dans la maison...)
>

Non street_cabinet est uniquement proposé pour se différencier d'un
bâtiment dans lequel l'humain peut circuler.
Les coffrets de compteurs sont donc bien des street cabinet (on peut
disserter sur street, mais ca désigne en gros les armoires où qu'elles se
trouvent et quel que soit leur exploitant)


> Bref normalement tu ne peux pas y mettre les mains dedans
>
Uniquement parce que tu es trop grand pour y rentrer
C'est ensuite operator=* qui dit qui est exploitant.


> avec streetcabinet il y a une notion de propriété et d'impossibilité de
> circuler dans l'édifice.
>
Ce n'est pas ce qui était envisagé. Qu'est-ce qui te fait dire cela ?


>
> Maintenant je pense que le street_cabinet n'est pas un élément terminal
> mais un élément destiné à distribuer plusieurs équipements
>
Si si, man_made=stret_cabinet a pour vocation de remplacer
power=cable_distribution_cabinet qui était aussi utilisé pour taguer les
logettes compteur


>
> chez nos amis anglais c'est* distribution panel *maintenant c'est plus la
> localisation et le type d'élément le contenant qui me pose problème.
>
C'est pour ca qu'on met man_made=street_cabinet et on complete par d'autres
tags (genre usage=* ou power=* si possible)


François
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] B Friuli Venezia Giulia

[Sergio Manzi]

... quindi... ARS_TR_, giusto?  :-)


On 2018-11-23 14:49, Cascafico Giovanni wrote:
> Il ven 23 nov 2018, 14:33 Sergio Manzi mailto:s...@smz.it>> ha 
> scritto:
>
> P.S.; ma "astr" per cosa sta
>
>
> Typo mio, sorry
>
> Anagrafe regionale delle strutture turistico-ricettive (ARSRT
>
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] B Friuli Venezia Giulia

[Cascafico Giovanni]

Il ven 23 nov 2018, 14:33 Sergio Manzi  ha scritto:

> P.S.; ma "astr" per cosa sta
>

Typo mio, sorry

Anagrafe regionale delle strutture turistico-ricettive (ARSRT

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

Re: [Talk-cz] OpenLoveMap

[Michal Fabík]

On Fri, Nov 23, 2018 at 2:35 PM Jan Macura  wrote:
> "počkej v autě miláčku, musím si tu něco zmapovat"

Taky existuje tag service=*, ve kterém lze uvést poskytované služby.
Zatím jsem ho použil jen u autoservisů.
https://wiki.openstreetmap.org/wiki/Key:service

-- 
Michal Fabík

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

Re: [Talk-cz] OpenLoveMap

[Petr Vozdecký]

-- Původní e-mail --
Od: Jan Macura 
Předmět: Re: [Talk-cz] OpenLoveMap "


"




Taky by to po 3 letech chtělo zjistit, jestli to pořád ještě platí, nebo to
nechce nějaký opening_hours tag. Co vím, tak třeba na E55 směrem na Rakousko
 ty štafly bývaly silně sezónní záležitost.



"



Ono obecně, kdyby chtěl tohle někdo poctivě doplnit pro celé česko-
německojazyčné pohraničí, tak má dost práce na pár let. Kam se turistické
trasy hrabou


"



A zapojíme do tohoto projektu i Fody?

:)
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] OpenLoveMap

[Jan Macura]

On Fri, 23 Nov 2018 at 14:24, majka  wrote:

> Už vidím to ověřování na místě a to, jak to vysvětlujete manželce :)
>

"počkej v autě miláčku, musím si tu něco zmapovat"


> Taky by to po 3 letech chtělo zjistit, jestli to pořád ještě platí, nebo
> to nechce nějaký opening_hours tag. Co vím, tak třeba na E55 směrem
> na Rakousko ty štafly bývaly silně sezónní záležitost.
>

Ono obecně, kdyby chtěl tohle někdo poctivě doplnit pro celé
česko-německojazyčné pohraničí, tak má dost práce na pár let. Kam se
turistické trasy hrabou.

H.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-it] B Friuli Venezia Giulia

[Sergio Manzi]

Ciao Giovanni,

le mie perplessità riguardo i B le ho già espresse, per cui non mi ripeto.

Riguardo al namespacing, sono *totalmente d'accordissimo*!

L'uso diffuso del namespacing (/e non solo nei ref/) è, a mio avviso, l'unica 
strada possibile per mettere un po' di ordine nella nostra babele di tag...

Sergio

P.S.; ma "astr" per cosa sta?


On 2018-11-23 13:49, Cascafico Giovanni wrote:
> Ciao Listàti,
> scrivo qui, perchè in lista regionale siamo in pochi.
>
> Ho scritto la wiki [1] per l'import all'oggetto e prodotto un primo candidato 
> [2]. Qualsiasi commento sulla pagina è benvenuto.
>
> In particolare vorrei capire se ci siano dei vincoli alla generazione di un 
> ref namespace per questo dataset, nello specifico "ref:astr". In passato ho 
> ricevuto critiche e perplessità sull'uso di namespace applicati al ref, per 
> cui vi chiedo in quali condizioni è accettabile.
>
>
>
>
>
>
>
> [1] https://wiki.openstreetmap.org/wiki/Import/Catalogue/BB-RAFVG
> [2] 
> https://github.com/cascafico/OSM-RAFVG-BB_import/blob/master/BBconflated.osm
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-cz] OpenLoveMap

[majka]

On Fri, 23 Nov 2018 at 14:12, Jan Macura  wrote:

> Ahoj,
>
> díky za poučnou zprávu. Uzly jako je tento mají jistě časté využití:
> https://www.openstreetmap.org/node/3677590921#map=19/49.71616/13.29475
>
> Ještě by tam někdo ze zákazníků mohl doplnit tag payment, zajímalo by mě,
> jestli tam berou Sodexo karty.
>

Už vidím to ověřování na místě a to, jak to vysvětlujete manželce :)

Taky by to po 3 letech chtělo zjistit, jestli to pořád ještě platí, nebo to
nechce nějaký opening_hours tag. Co vím, tak třeba na E55 směrem
na Rakousko ty štafly bývaly silně sezónní záležitost. Ale kolega z
Rakouska, který by mi to mohl zkontrolovat každý týden cestou na víkend
domů a po víkendu zpátky už tu nepracuje, a jeho nástupce jezdí jinudy ;)
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] OpenLoveMap

[Jan Macura]

Ahoj,

díky za poučnou zprávu. Uzly jako je tento mají jistě časté využití:
https://www.openstreetmap.org/node/3677590921#map=19/49.71616/13.29475

Ještě by tam někdo ze zákazníků mohl doplnit tag payment, zajímalo by mě,
jestli tam berou Sodexo karty.

H.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] Knihkupectví a kavárna v jednom

[Jan Macura]

Ahoj,

On Fri, 23 Nov 2018 at 12:35, majka  wrote:

> Podobný "problém" je třeba Rock 'n' Wall v Plzni na Sadech 5. května 24 -
> v mapě nám chybí, je to hospoda s lezeckou stěnou vzadu.
>

Tak to je na mojí hlavu, že chybí.. ;-) Tuším, že už jsem jednou chtěl
přidat, ale nevěděl jsem jak značit a nechtělo se mi nad tím zrovna dumat,
tak jsem to nechal být.
Nicméně myslím si, že "správně" je označit na jednom uzlu všechny platné
tagy (protože to je jen jedna provozovna s jedním majitelem, jednou
otevírací dobou, jedním vstupem, ...). To, že je to pak oříšek pro
vykreslovače, je samozřejmě pravda...
Tak jsem tam nasekal pěknou kombinaci tagů a jsem zvědav, co z toho v
různých renderech vyleze: https://www.openstreetmap.org/node/6085547866

H.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[Talk-it] B Friuli Venezia Giulia

[Cascafico Giovanni]

Ciao Listàti,
scrivo qui, perchè in lista regionale siamo in pochi.

Ho scritto la wiki [1] per l'import all'oggetto e prodotto un primo
candidato [2]. Qualsiasi commento sulla pagina è benvenuto.

In particolare vorrei capire se ci siano dei vincoli alla generazione di un
ref namespace per questo dataset, nello specifico "ref:astr". In passato ho
ricevuto critiche e perplessità sull'uso di namespace applicati al ref, per
cui vi chiedo in quali condizioni è accettabile.







[1] https://wiki.openstreetmap.org/wiki/Import/Catalogue/BB-RAFVG
[2]
https://github.com/cascafico/OSM-RAFVG-BB_import/blob/master/BBconflated.osm
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Station hydrographique

[David Crochet]

Bonjour

https://wiki.openstreetmap.org/wiki/Key:monitoring:water_level

Cordialement

--

David Crochet


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

Re: [Talk-cz] Knihkupectví a kavárna v jednom

[majka]

Dávám taky samostatně. Ideálně jeden tag na budovu, a jeden bodem, pokud to
tak odpovídá, ale klidně i dva samostatné body, když to nejde jinak, každý
do jiného kouta :). Taky tu takové máme (nebo jsme měli, už jsem tam dlouho
nebyla). V Praze takhle fungovalo Globe, jestli si vzpomínám dobře
(anglické knihy, byla jsem tam naposledy snad před 15 lety, navíc jako wifi
kavárna).
Podobný "problém" je třeba Rock 'n' Wall v Plzni na Sadech 5. května 24 - v
mapě nám chybí, je to hospoda s lezeckou stěnou vzadu.

On Fri, 23 Nov 2018 at 11:51, Mikoláš Štrajt  wrote:

> Teď něco praktičtějšího: Přidával jsem Knihkupectví a kavárnu U Řehoře
> Samsy (https://www.openstreetmap.org/node/6082518335) a přemýšlel jsem,
> jak to mám vlastně otagovat. Ono je to skutečně knihkupectví a kavárna v
> jednom, tady to dokonce funguje tak, že se, za knihy platí na baru (nebo
> minimálně barmance).
>
> Nakonec jsem tam dal oba tagy (amenity=cafe a shop=books), ale nepřijde mi
> to úplně košér a třeba na hotosm mapě se pak nápis (zřejmě díky tomuto)
> vykreslí dvakrát.
>
> Mimochodem - podobná situace je v Neoluxoru na Hlavním nádraží, tam mají
> taky kavárnu v rámci knihkupectví (tam se ovšem kafe platí jinde než knihy).
>
> --
> Severák
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[OSM-talk-fr] Station hydrographique

[Txo]

Bonjour, 
Tout est dans le titre. Comment taguer une station qui, entre autre, 
alimente le site vigicrues. Et plus précisément, celle là :

https://www.vigicrues.gouv.fr/niv3-station.php?CdStationHydro=Y341400501=20=H=1=

Je n'ai rien trouvé, peut-être mal cherché, à ce sujet.

Merci.


-- 
-- Dominique Marin http://txodom.free.fr  --
ST: L'intelligence et la connerie ne sont pas incompatibles.
PG: La bêtise et la connerie non plus.
-- in: Guide du Cabaliste Usenet - Des imbéciles heureux  --

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

Re: [Talk-cz] OpenLoveMap

[Miroslav Suchý]

Dne 23. 11. 18 v 11:08 Mikoláš Štrajt napsal(a):
> Věděli jste, že existuje OpenLoveMap, která zobrazuje sexshopy,
> striptýzové bary, nevěstince a automaty na kondomy?
> 
> Já teda ne a pak jsem docela koukal. :-O

Koukam ze maji spatne uvedenou contribuci :)

Mire

-- 
,,,
   (o o)
  =oOO==(_)==OOo===
 )  mailto:miros...@suchy.cz  tel:+420-603-775737
(   One picture is worth 128K words.
 )Oooo.
 .oooO   (   )
 (   )) /
  \ ((_/
   \_)


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

[Talk-cz] Knihkupectví a kavárna v jednom

[Mikoláš Štrajt]

Teď něco praktičtějšího: Přidával jsem Knihkupectví a kavárnu U Řehoře Samsy
(https://www.openstreetmap.org/node/6082518335) a přemýšlel jsem, jak to mám
vlastně otagovat. Ono je to skutečně knihkupectví a kavárna v jednom, tady
to dokonce funguje tak, že se, za knihy platí na baru (nebo minimálně
barmance).

Nakonec jsem tam dal oba tagy (amenity=cafe a shop=books), ale nepřijde mi
to úplně košér a třeba na hotosm mapě se pak nápis (zřejmě díky tomuto)
vykreslí dvakrát.

Mimochodem - podobná situace je v Neoluxoru na Hlavním nádraží, tam mají
taky kavárnu v rámci knihkupectví (tam se ovšem kafe platí jinde než knihy).

--
Severák___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[OSM-talk-fr] Salon "Aujourd'hui pour demain" le 24 novembre à Lyon

[Sylvain Maillard]

Bonjour,

un petit message pour vous informer que l'équipe d'OSM Lyon sera présente
aujourd'hui et demain samedi 24 novembre au salon "Aujourd'hui pour demain"
organisé par la métropole de Lyon.

"Demain se construit dès aujourd’hui. Alors, venez expérimenter et débattre
des nouveaux modes de consommation écoresponsables. Au programme : des
conférences pour s’informer, des ateliers-débats pour s’inspirer et donner
de la voix. Faites le plein de bonnes pratiques pour agir au quotidien sur
l’alimentation, la mobilité, l’habitat…"

Plus d'infos ici : https://met.grandlyon.com/aujourdhui-pour-demain/


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

Re: [Talk-cz] OpenLoveMap

[Michal Fabík]

On Fri, Nov 23, 2018 at 11:09 AM Mikoláš Štrajt  wrote:
> Věděli jste, že existuje OpenLoveMap, která zobrazuje sexshopy, striptýzové 
> bary, nevěstince a automaty na kondomy?

Jo, věděli, dokonce jsem nedávno v Brně hrdě přidával první bordel.
Vím o něm proto, že ho mám vedle práce. Mimochodem je hned vedle
nějakého zařízení pro problémovou mládež - třeba by se z umístění
bordelů dalo něco zajímavého vyčíst.

-- 
Michal Fabík

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

Re: [Talk-cz] OpenLoveMap

[majka]

On Fri, 23 Nov 2018 at 11:09, Mikoláš Štrajt  wrote:

> Ano, i takovéhle věci mapujeme. :-)
>

Jak kde :)
Podle té mapy u nás nic takového neexistuje, ukazuje mi to všeho všudy
jeden nevěstinec, žádný sex shop ani nic jiného. To ostatní je podle všeho
opravdu veřejné... , ale asi spíš veřejné tajemství.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[Talk-cz] OpenLoveMap

[Mikoláš Štrajt]

Věděli jste, že existuje OpenLoveMap, která zobrazuje sexshopy, striptýzové
bary, nevěstince a automaty na kondomy?

Já teda ne a pak jsem docela koukal. :-O

Viz https://openlovemap.de/#13/50.0855/14.4261
a https://wiki.openstreetmap.org/wiki/OpenLoveMap

---

A kdyby vám vrtalo hlavou, jak jsem se vůbec k takové věci dostal:

- zkoumal jsem, proč se Cross club ukazuje jen na některých mapách
- tak jsem koukal na wiki stránku tagu amenity=nightclub
- odtud to byl jen krůček na amenity=striptbar (s krásnou ikonkou dívky u
tyče :-D)
- kde psali, že to nemáme zamněňovat s amenity=brothel

Ano, i takovéhle věci mapujeme. :-)

--
Severák___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-au] Hello!

[Andrew Harvey]

Hey Martijn,

We ran a mapping session at the FOSS4G SotM Oceania Community Day today
using maproulette. It worked really well spreading tasks out among the
participants. Lot's of new people getting into using JOSM.

I ran into an error trying to upload one particular GeoJSON files but apart
from that it went well.

On Thu., 8 Nov. 2018, 5:11 am Martijn van Exel  I’m new on this list. My name is Martijn van Exel. I am Dutch but live in
> the U.S.A. where I work for Telenav. I already introduced myself on Slack
> where I talked a bit about Telenav looking at possibly helping improve the
> map in Australia. I am just not sure if there’s folks here who are not on
> Slack so I wanted to say hi. We’re not making any improvements yet and we
> will keep you updated as our plans materialize.
>
> We have a page on the OSM wiki that has more about how / what we typically
> work on in OSM: https://wiki.openstreetmap.org/wiki/Telenav
>
> Please do get in touch with any questions!
>
> Happy mapping,
> Martijn
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk] OSMF makes a political decision where should be a technical solution?

[Tomas Straupis]

2018-11-23, pn, 11:19 Oleksiy Muzalyev rašė:
> The topic of territorial claims is very complicated, long lasting,  and
> painful. It involves not only such relatively remote and insignificant
> cases as Hans Island, Sudan, Croatia, Crimea, Pakistan, etc. cases, but
> also the industrial developed lands. For example, the Reconquista [1] in
> the USA is about millions of square kilometers, including the
> California, the 6th economical power in the world if taken by itself.
> After visiting some areas of Los Angeles, California, the Reconquista
> does not seem to me as ridiculous as before. Demography and linguistics
> do have certain significance.

  It was already stated we're only talking about official claims by
official governments.
  To my knowledge official Mexican government has no official claims
on territory lost in XIXa.

  Victor and Yuri has stated, that having such an overlapping but
representing official local position borders would help data users to
adapt data to local needs: create Chinese map as Chinese want, create
Ukraine map as most of the world wants etc. etc.

  And "ground truth" will not be enough to settle some peaceful border
disputes or just agreement of joint rule.

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

Re: [OSM-talk] OSMF makes a political decision where should be a technical solution?

[Oleksiy Muzalyev]

The topic of territorial claims is very complicated, long lasting,  and 
painful. It involves not only such relatively remote and insignificant 
cases as Hans Island, Sudan, Croatia, Crimea, Pakistan, etc. cases, but 
also the industrial developed lands. For example, the Reconquista [1] in 
the USA is about millions of square kilometers, including the 
California, the 6th economical power in the world if taken by itself. 
After visiting some areas of Los Angeles, California, the Reconquista 
does not seem to me as ridiculous as before. Demography and linguistics 
do have certain significance.


Or the expulsion of Germans (the civilian population) from Eastern 
Poland after WW2 [2]. There is already in Germany the official 
organization The Centre Against Expulsions (German: Zentrum gegen 
Vertreibungen, ZgV) [3]. And the Germany is the world class industrial 
superpower.


Fortunately, these controversial massive cases are dormant, and I hope 
they will remain so. There are many other similar cases.


I suggested still several years ago to include in the OpenStreetMap 
foundation Core Values [4] the principle of Impartiality and Neutrality, 
similarly as it is done at the International Committee of Red Cross.

For example:
--
IMPARTIALITY
OSM makes no discrimination as to nationality, race, religious beliefs, 
class or political opinions. It endeavours only to map the objective 
“Ground Truth”.


NEUTRALITY
In order to continue to enjoy the confidence of all, the OSM may not 
take sides in hostilities or engage at any time in controversies of a 
political, racial, religious or ideological nature.

--

In 2014 Le Monde named the author Rana Dasgupta one of 70 people who are 
making the world of tomorrow. Rana Dasgupta wrote earlier this year an 
amazing article "The demise of the nation state" [6]. If what he writes 
is true, and it seems to be, the borders issue will become even more 
complicated.


In my opinion, the OSM should map nation states' borders in such a way 
as to promote constructive innovative peaceful resolutions of the 
territorial disputes. At the same time the interests of travelers and 
local residents should be also taken into account. If two competing 
borders are shown, still the line of passport control, where a tourist 
may be actually stopped for the passport & customs control somehow 
should be marked on the map. So she/he could prepare for the control, or 
not to cross inadvertently while hiking, cycling or rowing in wilderness.


No idea I heard or saw so far is perfect. I think there is still a lot 
of space for innovation in this domain.


[1] https://en.wikipedia.org/wiki/Reconquista_(Mexico)
[2] 
https://en.wikipedia.org/wiki/Flight_and_expulsion_of_Germans_from_Poland_during_and_after_World_War_II

[3] https://en.wikipedia.org/wiki/Centre_Against_Expulsions
[4] https://wiki.osmfoundation.org/wiki/Mission_Statement
[5] 
https://www.icrc.org/en/doc/resources/documents/misc/fundamental-principles-commentary-010179.htm
[6] 
https://www.theguardian.com/news/2018/apr/05/demise-of-the-nation-state-rana-dasgupta


Best regards,
Oleksiy

On 23.11.18 10:10, Tomas Straupis wrote:

I fear that this is only "kicking the can down the road" though because
we'd likely have - just as we have with names - one "default" set of
boundaries where we say "that's the one you get if you don't ask for any
particular one", and the fight would then be on which one that is going

   "default" is not required (map/app creator should have a freedom to
make decision).

   The only change required is to allow OVERLAPPING borders which
apparently is a normal thing for borders even when there is no war,
nobody on the ground to make "ground truth". For example:
   https://en.wikipedia.org/wiki/Hans_Island

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




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

Re: [OSM-talk] OSMF makes a political decision where should be a technical solution?

[Lester Caine]

On 22/11/2018 18:53, Victor Shcherb wrote:
In that case I would actually support idea of deleting all country 
boundaries to avoid this question completely.


There are numerous sets of data within OSM that are disputed and one 
'controlling body' or another would prefer was not published at all. The 
best that can be done is for local displays of that data to provide 
local filters. Simply deleting data is never going to be the right 
solution, but allowing tools that censor the data is equally controversial.


For the point of view of OSMAND, the display needs to know where one can 
drive and where one will be stopped and need paperwork to proceed. THAT 
in my book is the simple ToTG because it is flagged by something 
physical. That some areas don't actually have 'border posts' does create 
a problem, but as an 'outside visitor' to the Ukraine or Cyprus, where 
can I drive and where could I run into difficulty if I do drive into a 
disputed area. It's the grey areas that are something that will cause 
problems and may require projects like OSMAND to censor data based on 
the user view? I doubt that OSM services are really able to manage this 
area in a generic way?


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk] OSMF makes a political decision where should be a technical solution?

[Pavlo Dudka]

Good points, Victor! Thanks for sharing your opinion.

You've just demonstrated how DWG could have started the discussion.
Current discussion (not only this topic but all the messages on OSM
lists.*, OSM forum, OSM diaries, Twitter etc) raises the question about the
DWG role in OSM. While expected to resolve conflicts, find consensus and
prevent edit wars some members of DWG doing the opposite and trigger edit
war.
(Since it is not related to the points you highlighted I'll start a
separate thread.)

Pavlo

чт, 22 лист. 2018 о 20:57 Victor Shcherb  пише:

> Hi All,
>
> I followed many topics for the last 3 days about the Ukraine/Crimea and I
> would like to propose another look to all known issues.
>
> *DISCLAIMER:*
> First of all, I would like to thank everybody for staying calm and
> considering all views for this *non-trivial* problem. Originally, I'm
> from Belarus (former USSR) and currently I live for a long time in the
> Netherlands, so I hope I can express my point of view objective but also
> explaining the gist of the issue. Even though I'm leading OsmAnd mobile
> development, I will speak solely from my perspective on this question.
>
> *STATEMENT 1. *There is no ToTG principle for artificial objects such as
> boundaries + Boundaries are always driven by one or another authorities.
>
> *1.1 *To clarify that principle we can go the lowest level, city or
> suburb boundaries. it is very clear that it is impossible to identify on
> the ground whether city-suburb has ended and another has started.
> *1.2 *Of course, we can clarify or build it that knowledge from
> milestone, flags or fence. Though we have different Mapping for fence,
> milestone and *we shouldn't mix it with country borders.* Following that
> principle, it will be hard to build polygons cause we always could miss
> data in between or it could be very incomplete from the Ground knowledge
> *1.3 *Most of the data today is coming from authorities. Local
> municipalities provide that public data, so admin_level of lower level
> corresponds to
> *1.4 *There is no ToTG to identify a country, unless you go and do a
> voting on the special piece of terriritory. I think you can find lots of
> places like Kurdistan where people would say that they belong to country
> that doesn't exist or not listed in UN. Country is an entity that coexist
> with other countries and other countries should acknowledge it and
> acknowledge their borders (especially for neighbor countries).
> *1.5 *Fence or any physically present object which could be verified by
> ToTG doesn't make border legitimate and will be very likely removed from
> admin_level relations doesn't matter if it looks or claimed by
> non-authorized entity a special territory if it contradicts to 99.9%
> perception of other mappers.
>
> With this point I'm trying to say, that hiding a solution behind ToTG
> principle we are raising even more questions than we had.
>
> *STATEMENT** 2. *There is no right decision unless we clarify what
> exactly data and how it should be organized.
>
> *2.1 *Moving objects or making special statements about concrete objects
> will drive to a mess. It is obvious that we better focus on Proposal and
> clarify how to deal with data rather than changing the map itself.
> *2.2 *Every mapper should be able to make the right decision himself
> following the wiki documentation. If it is not possible than the
> documentation or rules are not complete or not correct. We should not block
> people that do mistakes in understanding whether their logic correct or not
> especially if it is a significant number of people.
>
> *STATEMENT** 3. *Any decision about current Relations in OSM will be
> political and it will only evolve confrontation between local editing
> groups. I believe OSMF should not take any political decisions in such
> manner.
>
> I truly believe that DWG/ OSMF didn't want to make any political decision
> and only correct the data and make it consistent which makes perfect sense
> from top level view unless you don't bother with the real situation itself.
> Unfortunately it is not possible to solve political question and don't get
> dragged into politics.
> *3.1 *Hidden political decisions are bad. Why this decision is political?
> First of all, there is a small politics involved anyway DWG is elected by
> OSMF members and DWG made that decision. In case people are against it,
> they can vote for different DWG group and next year the situation around it
> will be changed again and again. The problem remains here anyway, what if
> Ukrainian community to vote will be smaller than Russian or what if votes
> can be based on various connections between people, so we'll get into a
> minority problem.
>
> *3.2 *THE WORST PART: We evolve confrontation between 2 big group of
> mappers which were always welcome in OSM but as of today they read OSM
> rules differently and the war of edits begins. In case we want to keep both
> group of mappers because they INDIVIDUALLY 

Re: [Talk-it] licenza - valida anche per video?

[Gabriele Sani]

Ottimo, ultima cosa:
pensavo di scrivere un email alla redazione per notificare questa cosa:
quale'e' il modo migliore di porsi? Cioe', per chi ha gia' avuto casi del
genere, cosa scrivete di solito?

Grazie

Gabriele

Il giorno gio 22 nov 2018 alle ore 18:43 Maurizio Napolitano <
napoo...@gmail.com> ha scritto:

>
>
> Il giorno Gio 22 Nov 2018, 09:59 Gabriele Sani 
> ha scritto:
>
>> Buongiorno,
>>
>> in questo video, verso la fine, si vede quella che sembra essere
>> chiaramente una mappa OSM -> https://youtu.be/BwBKmTHm_UY?t=165
>>
>> La licenza andrebbe riportata anche in questo caso?
>>
>
> SEMPRE
>
>> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] OSMF makes a political decision where should be a technical solution?

[Tomas Straupis]

> I fear that this is only "kicking the can down the road" though because
> we'd likely have - just as we have with names - one "default" set of
> boundaries where we say "that's the one you get if you don't ask for any
> particular one", and the fight would then be on which one that is going

  "default" is not required (map/app creator should have a freedom to
make decision).

  The only change required is to allow OVERLAPPING borders which
apparently is a normal thing for borders even when there is no war,
nobody on the ground to make "ground truth". For example:
  https://en.wikipedia.org/wiki/Hans_Island

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