Re: [OSM-legal-talk] Adding OSM-ids to an external database and publish in CC-BY

[Falk Zscheile]

Am 31.03.20 um 19:56 schrieb Martin Koppenhoefer:
> In Italy we have been discussing this situation: a member of the community
> wants to add links to OSM objects into a list of specific shops (those that
> are open during the covid-19 pandemia).
>
> The list will be published here: https://www.covid19italia.help/opendata/
> with an CC-BY-4.0 license.
>
> The links will be of the kind https://www.openstreetmap.org/relation/1834818
>

In decision C‑466/12 - Svensson and Others , the European Court of Justice 
stated:

"[...] that the provision on a website of clickable links to works freely 
available on another website does not constitute an act of communication to the 
public, as referred to in that provision."

> Question is, will it be possible to publish such a list, containing OSM-ids
> (or links to OSM objects) with a CC-BY-4.0 license?
>

In my opinion, this case applies not only to links to works, but also to links 
to publicly accessible databases. Since links to database objects are not 
legally relevant duplication of the database, no license terms of the ODbL need 
to be observed in this case.

Falk

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

Re: [OSM-legal-talk] Legal regulation of the use of OSM data

[Falk Zscheile]

Am 12.03.20 um 16:54 schrieb Полина Новикова via legal-talk:
> 
> Hello, everybody!
>  
> Please deal with the issue of legal regulation of OSM data.
>  
> If we collect data from your API in XML format or perhaps directly from the 
> front of the API in JSON format (is there any difference in this situation?). 
> The final format for displaying data is the pins of organizations in the 
> custom (our) design, which we place on a third-party map, with the ability to 
> do so under license. Users can find out what type of organization and what 
> kind of organization, filter organizations on the map, i.e., for example, 
> view only hospitals. We assume to take and reflect on the map only socially 
> significant objects on the map - schools, kindergartens, sports institutions, 
> hospitals and shops (a fairly small number of objects). Is this obvious 
> limits to the usefulness? 
>  
> If we allow to use the specified data on our site, which we put on a map, and 
> under the terms of the purpose is not to extract the data, but only for the 
> user to see these data, i.e. the goal is to bring it to the end user as shown 
> in the example with Garmin maps on the site at the link   
> https://wiki.openstreetmap.org/wiki/Open_Data_License/Produced_Work_-_Guideline
>    and it says it's Produced Work. In our situation, is this also a Produced 
> Work? 
>  
I am not sure if I understand the facts correctly. In general, however, one can 
say: If you query all "amenity = hospital" for a specific region, then this is 
a database extract from the OSM database for which section 4.4 of the ODbL 
applies. It does not matter whether the query is made by many individual 
queries or by a single large query. If you show the geographical position and 
the related information of "amenity = hospital" on a map, this display is a 
produced work.

It is particularly important to note that if you use information from "amenity 
= hospital" from the OSM database with your own data and information about 
hospitals, then you create a "derivative database". In this case, section 4.6 
of the ODbL also applies. The own data are then to be released on request 
(share alike)!


> And I would like to clarify about attribution. The guideline states that we 
> should indicate that we are contributors and provide a link to distribution 
> under the ODbL license, on the other hand, for Produced Work in clause 4.3. 
> license ODbL is written a little differently and that is not consistent with 
> the logic written in guidline. Based on this, the question arises whether it 
> is enough that we specify that the map simply contains information from the 
> OSM as indicated at the beginning of paragraph 4.3?

I agree with you that the FAQ does not properly fit the licensing terms in 4.3 
of the ODbL. In particular, the descriptions in the FAQ do not do justice to 
the idea behind the attribution. You can choose your own license for a produced 
work, see section 4.5. b of the ODbL. A proprietary license is also possible 
for the produced work. The idea behind the attribution with the specification 
of the license refers to it. A proprietary license can prevent the user from 
reusing the produced work. The attribution and license information for the 
source should enable the user to create a comparable produced work from the 
open data. For this reason, the ODbL recommends stating the name of the 
database and the license in section 4.3a of the ODbL. I therefore recommend the 
following information: "Data: OpenStreetMap-Contributors (Open Database 
License)". In addition to the information on the data, a separate license can 
be added for the produced work: "Map design: (c) [name], license XYZ.

Regards, Falk


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

Re: [Talk-de] OSM auf den Chemnitzer Linux-Tagen (14.3.-15.3.)

[Falk Zscheile]

Am Mo., 6. Jan. 2020 um 20:43 Uhr schrieb Michael Kugelmann via
Talk-de :
>
> Am 06.01.2020 um 15:27 schrieb André Riedel:
> > https://chemnitzer.linux-tage.de/2020/de
> schade: findet am 14. und 15.3. 2019 statt und kollidiert somit leider
> mit dem OSM-Samstag der FOSSGIS-Konferenz in Freiburg:
> https://fossgis-konferenz.de/2020/
> https://wiki.openstreetmap.org/wiki/FOSSGIS_2020 bzw.
> https://wiki.openstreetmap.org/wiki/FOSSGIS_2020/OSM-Samstag

Dann kann es am OSM-Stand auf den Chemnitzer Linuxtagen eine
Liveübertragung aus Freiburg geben :-)

Viele Grüße

Falk

___
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"

[Falk Zscheile]

Moin,

Am Mi., 19. Dez. 2018 um 17:38 Uhr schrieb Michael Reichert
:

> Am 19.12.18 um 13:30 schrieb Christoph Hormann:
> > Ich muss sagen, dass ich ziemlich enttäuscht davon bin, dass mein
> > zweimaliger Hinweis hier (in Antwort auf Nakaner vom 23.11. und in
> > Antwort auf Tigerfell vom 27.11.) hinsichtlich der Nachvollziehbarkeit
> > und Klarheit der Regeln insbesondere für neue Mapper kein Gehör fand.
> >
> > Unabhängig vom Abstimmungs-Ergebnis wird da so kein Community-Konsens
> > draus, wenn selbst so offensichtliche und begründete Vorschläge mit
> > keinerlei Potential für inhaltliche Konflikte keine Berücksichtigung
> > finden.
> >
> > Und wenn dann Frederiks Einwände in der Abstimmung, die zum Teil in eine
> > ganz ähnliche Richtung gehen, damit entgegnet werden, dass man sie doch
> > früher hätte einbringen sollen (Duh! Siehe oben) dann deutet das für
> > mich ein bisschen darauf hin, dass hier manche mehr die homogenen
> > Ansichten einer kleinen Gruppe in die Welt exportieren wollen, als zu
> > einem breiten Konsens zu kommen, den alle verstehen und den die
> > allermeisten unterstützen können.
>
> Ich selbst finde die Regeln in ihrer derzeit zur Abstimmung stehenden
> Form ebenfalls schlecht geschrieben und habe nur zähneknirschend
> zugestimmt. Die Kritik ist aber berechtigt.
>
> Kritik mit "das hättest du auch früher sagen können" zu entgegnen, finde
> ich nicht gut. Stattdessen sollte man die Abstimmung abbrechen und
> zurück in die Entwurfsphase gehen.
>

Es wird immer so sein, dass es Punkte gibt, die einem persönlich nicht
gefallen oder die man gern anders hätte. Ein Abstimmungsprozess ist
durch das Gesamtpaket, das zur Abstimmung steht, auch immer eine
Abstraktion von der eigenen Auffassung. Genau aus diesem Grund ist es
auch immer einfach, über Politik zu schimpfen. Hier erleben wir am
eigenen Leib, wie schwierig es ist, Kompromisse zu finden, die eine
möglichst breite Zustimmung erfahren.

> Wenn das Proposal durchfällt (74 Prozent Mehrheit sind nominell
> erforderlich, aber bei 39 abgegebenen Stimmen ist die Abstimmung IMHO
> nicht repräsentativ), werde ich ihm nicht nachweinen, sondern einen
> zweiten, durchdachteren und besser begründeten Versuch starten.
>
Ich war eher positiv überrascht, dass überhaupt "so viele" eine Stimme
abgegeben haben. Einen Überblick, was sonst so übliche
Teilnehmerzahlen sind, habe ich aber nicht. Die
"Repräsentativitätskeule" wird ohnehin immer von Gegnern eines
proposals gezückt werden. Wir haben eben keine guten Mechanismen zur
quantitativen Meinungsforschung. Das Argument der
"Nichtrepräsentativität" funktioniert also faktisch immer. Als
qualitativ nutzbares Meinungsbild taugt die Abstimmung zumindest im
Ansatz.

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 unser Meinungsfindungsverfahren mit ihren Abstimmungsprozessen
nicht besonders gut sind, ist bekannt. Wir haben leider bisher nichts
besseres. Ich fände es toll, wenn man ein Verfahren hätten, bei dem
Beispielsweise alle, die in einem bestimmten Zeitraum ein relevantes
Objekt bearbeiten oder erstellen (z.B. Polygon) zur Abstimmung
aufgefordert würden. Dann hätte man zumindest von denen, die damit
arbeiten, ein repräsentatives Meinungsbild. Dann könnte man die
Gesamtstimmungslage zu einem Proposal besser einfangen.

> @Tigerfell Denk mal bitte darüber nach, ob du das hier so wirklich
> durchziehen möchtest oder du nicht auch einen Abbruch für sinnvoll
> erachtest.
>
Das Ergebnis wird nicht repräsentativer, wenn wir nochmal darüber
abstimmen. Ob das überhaupt gelingt, weil bei Formulierungsänderungen
ggf. auch neu diskutiert werden muss, ist für mich ohnehin fraglich.

Falk

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

Re: [Talk-de] service=driveway für alles was service ist?

[Falk Zscheile]

Am Mi., 28. Nov. 2018 um 08:19 Uhr schrieb Florian Lohoff :

> Hi,
> ich habe eine Diskussion zum Thema highway=service/service=driveway
> angezettelt weil [...].
>
> Ich halte das für falsch - [...].
>
> In https://wiki.openstreetmap.org/wiki/DE:Tag:highway%3Dservice
> ist das 2016 geändert worden von:
>
> "Ein driveway ist eine Auffahrt. Damit ist oft eine private
> Zufahrtsstraße gemeint, die zu einem Haus oder einer Firma führt."
>
> zu
>
> "Zufahrtsweg zu einem Wohn-, Geschäfts- oder Firmengrundstück"
>
> Letzteres ist Sprachlich natürlich schöner, ist aber in der Bedeutung
> nicht identisch zu ersterem.
>
> "Auffahrt" ist eher was ich als sub 100m bezeichne. Kleine Stiche auf
> die Grundstücke. Nicht alle Wege auf einem IKEA Gelände oder
> 300m lange Zufahrten zu farmyards.
>
> Genau so wird das aber gerade interpretiert. Quasi alles was irgendwie
> mal als Zufahrt zu irgendwas dienen kann ist jetzt ein driveway.
>
> Meinungen?
>
>
Dein Verständnis zu driveway deckt sich mit dem meinigen. Das sind auch für
mich kurze Wege/Straßen, die als Zufahrt auf Grundstücke dienen (und keine
darüber hinausgehende Erschließungsfunktion für das Grundstück haben).

Auch aus kartographischer Sicht macht das Sinn. Aus den Karten lassen
unsere OpenStreetMap Kartographen den driveway deutlich früher
verschwinden, als einen normalen highway=service. Kurze Auffahrten zu
Wohngrundstücken ballern nur unnötig die Karte zu (weil wir Straßen von der
breite her Überproportional zur tatsächlichen Breite darstellen) und
liefern keinen Mehrwert. Längere Straßenstücke auf Firmengeländen haben
einen darüber hinausgehenden Informationswert, weil sie länger sind und
eben Parkplätze oder Gebäude straßentechnisch verbinden. service=driveway
sollte also kein Fülltag für  highway=service sein, dem ein Subtag fehlt.

Soweit meine Meinung dazu.

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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Falk Zscheile]

Ich möchte das ganze im Folgenden versuchen ein wenig auf eine
Meta-Ebene zu heben, möchte aber nicht verhelen, dass ich auf
highway=value geklebte landuse=value nicht mag bzw. ablehnend
gegenüber stehe. Aber auch ich habe mal als "Verkleber" angefangen:

Abgesehen von der Sinnhaftigkeit (keine Metaebene) gibt es auf der
Metaebene folgende Aspekte:

1. Durch die snap-Funktion im JOSM lassen landuse und highway viel
leichter verbinden, als wieder trennen. Dadurch haben die
"Verschmelzer" beim Mappen einen taktischen und zeitlichen Vorteil
gegenüber den "Trennern".

2. Das getrennte erfassen erfordert mehr Genauigkeit. Man muss viel
weiter hineinzoomen, um Flächen zu erfassen, damit man nicht selbst
"Opfer" der snap-Funktion von JOSM wird. Man hat also einen kleineren
Kartenausschnitt auf dem Bildschirm. Hierdurch benötigt man mehr Zeit
und muss trotzdem aufpassen (wegen der snap-Funktion). Auch Mapper
sind sind nur Menschen, also bequem und möchten trotzdem viel pro
Zeiteinheit schaffen. Auch das ist ein strategischer Nachteil der
getrennten Erfassung. Die Verschmelzer sind faktisch im Vorteil, weil
sie mehr pro Zeiteinheit Mappen können. Dann können sie ggf. auch noch
sagen, "Seht her, in den Daten ist viel mehr verklebt als getrennt!
Wir sind die Mehrheit, wir haben Recht!"

3. Durch das verschmelzen sieht die Datenbasis im JOSM auch besser --
weil aufgeräumter wirkend -- aus, als mehrere parallele Linien. Man
sollte diesen ästhetischen Aspekt nicht vernachlässigen. Wir sind ein
Projekt, das von Laien getragen wird. Da spielen solche Aspekte eine
viel größere Rolle, als in einem professionellen Umfeld mit
festgefügten Regeln und Normen (wir müssen Regeln und Normen erst
finden und ständig darüber diskutieren).

4. Menschliches Beharrungsvermögen: Niemand gibt gern Gewohnheiten
auf. Warum sollte also ein "Verschmelzer" sich ändern? Zumal der
Verschmelzer merkt, dass die andere Methode aufwendiger ist und mehr
Sorgfalt erfordert. (Vielleicht liegt die Sorgfalt auch nicht so in
seiner Natur, wogegen die "Trenner" eher von pingeliger Natur sind).

5. Eine eigene Ausprägung von Beharrungsvermögen ist: Die Arbeit des
"Verschmelzers", das Verschmelzen, wird ein Stück weit entwertet, wenn
jetzt immer getrennt werden soll. Niemand sieht seine Arbeit gern
entwertet und wird daher immer alles versuchen, diese zu erhalten und
gegen Änderungen zu verteidigen.

6. Eine weitere Ausprägung des Beharrungsvermögens findet sich auch
bei der Regeldiskussion "das ist so nicht/anders Dokumentiert".
Einerseits sind Regeln sehr wichtig, weil erst sie eine Basis geben,
auf der man gemeinsam arbeiten kann. Andererseits ändern sich die
Gegebenheiten, auf denen die Regeln basieren. Vor fünf Jahren war man
froh ein einigermaßen vollständiges Straßennetz (DE) zu haben. Da
wollte man nicht über Straßenflächen diskutieren und gab sich
entsprechende Regeln. Doch warum sollen die Regeln heute noch gelten?
Die Regeln bei OSM sind ja nicht die (universell gültigen)
Menschenrechte. Also: geänderte Situation, geänderte Regeln. Das
Problem: Man erkennt quasi immer nur in der Retrospektive, ob sich die
Situation tatsächlich geändert hat. Da also niemand aus der Zukunft
zurückblicken kann, entstehen solche langen Threads zwischen
"Verklebern" und "Trennern".

Daraus folgt für mich auf der Handlungsebene:

Bei den Punkten 1. bis 3. muss auf Ebene der Werkzeuge zunächst
Waffengleichheit zwischen Verklebern und Trennern hergestellt werden!

Bei den Punkten 1. bis 3. wünsche ich mir einfach einen mutigen
Entwickler, der eine Warnung einbaut, wenn landuse als Fläche und
highway als way miteinander verbunden werden sollen. Problem: Wir
zeichnen erst die Geometrie und geben dann die Eigenschaften/Tags.
Aufgrund meiner Grundauffassung sollte das überhaupt nicht möglich
sein bzw. um den Verschmelzern nicht auf die Füße zu treten nur als
"opt in". Dann wäre zumindest was die Schwierigkeit angeht
einigermaßen Waffengleichheit hergestellt und neue Mapper kommen nicht
mehr so leicht in Versuchung zum "Verkleber" zu werden.

Eine schöne Lösung wäre es auch, wenn die snap-Funktion bei highways
nicht funktionieren würde (zumindest nicht für ways, die noch keine
Tags haben und generell nicht für landuse auf highway).

Wichtig ist, dass man das snap-Verhalten von landuse auf highway (way)
in der Grundfunktion abstellt, damit die Leute gar nicht erst
"klebstoffsüchtig" [Entschuldigung für den Kalauer] werden. Dann
stellen sich die Probleme aus Nr. 4 bis 6 nicht in gleichem Maße. Dann
erledigt sich das Problem in einem gewissen Maß von selbst. "Es wächst
sich raus."

Eine andere Möglichkeit ist es endlich handliche Tools zu entwickeln,
die das Entkleben genauso einfach machen, wie das Verkleben. Das hat
aber die große Gefahr von "edit wars".

An den Punkten 4. bis 6. kann man ansonsten in einem
Freiwilligenprojekt nicht viel ändern, außer vielleicht, das die
Beteiligten selbst Reflektieren, mal was anderes ausprobieren und dann
zu dem Ergebnis kommen "ist ja gar 

Re: [Talk-de] Navads-Tankstellenimport

[Falk Zscheile]

Am 29. März 2018 um 00:27 schrieb Tom Pfeifer :

> Wenn ich eine lokale Tanke herangezoomt habe, und als "good" bestätige,
> werde ich mit Überlichtgeschwindigkeit an einen anderen Ort in DE gebeamt,
> von dessen Existenz ich bisher nicht einmal geahnt habe.

Das folgende Vorgehen löst das Problem:

1. auf http://audit.osmz.ru/profile gehen
2. ggf. einloggen,
3. ein Rechteck über die Region ziehen, die man begutachten möchte
4. return -- man kommt (wieder) auf die Einstiegsseite mit den zu
validierenden Importen (http://audit.osmz.ru/)
5. wenn man nun "NavAds Fuel Stations Import (Germany)" auswählt
6. erscheinen nur noch Einträge aus dem unter 3. gewählten Bereich

Ich hoffe das macht es leichter.

Viele Grüße
Falk

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

Re: [Talk-de] Navads-Tankstellenimport

[Falk Zscheile]

Am 29. März 2018 um 00:27 schrieb Tom Pfeifer <t.pfei...@computer.org>:
> On 28.03.2018 23:06, Falk Zscheile wrote:
>>
>> Am 28. März 2018 um 21:58 schrieb Harald Hartmann
>> <osm-talk...@haraldhartmann.de>:
>>>
>>> Hmm, geht's wohl schon in die nächste Runde?
>>>
>>> weiter geht's mit http://audit.osmz.ru/project/navads_fuel_de
>>
>>
>> Das finde ich jetzt schon ziemlich gut. Man kann nun für jedes Node
>> sagen, ob man die Änderungen haben möchte oder nicht. Das sollte die
>> Qualität des (potentiellen) Imports deutlich verbessern und Datenmüll
>> vermeiden. Und einen Fortschrittsbalken, wie viele Daten schon geprüft
>> wurden, gibt es auch :-)
>
>
> Wenn ich eine lokale Tanke herangezoomt habe, und als "good" bestätige,
> werde ich mit Überlichtgeschwindigkeit an einen anderen Ort in DE gebeamt,
> von dessen Existenz ich bisher nicht einmal geahnt habe.

Ich habe Ilya eine Mail geschrieben, mit der Bitte, dieses
Rouletteverhalten  abzustellen bzw. eine entsprechende Option zu
implementieren.

> Nach lokaler
> Überprüfung sieht das dann nicht mehr aus.
>
Es ist noch nicht perfekt. Aber gegenüber dem ursprünglichen Plan ist
das ein riesiger Fortschritt und die Umsetzung ist sehr schnell
erfolgt. Ich finde schon, dass das einen gewissen Vorbildcharakter
hat. Wir haben schon immer Mapper, die über die ganze Republik nach
Fehlern suchen und berichtigen. Wichtig ist, dass lokale Kontrolle
möglich ist. Vielleicht motiviert es ja den einen oder anderen Mapper,
bei widersprechenden Öffnungszeiten noch einmal vor Ort zu
kontrollieren.

Gruß Falk

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

Re: [Talk-de] Navads-Tankstellenimport

[Falk Zscheile]

Am 28. März 2018 um 21:58 schrieb Harald Hartmann
:
> Hmm, geht's wohl schon in die nächste Runde?
>
> weiter geht's mit http://audit.osmz.ru/project/navads_fuel_de
>
Vielen Dank für den Hinweis.

Das finde ich jetzt schon ziemlich gut. Man kann nun für jedes Node
sagen, ob man die Änderungen haben möchte oder nicht. Das sollte die
Qualität des (potentiellen) Imports deutlich verbessern und Datenmüll
vermeiden. Und einen Fortschrittsbalken, wie viele Daten schon geprüft
wurden, gibt es auch :-)

Gruß, Falk

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

Re: [Talk-de] Navads-Tankstellenimport

[Falk Zscheile]

Moin,

wenn es auf eine ja/nein Entscheidung (also ohne
Kompromissmöglichkeiten) hinaus läuft, dann hast
 du für den Text meine Rückendeckung.

Ansonsten ist die Darstellung ja schon so ausgefuchst, dass es für den
Importwilligen möglich sein sollte, an die einzelnen Daten eine
Auswahlmöglichkeit für deutsche Mapper hinzuzufügen: ja, bitte
importieren, nein, dieses Datum nicht importieren (weil irgendetwas
nicht stimmt).

Ein Großteil der Daten passt ja vermutlich, so das eine opt in Lösung
für mich ein guter Kompromiss für Deutschland wäre. Wir sind eine so
große Community, dass der Datensatz sicher in kurzer Zeit geprüft und
dann fit für den Import wäre. Falls er von den Mappern nicht geprüft
wird, also keine Freigabe für die einzelnen Daten erfolgt, dann wäre
das eine Abstimmung mit den Füßen, dass man den Import nicht wünscht.

Gruß Falk

Am 27. März 2018 um 23:10 schrieb Michael Reichert :
> Hallo,
>
> Am 26.03.2018 um 23:50 schrieb Michael Reichert:
>> Falls euch solche oder andere Fehler auffallen, so meldet euch bitte
>> hier oder direkt auf der Imports-Mailingliste.
>
> ich bin euch für eure Kommentare und Fehlermeldungen sehr dankbar. Wenn
> ich die Community vertreten würde, würde ich meine Auflistung der
> gefundenen Fehler mit folgenden Worten abschließen:
>
>> (Zusammenfassung eurer Kommentare und Fehlerberichte)
>>
>> German POI data is not complete and will never be complete. We welcome help 
>> to improve the POI data in Germany. However, the quality of the import does 
>> not meet our expectations. We ourselves have also areas which do not have 
>> active mappers who take care for their area. Therefore, errors introduced by 
>> the import in this area will not be fixed. In addition, it is not the task 
>> of us, the *volunteers*, to fix a commercial dataset.
>>
>> *This import is against the interests of the German OSM community* Providing 
>> a list or a diff between the Navads dataset and OSM is welcomed and will 
>> help us to improve our work without increasing the burden for the manager of 
>> the import to invest more work into fixing all the errors of the data and 
>> the software.
>>
>> Best regards
>>
>> Michael Reichert aka Nakaner
>> after discussion and on behalf of the German OpenStreetMap community on the 
>> German OSM Forum and the Talk-de mailing list
>
> Deutsche Übersetzung:
>> (Zusammenfassung eurer Kommentare und Fehlerberichte)
>>
>> POI-Daten sind auch in Deutschland unvollständig und werden unvollständig 
>> bleiben. Wir begrüßen Unterstützung bei der Verbesserung des 
>> POI-Datenbestands in Deutschland. Trotzdem entspricht die Datenqualität des 
>> Imports nicht unseren Erwartungen. Wir selbst haben auch Gegenden ohne 
>> aktive Mapper, die sich um ihre Gegend kümmern. Daher werden Fehler, die der 
>> Import mit sich bringt, nicht behoben werden. Außerdem ist es nicht die 
>> unsere Aufgabe als *Freiwillige* den Datenbestand eines kommerziellen 
>> Anbieters zu verbessern.
>>
>> *Dieser Import ist gegen die Interessen der deutschen OSM-Community*. Das 
>> Anbieten einer Liste oder der Unterschiede zwischen dem Navads-Datenbestand 
>> und OSM ist gern gesehen und hilft uns, unser Werk zu verbessern, ohne die 
>> Aufwand des Importmanagers in die Verbesserung der Daten oder der Software 
>> zu erhöhen.
>>
>> Viele Grüße
>>
>> Michael Reichert aka Nakaner
>> nach Diskussion und im Namen der deutschen OpenStreetMap-Community im 
>> deutschen OSM-Forum und auf der Mailingliste Talk-de
>
> Fühlt sich jemand von diesen Worten nicht ausreichend repräsentiert?
> Vertritt jemand eine abweichende Meinung und möchte diese kundtun?
> Verbesserungsvorschläge für diese Zusammenfassung sind ausdrücklich
> willkommen.
>
> 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)
>
>
>
>
> ___
> 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] Navads-Tankstellenimport

[Falk Zscheile]

Hier liegt ein Fehler vor (keine Tankstelle vorhanden). Etwas weiter
im Nordwesten gibt es eine Tankstelle in meiner Erinnerung ist das
aber nicht Aral:

http://audit.osmz.ru/browse/navads_fuel/NVDS114_27007300DE1

Hier passen name (Jet) und das neu hinzugefügte brand (avia) nicht zueinander:

http://audit.osmz.ru/browse/navads_fuel/NVDS126_3243


Zudem scheint der Import auch Betriebs- oder Firmentankstellen
mitzubringen, aber das lässt sich aus der Ferne nur schwer sagen. Für
mich sehen diese Stellen aus der Ferne nach LKW-Diesel Stationen aus,
die nicht zwingend öffentlich zugänglich sein müssen:

http://audit.osmz.ru/browse/navads_fuel/NVDS126_3043 (Gelände der
"Regionalbus Rostock")
http://audit.osmz.ru/browse/navads_fuel/NVDS126_3243
http://audit.osmz.ru/browse/navads_fuel/NVDS126_3042

Grüße Falk

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

Re: [Talk-de] OpenMetroMaps - Ideenwerkstatt am 11. Februar 2018 in Berlin

[Falk Zscheile]

Moin,

Am 7. Februar 2018 um 09:20 schrieb Frederik Ramm :

> On 02/05/18 19:14, Stefan Kaufmann wrote:
>>> Bei OSM sind wir da
>>> anderer Meinung, schließlich beanspruchen wir sogar Schutzrechte auf
>>> unsere Faktensammlung (und in Europa gibt es diese Rechte auch).
>>
>> „Wir“ finde ich eine etwas sportliche Aussage. Ich z.B. finde diese
>> Haltung gefaehrlich.
>
> Ja, natürlich gibt es in OSM eine große Breite verschiedener Meinungen.
> Die Meinung, die sich am Ende eines rund fünf Jahre dauernden Prozesses
> durchgesetzt hat und die OSM als Projekt daher vertritt, ist allerdings
> die, dass unsere Daten als Datensammlung ein Schutzrecht geniessen, das
> wir mit Hilfe unserer ODbL-Lizenz gestalten.
>
>

Wer sich näher für des Schutz der OpenStreetMap-Daten als Datenbank
(Datenbankherstellerrecht) und deren lizenzrechtliche Handhabung durch
die ODbL interessiert, der ist herzlich in meinem Workshop zur ODbL
auf der diesjährigen FOSSGIS-Konferenz eingeladen:

https://www.fossgis-konferenz.de/2018/programm/event.php?id=5269

Viele Grüß
Falk

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

Re: [Talk-de] Chemnitzer Linuxtage 2018

[Falk Zscheile]

Moin,

kann jemand sagen, ob mittlerweile eine Anmeldung von OSM für die CLT
2018 erfolgt ist?

Viele Grüße
Falk

Am 5. Januar 2018 um 08:49 schrieb André Riedel :
> Hallo Lars,
>
> ich hatte in den letzten Jahren immer die Anmeldung organisiert. In
> diesem Jahr soll es natürlich auch wieder einen Stand geben, die
> Anmeldung wird fristgerecht eingereicht.
>
> Wer möchte darf sich gern für einen Betreuungsstand melden. Die
> meisten Fragen kommen zu Themen, wie etwas gemappt wird oder was es
> neues gibt. Die tiefergehenden Fragen können dann gern an die
> „Spezialisten“ verwiesen werden, das hat in den letzten Jahren gut
> funktioniert. Man muss nicht die ganze Zeit am Stand sein, jeder wird
> die Chance haben interessante Vorträge zu besuchen. Als Dankeschön
> gibt es von den Chemnitzer Linuxtagen am Samstag Abend ein tolles
> Buffet mit allen bekannten Gesichtern der OSS-Welt.
>
> Beste Grüße
> André
>
> Am 29. Dezember 2017 um 00:50 schrieb lars lingner :
>> Hallo zusammen,
>>
>> auf dem 34C3 wurde ich heute gefragt, warum von OSM bisher keine
>> Anmeldung für die Chemnitzer Linuxtage 2018 [1] kam. Die Frage konnte
>> ich nicht beantworten und ich muss gestehen, ich war auch noch nie dabei.
>>
>> Es wäre laut OSM-Wiki [2] das 10. Jahr mit OSM-Beteiligung. Irgendwie
>> muss OSM auch einen positiven Eindruck hinterlassen haben, wenn man auf
>> eine fehlende Anmeldung hingewiesen wird.
>>
>> Besteht denn Interesse einen Stand auf den CLT zu haben? Gibt es Hürden?
>> Wird Hilfe benötigt?
>>
>> Eine Anmeldung ist noch bis 08.01.2018 möglich.
>>
>>
>> Viele Grüße vom 34C3,
>>
>> Lars
>>
>>
>> [1] https://chemnitzer.linux-tage.de
>> [2] http://wiki.openstreetmap.org/wiki/Chemnitzer_Linux-Tage_2017
>
> ___
> 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

[Talk-de] OSGeo/FOSSGIS/OSM-Stand auf der FrOSCon

[Falk Zscheile]

Moin,

ich möchte im Folgenden eine kurze Rückmeldung vom
OSGeo/FOSSGIS/OSM-Stand auf der diesjährigen FrOSCon geben.

Der Aufbau des Standes wurde von unseren Organisatoren der OSGeo & OSM
Subkonferenz gleich mit erledigt. Als ich am späten Nachmittag
hinzukam, war schon fast alles ferig "aufgetischt".

Die Standbetreuung wurde am Samstag im wesentlichen von Astrid, Harald
und mir übernommen, wobei Astrid später ins Videoteam für die
Subkonferenz wechselte. Die Fragen zu FOSS haben wir dann nach bestem
Wissen und Gewissen beantwortet, denn der Wissensschwerpunkt am Stand
lag nach dem Wechsel eindeutig im Bereich OSM. Am Sonntag waren dann
Harald und ich wieder für Fragen der Besucher am Stand bevor Harald
allein das Zepter übernahm, weil mich das Abenteuer einer langen
Bahnreise rief ...

Das Interesse an der Arbeit von OpenStreetMap ist nach meinem Eindruck
ungebrochen. Die Gespräche und Nachfragen am Stand hatten ein sehr
weites Spektrum, dass von "Was macht ihr eigentlich?", "Wie weit seid
ihr inzwischen? Ich habe vor Jahren auch mal etwas beigetragen.", bis
hin zu ganz konkreten Fragen zum Taggig oder zur Anwendung der
Daten/Karten ging. Aber auch Fragen wie: "Warum bietet ihr nicht den
gleichen Service wie Google?" waren dabei.

Für mich hat sich hierbei gezeigt, dass OpenStreetMap einen so breiten
Anwendungsbereich hat, dass es unmöglich ist, bei allen Themen so
umfassend zu antworten, wie man es eigentlich möchte. Hier hat sich
gezeigt, dass die Arbeit, die das Videoteam seit Jahren auf den
FOSSGIS-Konferenzen leistet (danke!), Gold wert ist. Den Fragestellern
konnte ich dann zumindest mit dem Verweis auf die eine oder andere
Viedeoaufzeichnung weiterhelfen.

Die OSM-Flyer und die Karten mit der Ankündigung der FOSSGIS-Konferenz
in Bonn waren bereits am ersten Tag vergriffen aber zum Glück gibt es
Smartphones. So fand die Verbreitung der Informationen am zweiten Tag
auf digitalem Weg durch Abfotografieren statt.

Für mich war es die erste Standbetreuung für FOSSGIS/OSM. Schon allein
für die vielen positiven Rückmeldungen, die zum Projekt am Stand
ankamen, hat es sich gelohnt, dabei zu sein. Auch wenn wir intern oft
mit uns hadern, weil es scheinbar nicht schnell genug oder nicht
"richtig" voran geht -- von außen werden wir als durchaus erfolgreich
wahrgenommen. Ich kann also jedem, der gerade mal wieder mit sich und
dem Projekt hadert, eine solche Standbetreuung empfehlen. Die
Rückmeldungen zeigen, dass sich die Beiträge aller Beitragenden (vom
Kritiker über den Macher bis hin zum Beharrer) lohnen und dass die so
entstandenen Ergebnisse außerhalb der Community große Anerkennung
erfahren.

Viele Grüße Falk

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

Re: [Talk-de] Nautische Sperrgebiete [war: Farbe des Meeres in OSM-Carto]

[Falk Zscheile]

2. Anstatt von military als Schlüssel evtl navy verwenden, also navy=danger_area

3. Den der gewarnt wird/für den es gefährlich wird als Schlüssel
verwenden: mariners=danger_area danger_area=military (orientiert an
aviation=danger_area)

Im Ergebnis würde mir das OSeaM Tag völlig reichen, aber Puristen
werden hier einwenden, das OSeaM ein eigenes extravagantes von OSM
abweichendes Taggingschema verwendet. Aber wenn es hilft doppeltes
Tagging unnötig zu machen und gleichzeitig kartographische Sündenfälle
vermieden werden können -- dann bekommt es meinen Segen. Man muss das
Rad ja nicht doppelt erfinden.

Gruß Falk

Gruß Falk

Am 16. August 2017 um 14:59 schrieb Falk Zscheile <falk.zsche...@gmail.com>:
> Es läuft ja darauf hinaus, dass wir das verwendete
> military=danger_area für Seegebiete ablösen, weil es dort (anders als
> an Land nicht passt). durch ein anderes Tag kann man das bei OSM zum
> Ausdruck bringen.
>
> Mir Fallen die folgenden Lösungen ein:
>
> 1. Löschen von military=danger_area und ausschließlicher Rückgriff auf
> das OSeaM-Tag seamark:restricted_area:category=military
>
>
> Am 15. August 2017 um 16:55 schrieb chris66 <chris66...@gmx.de>:
>> Am 15.08.2017 um 16:46 schrieb Markus:
>>
>>> Für das Rendering in Seekarten gibt es international genormte Icons und
>>> Farben.
>>
>>
>> Danke für die ausführliche Info.
>>
>> Nun ist die Frage, das bestehende Tagging (military=danger_area) so belassen
>> oder durch was anderes zu ersetzen, zB.:
>>
>> military=restricted_area oder
>> seamark:xxx=yyy (falls es bei den Kollegen schon was gibt).
>>
>> Chris
>>
>>
>>
>>
>>
>> ___
>> 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] Nautische Sperrgebiete [war: Farbe des Meeres in OSM-Carto]

[Falk Zscheile]

Es läuft ja darauf hinaus, dass wir das verwendete
military=danger_area für Seegebiete ablösen, weil es dort (anders als
an Land nicht passt). durch ein anderes Tag kann man das bei OSM zum
Ausdruck bringen.

Mir Fallen die folgenden Lösungen ein:

1. Löschen von military=danger_area und ausschließlicher Rückgriff auf
das OSeaM-Tag seamark:restricted_area:category=military


Am 15. August 2017 um 16:55 schrieb chris66 :
> Am 15.08.2017 um 16:46 schrieb Markus:
>
>> Für das Rendering in Seekarten gibt es international genormte Icons und
>> Farben.
>
>
> Danke für die ausführliche Info.
>
> Nun ist die Frage, das bestehende Tagging (military=danger_area) so belassen
> oder durch was anderes zu ersetzen, zB.:
>
> military=restricted_area oder
> seamark:xxx=yyy (falls es bei den Kollegen schon was gibt).
>
> Chris
>
>
>
>
>
> ___
> 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] Farbe des Meeres in OSM-Carto

[Falk Zscheile]

In der Ostsee gibt es ein ähnliches kartographisches "Ärgernis":

http://www.openstreetmap.org/way/173480188#map=10/54.3993/14.0570=N

2017-08-15 13:30 GMT+02:00 Hartmut Holzgraefe :
> name=Danger Area Sylt A
>
> Das dürfte seinen Grund haben warum das rot ist..
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

Kartographisch ist es auf jeden Fall nicht schön, weil viel zu
prominent dargestell. Das Verbot (wenn überhaupt, s.u,) richtet sich
nur an die Schifffahrt. Was an Land als Sperrgebiet bei dieser
Kartendarstellung Sinn macht, macht es noch lange nicht auf hoher See.

Bei OSM kann man sich über das richtige Tagging ja vortrefflich
streiten, ohne zu einem Ergebnis zu kommen. Meines erachtens ist es
nicht nur kartographisch unschön dargestellt, sondern auch tatsächlich
 falsch.

militay=danger_area soll ja so etwas wie ein Gebiet mit
schwerpunktmäßig militärischer Nutzung und korrespondierender Verbote
für zivilisten markieren.

Dagegen spricht meines Erachtens, dass sich die danger_area teilweise
außerhalb der 12 Seemeilenzone befindet. Dort gibt es keine
Staatsgewalt, die einem das Betreten oder Befahren einfach mal so
verbieten kann. Und auch innerhalb der 12 Seemeilenzone besteht das
Recht der friedlichen Durchfahrt. Ein tagging was in Richtung
gesperrtes oder verbotenes Gebiet geht, ist daher meines Erachtens
nicht haltbar.

Zudem laufen ganz reguläre Fährlinien durch diese Gebiete (in der
Ostsee). Würde es sich um gesperrte, verbotene oder besonders
(lebens-) gefährliche Gebiete handeln, dann wäre dass  kaum der Fall.

Auch ein Blick in OpenSeaMap zeigt anhand der Betonnung und der
Fahrzeuge (AIS), dass es sich im Grunde um normal genutztes Seegebiet
handelt.

Die Bekanntmachungen für Seefahrer, durch welche diese Gebiete
eingerichtet/bekannt gemacht wurden kann ich leider nicht mehr finden.
Grob umschrieben sind es (wohl) Gebiete, in denen potentiell
militärische Übungen stattfinden können und dann besondere
Aufmerksamkeit durch die Schifffahrt geboten ist, mehr aber auch
nicht. Vielleicht wissen die eingefleischten OpenSeaMapper mehr dazu?

Gruß Falk

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

Re: [Talk-de] Drei Tage mit dem Plug-In Hybrid

[Falk Zscheile]

Am 30. März 2017 um 14:14 schrieb Harald Hartmann
:
> Am 30.03.2017 um 09:17 schrieb Uwe Sennewald:
>> Habt ihr schon mal was von LEMnet ( http://www.lemnet.org/de ) gehört ?
>> Die nutzen OSM , müllen es aber mit den Informationen zu den
>> Ladestationen nicht voll.
>
> Hmm, und in wie weit nutzen die OSM? Also die ersten Stickpunkte die ich
> so gemacht habe, lässt den Eindruck erwecken, dass sie NUR einfach eine
> OSM Karte (Tiles) verwenden, von den angezeigten POIs
> (amenity=charging_station, etc.) war kein einziger in der OSM Datenbank.
>
Wenn ich Uwes E-Mail richtig verstanden habe, dann soll es gerade ein
großer Vorteil von LEMnet sein, dass die Ladesäulen außerhalb der
OSM-Datenbank gepflegt werden. Da kann man sicher unterschiedlicher
Ansicht sein ...

Auf der FOSSGIS 2017 gab es einen interessanten Vortrag zu der Frage,
wo Ladesäulen im Idealfall errichtet werden sollten:
https://www.fossgis-konferenz.de/2017/programm/event.php?id=5185

Das löst natürlich leider das aktuelle Ladesäulenproblem nicht im geringsten ...

Gruß Falk

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

Re: [Talk-de] Mobile Verkaufsstände

[Falk Zscheile]

Moin,

ich stelle mir gerade vor, wie das in der Datenbank aussieht, wenn
dort Montags der Hähnchengrill steht, Dienstags der Fischhändler ...
Dann gibt es neben dem Wochenmarkt noch den Oster-, Pfingst- und
Weihnachtsmarkt, die auch alle key=intermittent sind. Eine gewisse
dauerhafte Verbundenheit mit der Erdoberfläche sollten unsere
(Geo-)Daten schon haben.

Ich würde daher derlei bewegliche aber regelmäßig wiederkehrende
Verkaufsstände nicht in der Datenbank erfassen.

Gruß Falk

Am 13. Juli 2016 um 11:27 schrieb Carl von Einem :
> Hi,
>
> auch Wochenmärkte [1] sind nur einmal wöchentlich für ein paar Stunden in
> Betrieb, und ausserhalb der Zeit deutet an der Stelle nichts darauf hin.
> Meistens auf einem Platz oder am Rand einer Strasse, aber teilweise ist dann
> sogar die entsprechende Strasse in der Zeit für die Verkaufswägen gesperrt.
>
> Und Wochenmarkt-Händler sowie Hendlgriller dürften langfristige
> Genehmigungen für Stellplatz und Betriebszeit von der jeweiligen Kommune
> haben.
>
> Dann gibt es noch Bücherbusse [2] und sogar mobile Bankfilialen, die ähnlich
> kurze, aber regelmässige Öffnungszeiten an einem festgelegten Ort haben.
>
> Und als "tag, der signalisiert, dass das Teil da in 95% der Zeit in der man
> vorbeikommt überhaupt nicht anzutreffen ist", würde ich opening_hours
> vorschlagen.
>
> Gruss,
> Carl
>
> [1] https://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dmarketplace
> [2] https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dmobile_library
>
> Sven Geggus wrote on 13.07.16 10:37:
>>
>> Moin,
>>
>> in meinem Umfeld hat jemand einen mobilen Hähnchengrill als
>> amenity=fast_food erfasst.
>>
>> Ich selbst habe das Teil an dieser Stelle noch nie gesehen, was wohl daran
>> liegt, dass ich selten Mittwochs zwischen 11Uhr und 19Uhr an dieser Stelle
>> vorbeikomme.
>>
>> http://www.openstreetmap.org/node/3630432095
>>
>> Nun frage ich mich ob sowas überhaupt in die Datenbank gehört.
>>
>> Wie seht ihr das?
>>
>> Wenn ja, gibt es einen Tag, der signalisiert, dass das Teil da in 95% der
>> Zeit in der man vorbeikommt überhaupt nicht anzutreffen ist?
>>
>> Sven
>>
>
> ___
> 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] Verwendung von Markenlogos in Karten?

[Falk Zscheile]

Am 11. Juni 2016 um 14:20 schrieb gmbo :
> Am 11.06.2016 um 13:21 schrieb Eifelhunde:
>>
>>
>>
>> Am 08.06.2016 um 16:33 schrieb Sven Geggus:
>>>
>>> Nun sind dies Logos aber natürlich alles registrierte Marken das heißt es
>>> dürfte illegal sein, diese in einer öffentlichen karte zu verwenden.
>>
>>
>> Wikipedia verwendet die auch über die Jahre ohne das sich wer beschwert
>> hat.
>>
>
> In Wikipedia dürfen die Logos nur dort verwendet werden, wo der Artikel
> eindeutig nur über die Marke geschrieben ist. Also ein eindeutiger
> Zusammenhang zur Marke besteht.
>
> Da ist es bei der Karte nicht so einfach. Im Normalfall wird das Markenlogo
> zwar richtig verwendet, aber Wie ich scon schrieb müsste dann wirklich
> Eindeutigkeit herschen.
> Und die ist bei unserem Tagging nicht gegeben.
> Wir können nicht unterscheiden ist es Aldi Nord oder Süd. Gut hier wäre es
> möglich beide Logos zu einem  zu machen.
> Bei Netto und Netto Marken Discount geht es aber nicht.
>

Hallo,

ob eine Marke ohne Lizenz/Gestattung des Markeninhabers genutzt werden
darf, das richtet sich im vorliegenden Fall nach § 23 MarkenG:

"Der Inhaber einer Marke oder einer geschäftlichen Bezeichnung hat
nicht das Recht, einem Dritten zu untersagen, im geschäftlichen
Verkehr

[...]

2. ein mit der Marke oder der geschäftlichen Bezeichnung identisches
Zeichen oder ein ähnliches Zeichen als Angabe über Merkmale oder
Eigenschaften von Waren oder Dienstleistungen, wie insbesondere ihre
Art, ihre Beschaffenheit, ihre Bestimmung, ihren Wert, ihre
geographische Herkunft oder die Zeit ihrer Herstellung oder ihrer
Erbringung, zu benutzen,

 [...]

sofern die Benutzung nicht gegen die guten Sitten verstößt."

http://www.gesetze-im-internet.de/markeng/__23.html

Gruß
Falk

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

Re: [Talk-de] Wahlbezirksgrenzen als boundary/administrative

[Falk Zscheile]

Am 15. April 2016 um 00:32 schrieb Frederik Ramm :
> Hi,
>
> On 04/14/2016 12:51 PM, Florian Lohoff wrote:
>> Irgendwie finde ich das mit dem boundary=administrative ziemlich
>> unglücklich. Auf der einen Seite ist das natürlich richtig das das
>> "Administrative" Grenzen sind - aber ich vermute das OSMAnd
>> jetzt nicht der einzige ist der sich da verwirren lässt.
>
> Wenn's nach mir geht, raus mit dem Mist. Verwaltungsgrenzen und
> PLZ-Gebiete kann ich noch einsehen. Aber Wahlkreise,
> Grundschuleinzugsgebiete, Kirchengemeindegrenzen, das Sendegebiet vom
> NDR und das Liefergebiet vom Pizzadienst sind Grenzen, die in OSM nichts
> zu suchen haben.
>

Einmal angenommen bei OSM kommen wir zu dem Konsens, dass derlei Daten
nicht in die OSM-Datenbank sollen, es aber eine relevante Gruppe gibt,
die solche Daten erheben und pflegen möchte -- welche Alternativen
gäbe es? Ist es möglich sich eine eigene Datenbank auf Basis der
OSM-API und allem drumherum aufzusetzen, um die Daten pflegen und
erfassen zu können und gleichzeitig die Tools zu Nutzen, die wir um
unsere OSM-Datenbank herum gebaut haben, z.B. JOSM?

Gruß Falk

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

Re: [Talk-de] Staatliches Gesundheitsamt

[Falk Zscheile]

Am 8. Februar 2015 um 15:59 schrieb Martin Koppenhoefer
dieterdre...@gmail.com:

 Am 07.02.2015 um 11:08 schrieb Falk Zscheile falk.zsche...@gmail.com:

 office=administrative finde ich eine gute Idee.



 -1, office trifft es m.E. nicht, dort finden (amts)ärztliche Untersuchungen 
 statt, etc., das hat nicht (nur) mit Büro zu tun


Behörden sind zunächst einmal aktenmäßiger Umgang mit
Lebenssachverhalten. Ärztliche Untersuchungen sind nichts anderes als
Tatsachenermitlungen für die Akte. An die festgestellten Tatsachen,
wie sie in der Akte liegen, knüpft sich dann eine bestimmte
Rechtsfolge, z.B. Erteilung eines Gesundheitszeugnisses etc. Also
nichts, was einer Einordnung als Office entgegen stünde. Es geht ja
bei dem Tag erst einmal um Behörden allgemein und nicht um
Gesundheitsbehörde im besonderen!

Falk

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

Re: [Talk-de] Staatliches Gesundheitsamt

[Falk Zscheile]

Am 8. Februar 2015 um 20:35 schrieb Swen Wacker swen.wac...@gmail.com:
 Am 7. Februar 2015 um 11:08 schrieb Falk Zscheile falk.zsche...@gmail.com:


 Es gibt nicht nur staatliche Behörden (die man auch noch zwischen Bund
 und Ländern differenzieren kann), sondern auch kommunale Behörden etc.
 Die deutsche Behördenstruktur aus rechtlicher Sicht abbilden zu
 wollen, dafür fehlt es OSM derzeit an Möglichkeiten


 Das Wiki sagt in http://wiki.openstreetmap.org/wiki/DE:Key:office
 office=administrative Kreis-, Gemeinde-, Verwaltungs- und
 Aufsichtsbehörden, die keine Bundes- oder Landesbehörden sind
 office=government Büro einer Regierung / Behörde / Regierungseinrichtung

 Wenn ersteres zutrifft, dann sind office=government Landes- und
 Bundesbehörden

 Damit wäre die föderale Struktur in D recht gut abgedeckt.


Ich halte die von dir zitierte Differenzierung für nicht zielführend.
Es gibt aus meiner Sicht keinen vernünftigen Grund so zu
differenzieren. In den Stadtstaaten gibt es dann nur government
wogegen es in Flächenstaaten government und administrative gibt,
obwohl die Aufgaben überall gleich sind. Wenn man diese Unterscheidung
wirklich treffen will, kann man auch auf das operator-Tag
zurückgreifen und die Trägerkörperschaft (Kommune, Kreis, Bund, Land
etc.)damit angeben.

Falk

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

Re: [Talk-de] Staatliches Gesundheitsamt

[Falk Zscheile]

Am 7. Februar 2015 um 10:34 schrieb Helmut Kauer li...@helmut-kauer.de:
 Hallo,
 wie mapt ihr ein Staatliches Gesundheitsamt?
 office= ?
 Weder Gesundheitsamt noch health agencies ergaben einen Treffer.

Vielleicht wurde soetwas noch nie gemappt.

 Hinzu kommt,
 dass auch office=administrative nicht ganz stimmt, da es sich um eine 
 staatliche
 Behörde handelt, deren Kosten aber die Kommune mit trägt (Gebäude bzw Miete
 stellt)

 Für eure Ideen schon mal danke.


office=administrative finde ich eine gute Idee.

Es gibt nicht nur staatliche Behörden (die man auch noch zwischen Bund
und Ländern differenzieren kann), sondern auch kommunale Behörden etc.
Die deutsche Behördenstruktur aus rechtlicher Sicht abbilden zu
wollen, dafür fehlt es OSM derzeit an Möglichkeiten und ich glaube
auch nicht, dass es für unsere Zwecke notwendig ist. Das ist schon
keine raumbezogene Information mehr. Aufgaben und Funktion sind
ohnehin von Staat zu Staat verschieden. Einziges ziel kann es meines
Erachtens daher sein, dass die Behörde samt Adresse gefunden wird.
Derjenige, der weiß, dass er zum Gesundheitsamt der Stadt XY muss,
sollte das als Treffer in der Datenbank und damit auch als
Kartendarstellung finden.

Gruß
Falk

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

Re: [Talk-de] Umfrageplattform

[Falk Zscheile]

Am 21. Januar 2015 um 15:22 schrieb Andreas Neumann andr-neum...@gmx.net:
 On 21.01.2015 13:23, Harald Hartmann wrote:
 Hallo Andreas,

 die abgefragten Daten werden wie folgt verwendet:
 - osm user id (fürs Unterbinden des Mehrfachvotings), changesets und
 account created (für die Auswertungen) werden an der stimme gespeichert

 Im Umkehrschluss bedeutet das aber, dass du mein Abstimmverhalten
 nachvollziehen kannst. Solange es nur um wie tagge ich was geht,
 sollte es keine Probleme geben, aber wenn persönliche Daten abgefragt
 werden (trägst du nur freudenhäuser ein, die du vorher inspiziert hast)
 könnte es problematisch werden.

Wieso? Alle personenbezogenen Daten werden nach dem
Bundesdatenschutzgesetz erst einmal gleich behandelt. Nur für
besonders sensible Daten gibt es noch gesonderte Vorschriften.
Insbesondere kann jeder in die Erhebung, Verarbeitung und Nutzung
seiner personenbezogenen Daten einwilligen, § 4 BDSG. Es gibt kein
ich nehme freiwillig an der Erhebung teil, wende mich aber gegen die
Verwendung meiner Daten zum mit der Erhebung verfolgten Zweck.

Gruß Falk

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

[Talk-de] Aufsatz: Die Änderung des Lizenzmodells von OpenStreetMap

[Falk Zscheile]

Hallo,

in Mario Martini/Georg Thiel/Astrid Röttgen (Hrsg.), Geodaten und Open
Government - Perspektiven digitaler Staatlichkeit, Speyer, November
2014 [Speyerer Forschungsberichte, Nr. 280] ist ein Aufsatz von mir
zum Thema Die Änderung des Lizenzmodells von OpenStreetMap
veröffentlicht worden.

Die Publikation ist über
http://www.foev-speyer.de/publikationen/pubdb.asp?reihen_id=1 als PDF
zugänglich. Für den Download ist allerdings die Angabe eines Namens
und einer E-Mailadresse notwendig.

Viele Grüße
Falk

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

Re: [Talk-de] Copyright-Frage: Bekanntmachung einer Verordnung des Landkreises

[Falk Zscheile]

Am 23. November 2014 um 15:25 schrieb  smart...@gmx-topmail.de:
 Hallo,

 demnach kann man die Grenze übernehmen und als source wäre einzutragen:

 Laut § 5 Abs. 1 UrhG Gemeinfrei sowie §1 Abs. 3 Verordnung über das 
 Naturschutzgebiet Veerseniederung in der Gemeinde Scheeßel und der
 Samtgemeinde Bothel im Landkreis Rotenburg (Wümme): Die Karten sind 
 Bestandteile der Verordnung.
 http://www.landkreis-row.de/city_info/display/dokument/show.cfm?region_id=160id=370106design_id=1757type_id=0titletext=1

 sehe ich das richtig?

Das ist meines Erachtens schon mehr als rechtlich notwendig wäre.
Selbst Quelle § 1 Abs. 3 VO NSG Veerseniederung wäre ausreichend. §
5 UrhG gilt unabhängig davon, ob man ihn nennt oder nicht.

Gruß Falk

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

Re: [Talk-de] Copyright-Frage: Bekanntmachung einer Verordnung des Landkreises

[Falk Zscheile]

Am 23. November 2014 um 15:16 schrieb Mark Obrembalski m...@obrembalski.de:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 23.11.2014 14:10, Frederik Ramm wrote:

 Das folgende alles von einem Nichtjuristen, also mit Vorsichtzu
 geniessen:

 Ich (kein Jurist, aber in der Rechtsdokumentation tätig) glaube, da
 könnten Juristen auch keine sichereren Aussagen machen.

So ist es. § 5 UrhG stammt aus einer Zeit, als an Open Data noch nicht
im Ansatz gedacht wurde. Im Prinzip ist es eine Transparenzregel:
Alles was unter den Tatbestand fällt soll möglichst einfach zu
verbreiten sein, damit der rechtsunterworfene Bürger möglichst leicht
Kenntnis nehmen kann. Klassischerweise stellt sich bei Gesetzen und
Verordnungen auch nicht die Frage nach einer Weiterverarbeitung. In
Gesetzen/Verordnungen veröffentlichte Karten sind insoweit ein
Sonderfall.
In § 5 Abs. 2 UrhG wird für die dort genannten Fälle durch Verweis auf
§ 62 UrhG explizit ein Veränderungsverbot angeordnet. Bei § 5 Abs. 1
UrhG fehlt eine solche Anordnung. Der Umkehrschluss ist, dass es hier
zulässig ist und eine Weiterverarbeitung einschließlich Veränderung
möglich. Aber wie gesagt, § 5 UrhG ist im Kern keine Open Data
Regelung.


Gruß Falk

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

Re: [Talk-de] Suche Ansprechpartner und Lösungsvorschlag (elotse)

[Falk Zscheile]

Am 8. November 2014 16:46 schrieb Andreas Neumann andr-neum...@gmx.net:

 Ich verstehe nur nicht, warum ich Doppeleinträge haben soll (zumal ich
 den Mist wieder irgendwie auswerten muss)? Ich verstehe nicht, warum
 beide Einträge als Firma gemappt werden sollen und ich verstehe nicht,
 was der Sinn hinter der Anweisung des Bundesministeriums ist.

Mein Blick in die Glaskugel sagt mir eher: Das Ministerium hat ein
Produkt in Auftrag gegeben und die beauftragte Firma versucht unsere
Datenbank so hinzubiegen, dass von ihr mit möglichst wenig Aufwand das
Produkt erstellt werden kann. Das stellt die beauftragte Firma dann so
dar, als ob das Ministerium zwei Einträge in der Datenbank wünscht,
dabei wünscht das Ministerium vermutlich nur zwei E-Mailadressen im
Produkt und der Rest ist dem Ministerium völlig egal. Aber das ist nur
meine Vermutung.

Gruß Falk

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

Re: [Talk-de] Unscharfe Objekte (Bucht, Berg, Gebiet, Kanal, Meeresteil, etc)

[Falk Zscheile]

Am 4. November 2014 17:21 schrieb Markus liste12a4...@gmx.de:





 Jede Zone hat eine Bezeichnung und weitere Attribute.

 _Lösungsvorschlag_
 Spezieller *DB-Layer für unscharfe Objekte*
 Spezieller Editor (oder Tool in JOSM)

 Mein Vorschlag, den ich schon mal an anderer Stelle hier auf der Liste
unterbreitete:

Aus meiner Sich muss man erst einmal unterscheiden, ob es sich um genau
umgrenztes gebiet handelt oder um ein Gebiet mit fließenden Übergängen. Für
gebiete mit fließenden Übergängen ist es m.E. ausreichend und vor allem
Sinnvoll, wenn man einzelne Tags in der Art is_in:zonenbezeichnung=value
an schon vorhandene Nodes und Ways setzt. Dann kann man zwar aus der
Datenbank nicht unmittelbar fertige Zonen extrahieren, aber schöne
Punktewolken, anhand deren Verteilung man dann die Ausdehnung des Gebietes
bestimmen kann.

Also zum Beispiel könnte die Nodes der Küstenlinie der Deutschen Bucht
is_in:bight=Deutsche Bucht bekommen genau so wie Tonnen, die in der
Deutschen Bucht liegen etc. aus der Verteilung dieses Tags könnte man dann
die Ausdehnung der  Deutschen bucht als Fläche bestimmen. Oder wenn gar
nichts anderes hilft ein is_in:sea_area=value. Wobei value immer eine Name
ist. aus einem tag lassen sich mehrere Informationen ableiten: 1. die
Gattung: sea_area, bight, etc. 2. der Name des Gebietes, 3. die Ausdehnung
des Gebietes. Das Schema würde m.E. sogar funktionieren, wenn man im Schema
auf die Gattungsbezeichnung verzichtet. Dann bekommt man immer noch die
Info hier ist ein Gebiet mit ungefähr der Ausdehnung, dass den Namen XYZ
trägt.


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

Re: [Talk-de] Karte auf openstreetmap.de defekt

[Falk Zscheile]

Am 24. Oktober 2014 15:02 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de:



 Außerdem - Der Unterschied zwischen uns und kommerziellen Kartendiensten
 ist
 ja gerade der, dass es uns egal ist, wo wer wie oft sich die Karte ansieht.
 Bei uns wird da gemappt, wo der Mapper hinfällt (vor Ort ist/Lust
 hat/Luftbilder gut sind/...). Auf sehr lange Sicht ist unser Ziel (aus
 meiner
 Sicht) eine einigermaßen gleichmäßige Erfassung weltweit, im Gegensatz zum
 kommerziellen Anbieter, der sich die Frage stellen _muss_, wie weit
 aufgelöst
 die Karte wo angeboten werden sollte. Bei OSM wird das letzte Wigwam der
 Mohikaner - falls ein Mapper vorbeikommt - mit der gleichen Sorgfalt und
 Akribie aufgenommen wie der Times Square in New York.


 Aber auch wir haben es mit knappen Ressourcen zu tun (z.B.
Rechenkapazität). Man könnte also z.B. Regionen identifizieren, wo man
einen höhere Auflösungen rendert ...

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

Re: [Talk-de] Deutsche OSM-Vertretung sinnvoll?

[Falk Zscheile]

Am 24. Oktober 2014 14:23 schrieb Michael Buege mich...@buegehome.de:


 Die Zeiten haben sich geändert, das Projekt hat sich etabliert und
 gefestigt. Neben technischen und praktischen Fragen spielen immer mehr
 Themen eine Rolle, die man mehr oder weniger als politisch bezeichnen
 kann. Da ich es persönlich bei Vereinen eher mit Groucho Marx halte,
 kann ich nicht einschätzen, ob ein deutscher OSM-Verein taugt als
 Interessenvertretung der hiesigen Gemeinde. Aber eine Diskussion
 darüber wäre imho wieder angebracht, denn, wie gesagt, die Zeiten
 haben sich geändert...


 Was genau hat sich deiner Meinung nach geändert? Und wo wäre bei diesen
Änderungen der konkrete Vorteil gegenüber dem FOSSGIS als Trägerverein?
Welche politischen Themen sind es, die du besser oder anderes
repräsentiert sehen möchtest?

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

Re: [Talk-de] Karte auf openstreetmap.de defekt

[Falk Zscheile]

Am 24. Oktober 2014 16:11 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de:

 Am Freitag, 24. Oktober 2014, 15:18:06 schrieb Falk Zscheile:
  Am 24. Oktober 2014 15:02 schrieb Wolfgang Hinsch 
 osm-lis...@ivkasogis.de:
   Außerdem - Der Unterschied zwischen uns und kommerziellen
 Kartendiensten
   ist
   ja gerade der, dass es uns egal ist, wo wer wie oft sich die Karte
   ansieht.
   Bei uns wird da gemappt, wo der Mapper hinfällt (vor Ort ist/Lust
   hat/Luftbilder gut sind/...). Auf sehr lange Sicht ist unser Ziel (aus
   meiner
   Sicht) eine einigermaßen gleichmäßige Erfassung weltweit, im Gegensatz
 zum
   kommerziellen Anbieter, der sich die Frage stellen _muss_, wie weit
   aufgelöst
   die Karte wo angeboten werden sollte. Bei OSM wird das letzte Wigwam
 der
   Mohikaner - falls ein Mapper vorbeikommt - mit der gleichen Sorgfalt
 und
   Akribie aufgenommen wie der Times Square in New York.
  
  
  Aber auch wir haben es mit knappen Ressourcen zu tun (z.B.
  Rechenkapazität). Man könnte also z.B. Regionen identifizieren, wo man
  einen höhere Auflösungen rendert ...

 Wobei wir wieder beim Anbieter von Karten sind, nicht bei OSM. Wir schaffen
 eine Geodatenbank. Das Rendern ist nicht Sache von OSM, sondern eine von
 vielen möglichen Anwendungen.



 Unsere Karte auf der Hauptseite, en wie de, ist vor allem eine
 Motivationsstütze für die Mapper und nur ganz, ganz nebenbei und unter
 engen
 Voraussetzungen ein Angebot für die Öffentlichkeit.


Alles richtig was du sagst. Mit der konsequenz, die du ziehst bin ich
allerdings nicht einverstanden. Daraus folgt eben nicht zwingend,  dass die
Info nicht für uns von Interesse ist.


 Insofern ist es auch logisch und folgerichtig, dass ein Unternehmen wie
 Mapbox
 als Datennutzer sich fragt, wo am meisten Nachfrage besteht.
 Überraschenderweise da, wo die meisten Leute in einer einigermaßen
 durchtechnisierten Umgebung leben. Das hätte man auch mit dem Finger im
 Wind
 erraten können, aber jetzt ist es eben amtlich.

 So ähnlich wird Geld mit Verkehrszählungen verbraten. Jeder weiß, dass auf
 der
 A8 mehr los ist als auf der Dorfstraße von
 Hinterpfaffenburgstedtwinkelstättenhofen. Aber gezählt ist es doch viel
 ordentlicher und amtlicher ;-)


Ich glaube hier bist du etwas voreingenommen, was sozialwissenschaftliche
Forschung angeht. Die Welt ist voller Beispiele, in denen erst durch
empirische Sozialforschung gezeigt werden konnte, dass es nicht so ist, wie
es scheint. Oft trügt nämlich die menschliche Wahrnehmung ganz gewaltig.
Aber hier wird es OT. wir können diesen Aspekt aber gern privat weiter
vertiefen.


 Gegenden, in denen möglicherweise höher aufgelöst gerendert werden
 _könnte_,
 ergeben sich so durch die Datendichte.


Das ist ein eigener Ansatz. Er führt möglicherweise zur gleichen
Erkenntnis. Das wissen wir aber erst, wenn sich jemand findet, der beide
Methoden miteinander vergleicht.

Ein Aspekt von OSM ist ja auch, dass wir viel ausprobieren/erfassen, ohne
zu wissen wozu genau es gut ist :-) OSM ist mehr als eine Geodatenbank, es
ist ein soziales Phänomen.

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

Re: [Talk-de] Verbesserung der attributiven Heterogenität (War: Was gibt es für unterschiedliche Tagging-Schemen?)

[Falk Zscheile]

Am 9. Oktober 2014 12:10 schrieb Swen Wacker swen.wac...@gmail.com:

 Mal aus der Sicht eines relativen Neulings dazwischengeworfen:

 Am 8. Oktober 2014 07:49 schrieb Falk Zscheile falk.zsche...@gmail.com:

  Bei der ganzen Problematik überschneiden sich verschiedene Probleme.
 
  1. (...) Entsprechend des technischen Hintergrundes der meisten OSMer


 Ist das empirisch belegt oder eine Vermutung/Hoffnung/Befürchtung?


Es gibt Untersuchungen dazu, aber Quellen habe ich gerade nicht zur Hand.



  2. OSM ist ein soziales Phänomen. Bisher fehlt es auf der
  Dokumentationsseite/Wikiseite an Werkzeugen mit denen man diese Phänomen
  abbilden kann.
 

 Bevor ich etwas dokumentieren kann, muss eben dies erstmal entscheiden
 worden. Es nehme - in meiner aktuellen, subjektiven Anfängerwahrnehmung  -
 die aus meiner Sicht notwendig erscheinenden Entscheidungs- und
 Dokumentationsstrukturen nicht in aller Klarheit war. Wo wird was
 entscheiden? Wer dokumentiert das wo? Was Festlegungen gelten weltweit,
 welche sprachraumsweit, welche regional? Welche Mechanismen gelten für
 Übergangszeiten (Stichwort deprecated)? Gibt es bestimmte Qualitätslevel,
 die man erreichen/halten möchte? Gibt es eine Linie, entlang der sich
 scheidet, was in die Datenbank und was in externe Layer/DB gehören sollte?
 Und so weiter.


Du gibst doch schon sehr schön den Streitstand/Zustand wieder. Im Prinzip
hast du die soziale Komponente von OSM damit schon kennengelernt. Und der
von dir beschriebene Zustand zeigt, dass sich etwas ändern muss. Die Frage
ist nur was und wie. Was wir nicht wollen, das sind hierarchische
Entscheidungsprozesse. Also müssen wir andere Wege finden, zu sehen wie die
Mehrheiten verteilt sind. auch wenn wir hier meistens so tun, als gebe es
nur einen richtigen Weg, so zeigen die Diskussionen aber, dass man zum
gleichen Tag gut anderer Meinung sein kann. Wenn wir aber nicht mit harten
ja/nein Abstimmungen arbeiten wolle, dann müssen wir andere Mittel und Wege
finden, um das Schema voran zu bringen und nicht im status quo des Streits
zu verharren. In diese Richtung gehen meine Ideen.

Ich habe bislang gelernt
 - Es gibt ein Wiki, in dem was steht. Oder was nicht steht. Mal stimmt es.
 Mal stimmt es nicht. Mal ist es eindeutig formuliert (Das geht so:...), mal
 windelweich (Es gibt Mapper, die sind der Meinung ...)  Mal ist wohl das
 deutsche Wiki (für mich als Mapper in D) relevant, mal wohl das
 englischsprachige. Mal ist das deutsche Wiki nur in Deutschland relevant.
 Diskussionsseiten gibt es auch.


Oft wird beispielsweise das Argument dass das englische Wiki verbindlich
sei nicht gebraucht, weil es wirklich besser ist, sondern weil dem
Verweiser aufs englische Wiki einfach die vorgebrachte Meinung nicht passt.
Oft ist das deutsche Wiki einfach schon weiter, weil die Community in DE
besonders groß und aktiv ist und schon Probleme hat, an die andere noch
keinen Gedanken verschwinden, weil sie noch mit der Ersterfassung von
Straßen beschäftigt sind.


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

Re: [Talk-de] Verbesserung der attributiven Heterogenität (War: Was gibt es für unterschiedliche Tagging-Schemen?)

[Falk Zscheile]

Am 9. Oktober 2014 23:15 schrieb Swen Wacker swen.wac...@gmail.com:

 Am 9. Oktober 2014 19:24 schrieb Falk Zscheile falk.zsche...@gmail.com:

  Am 9. Oktober 2014 12:10 schrieb Swen Wacker swen.wac...@gmail.com:

 
   Was wir nicht wollen, das sind hierarchische Entscheidungsprozesse.


 Nicht aus Penibilität, sonder lernwillig gefragt: Wer ist wir und wo und
 wie habt ihr das beschlossen?


Wir das ist die Community. Und nein es gibt keinen Beschluss in der Art
65 % sing gegen hierarchische Entscheidungsprozesse, 30 % sind dafür und 5
% haben keine Meinung.



 Und mit welchen Argumenten?


Es soll nicht laufen wie vor Jahren bei der Wikipedia.


 Und wie konntet
 ihr das, wenn es keine hierarchische Entscheidungsprozesse gibt?


Mache hier oder im Forum den Vorschlag ein hierarchisches
Entscheidungssystem einzuführen und du wirst sehen, wie man auch ohne
förmlichen Beschluss etwas ablehnen kann :-)


 Oder positiv gefragt: Welche Entscheidungsprozesse wollt ihr denn?


Hier können du und ich nicht mit wir im sinne der Auffassung der
Community operieren. Mein Eindruck ist, das die Problematik um die
soziologische Komponente unseres Taggingschemas von einem Großteil der
Community noch nicht gesehen geschweige denn wahrgenommen wird.

Das erste Problem ist schon, dass sich nur die wenigsten überhaupt zu Wort
melden und bestimmte Vielschreiber unter Umständen mehr Gewicht erhalten,
als es dem tatsächlichen Meinungsbild in der Community entspricht.

Wenn
 es so einen (oder solche) gibt, kann man das/die Ergebnisse auch
 dokumentieren. Ansonsten beschreibt man in der Doku einen Zustand -
 Abstimmung mit Füßen, sozusagen.


Das Kernproblem unser Tags ist, das man sie verschieden Interpretieren
kann. Jeder kann sich unter dem gleichen Begriff etwas anderes Vorstellen.
Das meinte ich mit randscharf und kernprägnant. Wissenschaftliche Sprache
versucht per Definition die Ränder einer Sache genau zu bestimmen.
Kernprägnant zielt auf den inhaltlichen Kern ab, hat aber zu anderen
Begriffen keine scharfen Grenzen. Unsere Tags werden in der Regel
kernprägnant verstanden. Dann hat man vielleicht eine Abstimmung mit den
Füßen, aber das Schema entwickelt und verbessert sich nicht mehr, weil die
Mapper nicht zu dem Punkt gelangen -- offensichtlich ist unsere Definition
unscharf, wie müssen wir sie ändern um die Zweifelsfrage zu klären. Oft
liegt es auch nur daran, das mit einem Tag viele unterschiedliche Aspekte
zusammengefasst werden, so dass jeder den Schwerpunkt anders legen kann und
entsprechend Streit um die richtige Bedeutung ausbricht. Dabei bietet
unser Taggingschema den Vorteil, dass man nicht auf einem Tag beharren
muss, sondern neue tags schaffen und bestehende Tags durch sub-Tags
ergänzen kann. Das sind eigentlich (!) gute Voraussetzungen um vorwärts zu
kommen.

Die Radweg-Fußweg-Kombinationsproblematik ist ein schönes Beispiel dafür,
wie man Jahrelang diskutieren kann ohne ein brauchbares Ergebnis für die
Kartenauswertung zu bekommen. Die einen Mappen/Taggen nach dem
Verkehrszeichen, die nächsten nach dem Ausbauzustand und andere nach einer
Kombination aus beiden Aspekten etc.



 Die soziale Komponente scheint mir zu sein - und davor haben ich hohen
 Respekt - dass hier sehr viele damit leben können, dass die einen es so
 machen und die anderen so - und dennoch ein Werk entsteht, aus dem (auch
 durch die Interpretation der Renderer?) _eine_ Karte entstehen kann.


Siehe oben zum Taggingschema. Ja, wir können uns eine große Portion
Liberalismus leisten. Das geht aber auch ohne dass man bei den Definitionen
wirklich voran kommt.

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

Re: [Talk-de] Verbesserung der attributiven Heterogenität (War: Was gibt es für unterschiedliche Tagging-Schemen?)

[Falk Zscheile]

Bei der ganzen Problematik überschneiden sich verschiedene Probleme.

1. Das Taggingschema wird von den meisten als eine technische Anleitung zur
Abbildung der Wirklichkeit gesehen. Entsprechend des technischen
Hintergrundes der meisten OSMer wird dabei von einem richtig/falsch Schema
gedacht. Dabei werden zwei Dinge nicht berücksichtigt:
1.a) Wenn sich jemand ein Tagging für einen Gegenstand aus der Wirklichkeit
ausdenkt, so tut er dies aus der Froschperspektive und hat das große ganze
nicht im Blick. Schon eine kleine Positionsveränderung des Frosches bringt
einen riesigen Perspektivwechsel. So entstehen verschiedene
Interpretationen, Konflikte und Widersprüche.
1.b) Anders als die Wissenschaftssprache ist das Taggingschema von OSM
nicht Randscharf, sondern Kernprägnant. Also: Klar ist, was im Kern gemeint
ist, an den Rändern der Tags aber gibt es Unklarheiten, Konflikte und
Überschneidungen.

2. OSM ist ein soziales Phänomen. Bisher fehlt es auf der
Dokumentationsseite/Wikiseite an Werkzeugen mit denen man diese Phänomen
abbilden kann.
2.a.Beispielsweise, das man über Sätze im Wiki einzeln abstimmen kann.
Nicht als Verbindliche Abstimmung, sondern in der Art dieser Aussage
stimme ich zu/stimme ich nicht zu auf diese weise ließe sich erkennen, an
welchen Stellen die Auffassungen auseinander gehen. An diesen Stellen
könnten dann gezielt Diskussionen zur Verfeinerung von Definitionen und
Tags ansetzen.
2.b) Auch eine Seite mit Bildern zur Abstimmung könnte hilfreich sein: Auf
einem Bild ist ein Feldweg abgebildet. Die Mapper können hier dann ihre
Meinung hinterlassen, z.B. ich sehe einen tracktype=2 oder ich sehe einen
tracktype=3 etc. Dann würde klarer werden, wie viel Streit bei OSM
eigentlich nicht um das Tag, sondern um dessen Wahrnehmung durch
unterschiedliche Individuen geht.

3. Den besten Überblick über das Taggingschema und seine
Auswüchse/Überschneidungen/Unklarheiten/Widersprüche haben wohl die
Entwickler von Karten und Routingsoftware. Denn diese Personen müssen aus
einem Bunten Blumenstrauß an Tags in ihrer Karte ein einheitliches und
konsistentes Bild erzeugen. Es fehlt auch hier ein Werkzeug, wo sich diese
Entwickler austauschen können, wie sie das OSM-Taggingschema zu einer
brauchbaren Karten normalisieren

Gruß Falk

Am 5. Oktober 2014 14:05 schrieb Stefan Keller sfkel...@gmail.com:

 Am 5. Oktober 2014 11:41 schrieb Florian Lohoff f...@zz.de:

  Das Problem ist das das Wiki leider eine menge Müll enthält. Aus der
 Natur
  der Sache kopiert da jeder zeugs hin und her und ändert das .
 ...
  Dazu kommen noch jede menge semantische änderungen die alleine durch die
 Übersetzungen
  eingepflegt werden. Die Übersetzungen aus dem Englischen sind halt alle
 subjektiv.
 
  Und da ja auch niemand sagt Die Englische version der Seite ist die
 führende ist
  am Ende das Wiki ein Oktopus mit 250 Armen.

 D.h., dass wir keine aufgeräumte Datenbank haben, v.a. weil das Wiki
 nicht aufgeräumt ist?
 Falls ja, dann müsste man wohl an Aktionen wie
 Wiki-Übersetzungs-Verbesserung und Wiki-Aufräumen denken?
 Es müsste ja nicht gleich das Ganze Wiki sein, sondern nur Vorschlag
 3. mit den Seiten
 http://wiki.openstreetmap.org/wiki/DE:Howto_Map_A und
 http://wiki.openstreetmap.org/wiki/Map_Features u

 LG, S.


 Am 5. Oktober 2014 11:41 schrieb Florian Lohoff f...@zz.de:
  On Sat, Oct 04, 2014 at 08:51:07PM +0200, Stefan Keller wrote:
  Ok. Aber Tatsache ist m.E., dass es Verbesserungspotential gibt.
 
  Und wie es scheint, geht es nicht nur um Neulinge. Auch gestandene
  Mapper können übersehen, dass es geläufigere und aktuellere
  Tagging-Schemen gibt.
 
  Wenn dem so ist, wie könnte man das verbessern?
  1. Sind die Suchfunktionen von Wiki und z.B. Taginfo ungenügend (bzw.
  ungenutzt)?
  2. Sind im Wiki die Seiten
  http://wiki.openstreetmap.org/wiki/DE:Howto_Map_A und
  http://wiki.openstreetmap.org/wiki/Map_Features ungenügend?
  3. Sollte man es mit einer interaktiven Bestimmungs-Anleitung versuchen?
  4. Oder einem Plugin (ähnlich OSMantic für JOSM = Hat das jemand
 ausprobiert)?
 
  Oder liegt es einfach daran, dass die Daten mit alten Tagging-Schemen
  zuwenig schnell verbessert werden?
 
  Das Problem ist das das Wiki leider eine menge Müll enthält. Aus der
 Natur
  der Sache kopiert da jeder zeugs hin und her und ändert das .
 
  Irgendwann gibts es 20 Tagging Schemata und jedes sieht semi-akzeptiert
 aus.
  Jeder mapped dann so vor sich hin und beruft sich auf das Schema was er
 für das
  richtige hält.
 
  Dazu kommen noch jede menge semantische änderungen die alleine durch die
 Übersetzungen
  eingepflegt werden. Die Übersetzungen aus dem Englischen sind halt alle
 subjektiv.
 
  Und da ja auch niemand sagt Die Englische version der Seite ist die
 führende ist
  am Ende das Wiki ein Oktopus mit 250 Armen.
 
  Flo
  --
  Florian Lohoff f...@zz.de
 
  -BEGIN PGP SIGNATURE-
  Version: GnuPG v1.4.10 (GNU/Linux)
 
  

Re: [Talk-de] Unbenutzbare Wanderwege - was tun?

[Falk Zscheile]

Am 27. September 2014 12:28 schrieb thsMD thomas.schind...@ovgu.de:
 dieterdreist wrote
 Am 25. September 2014 13:03 schrieb thsMD lt;

 thomas.schindler@

 gt;:


 3. Parallel zu den besagten Wegen gibt es neue Wege.


 wie weit entfernt sind die denn? Evtl. hat sich ja auch nur lokal die
 Wegeführung durch Geröllabgänge geändert?

 Hi,
 genau das vermute ich. Wegführung geändert und irgendwer hat den neuen Weg
 hinzugefügt. Abstand max. 200m. An einer Stelle gibt es sogar 3 Varianten
 von denen genau eine ausgeschildert ist.


Dann ist der alte 'Weg auch aus meiner Sicht reif zur Löschung.

Gruß Falk

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

Re: [Talk-de] Unbenutzbare Wanderwege - was tun?

[Falk Zscheile]

Am 26. September 2014 07:50 schrieb bkmap burkhard.kirch...@web.de:
 Am 25.09.2014 13:03, schrieb thsMD: Noch eine Zusatzfrage: Welche
 Attribute verwendet man, wenn Radfahren auf
 dem Weg explizit nicht verboten ist (kein Schild), ich aber der
 Meinung bin,
 dass dort keiner mit seinem Rad langfahren möchte?


 Theoretisch gilt für Wege ohne Schilder (aus Art. 25 BayNatSchG):

 Also bei mir steht da etwas von Tiehrhege! Du meinst vermutlich Art.
13 Abs. 3 BayWaldG.[1]

 Das Radfahren, das Fahren mit Krankenfahrstühlen und das Reiten ist
 im Wald nur auf Straßen und geeigneten Wegen zulässig. Die Vorschriften
 des Straßen- und Wegerechts und des Straßenverkehrsrechts bleiben
 unberührt.


Die Betonung liegt auf Wald. In den Alpen gibt es ja noch andere
Landschaftsformen. Beim ausgangsposting habe ich mir eher eine
hochalpine Landschaft ohne Bäume vorgestellt. Gut möglich, dass da
meine Phantasie mit mir durchgegangen ist und ein anderes Szenario
zugrunde lag.

Zur Benutzung der freien natur findet sich etwas in Art. 28
BayNatSchG.[2] Der beschränkt das Fahren aber in der Tat auch auf
Wege. Im Kern hast du also Recht ...

Gruß Falk

[1] 
http://www.gesetze-bayern.de/jportal/portal/page/bsbayprod.psml?showdoccase=1doc.id=jlr-WaldGBY2005rahmendoc.part=X
[2] 
http://www.gesetze-bayern.de/jportal/?quelle=jlinkdocid=jlr-NatSchGBY2011rahmenpsml=bsbayprod.psmlmax=trueaiz=true

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

Re: [Talk-de] Gebiete bezeichnen

[Falk Zscheile]

Am 26. September 2014 12:43 schrieb Martin Koppenhoefer
dieterdre...@gmail.com:
 Am 25. September 2014 22:46 schrieb malenki o...@malenki.ch:

 Kürzlich wurde ich im Hilfe am Westerwald (ein Mittelgebirge)¹ gebeten;
 der war aber bereits ohne mein Zutun repariert worden. Regionen werden
 also durchaus schon gemappt.

 ¹
 http://de.wikipedia.org/wiki/Westerwald
 http://www.openstreetmap.org/relation/3273435



 wobei das im Detail natürlich fragwürdig ist. Wenn ich mir hier ansehe,
 dass die Basaltwerke noch mit einem Zipfel im Westerwald sind:
 http://www.openstreetmap.org/?mlat=50.68842mlon=7.32396#map=17/50.68842/7.32396
 oder diese Einfamilien(?)-Häuser zum Teil ja, zum Teil nicht:
 http://www.openstreetmap.org/?mlat=50.68359mlon=7.31864#map=18/50.68359/7.31864

 dann wird klar, dass so was eigentlich keine schönen Daten sind, meint: der
 Datentyp Polygon mit seinen klaren Grenzen passt nicht nur Natur dessen,
 was beschrieben werden soll. Das kann man zwar verfeinern, aber richtig
 klar wird es nie, weil man vermutlich auch in der Realität beide
 Standpunkte vertreten kann (Ist im Westerwald bzw. ist nicht im WW).

 Z.B. manche Vororte von Koblenz sind im Westerwald, Koblenz aber nicht?
 Dieser Punkt hier ist im Westerwald:
 http://www.openstreetmap.org/?mlat=50.3191mlon=7.5918#map=15/50.3191/7.5918
 der hier aber nicht?
 http://www.openstreetmap.org/?mlat=50.3203mlon=7.5874#map=15/50.3203/7.5874

 Solche Gebiete den Fluss durchschneiden zu lassen halte ich eher für eine
 schlechte Idee, der Fluss(abschnitt) wird doch ganz oder gar nicht
 dazugehören?

 Ziemlich sicher werden solche Konstrukte auch alle Nas' lang kaputtgehen
 (ähnlich den politischen Grenzen).

 Ich bin nach wie vor der Meinung, man sollte dafür einen neuen Datentyp
 erfinden, z.B. eine Sammlung von beliebigen Dingen (Nodes und vielleicht
 auch ways), die dann entweder als drin oder draußen bezeichnet werden
 (Rolle), bzw. in Fällen einer harten Grenze (Fluss, Bergrücken, Küste
 etc.) auch als echte Grenze (in Teilbereichen).


Ein Polygon zur Strukturierung solcher Gebiete erscheint mir auch
ungeeignet. Genau wie der Anspruch mittels Relation alle Wege erfassen
zu wollen, die das Gewiet umgrenzen.

Würde es nicht reichen, wenn man einzelne Nodes zu einer Relation
packt. Also diese Stadt oder dieser Berggipfel liegt im Erzgebirge
oder, wem das zu sehr nach Sammelrelation klingt einfach etwas
analoges zu is_in=value. Dann kann man auf der Auswertungseite die
Ausdehnung dieses Bereichs ermitteln und vom Renderer entsprechend
beschriften lassen. Damit geht man auch dem Streit aus dem Weg, wo die
Grenze genau verläuft und es entspricht unserem Crowdsourcingansatz.
Keiner muss wissen, wo Erzgebirge genau anfängt oder aufhört. Es
reicht, dass ich weiß dieser Berg oder diese Stadt liegt im Erzgebirge
und bekommt dann das Tag/Relation. Die Region ergibt sich dann erst
mit der Zeit aus der Zuordnung einzelner Nodes zu einem Region-Tag
durch eine Vielzahl von Mitwirkenden.

Der Nachteil ist, dass sich keine festen Grenzen unmittelbar aus der
Datenbank extrahieren lassen, sondern man nur eine Datenwolke erhält.
Aber gerade für so einen Anwendungsfall, wo eine klare Grenzziehung
ohnehin nicht möglich ist, finde ich das ganz vernünftig. Besser
jedenfalls als riesige Waypolygone oder Relationen mit Ways zu haben,
die ständig kaputt gehen. Für Verwaltungsgrenzen geht das nicht, aber
für difuse Grenzen wie Namen von Regionen schon.

Gruß Falk

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

Re: [Talk-de] Unbenutzbare Wanderwege - was tun?

[Falk Zscheile]

Am 24. September 2014 22:04 schrieb thsMD thomas.schind...@ovgu.de:
 Hi,
 ich mache gerade Urlaub in den Alpen. Dabei ist mit aufgefallen, dass in der
 OSM-Karte Bergwanderwege T3/T4 vorhanden sind, die nicht mehr benutzbar
 sind. Keine Wegweiser an den Kreuzungen/Einmündungen oder
 Kreuzungen/Einmündungen nicht gar nicht meht vorhanden.

 Verlauf kann man
 stellenweise noch erahnen,

Wikipedia sagt zu T3: Weg am Boden nicht unbedingt durchgehend
sichtbar.[1] und zu T4: Wegspur nicht zwingend vorhanden..[2] Auch
scheint eine Markierung dieser strecken nicht zwangsläufig vorhanden
zu sein. So verstehe ich jedenfalls den Wikipediaartikel.


 aber Weg ist wie gesagt garantiert nicht
 benutzbar.

Woraus schließt du die Unbenutzbarkeit (abgesehen von fehlender
Markierung und fehlender durchgehender Sichtbarkeit).

 Was tun?

Falls das deine einzugen Kriterien sind, dann nichts löschen, sondern
ggf. noch  trail_visibility=[value] ergänzen.

Gruß Falk

[1] http://de.wikipedia.org/wiki/SAC-Wanderskala
[2] http://de.wikipedia.org/wiki/SAC-Wanderskala

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

Re: [Talk-de] OSM quo vadis - OSM-Account für Workshop

[Falk Zscheile]

Was ist so verkehrt daran, dass Markus die Leute an die Hand nimmt?
Mir ist jemand, der schon einmal in OSM unter Anleitung editiert hat
lieber, als jemand, der gar nicht hineingeschnuppert hat, weil im die
Zeit oder der Mut dazu gefehlt hat. Es gibt Menschen, die sich besser
dabei fühlen, wenn ihnen bei den ersten Gehversuchen jemand über die
Schulter schaut. Ich finde dass sogar gut, schließlich werden so
vielleicht die gröbsten Anfängerfehler vermieden.

Gerade bei älteren Semestern konnte ich beobachten, dass sie mit dem
Einstieg bei OSM zögern, weil sie nichts falsch machen wollen. Einige
sind nur dabei, weil sie am Anfang jemanden hatten, den sie direkt
fragen konnten. Wenn wir in Richtung wir brauchen niemanden, der sich
nicht allein anmelden kann/will argumentieren, dann ist das meines
Erachtens ein falscher elitärer Ansatz.

Falk

Am 23. September 2014 10:59 schrieb Michael Reichert naka...@gmx.net:
 Hallo,

 Am 2014-09-23 um 10:56 schrieb Peter Wendorff:
 die Herausforderungen, die du ansprichst, sind richtig, aber es sind
 eben auch Herausforderungen.
 Richtig ist auch, dass wir aufpassen müssen, nicht nur für IT-Nerds, wie
 du das ausdrückst, nutzbar zu sein, aber trotzdem: Ein gewisses
 Mitdenken zumindest kann man erwarten.
 Einen Benutzernamen und Passwort auszudenken sowie ein Formular und
 E-Mails zu benutzen, die - so hoffe ich, ohne es aktuell geprüft zu
 haben - selbst erklären, was zu tun ist, erfordert als Grundwissen
 eigentlich nur die Benutzung des Webbrowsers und des eigenen
 E-Mailprogramms, und darüber hinaus Lesekompetenz, um zu verstehen, was
 erklärt wird.
 Wenn wir da was verbessern können, sollten wir das tun, aber wenn -
 abgesehen von Verbesserungen bei diesen Erklärungen - dies schon eine
 Hürde in Bezug auf das Verständnis oder die Fähigkeiten des Nutzers
 darstellt, dann kann das fürs Tagging nicht funktionieren. Dann ist
 meines Erachtens erstmal der richtigere Weg, die Nutzer zum Fehlermelden
 via Notes aufzufordern.

 +1

 Viele Grüße

 Michael


 --
 Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt.


 ___
 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] Adressdaten in POI nodes

[Falk Zscheile]

Am 13. August 2014 09:14 schrieb Martin Vonwald imagic@gmail.com:

 Am 12. August 2014 17:44 schrieb Christian H. Bruhn br...@arcor.de:

 In Lübeck haben wir eine building-Relation erstellt, die als
 outline-member die Gebäudehülle mit den Adressinfos enthält und die
 einzelnen POIs als contains-member (z.B. [1]) ohne Adressangaben.


 Warum sollte man in einer Geo-DB jene Knoten, welche sich alle innerhalb
 einer bestimmten Fläche befinden, extra noch in eine Relation geben?


Weil es nicht zwingend ist, dass etwas innerhalb eines Polygons auch
eine Beziehung zum Polygon hat. Aber davon abgesehen bin ich kein
Freund dieser Relationslösung sondern bevorzuge jedem Node seine
eigene Adresse :-)

Gruß
Falk

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

Re: [Talk-de] Adressdaten in POI nodes

[Falk Zscheile]

Am 9. August 2014 22:59 schrieb Andreas Neumann andr-neum...@gmx.net:
 Am 09.08.2014 um 18:40 schrieb Bernhard Weiskopf:
 Hallo an alle,

 z. B. in meiner Umgebung wurden bei zahlreichen Restaurant-Nodes u. ä. die
 Adressdaten (addr:* = …) gelöscht.

 Soll man die jetzt nicht mehr eintragen, weil die z. B. aus der Umrandung
 „building = …“ herausgelöst werden können, oder hätte der Mapper die nicht
 löschen sollen?


 Eigentlich sind die Daten redundant, jedoch ist es für einen Auswerter
 deutlich schwieriger, umfassende Adressdaten mit Nodes und Ways zu
 verknüpfen (noch grausamer sind übrigens einige Varianten mit Relationen).

 Ob also eine umfassende Adresse mit dem Node verknüpft wird, hängt vom
 Auswerter ab.

 Es gibt unzählige Auswerter, die dieses Feature nicht unterstützen. Dazu
 zählen fast alle Tools, die mit Overpass arbeiten. Aber auch Tools, wie
 wheelmap, wo man Adressdaten von Hand nachtragen kann. Es wird also
 zukünftig auch immer wieder zu redundanten Daten kommen, weshalb ich
 diese nie lösche.


Und es ist
1. eine zusätzliche Kontrolle. Ein schlaues tool könnte Prüfen, ob das
Node im Gebäudepolygon die gleichen Adressdaten hat und ggf. Alarm
schlagen.
2. es ist einfacher, bei der Datenabfrage. Ich weiß GIS-Profis werden
darüber nur müde lächeln ...

Jedenfalls bei mir bekommen sowohl das Gebäudepolygon als auch die
darin befindlichen Geschäfte die Adresstags. Eine Löschung würde ich
als unnötige Maßnahme im leben und leben lassen Universum von OSM
empfinden.

Gruß Falk

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

Re: [Talk-de] Bebauungspläne als Amtliche Werke? Was: Radweit routen löschen? (WAS: Radweit)

[Falk Zscheile]

Am 5. August 2014 23:58 schrieb Mark Obrembalski m...@obrembalski.de:

 Aber wenn man für ein Gebiet nix Besseres hat, kann man natürlich auch
 erst mal die Angaben aus dem Bebauungsplan eingeben, solange man nur
 weiß, dass das Gebiet tatsächlich schon bebaut ist.

 Was aber auf jeden Fall auch drinsteht, sind die eigentlichen
 Festsetzungen, von denen es einige meiner Meinung nach durchaus
 verdienen, in OSM aufgenommen zu werden. Gerade die Information, was
 nun als reines Wohngebiet, allgemeines Wohngebiet, Mischgebiet,
 Gewerbegebiet etc. ausgewiesen ist, halte ich für interessant.

Dabei ist natürlich zu beachten, dass solche Festsetzungen im Sinne
der Baunutzungsverordnung (BauNVO) deutsches Recht sind und sich in
gleicher Weise nicht ein zu eins bei unseren Nachbarn finden. Um
global verständlich zu sein müssen wir an unserem landuse=value
festhalten. Was natürlich nicht heißen soll, dass das Schema nicht
verbesserungswürdig ist, z.B. Unterscheidung zwischen Bodenbedeckung
und Landnutzung. Wenn man Festsetzungen nach der BauNVO eintragen
möchte, dann also als eigenes Tag, vielleicht
landuse:de=baunvo:reines_wohngebiet oder als subtag zu landuse. Wie
auch immer: Man muss berücksichtigen, dass die BauNVO eine rein
nationale Kategorisierung ist.

Gruß Falk

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

Re: [Talk-de] wie tagge ich Zeltplätze?

[Falk Zscheile]

Am 8. Juli 2014 00:01 schrieb gmbo g...@kilometerfresser.eu:
 Am 07.07.2014 21:04, schrieb Falk Zscheile:


 Es kommt zum Nebeneinander statt zum miteinander und es entstehen im
 schlimmsten Fall taggingschulen, die sich unvereinbar und unversöhnlich
 gegenüberstehen. Was meines Erachtens fehlt ist ein zentraler Anlaufpunkt,
 an dem man schauen, diskutieren und ausprobieren kann ohne gleich einen
 Editwar zu riskieren. Ggf. könnte man auch verschiedene Beispiele zur
 Abstimmung stellen und so ein unverbindliches Voting erhalten, welches
 Modell besser ankommt.


 Aber wer würde in einer Sandbox nachsehen in der nur getestet werden kann
 und über welchen Weg sollte man das finden?


Sandbox trifft es vielleicht nicht ganz, was mir vorschwebt. Es soll
ein Raum sein, in dem man einen Vorschlag unterbreiten und mit
anderen diskutieren kann, um dann zu einer Art best practice zu
kommen. Eine Sandbox in diesem Sinne müsste natürlich in geeigneter
Weise mit dem Wiki und über andere Seiten, die zu Taggingfragen in der
Regel konsultiert werden, verknüpft sein.

Eine andere Idee: man erstellt für JOSM Taggingvorlagen, die sich an
einem komplexen Objekt, wie Zeltplatz orientieren. Und als
Tagvorschläge findet sich dann alles, was es auf einem Zeltplatz so
gibt, ohne dass man sich durch zig andere Menüs Straße Einrichtung
Geografie hangeln muss.

 Meiner Meinung nach sollte ein Taggingschema für komplexe Gebilde erst
 wertungsfrei, also ohne das nachzuschauen wie es am häufigsten genutzt wird,
 beschrieben werden. Das könnte wenn es beschreibbar ist auch in realen Orten
 gemappt werden. In der Beschreibung würde dieser Ort dann angegeben.


Das funktioniert so nicht, da jeder anders Wertungsfrei ans Mappen
heran geht. Das Ziel, welches man vor Augen hat, bestimmt auch ganz
entscheidend das Tagging mit. Sowohl Detailgrad als auch die
Verwendung bestimmter Tags. Ein wie auch immer geartetes best
practice-Beispiel kann da schon den Horizont erweitern: Ach, den
Wasseranschluss, den ich da auf dem Foto sehe, kann ich auch
eintragen!

Bei der Orientierung an Realen Orten ist immer die Gefahr, dass der
status quo verteidigt wird, denn man hat das ja selbst und in jedem
Fall richtig gemappt. Das ist eine zusätzliche Hürde auf dem Weg zu
einer konstruktiven Diskussion. Niemand lässt sich gern sagen, dass er
etwas falsch gemacht hat. Auf dem neutralen Boden einer Sandbox,
losgelöst von einem existierenden Ort, ist das meines Erachtens
leichter.

 Aber auch hier fehlt die Übergeordnete Beschreibung. Die How to map Seite
 wäre da ein Einsprungspunkt.

Ja, das wäre auf jeden Fall einfacher zu realisieren, als meine Sandbox.

 Es gäbe noch eine zweite Möglichkeit einer Vorgehensweise.
 Dazu müsste man alle bisher gemachten Proposels und eventuell dazugehörenden
 Votings zu einem Thema finden, ebenfalls die sonstigen Wikieinträge. Das
 ganze müsste dann zusammengefasst werden und auf Widerspüche geprüft werden.
 Wenn alles schlüssig ist, noch auf Veränderung in der Istzeit und
 Vollständigkeit prüfen.

Das können wir zeitlich nicht leisten. wir müssen darauf hoffen, das
der relevante personenkreis anspringt und sein Wissen/ seine Meinung
beiträgt.


 Ich weiß, wer soll das machen, man will ja nur mal eben den Stellplatz
 mappen, den man gerade gesehen hat, und sich nicht um das Drumherum kümmern
 müssen.

Genau :-/

Gruß Falk

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

Re: [Talk-de] wie tagge ich Zeltplätze?

[Falk Zscheile]

Am 8. Juli 2014 09:12 schrieb Peter Wendorff wendo...@uni-paderborn.de:
 Falsch, wieso muss jedes Tag gerendert werden? Und wieso in jeder Karte?
 Routen z.B. (Bus, Wanderwege etc) sind auf der allgemeinen Karte nicht
 sichtbar, und würden da eher stören, weil die vergleichsweise voll ist;
 in den Spezialkarten sind die aber super.

Interessant wäre in der Tat, wenn man den Vergleich hat: wie sieht die
gleiche Datengrundlage in verschiedenen Kartenstilen aus. Im besten
Fall kommt man so auch von der Auffassung weg, der Mapnik-Stil auf
openstreetmap.org sei das Maß aller Dinge.


Gruß Falk

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

Re: [Talk-de] wie tagge ich Zeltplätze?

[Falk Zscheile]

Im Zusammenhang mit der Diskussion um das richtige Tagging von
zeltplätzen ist mir die folgende Idee gekommen, zu der ich gern eure
Meinung hören würde:

Die wenigsten von uns sind Experten im Taggen von Zeltplätzen,
Schulen, Freibädern und anderen komplexen Einrichtungen, die nicht nur
aus einem key=value-Paar bestehen, sondern aus einer Kombination
vieler verschiedener Elemente. Zum Beispiel beim Zeltplatz:
verschiedene Arten von Stellplätzen, Sanitäreinrichtungen (Toiletten,
Duschen), Infrastruktur (Wasser, Wege, Rezeption),
Versorgungseinrichtungen, Spielplatz, Sportplatz.

Die wenigsten haben Lust, sich bei jedem Mappen durchs Wiki zu wühlen,
wenn sie das richtige Tag nicht im Kopf haben oder sich auf die Suche
nach einem schon ordentlich gemappten Zeltplatz zu machen, den sie
als tagging-Vorlage verwenden können. Und es ist auch keineswegs
sicher, dass man im Wiki gleich das etablierte Tag findet.

Meine Idee wäre eine Art Sandkasten in dem ein Mustertagging für
komplexe Strukturen, wie z. B. Zeltplätze, stattfindet. Wenn man also
einen Zeltplatz eintragen will, dann geht man auf die Musterseite und
hat schon eine Übersicht über alle wichtigen Elemente. Ein weiterer
angenehmer Nebeneffekt wäre sicher die Vereinheitlichung des Taggings.
Auch Probleme im Taggingschema würden schneller entdeckt, weil man sie
anhand eines Musterbeispiels diskutieren kann. Schließlich hätten es
auch Einsteiger leichter, weil alle wichtigen Tags für einen Zeltplatz
schon an einer Stelle gesammelt sind und das Zusammenspiel der Tags
deutlich wird.

Perspektivisch könnte man den Sandkasten dann auch an verschiedene
Rendervorschriften anschließen und könnte dann auch gleich sehen, wie
das Tagging auf verschiedenen Karten aussieht. Vielleicht würde man
damit auch ein wenig das Mapnik-Standardstil-Problem bzw. der starken
Orientierung daran abschwächen.

Nur so ein Gedanke. Ich weiß, dass Ressourcen zur Umsetzung knapp
sind. Aber halten ihr etwas in der oben beschriebenen Art für sinnvoll
oder reicht eurer Meinung nach ein how-to-map, wie es im Wiki
niedergelegt ist. Es wäre aber vielleicht auch eine Masterarbeit Wert:
Verbesserung der Abstimmung in unstrukturieren Organisationen mit
Hilfe 'von-was-auch-immer' am Beispiel von OSM.

Gruß
Falk

Am 5. Juli 2014 11:51 schrieb gmbo g...@kilometerfresser.eu:
 Auf dem letzten Stammtisch in Essen ist uns bewusst geworden, dass es beim
 taggen von Campingplätzen sehr unterschiedliche Ansichten gibt.

 Nehmen wir die derzeitigen Taggingschemen gint es viele Widersprüche.

 Zur Zeit wird für Camping der Tag tourism=camp_site(51 456) benutzt und für
 Wohnmobile der Tag tourism=caravan_site (12 408).

 Bei den Campingplätzen wird dann tents=yes/no die Möglichkeit zum Aufstellen
 von Zelten getaggt und mit caravan==yes/no beschrieben ob dort Wohnmobile
 abgestellt werden dürfen.

 Meinem Verständnis nach ist genau das der Punkt warum es dort zu
 Fehlinterpretationen kommt.


 Denn

 Caravan englisch - deutsch Wohnwagen ist ja eigentlich kein Reise- oder
 Wohnmobil.

 camp_site wird beim Tagging in OSM Camping und Zeltplätze benutzt, was dem
 umgangssprachlichem Campingplatz entspricht, der aber eben sowohl ein
 Jugendzeltplatz wie einprivater Campingplatz mit Parzellen für Wohnwagen von
 Dauercampern sein kann auf dem das Zelten nicht erlaubt ist.

 Wie unterscheiden wir also einen Zeltplatz wie Tönnebön-Camp ( way 129645725
 ) von einem Campingplatz auf dem man als nur Zelter nicht eingelassen wird.

 Ebenso gibt es Kombinationen bei denen man Zelten darf, aber Wohnmobile
 nicht eingelassen werden.

 Auf der anderen Seite gibt es Wohnmobilstellplätze die Zelten erlauben aber
 dafür Zelten erlauben. Dort dürfte ein Fahradfahrer mit Zelt ja auch zelten.

 Wie schon oben erwähnt gibt es wie man an den Übersetzungen vom englichen
 ins deutsche und umgekehrt unterschiedliche Sichtweiden. damit wird es für
 mich sehr schwer das ganze in englisch fürs Tagging zu beschreiben.

 LG
 Gisbert

 ___
 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] wie tagge ich Zeltplätze?

[Falk Zscheile]

Am 7. Juli 2014 20:55 schrieb Henning Scholland o...@aighes.de:

 ich empfinde so einen Sandkasten als nur bedingt für OSM tauglich. Man
 sieht dann zwar, was man so alles an einem Objekt erfassen kann. Aber es
 fehlt dann die komplette Dokumentation, was das Tagging genau bedeutet.

 Wenn ich dir in die Sandbox einen way mit highway=track und
 tracktype=grade1 eintrage, weißt du mit Sicherheit nicht, wofür das nun
 steht. Ähnlich der Kombination von access-Tags.


Eine Legende müßte vorhanden sein, sonst wäre das Konzept sicher im
Nutzen eingeschränkt.


 Letztlich kommt man um das Handbuch-lesen nicht drum rum. Und ehrlich
 gesagt ist es mir lieber, da steht nur ein grobes Gerüst an Taggs an
 einem Objekt und der stimmt, als diverse Detail-Taggs, die fehlerhaft
 sind und alle Experten einen Bogen um die Ecke machen, weil ja
 augenscheinlich alles erfasst ist.


Ich möchte, dass auch die Experten die Möglichkeit haben anhand des
Sandkastenbeispiels über gutes und richtiges tagging zu diskutieren.
Jetzt ist es ja eher ein nebeneinander. der eine mappt ein paar
Zeltplätze in Nordeutschland, der andere in Italien. Aber keiner
schaut sich an, wie es der andere macht.  Es kommt zum Nebeneinander
statt zum miteinander und es entstehen im schlimmsten Fall
taggingschulen, die sich unvereinbar und unversöhnlich
gegenüberstehen. Was meines Erachtens fehlt ist ein zentraler
Anlaufpunkt, an dem man schauen, diskutieren und ausprobieren kann
ohne gleich einen Editwar zu riskieren.

Ggf. könnte man auch verschiedene Beispiele zur Abstimmung stellen und
so ein unverbindliches Voting erhalten, welches Modell besser ankommt.

Gruß Falk

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

Re: [Talk-de] wie tagge ich Zeltplätze?

[Falk Zscheile]

Am 7. Juli 2014 21:19 schrieb Henning Scholland o...@aighes.de:

 da könnte man jetzt aber auch osm-Dateien ins wiki laden und jeder
 schaut sie sich an. Oder man taggt ein Beispiel in OSM und diskutiert
 darüber.

Das ist für den Anfang auf jeden Fall eine gute Idee! Problematisch
ist aus meiner Sicht nur, dass man dann echte geographische
Koordinaten verwenden würde und somit die Gefahr besteht, dass
Modelldaten in die echte Datenbank gelangen. Ich denke ich werde bei
Gelegenheit mal so eine Modelldatei basteln :-)

Gibt es im OSM-Datenformat die Möglichkeit, Koordinaten als rein
hypothetisch zu kennzeichnen?

Gruß Falk

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

Re: [Talk-de] Wie exakt Landnutzungsflächen eintragen?

[Falk Zscheile]

Am 4. Juli 2014 21:02 schrieb Sascha Pomplun fo...@saschapomplun.de:

 Ich würde gerne klären wieviel Genauigkeit in OSM erwünscht ist, [...]


Das ist eine schwierige Frage, denn sie hängt von vielen Randbedingungen ab:

1. Zunächst einmal davon, welche Meinung der Mapper zur Aufgabe der
Kartendaten hat. Geht er mit der Vorstellung an die Sache, das
maximale wozu die Daten genutzt werden (sollten), ist eine Karte auf
Zoomlevel 12, dann geht er an die Datenerfassung/Eintragung ganz
anders heran, als jemand, der den Datenbankinhalt als Sammlung mit
offenem Verwendungszweck sieht. Eine solche Person wird eher Details
mappen, die auf Z12 nicht unbedingt hübsch aussehen.

2. Randbedingung ist die Qualität der Informationen, aus denen die
Daten für die OSM-Datenbank gewonnen werden. Wenn Mapper A ein
detailliertes Luftbild als Hintergrund verwendet, Mapper B aber eines
mit grober Auflösung so kommen dabei nicht nur ganz andere
Datendetails in die Datenbank, sondern hat auch Einfluss auf das
verwendete Datenschema. Jemand der gerade noch so Häuser auf dem
Luftbild erkennen kann wird nicht einmal einen Gedanken daran
verschwenden, dass es kleinteiliger Informationen gibt und wie diese
im Datenschema und der Datenbank abgebildet werden können.

3. Das Datenschema ist alles andere als klar. oft weder in der
konkreten Definition des Tags noch in der logischen Struktur der Tags
zueinander. Die einzelnen landuse-Tags sind nicht konsistent
zueinander und lassen sich nicht logisch zueinander ins Verhältnis
setzen[1]. Das gilt zum Beispiel für die Dinge, die wir mit landuse
beschreiben. So könnte (!) man landuse=vineyard als Untermenge von
landuse=farmland sehen, denn es ist ein Sonderfall
landwirtschaftlicher Fruchtproduktion. Man könnte (!) die einzelnen
Weinbergsflächen einzeln einzeichen und das ganze mit einem
landuse=farmland umschließen. rein logisch gesehen wäre das richtig.
Es wird bei OSM so aber nicht gehandhabt, weil die Mehrheit der
Meinung ist, zwischen Feld und Weinberg gebe es hinreichend deutliche
Unterschiede. Im Übrigen fehlt natürlich auch der Informative
Mehrwert. Bei Straßen ist es eben nicht mehr so klar. Wenn man es
wörtlich betrachtet, dann könnte ein Feldweg oder eine Wohnstraße
durchaus Teilmenge von landuse=farmland oder landuse=residential sein,
würden die Flächen also nicht unterbrechen. Legt man den Fokus
natürlich auf die tatsächliche Nutzung, so endet  landuse=residential
natürlich an der Straße (und nicht auf dem Straßenvektor!). Straße und
Wohngebiet haben dann keine gemeinsame Menge. Die eine Fläche dient
dem Wohnen, die andere dem fahren mit Fahrzeugen. Eine gemeinsame
Obermenge wäre dann vielleicht menschliche Nutzung :-)

4. Die Qualität von OSM und damit auch der Detailgrad wird auch von
der Anzahl der Mitwirkenden bestimmt. Were sich schon mal im
Micro-Mapping versucht hat, weiß wie viel Zeit man an relativ kleinen
Flächen verbringen kann und wie viel Wald, ausreichend genau für Z12,
man in der gleichen Zeit mappen kann.   Micro-Mapping wird sich also
perspektivisch nicht durchsetzen, weil wir dafür nicht genug Mapper
sind. Damit wird sich meine Meinung nach aber auch das Verständnis für
die Probleme in diesem Bereich in Grenzen halten.

Kurzum Sascha spricht altbekannt Probleme von OSM an, die sich in der
sozialen Wirklichkeit als gegenseitiges Weglöschen zeigen, weil der
andere ja etwas falsch gemacht hat. Außer zu versuchen, in solchen
Fällen räumlich nebeneinander und nicht miteinander zu mappen, fehlen
mir auch gute Ideen, wie wir das in den Griff bekommen könnten. Die
Community ist so heterogen, dass man immer Mapper mit
unterschiedlichem Kenntnisstand und Vorstellungen vom richtigen
Detailgrad geben wird.

Etwas ratlos aufgrund der Rahmenbedingungen
Falk


[1] Hierzu plane ich (vorbehaltlich Zeit und der Annahme) einen
Vortrag auf der nächsten FOSSGIS-Konferenz.

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

Re: [Talk-de] Wege mit zeitlicher Zutritts-Beschrängung

[Falk Zscheile]

Am 3. Juni 2014 11:03 schrieb Martin Koppenhoefer dieterdre...@gmail.com:


 Am 02/giu/2014 um 16:07 schrieb Falk Zscheile falk.zsche...@gmail.com:

 Und sollen wir das jetzt einzeln je nach Hausordnung mappen oder wie
 soll ich deinen Hinweis verstehen? Ich finde deine Argumentation daher
 nicht besonders konstruktiv im Hinblick auf OSM und das Datenschema.


 ich hatte lediglich eingewandt, dass permissive m.E. besser passt als yes, 
 dann kamst Du mit unpassenden Bundesverfassungsgerichtsurteilen zur 
 Meinungsfreiheit und jetzt bin ich unkonstruktiv?

 ;-)

Mein Eindruck war, zwischenzeitlich ein anderer, aber das war
natürlich nur mein subjektives Empfinden.

Ich denke, jetzt hat jeder Interessierte genug Argumente, um sich
zwischen permessive und yes zu entscheiden, also zwischen quasi
öffentlichem Raum und privatrechtlich gewährtem Zugang zu wählen.

Bei den Aussagen und Folgerungen aus dem BVerfG-Urteil werden wir uns
wohl nicht einig werden. Die
Bibel liest ja auch jeder anders ;-) Eine weitere Vertiefung wäre
daher OT. Aber ich denke, die nächste Diskussion, bei der wir
unterschiedlicher Meinung sind, kommt auch so :-)

In diesem Sinne Gruß
Falk

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

Re: [Talk-de] Wege mit zeitlicher Zutritts-Beschrängung

[Falk Zscheile]

Am 2. Juni 2014 02:49 schrieb Martin Koppenhoefer dieterdre...@gmail.com:
 Am 30. Mai 2014 11:23 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de:

 Bei einem Einkaufszentrum gelten andere Regeln als in Wohnzimmer ;-)



 Die Regeln sind jedenfalls deutlich eher die eines privaten Hofs als die
 eines oeffentlichen Raumes / Strasse.

Mit solch einer Aussage wäre ich in Deutschland vorsichtig. Seit dem
Fraport Urteil des Bundesverfassungsgerichts[1] reicht es nicht mehr,
dass ein Einkaufszenrum o. ä. in privater Hand ist um nach Belieben
Dritte vom Zugang auszuschließen. Jedenfalls wenn diese Dritte ihre
Grundrechte auf Meinungsäußerungs- und Versammlungsfreiheit dort
ausüben wollen. Wie es in Italien ist, das weiß ich nicht. Jedenfalls
sind mit dieser Entscheidung deutlich in Richtung öffentlichen Raum
gerückt worden. Ich weiß, dass man access=Grundrechtsausübung nicht
mappen kann, aber den Vergleich Bauernhof--Einkaufszentrum wollte ich
dann doch hier nicht so stehen lassen.

 Normalerweise gibt es da eine
 Hausordnung die genau so was sagt (klar, wer wie ein potentieller Kunde
 aussieht wird natuerlich reingelassen, solange er sich nicht laestig
 verhaelt, ist ja im ureigensten Interesse, moeglichst viele Kunden
 anzuziehen).

Hausordnung hin oder her -- der Allgemeinheit zugängliche private
Areale wie Einkaufszentren, Flughäfen etc. stehen der Öffentlichkeit
zur Grundrechtsausübung zur Verfügung, ob das den Eigentümern passt
oder nicht (und es passt in der Regel natürlich nicht). Aber natülich
hat alles auch seine Grenzen ...

Beim privaten Bauernhof gilt der allgemeine Zugang so nicht.

 Einfach mal im Internet gesucht und das erste angeclickt:
 http://www.mira-einkaufszentrum.de/hausordnung.html
 So was aehnliches gilt praktisch in allen Einkaufszentren.


In ihre Hausordnungen können die Eigentümer erst einmal alles
hineinschreiben. Ob das auch vor Gericht bestand hat, das ist eine
ganz anderes Frage :-). Es gibt keinen Anspruch auf ungestörtes
Einkaufserlebnis in einem Einkaufszentrum.

Gruß Falk

[1] 
http://www.bundesverfassungsgericht.de/entscheidungen/rs20110222_1bvr069906.html

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

Re: [Talk-de] Wege mit zeitlicher Zutritts-Beschrängung

[Falk Zscheile]

Am 2. Juni 2014 12:32 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de:
 Hallo,
 Am Montag, den 02.06.2014, 10:15 +0200 schrieb Bernd Wurst:
 Hallo.

 Am 02.06.2014 08:41, schrieb Falk Zscheile:
  Die Regeln sind jedenfalls deutlich eher die eines privaten Hofs als die
   eines oeffentlichen Raumes / Strasse.
  Mit solch einer Aussage wäre ich in Deutschland vorsichtig. Seit dem
  Fraport Urteil des Bundesverfassungsgerichts[1] reicht es nicht mehr,
  dass ein Einkaufszenrum o. ä. in privater Hand ist um nach Belieben
  Dritte vom Zugang auszuschließen.
  Jedenfalls wenn diese Dritte ihre
  Grundrechte auf Meinungsäußerungs- und Versammlungsfreiheit dort
  ausüben wollen. Wie es in Italien ist, das weiß ich nicht. Jedenfalls
  sind mit dieser Entscheidung deutlich in Richtung öffentlichen Raum
  gerückt worden. Ich weiß, dass man access=Grundrechtsausübung nicht
  mappen kann, aber den Vergleich Bauernhof--Einkaufszentrum wollte ich
  dann doch hier nicht so stehen lassen.

 Das Urteil stützt sich maßgeblich auf den Fakt, dass die Fraport AG zu
 über der Hälfte in Besitz der öffentlichen Hand ist:
 Von der öffentlichen Hand beherrschte gemischtwirtschaftliche
 Unternehmen unterliegen ebenso wie im Alleineigentum des Staates
 stehende öffentliche Unternehmen, die in den Formen des Privatrechts
 organisiert sind, einer unmittelbaren Grundrechtsbindung. (46)

 Ja, aber erweitert auf z.B. Einkaufszentren in Randnummer 68 ff. und
 noch stärker 98 ff.


Danke! Du hast mir soeben sehr viel Tipparbeit abgenommen :-)

Gruß Falk

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

Re: [Talk-de] Wege mit zeitlicher Zutritts-Beschrängung

[Falk Zscheile]

Am 2. Juni 2014 14:29 schrieb Martin Koppenhoefer dieterdre...@gmail.com:
 Am 2. Juni 2014 12:32 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de:

 Ja, aber erweitert auf z.B. Einkaufszentren in Randnummer 68 ff. und
 noch stärker 98 ff.




 ich glaube kaum, dass dieses Urteil z.B. einen Obdachlosen davor bewahren
 wird, aus einem Einkaufszentrum geworfen zu werden, bzw. nicht eingelassen
 zu werden, genausowenig sehe ich Hinweise darauf, dass z.B. Betteln oder
 Hausieren oder Tanzen oder Musizieren dadurch moeglich wuerde, wenn es
 bisher verboten war.

Und sollen wir das jetzt einzeln je nach Hausordnung mappen oder wie
soll ich deinen Hinweis verstehen? Ich finde deine Argumentation daher
nicht besonders konstruktiv im Hinblick auf OSM und das Datenschema.
Irgend ein Fall wird sich immer finden lassen, auf den es nicht passt.
Ich finde das bringt uns nicht weiter.  Mein Hinweis auf das Urteil
bezog sich nur darauf zu verdeutlichen, dass Einkaufszentren
öffentliche Räume sind und bei OSM anders zu bewerten sind als die
Privatauffahrt zu einem Bauernhof.

Passieren dürfen deine Stadtmusikanten und Hausierer durchs
Einkaufszentrum, sie dürfen dort bloß nicht ihrem Beruf nachgehen.
Wobei das für Musiker im Hinblick auf die Kunstfreiheit im Lichte des
Urteils noch genauer überlegt werden müsste.

 Das Urteil bezieht sich vielmehr auf die
 Meinungsaeusserungsfreiheit und die Versammlungsfreiheit, d.h.
 Kommunikation auch z.B. politischer Natur.

Die Aussage, die du hier wieder unterschlägst ist: Einkaufszentren
etc. sind öffentliche Räume, die grundsätzlich allen offen stehen,
auch wenn sie im Privateigentum stehen und dies auch für Personen, die
nicht einkaufen wollen.

Gruß Falk

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

Re: [Talk-de] Geodaten des Bundes

[Falk Zscheile]

Am 27. Mai 2014 19:38 schrieb Frederik Ramm frede...@remote.org:
 Hallo,

 On 05/27/2014 06:31 PM, Stephan Wolff wrote:
 Es scheint absurd, dass der Bund und OSM die gleiche Bedingung an die
 Nutzer stellen und die Lizenzen deshalb nicht kompatibel sind.

 Ist doch aber logisch, oder?

 Wir verlangen überall wo OSM drin ist, muss auch OSM drauf stehen;
 weitergehende Forderungen bezüglich der Namensnennung erheben wir nicht.

 Wenn ein anderer nun sagt überall wo Bund drin ist, muss auch Bund
 drauf stehen, dann können seine Daten eben nicht in OSM einfliessen,
 weil wir eben nicht mehr garantieren können, dass später noch Bund
 draufsteht.


In § 3 Nr. 2 GeoNutzV ist vorgesehen: [dass] Veränderungen,
Bearbeitungen, neue Gestaltungen oder sonstige Abwandlungen mit einem
Veränderungshinweis im beigegebenen Quellenvermerk versehen werden
oder, sofern die geodatenhaltende Stelle dies verlangt, der
beigegebene Quellenvermerk gelöscht wird.[1]

Man muss die geodatenhaltende Stelle, also den Bund, also nur dazu
bringen, dass sie die Löschung des Quellenvermerks verlangt, was
natürlich Überzeugungsarbeit oder eine Frage geschickter geschickter
Argumentation Es könnte sein, dass die Daten durch meine Bearbeitung
schlechter werden, die Namensnennung ist doch dann nicht mehr in Ihrem
Interesse!? ist. Vielleicht nicht optimal, aber es ist ein Weg.

Die GeoNutzV ist die zum GeoZG gehörende Verordnung. Das GeoZG regelt
das Ob der Freigabe als Open Data, die GeoNutzV regelt das  Wie
der Freigabe von Open Data.

Gruß Falk

[1] http://www.gesetze-im-internet.de/geonutzv/__3.html

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

Re: [Talk-de] Geodaten des Bundes

[Falk Zscheile]

Am 27. Mai 2014 21:40 schrieb Stephan Wolff s.wo...@web.de:
 Am 27.05.2014 20:50, schrieb Joachim Kast:


 Ich bin im Juni/Juli zu Workshops beim Lenkungsgremium GDI-DE und beim
 BMI eingeladen. Dabei werde ich natürlich (wie immer) auf die verzwickte
 Situation der Namensnennung sowie deren Lösung in Berlin und NRW
 hinweisen.


 Das wäre moralisch einfacher, wenn OSM umgekehrt genauso flexibel wäre.


Naja, ein wesentlicher Unterschied ist es meines Erachtens schon, ob
man eine Namensnennung verlangt, weil viele freiwillige in ihrer
Freizeit etwas zu einer gemeinsamen Sache beitragen, oder ob man einen
anderen Grund dafür hat. Ehrlich gesagt ist mir bei Open Government
Data noch kein überzeugender Grund für die Namensnennung eingefallen.
Vielleicht habt ihr ein paar Ideen?

Gruß Falk

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

Re: [Talk-de] ARD Ratgeber: Internet - Alternativen zu Google-Maps Open Source

[Falk Zscheile]

Am 25. Mai 2014 10:48 schrieb Simon Poole si...@poole.ch:
 Es ist halt noch eine Heidelberger Leiche und passt nahtlos in die Reihe mit
[¯...]

 Schädigt OSM massiv, aber dass scheint die Leute nicht zu interessieren.
 Die Community seh ich das nicht in der Pflicht, die kann ja die Server
 nicht abschalten.

 Simon

Hat denn jemand schon mal den Kontakt zum Lehrstuhl gesucht? Es macht
ja wenig Sinn, wenn wir uns jetzt hier alle beschweren und niemand der
betreffenden nimmt es zur Kenntnis, weil sie die Liste nicht oder nur
sporadisch lesen ...

Gruß Falk

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

Re: [Talk-de] Hausnummern-Mapping

[Falk Zscheile]

Am 24. Mai 2014 10:27 schrieb Andreas Neumann andr-neum...@gmx.net:


 Am 24.05.2014 09:52, schrieb Andre Hinrichs:

 Lösung 5: Gleich dem Ordnungsamt Bescheid geben. Das fände ich schon böse...

 Das klingt böse, wäre aber der korrekte Weg. Zumal ich die verdutzten
 Gesichter im Ordnungsamt sehen möchte :D. Warum der korrekte Weg? Bei
 vielen Komunen ist es in einer Verordnung geregelt, dass jedes
 Grundstück eine von außen gut sichtbare Hausnummer haben muss. Leider
 halten sich, insbesondere auf den Vororten (wo doch jeder weiß, dass
 hier Nummer X ist), recht viele nicht an diese Anordnung.

Die Pflicht zur Anbringung einer Hausnummer ergibt sich übrigens aus §
126 Abs. 3 Satz 1 BauGB.

Du musst es ja nicht im Sinne einer Anzeige formulieren. Wenn du
schilderst was OSM tut und darauf hinweist, welche Probleme du bei den
Hausnummern festgestellt hast, dann ergibt sich vielleicht auch die
Möglichkeit einer Kooperration -- Straßenlisten u.ä. Das hängt aber
auch davon ab, ob dir Kontakt mit Menschen und Ämtern liegt.
Vielleicht findet sich ja in der Behörde jemand, der für ein
gegenseitiges Geben und Nehmen in diesem Bereich offen ist. Vielleicht
sucht ja dere Bürgermeister gerade nach ener Möglichkeit, sich im
Bereich des Open Government zu profilieren.

Gruß Falk

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

Re: [Talk-de] Privat oder nicht von der öffentlichen Verwaltung benannte Wege, was: Wegenamen in Kleingärten

[Falk Zscheile]

Am 21. Mai 2014 01:25 schrieb Stephan Wolff s.wo...@web.de:
 Am 20.05.2014 16:17, schrieb Falk Zscheile:

 Am 20. Mai 2014 10:13 schrieb Sven Anders s...@anders-hamburg.de:


 source:name=Straßenverzeichniss Hamburg vom 07.05.2009
 source:name=Schild am Eingang des Kleingartens.

 Dann sollte man das aber so weit abstrahieren, dass eine
 Maschinenlesbarkeit gewährleistet ist! Sonst hält sich der Mehrwert
 des zusätzlichen Tags doch sehr in Grenzen.


 Ja, die Beispieltexte sind nicht nutzbar.


 Wenn man abstrahiert source:name=offical, local [was weiß ich] hätten
 auch die Leute, die Straßenlistenauswertungen machen oder eben
 Navigationssoftware bauen (Ausgangsproblem) etwas davon, weil sie bei
 der Datenauswertung Besonderheiten identifizieren und eine Lösung
 erarbeiten können.


 Für einige Anwendungen wäre diese Information sicherlich nützlich,
 aber:
 - es gibt fast 74.000.000 way mit highway in der Datenbank.
 - viele Mapper werden wohl die Mühe scheuen, viel Arbeit in eine
 Zusatzinformation von geringem Nutzen zu investieren.
 - die meisten Mapper können gar nicht entscheiden, vom wem Name auf dem
 Straßenschild festgelegt wurde. Insbesondere in den Problemfällen (Militar-,
 Uni oder Kleingartengelände) ist es vor Ort oft nicht erkennbar.

 Praktisch ist die Idee wohl nicht umsetzbar.


Es kommt darauf an, von welcher Seite man das aufzieht. In der von dir
geschilderten Richtung sehe ich das genau so. Der Mapper wird --
maschienenlesbar oder nicht -- kaum ein Tag ergänzen, dessen Nutzen
begrenzt ist bzw. den er nicht sieht bzw. Nutzen-Aufwand.

Wenn jetzt aber die Straßenlistenauswerter einen Korrekturlayer oder
ähnliches anbieten, anhand dessen man nicht amtliche Namen auffinden
und mit einem Zusatztag versorgen kann, könnte ich mit schon
vorstellen, dass sich Leute finden, die das übernehmen. Das ist ja
auch ein ziemlich deutsches Problem. Es wird nicht viele Länder auf
der Welt geben, wo man es mit amtlich gepflegten Straßenlisten zu tun
hat, die einigermaßen stimmen. viele Länder werden das sicher ganz
pragmatisch der Post überlassen -- könnte ich mir jedenfalls
vorstellen.

Vielleicht reicht es aber anhand der addr:*=value Tags an Gebäuden auf
Auswertungsseite zu identifizieren, wo es sich nicht um offizielle
Namen handelt. das wäre zum Beispiel auch etwas für die Aktion des
Monats, Gebäudeumrisse und Adressen für Kleingartenkolonien :-) Wobei
das add:*=value Schema wiederum mit den lokalen, in der
Kleingartenkolonie verwendeten Adressen kollidieren dürfte. Aber
irgendwo beißt sich die Katze immer in den Schwanz :-/

Gruß Falk

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

Re: [Talk-de] Privat oder nicht von der öffentlichen Verwaltung benannte Wege, was: Wegenamen in Kleingärten

[Falk Zscheile]

Am 20. Mai 2014 10:13 schrieb Sven Anders s...@anders-hamburg.de:
 Am 19.05.2014 15:52, schrieb Wolfgang Hinsch:

 Wer es für wichtig hält, kann ja taggen, ob der Name privat vergeben und
 amtlich anerkannt oder amtlich vergeben und privat anerkannt wurde ;-)

 Ja, genau das wäre mein Vorschlag:
 Offizielle Straße
 name=Dahlienweg
 source:name=Straßenverzeichniss Hamburg vom 07.05.2009

 Kleingartenverein

 name=Dahlienweg
 source:name=Schild am Eingang des Kleingartens.

Dann sollte man das aber so weit abstrahieren, dass eine
Maschinenlesbarkeit gewährleistet ist! Sonst hält sich der Mehrwert
des zusätzlichen Tags doch sehr in Grenzen.

Wenn man abstrahiert source:name=offical, local [was weiß ich] hätten
auch die Leute, die Straßenlistenauswertungen machen oder eben
Navigationssoftware bauen (Ausgangsproblem) etwas davon, weil sie bei
der Datenauswertung Besonderheiten identifizieren und eine Lösung
erarbeiten können. Das setzt Maschinenlesbarkeit voraus.

Gruß Falk

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

Re: [Talk-de] FOSSGIS 2015 (Uni Münster) Programmkomitee

[Falk Zscheile]

Ich könnte mir vorstellen, anstelle von Michael im Programmkomitee
2015 mitzuarbeiten.

Gruß Falk

Am 18. Mai 2014 18:47 schrieb Michael Kugelmann michaelk_...@gmx.de:
 Hallo allerseits,

 in den letzten Jahren war ich Mitglied des Programmkomitee der FOSSGIS
 Konferenz. Mein Schwerlunkt lag dabei auf dem Bereich OSM. Für die FOSSGIS
 2015 stehe ich aber leider nicht zur Verfügung, gesucht werden deswegen zur
 Verstärkung ein oder auch gerne mehrere Vertreter mit Kenntniss der
 OSM-Szene.

 Aufgabe des Programmkomitee sind die Bewertung der eingereichten Vorträge
 und das Zusammenstellen eines ansprechenden Programms für die Besucher.
 Die Arbeit läuft zum größten Teil im WWW (z.B. pentabarf/FRAB), die
 Koordination in einer geschlossenen ML. Es gibt eine abschließende Sitzung
 des PK (physikaisches Treffen), die Teilnahme daran ist aber nicht zwingend.
 Der Zeitaufwand für die Tätigkeit hält sich in Grenzen, ein Schwerpunkt
 liegt zum Zeitpunkt des Ende der Einreichungsfrist.
 Nachfolgend mal der Link zur Orga-Liste:
 http://www.fossgis.de/wiki/Konferenz_2015/Organisationsteam#Programm-Komitee

 Ich würde mich sehr freuen wenn es Freiwillige gibt.


 Grüße,
 Michael.

 PS: die Tätigkeit ist nicht an eine FOSSGIS-Mitgliedschaft gebunden, jeder
 kann mitmachen!


 ___
 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] Wegenamen in Kleingärten

[Falk Zscheile]

Am 19. Mai 2014 03:06 schrieb Michael Kugelmann michaelk_...@gmx.de:
 Am 19.05.2014 00:09, schrieb Hartmut Holzgraefe:

 Amtlich ist das was der operator als Namen vergeben hat, egal
 ob öffentliche amtliche Wege in einer Gemeinde, Wege in einer
 Gartenkolonie, oder Straße auf einem Werksgelände ... und damit ist
 es name= Insbesondere wenn der Name nicht nur auf Plänen
 auftaucht sondern Wege auch beschildert sind (ist in vielen
 Kleingärten der Fall) ist das für mich eindeutig ein name=

 ich will mal ein paar Anmerkungen einbringen, welche aus einem Gespräch beim
 Vermessungsamt der Stadt München abgeleitet sind.

 Ich konstruiere mal einen Fall:
 in einer Kleingartenanlage passiert ein schwerer Unfall, es wird ein Notarzt
 gerufen. Die Kleingärtner nutzen OSM-Karten (löblich), und geben Blumenweg
 als Unfallort an, so wie in der OSM-Karte aufgeführt.
 Der Notarzt nutzt eine amtliche Karte, dort gibt es keinen Blumenweg, der
 Notarzt weiß nicht wo er hinfahren soll.

 Aus derartigen Gründen sind die amtlichen Stellen der Meinung, dass nur
 offizielle Namen auf Karten erscheinen sollen. Namen in Kleingartenanlagen
 sind nicht offiziell.
 Ich kann die diese Argumentation sehr wohl verstehen.


Es bestreitet hier auch niemand, dass dies ein wichtiger Aspekt ist.
Wir sagen nur: name=value ist bei OSM nicht gleichbedeutend mit
official_name=vale oder gar auf diesen beschränkt. Nebenbei in vielen
Ländern würdest du mit dieser Ansicht nur Verwunderung ernten. Da sind
die Leute froh, dass sie überhaupt eine Adresse haben. Nicht überall
ist die Welt so durchadministriert wie bei uns.

Als Lösung schlagen einige hier vor das vorhandene Tagginschema so zu
nutzen, dass Irrtümer weitgehend ausgeschlossen werden, insbesondere
auf der Auswertungsseite zu schauen, ob man dort nicht etwas
verbessern kann, bevor man daran geht zu sagen name bedeutet etwas
anderes als name

Wenn es wirklich keine Lösung auf der Auswertungsseite gibt, dann
könnte ich mir auch vorstellen, dass man für nicht amtlich
registrierte Wege ein name=value und ein official_name=nonexistent
vergibt, obwohl das auch gegen die OSM-Konvention ist und bei den
Kartenrenderern vielleicht zu Problemen führt. Es handelt sich bei
nonexistent ja schließlich nicht um einen echten Namen, sondern um
eine technische Interpretationsregel.

Jedenfalls würde ich mich über mehr Beiträge freuen, die über Lösungen
nachdenken, die nicht die Inhaltsdefinition von name=value berühren.

Gruß Falk

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

Re: [Talk-de] Privat oder nicht von der öffentlichen Verwaltung benannte Wege, was: Wegenamen in Kleingärten

[Falk Zscheile]

 Oder anders ausgedrückt, mit Zusatztags beschreiben, was name=value
 definiert, damit die Mapnik-Karte nicht berührt wird. Obwohl man auch
 loc_name rendern könnte, wenn name fehlt. ;-)

 Ich vermute mal, dass das für die meisten der Hauptgrund ist.

 official_name ist vergeben und sollte nicht umdefiniert werden.

 loc_name statt name passt IMO, soll aber nicht benutzt werden.

 source:name=inofficial?
 name_operator=local?

Klingt für mich praktikabel.

Wobei ich ja name:source=value besser finde :-)

Gruß Falk

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

Re: [Talk-de] Wegenamen in Kleingärten

[Falk Zscheile]

Am 18. Mai 2014 15:37 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de:
 Hallo,

 in vielen Kleingartenanlagen vergeben die Kleingärtner Wegenamen nach
 eigenem Ermessen. Das führt dann dazu, dass z.B. der Dahlienweg in HH
 10x oder öfter existiert, davon aber nur 1x offiziell von der Stadt
 benannt und in öffentlichen Verzeichnissen vorhanden.

 Wenn das Tag name für diese Wege benutzt wird, macht das die Navigation
 nach OSM-Daten unbrauchbar, für jeden Navi-Benutzer wie für
 Rettungsdienste, Taxi etc.

Aber nicht, weil unsere Daten schlecht sind, sondern weil auf
Auswertungsseite nicht hinreichend berücksichtigt wird, dass
name=value nicht unbedingt deckungsgleich mit offical_name=value ist.
Die Auswertung muss also besser werden, nicht (zwingend) die
Datenbank. Wir haben, jedenfalls was name* angeht, ausreichend viele
Tags um die auftretenden eventualitäten abzudecken. Der Auswerter muss
sich etwas einfallen lassen, wenn neben name=value noch
offical_name=value, local_name=value, short_name=value etc. auftauchen
und nicht übereinstimmen.

 Ich würde vorschlagen, in Fällen, in denen der Name nicht offiziell ist
 (es gibt auch offizielle Namen), das Tag loc_name zu benutzen, da der
 Namen nur lokal im Bereich der jeweiligen Gartenanlage gilt. Name sollte
 dann nicht vergeben werden.

Ich bin der Meinung name=value ist der vor Ort verwendete Name und
nicht zwingend der offizielle Name, sonst wäre name auch bei Feldwegen
unanwendbar, nur weil sie nicht in der Straßenliste auftauchen. Wir
mappen schließlich on the ground. Ein Straße kann auch einen Namen
haben, wenn das nicht amtlich festgestellt ist. Die Verwaltung vergibt
nur dort Namen, wo sie die für ihre Zwecke braucht. Menschen vergeben
Namen auch dort, wo es die Verwaltung nicht für nötig hält.

 Gegenargument der meisten Mapper dürfte sein: Dann steht der Name aber
 nicht in der Karte.


... und das obwohl die Straße/der Weg von den Leuten die in Nutzen
einen Namen hat. Das ist nicht schön ...

Ich weiß, bei den Leuten, die Straßenlistenauswertungen betreiben,
sind solche basisdemokratisch vergebenen Namen sehr unbeliebt, weil
sie die Fehlerquote bei der Auswertung erhöhen, aber das sollte kein
Grund sein, solchen Straßen und Wegen das name-tag zu verweigern, nur
damit die Statistik stimmt.

Mein Vorschlag wäre der folgende: Kleingartenkolonien haben in der
Regel auch eine echte Adresse. wenn man gleichzeitig neben dem
Vorortnamen name=value noch addr:street=value setzt, kann man das
Auswerten und für alle ein brauchbares Ergebnis erzielen.

 Meinungen?


Hiermit geschehen.


Gruß Falk

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

Re: [Talk-de] Verhältnis von access und designated, war: Re: deutsches Wiki, access=designated kurzdefinition

[Falk Zscheile]

Am 12. Mai 2014 11:39 schrieb Martin Koppenhoefer dieterdre...@gmail.com:
 Am 10. Mai 2014 14:17 schrieb Dirk Sohler s...@0x7be.de:

 Falk Zscheile schrieb:
  bicycle=designated und foot=designated wird insbesondere im
  Zusammenhang mit traffic_sign=DE:240 bzw. DE:241 verwendet. Dann heißt
  es aber eigentlich access=designated, designated=bicycle,
  designated=foot, womit alle anderen Verkehrsteilnehmer ausgeschlossen
  sind.



 das wäre mir neu, normalerweise taggt man foot=designated
 bicycle=designated.

Das hast du völlig richtig bemerkt. Mein Posting hatte nicht zum
Inhalt so müssen wir das bei OSM machen sondern so wäre es (aus
meiner Sicht logisch und konsistent

Das Problem was ich sehe: Wenn wir mit unserer Mehtode zu taggen
ständig nur Einzel- und Sonderfälle verursachen, dann produzieren wir
unnötig Kompläxität. Man kann dann anhand der Logik keine Regeln
herleiten, sondern muss alle Regeln kennen. Das kann niemand leisten,
schon gar nicht in einem Hobbyprojekt. Mehr wollte ich nicht
aufzeigen.

 Was Du oben vorschlägst geht ja schon deshalb nicht,
 weil jeder Schlüssel nur einmal vorkommen darf. Das generische access
 sollte man m.E. eher nicht oder sparsam verwenden (d.h. wenn die Regeln für
 alle Verkehrsarten gelten), ansonsten erhöht man nur unnötig die
 Komplexität und schließt ggf. Verkehrsarten aus, an die man nicht gedacht
 hat und die deshalb nicht explizit den generellen Wert überschreiben durch
 einen spezifischen tag.

Etwas anderes ist aber ein Rad-/Fußweg nicht. Er schließt andere
Verkehrsmittel aus, soweit sie nicht explizit zugelassen werden. Ich
verstehe also im Moment nicht, was du mir erklären willst.

Gruß Falk

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

[Talk-de] Verhältnis von access und designated, war: Re: deutsches Wiki, access=designated kurzdefinition

[Falk Zscheile]

Am 9. Mai 2014 19:08 schrieb Hubert sg.fo...@gmx.de:

 die Grüne Box hab ich nicht gesehen. Müsste aufjedenfall mal überarbeitet
 werden.

 Ob vorgesehe, gewidmet oder ausgeschildert eingesetzt werden soll,
 hängt davon ab, was man unter designated versteht.
 Ich verstehe darunter alle ausgeschilderten Wege (Blaue VZ 237,240,241 oder
 eventuell sogar Radroutenschilder) aber auch rechte nichtbenutzungpflichtige
 Radwege (ohne jegliche Beschilderung). Daher empfinde ich verpflichtend
 auf den Fall als Falsch und ausgeschildert dementsprechend auch nicht
 passend.

designated=value ist, wenn ich das richtig sehe nichts anderes und
allgemein gebräuchliche Kurzform von access=designated,
designated=value.

Wir verwenden aber immer nur bicycle=designated und foot=designated

Wie so oft bei OSM passt key=designated natürlich nicht bruchfrei zu
access=value, wie es sonst verwendet wird.

Sind auch Fälle denkbar wie: access=all, designated=[bestimmtes Fahrzeug]?

bicycle=designated und foot=designated wird insbesondere im
Zusammenhang mit traffic_sign=DE:240 bzw. DE:241 verwendet. Dann heißt
es aber eigentlich access=designated, designated=bicycle,
designated=foot, womit alle anderen Verkehrsteilnehmer ausgeschlossen
sind.

Alles höchst unbefriedigend, höchst unbefriedigend ...

Oder gelingt es jemandem von euch designated und access in ein
logisches und für OSM konsistentes Schema zu bringen?


Gruß Falk

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

Re: [Talk-de] Verhältnis von access und designated, war: Re: deutsches Wiki, access=designated kurzdefinition

[Falk Zscheile]

Am 10. Mai 2014 14:17 schrieb Dirk Sohler s...@0x7be.de:
 Falk Zscheile schrieb:
 bicycle=designated und foot=designated wird insbesondere im
 Zusammenhang mit traffic_sign=DE:240 bzw. DE:241 verwendet. Dann heißt
 es aber eigentlich access=designated, designated=bicycle,
 designated=foot, womit alle anderen Verkehrsteilnehmer ausgeschlossen
 sind.

 Zumindest beim Zeichen 241 gilt es eben nicht, da es sich hier
 rechtlich um zwei direkt nebeneinanderliegende Wege handelt, einen für
 Fußgänger, und einen für Radfahrer. Streng genommen müssten also zwei
 Wege gemappt werden, einen mit „access=designated, designated=bicycle“,
 und einen mit „access=designated, designated=foot“ … Wobei die diversen
 Sonderfälle und Ausnahmen von der Benutzungspflicht hier noch gar nicht
 berücksichtigt sind …

Also ich habe mich gerade auf der osm-mv liste in Bezug auf
Autostraßen aufklären lassen, dass bei Straßen/Wegen die physische
Beschaffenheit gemappt wird, also ein geteerter Weg, und nicht die
rechtliche Beschaffenheit, eine Spur für Fahrräder und eine Spur für
Fußgänger.

Im Endeffekt sind es auch mehrere Informationen, die wir getrennt
erfassen sollten: 1. der Weg als physische Einheit, 2. ggf. die
Aufteilung des Weges in einzelne Spuren, 3. die Benutzungsbedingungen
für den Weg bzw. die Fahrspuren.

1. wäre highway=path
2. wäre segregated=yes
3. wäre die access/designated-Problematik

Gruß Falk

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

Re: [Talk-de] Verhältnis von access und designated, war: Re: deutsches Wiki, access=designated kurzdefinition

[Falk Zscheile]

Am 10. Mai 2014 14:23 schrieb Hubert sg.fo...@gmx.de:

 das wird schwierig. Besonders in Hinblick auf backward-capability.
 Wenn ich das Richtig verstehe versuchst Du so etwas ananlog zu
 highway=footway + footway=sidewalk/crossing.
 Von der Key:bicycle-Seite steht zu der Werten nur:  For values see
 access=*. 

Naja, so lange für backward die gleichen access-Bedingungen gelten wie
für forward ist es kein Problem, sonst schon ...

 (Wäre übrigens ein Grund bicycle=use_sidepath nicht zu erlauben)

Da bin ich mir nicht sicher. Ohne das Proposal vollständig verstanden
zu haben, wäre die Information von bicycle=use_sidepath doch (aus dem
Blickwinkel von access) etwa: für die Straße an der das Tag hängt:
access:bicycle=no und bicycle=use_sidepath die Zusatzinformation, dass
es einen parallel verlaufenden Weg gibt, den der Fahrradfahrer
benutzen kann/soll/darf, oder?


Gruß Falk

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

Re: [Talk-de] Verhältnis von access und designated, war: Re: deutsches Wiki, access=designated kurzdefinition

[Falk Zscheile]

Am 10. Mai 2014 16:11 schrieb Hubert sg.fo...@gmx.de:
 Am 10. Mai 2014 15:42 schrieb falk.zsche...@gmail.com:

 Am 10. Mai 2014 14:23 schrieb Hubert sg.fo...@gmx.de:

  das wird schwierig. Besonders in Hinblick auf backward-capability.
  Wenn ich das Richtig verstehe versuchst Du so etwas ananlog zu
  highway=footway + footway=sidewalk/crossing.
  Von der Key:bicycle-Seite steht zu der Werten nur:  For values see
  access=*. 

 Naja, so lange für backward die gleichen access-Bedingungen gelten wie
 für forward ist es kein Problem, sonst schon ...

 Ich glaub, da hast du mich missverstanden, oder ich dich gerade. Mit 
 backward-capability  meinte ich nicht in Bezug auf die Fahrtrichtung der
 Straße sondern in Hinblick auf schon in den Daten vorhandene Tags.

 In der Tat. Habe ich.

Aber das Problem haben wir bei OSM immer, wenn sich etwas entwickelt.
Und das sich nichts mehr entwickelt, das wollen wir ja auch nicht,
denn perfekt ist unser Datenschema, wie mein Beispiel zeigt, noch
lange nicht.

Gruß Falk

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

Re: [Talk-de] JOSM: Tags = Schlagwörter

[Falk Zscheile]

Am 28. April 2014 06:25 schrieb Dirk Sohler s...@0x7be.de:
 Frederik Ramm schrieb:
 Findet irgendjemand das gut […]

 Nein. „Tag“ ist, wie viele andere Begriffe, eine Etablierte
 Bezeichnung. Auch, wenn „Schlagwort“ eine angemessen sinnvolle
 Übersetzung darstellt, ist „Tag“ die bessere, weil eben etablierte
 Bezeichnung. Zum Internet sagt ja auch (hoffentlich) niemand
 „Weltnetz“, auch, wenn die Übersetzung passt :)


Da sich mir nach fast 6 Jahren bei OSM immer noch ein innerer
Widerstand aufbaut, wenn ich hier Tag schreibe und nicht den
Wochentag meine, wäre ich für eine Übersetzung. Attribut oder
Eigenschaft fände ich passend. Schlagwort ist etwas anderes und daher
nicht geeignet.

Gruß Falk

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

Re: [Talk-de] JOSM: Tags = Schlagwörter

[Falk Zscheile]

Am 28. April 2014 10:03 schrieb Sven Geggus li...@fuchsschwanzdomain.de:
 Falk Zscheile falk.zsche...@gmail.com wrote:

 Da sich mir nach fast 6 Jahren bei OSM immer noch ein innerer
 Widerstand aufbaut, wenn ich hier Tag schreibe und nicht den
 Wochentag meine, wäre ich für eine Übersetzung.

 Aha, und bei Montageanleitungen kommt es Dir dann vermutlich auch jedesmal
 komisch vor, wenn nicht gerade Montag ist %-/

Wenn ich hier der einzige bin, dem es so geht, dann ist es ja gut.
Glaube ich aber nicht. Vielleicht deshalb mit Polemik etwas
zurückhalten, damit hier nicht gleich alle sagen oh diskutieren macht
ja hier eh keinen Sinn, man ernete nur bissige Bemerkungen. Noch
weniger Hilfreich sind die Bemerkungen von Dirk a la Weltnetz --
Todschlagargument. Bis unser T(t)ag so allgemein verbreitet ist wie
der Begriff Internet hat OSM noch einen weiten Weg vor sich. Also:
Wer eine Übersetzung generell für falsch hält, der soll sich doch
bitte an die englische JOSM-Version halten. Alle anderen können gern
weiter darüber nachdenken, ob es für T(t)ag eine bessere Übersetzung
als Schlagwort gibt, oder ob es als Fachbegriff nicht übersetzt werden
sollte. Wobei T(t)ag im deutschen nicht besonders intuitiv ist. Das
Zeile einer Übersetzung ist doch aber die leichtere Verständlichkeit.
Daher  meine Vorschläge Attribut oder Eigenschaft.

Gruß Falk

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

Re: [Talk-de] JOSM: Tags = Schlagwörter

[Falk Zscheile]

Am 28. April 2014 13:48 schrieb Sven Geggus li...@fuchsschwanzdomain.de:

 Worauf ich raus möchte: Lokalisierung ist super, wenn Sie dem Benutzer
 hilft. Wenn sie aber dazu führt, dass der Benutzer Fachtermini nicht mehr
 einordnen kann, dann ist sie über das Ziel hinausgeschossen.

Soweit sind wir uns einig.

 Im Falle der
 tags finde ich, dass das wie bei Interrupt der Fall ist.

 Mit
 Schlagwörtern assoziiere ich eine ganze Menge, die key-value tags an
 Objekten bei osm gehören aber nicht dazu.

Auch hier sind wir konform.

 Daher muss der weg. Schon der
 Begriff Objekteigenschaften oder Merkmale wäre IMO besser als Schlagwörter,
 wenn man den englischen Begriff partout nicht beibehalten möchte.


Was denkt ihr, sollte man vielleicht eine Umfrage starten, um die am
wenigsten Abgelehnte Übersetzung von Tag herauszufinden? Oder warten
wir einfach zu, bis jemand einfach Ändert und damit einen neuen
Vorschlag in den Ring wirft?

Gruß Falk

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

Re: [Talk-de] Baum der Woche: Kastanie

[Falk Zscheile]

Am 15. April 2014 09:37 schrieb tumsi tu...@gmx.de:

 zu taggen. Vielleicht gibt es dann im Herbst eine
 Kastaniensammelkarte?


 Sollten wir nicht auch die Bärlauchfelder im Wald mappen, damit man auch in
 unbekannteren Gegenden schnell mal ein paar Blätter für die Küche sammeln
 kann?


:-)

Oh, das ist ein extrem schwieriges Thema. Möglicherweise brauchen
wir dann neben dem surface-Tag auch noch ein
vegetation-Tag, dass dann auch noch nach Bewuchshöhe differenzieren
muss. Wenn unsere Mitgliederzahl auf 100 Mio. aktive (!) Mitglieder
gestiegen ist, dann setze ich das Thema nochmal auf die Tagesordnung
-- versprochen ;-)

Viele Grüße
Falk

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

Re: [Talk-de] Flächenmapping so korrekt? Wie korrigieren?

[Falk Zscheile]

Am 5. April 2014 20:38 schrieb Martin Koppenhoefer dieterdre...@gmail.com:


 Am 05/apr/2014 um 20:08 schrieb Andreas Labres l...@lab.at:

 Meine radikaler Lösungsansatz: wir kübeln (gedanklich) alle landuse, natural,
 leisure, area Tags und machen einen landcover (z.B.) Tag, der die
 geographisch/kartographisch relevante Flächenbeschreibung wiedergibt. Alles
 andere ist nur Fallback, falls es keinen landcover Tag gibt


 ich finde es kein Problem, wenn es überlappende Flächen gibt, solange das 
 jeweils orthogonale Eigenschaften sind. Landnutzung und Bewuchs hängen zwar 
 schon zusammen, im Sinne dass nicht jegliche Kombination möglich ist, aber 
 das hat schon beides seine Berechtigung, getaggt zu werden



Was meinst du in diesem Zusammenhang mit orthogonal?

Das Problem ist, das wir mit dem offenen on the ground Ansatz von OSM
auch ganz oft eine Froschperspektive einnehmen: Ich sehe etwas und
geben dem Etwas ein Tag. Allzuoft wird dabei nicht links und rechts
geschaut. So finden wir heute viele Tags, bei denen es
unterschiedliche Auffassungen gibt und die hier oft für Diskussion
sorgen. Das liegt oft nicht daran das man das Tag nicht richtig
versteht, sondern weil es unterschidliche Interpretationen zulässt.
Das liegt in der Regel daran, dass ein Tag nicht nur eine Information
enthält, sondern in der Regel viele, die sich überlagern. Ein
Beispiel: highway=track, tracktype=value, ist eine (je nach
Sichtweise) lustige bis üble Mischung aus
1. landuse: der Weg führt durch Wald oder Feld,
2. access:  da dürfen nur forst- und landwirtschaftliche Fahrzeuge fahren,
3. surface: befestigt, asphaltiert, unbefestigt, etc.,
4. highway: es handelt sich um eine Straße.

Das Ganze hat man auch bei Radwegen und insbesondere bei Landuse: da
wird Nutzung, Bewuchs und Oberflächen lustig in einem Tag
zusammengefasst, obwohl man das auch in getrennten Tags erfassen kann
und sollte!
Verallgemeinernd kann man sagen: die Tags werden um so
unbefriedigender und der Streit um so größer, je mehr
Einzelinformationen in einem Tag zusammengefasst sind.

Man kann sich viel leichter darauf einigen, ob auf einer Fläche Gras
wächst als darüber zu diskutieren, ob das eine Kuhweide, Heuwiese,
Parkwiese, Rasen, Golfrasen etc. ist. All diese Begriffe haben eben
nicht nur die Information Bewuchs, sondern auch noch zumindest eine
Information zur Nutzung. Wenn jemand einfach nur Gras mappen möchte
muss er sich gleichzeitig mit der Bedeutung dieser vielen
unterschiedlichen Nutzungsarten beschäftigen, um das richtige Tag zu
finden. Die dabei auftretenden Fehler und Missverständnisse machen in
meinen Augen 75 % der Tagstreitereien bei OSM aus -- dabei wollte man
doch einfach nur Gras eintragen ...

 Und vor allem: die geographische Information hier ist Wiese ist entkoppelt 
 von
 jeglicher Frage wem gehört die Fläche?, wie wird sie genutzt?,...


 Wiese ist ja eine Nutzung, Grasbewuchs hingegen wäre ein landcover

Genau. Und das gehört getrennt erfasst.

Gruß Falk

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

Re: [Talk-de] Flächenmapping so korrekt? Wie korrigieren?

[Falk Zscheile]

Am 5. April 2014 23:30 schrieb Christoph Hormann chris_horm...@gmx.de:
 On Saturday 05 April 2014, Andreas Labres wrote:
 On 05.04.14 20:38, Martin Koppenhoefer wrote:
  Wiese ist ja eine Nutzung, Grasbewuchs hingegen wäre ein landcover

 Eben das ist ja das Übel. Das Rendering basiert (in vielen Fällen)
 auf einer Nutzungsklasse. Wir sollten aber eine kartographisch
 Oberflächentypisierung haben, wo man Wiese als Wiese klassifizieren
 kann, Wald als Wald, Weingärten als Weingärten (usw., was man halt
 kartographisch braucht).

 Das ganze funktioniert aber selbst in Mitteleuropa nicht - eine
 Streuobstwiese ist zum Beispiel gleichzeitig eine Wiese und ein
 Obstbaumbestand.  In anderen Gegenden, wo nicht jeder Quadratmeter Erde
 zugeschnitten und mit deutscher Gründlichkeit verwaltet wird, gilt das
 noch viel mehr.

Wieso nicht, man kann die Informationen doch getrennt erfassen. Aus
der Kombination der Informationen ergibt sich dann, dass es eine
Obstwiese ist.

Nur weil die Welt vielfältiger ist, als man es in Karten abbilden
kann, heißt es doch nicht, dass man es gleich lassen soll möglichst
einfache Tags zu finden. Einfach heißt in diesem Fall, dass wichtige
Informationen möglichst getrennt erfasst werden.

 Was Du 'Oberflächentypisierung' nennst ist im Grunde vor allem
 Wunschdenken von Bürokraten, jeder Fläche eine von 20-30 Klassen
 zuzuweisen.  Wie diese Klassen zugeschnitten sind, hängt natürlich von
 der jeweiligen Zielrichtung ab, immer ist es aber entweder das eine
 oder das andere und kein Mittelding.

Was ist dein Lösungsvorschlag? Man kommt bei einer Datenbank mit
geografischen Informationen nun einmal nicht um Abstrahierung herum.
Und dort wo man abstrahiert muss man notgedrungen auch klassifizieren.
Dazu gibt es keine Alternative. Und wenn es schon keine Alternative
gibt, dann sollte man es möglichst in ein handhabbares Schema bringen.
Daran fehlt es manchmal bei OSM.

 In OSM ist das letzendlich nicht anders und natürlich wäre es irgendwie
 eleganter, das über die Zeit gewachsene System mit seinen inneren
 Wiedersprüchen durch ein konsistent gestaltetes System zu ersetzen.
 Das würde aber a) auch nicht perfekt sein und mit der Zeit genauso
 verkorkst werden wie das jetzige und b) die inherente Problematik einer
 solchen Klasseneinteilung nicht lösen.

Es muss noicht perfekt sein. Gut reicht völlig. Ziel muss es sein,
dass jemand der nur Gras eintragen will, sich nicht auch noch mit den
verschiedenen Nutzungsarten von Gras auseinandersetzen muss (Weide,
Zierrasen, Heuwiese, Parkwiese).

Was ist deiner Meinung nach die inherente Problematik einer
Klassifizierung? Die Abstrahierung der uns umgebenden Umwelt?

 Was sehr schön wäre ist, wenn es möglich wäre, die gröbsten
 Inkonsistenzen durch gezielte und ggf. auch radikale Änderungen an den
 im Wiki dokumentierten Regeln und entsprechend im
 Standard-Rendering-Stil zu ändern.  Ob das jeweils dann als landuse-,
 landcover- oder natural-key läuft, ist denke ich egal - die meisten
 Mapper interessieren sich eh nicht für die Feinheiten der Semantik.

Deswegen ist es auch so Wichtig nicht mehrere wichtige Informationen
in einem Tag zu verstecken. Eine einfach Semantik im Sinne von nur
eine Hauptinformation pro Tag wäre wünschenswert.

 Es
 gibt ja immer wieder vernünftige Ansätze in der Richtung, die sich aber
 meist im Sand verlaufen.  Zuletzt wenn ich mich recht erinnere zum
 Beispiel zum natural=wood/landuse=forest-Chaos, woraus dann aber auch
 wieder nichts geworden ist (warum eigentlich?).

Woran machst du fest, dass sich nichts entwickelt. An welchen
Kriterien würdest du erkennen, dass sich etwas ändert oder eben nicht?
Nur weil man nicht gleich los zieht und alle natural=wood löscht heißt
das doch nicht, dass sich nichts entwickelt.

Gruß Falk

Gruß Falk

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

Re: [Talk-de] Flächenmapping so korrekt? Wie korrigieren?

[Falk Zscheile]

Am 6. April 2014 14:44 schrieb Christoph Hormann chris_horm...@gmx.de:
 On Sunday 06 April 2014, Falk Zscheile wrote:
 [...]
 Was ist deiner Meinung nach die inherente Problematik einer
 Klassifizierung? Die Abstrahierung der uns umgebenden Umwelt?

 Nein, sondern die Notwendigkeit, in jedem Fall eine
 entweder-oder-Entscheidung zu fällen.  Mit einem allgemeinen
 landcover-Schema gäbe es halt ein landcover=grass und ein
 landcover=trees und man müsste sich bei der Streuobstwiese unsinnig
 entscheiden, was man nimmt.  Das wäre gegenüber der derzeitigen
 Situation, wo man zumindest teilweise natural- und landuse-Tags
 kombinieren kann, nochmals verschärft.

 Auch wenn man in der gerenderten Karte am Ende vielleicht nur entweder
 das eine oder das andere darstellt, sollte man das nicht schon bei der
 Erfassung vorbestimmen.


Man soll durch das Zerlegen eines Tags in seine Hauptbestandteile ja
gerade eine differenzierte Entscheidung treffen können. Eben zwischen
Bewuchs und dessen Nutzung. Das kann ja durchaus redundant zueinander
sein: landcover=trees und landuse=park. Landcover kann man vom
Luftbild zeichnen, landuse muss einer mit Ortskenntnis ergänzen. Und
beim Streit um landuse=park ginge es dann nicht mehr um die Frage ob
da Bäume stehen, sondern nur noch um die Frage was einen park sonst
noch auszeichnet. Dann wäre landcover=trees und landcover=grass
jeweils mit landuse=park. Ich gebe zu kein perfektes Beispiel, aber
ich denke man erkennt, was ich meine.

  Was sehr schön wäre ist, wenn es möglich wäre, die gröbsten
  Inkonsistenzen durch gezielte und ggf. auch radikale Änderungen an
  den im Wiki dokumentierten Regeln und entsprechend im
  Standard-Rendering-Stil zu ändern.  Ob das jeweils dann als
  landuse-, landcover- oder natural-key läuft, ist denke ich egal -
  die meisten Mapper interessieren sich eh nicht für die Feinheiten
  der Semantik.

 Deswegen ist es auch so Wichtig nicht mehrere wichtige Informationen
 in einem Tag zu verstecken. Eine einfach Semantik im Sinne von nur
 eine Hauptinformation pro Tag wäre wünschenswert.

 Ich denke, da sind wir uns weitgehend einig, ich denke aber auch, dass
 dies eher durch klarere Eingrenzungen bestehender Tags als durch
 Schaffung vollkommen neuer gelingen könnte.

 Generell scheint es mir von primärer Bedeutung, dass der Mapper für das,
 was er sieht, die passenden Tags findet.  Dafür ist es oft sehr
 hinderlich, wenn die Tags in ihrer Bedeutung viele Aspekte kombinieren,
 wie es ja leider oft vorkommt.

Da sind wir uns in der Tat vollkommen einig.

 Gleichzeitig ist es aber auch
 erschwerend, wenn der Mapper für die exakte Beschreibung von dem was er
 sieht ein halbes Dutzend Tags kombinieren muss und der Renderer dann
 trotzdem nur eines davon für die Darstellung nutzt.  Sieht der Mapper
 zum Beispiel einen Park, ist es durchaus recht praktisch, dass er das
 leisure=park taggen kann und damit fertig und nicht eine Kombination
 von

 landcover=grass
 trees=yes
 access=public
 purpose=recreation
 sitting=yes
 walking=yes
 running=no
 bike=no
 children=yes
 ballsport=no

 verwenden muss, um das zu umschreiben und der Renderer es dann trotzdem
 genau wie eine Viehweide darstellt.  Ideal ist es natürlich, wenn
 beides möglich ist, es also fein granulierte Tags gibt sowie
 shortcut-Tags für gängige Kombinationen.  Das würde aber vor allem von
 den Renderern eine intelligentere Tag-Auswertung erfordern.


Ja, ich erkenne das Problem, wenn man ein Tag zu stark in einzelne
Informationen zerteilt. Deswegen sprach ich auch von Hauptelementen.
Es wäre vielleicht mal ein Hackingweekend ganz anderer Art, wenn man
mal einen Workshop zu der Frage veranstalten würde.

Meine Idee ist bisher mehrere Hauptkategorien zu bilden, in der Art:
Oberflächenbewuchs, Nutzung, Vegetationsform, ???. Dann müsste man
schauen, ob sich daraus alle wichtigen OSM-Tags einfach und
verständlich wiederfinden. Anhaltspunkt könnten die wichtigsten
Kartendarstellungen sein. Dann wäre eine Aufgabe des Wikis eben auch
zu sagen, welche wesentlichen Elemente getaggt werden müssen, wenn es
ein Park sein soll. Drei Elemente wären da schon die äußerste Grenze.
Gewisse Redundanzen können ja durchaus hilfreich sein landuse=park
landcover=trees.

Wie gesagt, könnte ein interessantes Workshop-Wochenende werden ...
Allein schon die Frage, ob es überhaupt möglich ist, wäre spannend ...

Gruß Falk

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

Re: [Talk-de] Flächenmapping so korrekt? Wie korrigieren?

[Falk Zscheile]

Am 5. April 2014 06:24 schrieb Andreas Labres l...@lab.at:
 On 04.04.14 20:24, Tobias Knerr wrote:
 wenn die
 Fläche als area:highway getaggt ist - also das Gegenstück zum
 Riverbank-Modell.

 Klingt gut, aber das Proposal ist doch tot...


Man könnte es wiederbeleben. ein Phänomen von OSM ist ja auch, dass
manche Mapper bzw. Communitys aufgrund ihrer Spezialisierung oder
mangels anderer Objekte ein Problem schon so früh entdecken, dass alle
anderen Mapper nur mit den Schultern zucken. Es kann durchaus sein,
dass diese früher schulterzuckenden Mapper früher oder später auf die
gleiche Problematik stoßen und dann genug Mapper vorhanden sind, um
einem Taggingvorschlag zum Durchbruch zu verhelfen. Es kann daher nie
schaden, ein Problem immer wieder auf die Mailingliste zu bringen und
auf einen Durchbruch zu hoffen. :-)


 Stand heute ist, dass Flächenmapper highway=footway (z.B.) Wege entfernen und
 durch pedestrian areas ersetzen. Und damit das Routing kaputten. Und wenn ein
 anderer Mapper footways zeichnet (durchaus in sinnvollem und anschaubarem
 Ausmaß), werden die wieder entfernt.

Das ist natürlich nicht in Ordnung, weil es dem OSM-Grundsatz von
leben und leben lassen. Zumal Straßenvektorenmapping und
Straßenflächenmapping sich nicht wirklich widersprechen bzw.
gegenseitig behindern. Hier wird scheinbar so verfahren als gebe es
bereits eine allgemein akzeptierte Lösung.

Straßenflächen habe ich auch schon einmal gemappt (natürlich unter
Belassung der Straßenvektoren), weil mich die auf einen Straßenvektor
gepappten Flächennutzungsgebiete (landuse) gestört haben. Der
Straßenvektor wurde also als Grenze genutzt und alles miteinander
verbunden -- sehr unschön. Also habe ich die Straßen als Fläche
eingetragen und diese Straßenfläche mit den angrenzenden
Flächennutzungen verbunden. Sieht besser aus und lässt sich auch im
Editor viel besser handhaben. Und natürlich entspricht es auch eher
der Realität.


 Ist status quo sehr unbefriedigend.

In der Tat, insbesondere wenn sich die Mapper gegenseitig auf die Füße
treten und sich gegenseitig bei ihrem Hobby behindern.

Gruß Falk

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

Re: [Talk-de] Announce: Mapnik-de: Schöneres Rendering von Sportplätzen

[Falk Zscheile]

Am 5. April 2014 15:22 schrieb Sven Geggus li...@fuchsschwanzdomain.de:
 am französischen Stil gefällt mir das Rendering von Sportplätzen
 besonders gut.

 [...]

 Deashalb habe ich das mal in die klassische xml Syntax von Mapnik
 konvertiert und in den deutschen Stil eingebaut.

[...]

Sehr schön! Vielen Dank! Sieht toll aus!

Gruß Falk

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

Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)

[Falk Zscheile]

Am 4. April 2014 14:23 schrieb Martin Koppenhoefer dieterdre...@gmail.com:
 Am 3. April 2014 20:52 schrieb Falk Zscheile falk.zsche...@gmail.com:

  Wenn man das Schild erfassen will (ich finde das eher unnötig), dann
 wäre
  mit traffic_sign=DE:397 der Inhalt vollständig beschrieben.
 
  Und was machst du, wenn auf der Straße gleichzeitig noch eine
  Geschwindigkeitsbegrenzung und ein Halteverbot stehen. Ich habe da
  eine Lösung: access:traffic_sign=DE:value und
  parking:traffic_sign=DE:value  und maxspeed:traffic_sign=DE:value
 
 
  @Falk: Siehe oben, ich würde Verkehrsschilder immer dort mappen, wo sie
  stehen (nicht am Ende der Sackgasse).

 Wie gesagt, bei Straßennamen handhaben wir das anders und ich halte
 das auch bei anderen (hier Verkehrs-) Schildern für sinnvoll.




 wie ist denn der tag für ein Straßennamen-schild? In den name-tag des
 highway gehört der Name der Straße, das ist nicht zwangsläufig was auf dem
 Schild steht. Dass überhaupt Straßennamenschilder getaggt würden ist mir
 neu, macht aber vielleicht schon Sinn, vor allem in den Fällen, wo die
 Beschriftung vom Namen abweicht (wobei ich da noch ein note zusätzlich
 anbringen würde um den anderen Mappern mitzuteilen, dass es sich um eine
 geprüfte Abweichung und nicht um einen Tippfehler handelt). Ich würde in
 dem Fall aber auch auf einem Node taggen.

Ok, lass uns Haarespalten :-) Da es bei Verkehrsschildern nur eine
Bedeutung gibt, Verkehrsschilder sind nämlich immer richtig
geschrieben, kann es hier schon von Anfang an keine differenzierung
zwischen old_name, official_name, short_name etc. geben. Damit läuft
dein Argument hier völlig ins leere. Und im übrigen bleibt es dabei:
Erste Quelle für einen Straßennamen ist das Straßenschild und den
trägt man nicht dort ein, wo das Schild steht, sondern als Namen auf
dem Straßenvektor.



 Ich
 erinnere mich noch gut an die Klagen, von Leuten, die versucht haben
 die Bedeutung von als Punkt eingetragenen Schildern auszuwerten. Das
 hat bei Stoppschildern nicht funktioniert, das funktioniert bei
 Ortseingangsschildern nicht ... Deshalb will ich nicht ein in meinen
 Augen falsches Konzept übernehmen.

 [...]

 Die Frage ist, was man durch die Angabe des Schild-tags erreichen will. Mit
 Deinem System taggst Du Deine Interpretation / Kenntnisstand auf den
 gesamten Way für den Fall,

Falsch! Ich trage das ein, was vor Ort ausgeschildert ist. Das schöne
an einem Verkehrsschild ist ja gerade, das es eine feste Definition
hat und einer Uminterpretation durch OSM-Nutzer, das OSM-Wiki oder was
auch immer unproblematisch widersteht.

 dass die OSM-tags nicht eindeutig sind, bzw. um
 anzugeben, aufgrund welcher Schilder diese tags gewählt wurden. Was aber
 trotzdem passieren kann ist, dass Du ein oder mehrere Schilder übersiehst,
 oder dass das Schild nur für eine Richtung gilt oder so.

Und, das ist ein Problem der Erfassung und nicht des Taggingschemas.
Das problem besteht bei maxspeed in genau dieser Form und wird durch
foreward: backward: gelöst.

 Wer dann danach
 kommt und an anderer Stelle der Straße Unstimmigkeiten findet (d.h. z.B.
 ein anderes Schild mit anderem Inhalt als dem getaggten) hat dadurch keine
 Hilfe, (z.B. Dein Schild zu finden), und wenn er ein Schild findet, das

Klar, er geht aufmerksamer die Straße ab und schaut ob es eine
Erklärung für das falsche mapping gibt. Dann korrigiert er oder
setzt einen Bug. so arbeiten wir ...

 Du übersehen hast, (z.B. ein Maxspeed), dann weiss er nicht genau, von wo
 bis wo das neue Schild gilt. Wenn man hingegen alle Schilder taggt und
 danach noch weitere findet, muss man nicht unbedingt eine komplette
 Neubegehung machen um die Informationen zu ergänzen, weil sich das neue
 Schild in die vorhandenen einfügt.

Sorry, aber du musst schon so viel vertrauen haben, dass ich in der
Lage bin, Dinge richtig einzutragen. Mir wegen potentiellem
Fehlmappens von meinem Schema abzuraten ist etwas eigenartig. Wenn
das ein Grund wäre, dann müssten wir die ÖPNV-Schemas erst recht
verbieten ;-)

 Es ist sozusagen näher an der Realität
 und erfordert keine oder kaum Interpretation, um ein Schild als Node
 einzutragen, während das Übertragen eines Straßenschildes auf einen
 linearen way bereits eine Abstraktion / Interpretation ist, die auch mal
 (z.B. für einen Teil des ways) fehl liegen kann.

Naja, wir werden uns nicht einig werden, wie so oft :-)

 Gruß Martin

Gruß Falk

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

Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)

[Falk Zscheile]

Am 3. April 2014 00:38 schrieb Stephan Wolff s.wo...@web.de:

 Am 01.04.2014 10:14, schrieb Falk Zscheile:

 Ich bin dazu übergegangen im Verkehrsbereich (zusätzlich) zu den
 etablierten Tags von OSM auch explitzit das Straßenschild zu erfassen,
 um der möglichen Doppelbedeutung von tags entgegenzuwirken.

 Damit führst du doch eine Doppelbedeutung erst ein.


Nein, entweder ist es redundant oder klarstellend. Aber jedenfalls
keine Förderung von Doppelbedeutungen, denn im Gegensatz zu noexit=yes
hat access:traffic_sign=DE:397 einen festen Bedeutungsinhalt, den du
in der StVO nachschlagen kannst.


 Im Falle eines Verkehrsschildes würde ich also mappen: noexit=yes,
 access:traffic_sign=DE:397

 Wenn man das Schild erfassen will (ich finde das eher unnötig), dann wäre
 mit traffic_sign=DE:397 der Inhalt vollständig beschrieben.

Und was machst du, wenn auf der Straße gleichzeitig noch eine
Geschwindigkeitsbegrenzung und ein Halteverbot stehen. Ich habe da
eine Lösung: access:traffic_sign=DE:value und
parking:traffic_sign=DE:value  und maxspeed:traffic_sign=DE:value

 Die Ausrichtung des Schildes, die für ein Rendering oder die Zuordnung zur
 Straße nötig wäre, fehlt natürlich noch.
 access:traffic_sign statt traffic_sign wird jede Auswertung verhindern
 und passt auch logisch nicht, da das Schild keine Zugangsbeschränkung
 beinhaltet.

Ich bin optimistisch, dass die Vorteile meines Taggingingvorschlags
auch andere zu würdigen wissen und sie vermehrt auftreten werden. Zur
Not kann sich der Auswerter damit begnügen den value auszuwerten und
zu schauen, ob der für seine Zwecke relevant ist.


 noexit=yes beschreibt, dass an diesem Punkt ein Weg blind endet, und ist
 für das Schild nicht nur überflüssig sondern falsch.

Aha?  Übrigens heißt access nicht Zugangsbeschränkung sondern Zugang
und darüber trifft traffic_sign=DE:397 sehr wohl eine Aussage.


 PS.: So handhabe ich es auch bei der
 Radweg-/Fußweg-/-kombinations-/Poblematik.

 Aber hoffentlich nicht mit access-Tags.

s. o.

Gruß Falk

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

Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)

[Falk Zscheile]

Am 3. April 2014 15:20 schrieb Martin Koppenhoefer dieterdre...@gmail.com:
 Am 3. April 2014 00:38 schrieb Stephan Wolff s.wo...@web.de:

 Wenn man das Schild erfassen will (ich finde das eher unnötig), dann wäre
 mit traffic_sign=DE:397 der Inhalt vollständig beschrieben.
 Die Ausrichtung des Schildes, die für ein Rendering oder die Zuordnung zur
 Straße nötig wäre, fehlt natürlich noch.
 access:traffic_sign statt traffic_sign wird jede Auswertung verhindern
 und passt auch logisch nicht, da das Schild keine Zugangsbeschränkung
 beinhaltet.
 noexit=yes beschreibt, dass an diesem Punkt ein Weg blind endet, und ist
 für das Schild nicht nur überflüssig sondern falsch.




 +1, ich würde wenn ich Schilder erfassen würde (was ich derzeit nur für
 Ortseingangsschilder und Geschwindigkeitsbegrenzungen, und Höhen-, Breiten-
 und Gewichtsbegr. mache), das nicht an den Weg taggen, sondern an einen
 node, eben so, wie man es auch antrifft. Dabei setze ich das Schild in
 Fahrtrichtung rechts des Wegs in einem geringen Abstand, so dass die
 Richtung normalerweise klar wird (bisher noch keine Ausnahme angetroffen,
 gibt es aber vielleicht, kann man i.d.R. durch Optimieren der Abstände
 regeln). Wenn man das Schild an den way setzt, dann führt das hinterher zu
 ähnlichen Folgefehlern (durch Splitten des ways, Verschieben der Endnodes
 etc.) wie bei den übrigen tags auch.

\begin{Ironie}So wie wir die Straßennamensschilder auch dort eintragen
wo sie stehen, aber keinesfalls den Namen an der Straße selbst, denn
da steht ja kein Namen auf den Asphalt gemalt?\end{Ironie}

Die Information gehört dorthin, wo sie sinnvoll ist und dass ist am
highway=value! So machen wir das bei oneway, maxspeed, maxweight/hight
etc. Also warum nicht auch bei allen anderen Verkehrsschildern, die
sich auf ein Wegstück und nicht auf einen Punkt (Fußgängerüberweg,
Ampel) beziehen?


 Diese Schilder sehe ich als ggf. hilfreich für andere Mapper an, aber ich
 erwarte davon nicht, dass deren Aussage von Datenkonsumenten wie Router etc
 berücksichtigt wird, von daher setze ich das zusätzlich zu den
 entsprechenden Auswirkungen / Interpretationen, die mit den entspr.
 osm-tags auf den Weg-segmenten getaggt werden.

Ich trage die die Verkehrsschilder auf dem weg ein für den sie gelten
-- fertig. Was andere damit anfangen interessiert mich nicht, freue
mich aber natürlich, wenn es jemand nützlich findet. Und mir
persönlich hilft es klarzustellen, was genau für StVO-Eigenschaften
der Weg hat. aus vielen OSM-Tags geht das ja leider nicht klar hervor,
man denke nur an die Fuß-/Radwegproblematik ...

Gruß Falk

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

Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)

[Falk Zscheile]

Am 3. April 2014 20:30 schrieb Tobias Knerr o...@tobias-knerr.de:
 Am 03.04.2014 20:16, schrieb Falk Zscheile:
 Und was machst du, wenn auf der Straße gleichzeitig noch eine
 Geschwindigkeitsbegrenzung und ein Halteverbot stehen.

 Der Wert von traffic_sign kann ausdrücklich eine Semikolon-getrennte
 Liste von Schildern und Schildergruppen enthalten.

Was genauso wenig ausgewertet wird, wie mein System. Mit Aufzählungen
im value-Bereich tut man sich meines Wissens auch sehr schwer, oder?
Bei mir ist nur klarer (für den Mapper), in welchem Bereich das
Verkehrsschild eine Regelung trifft. Ich nehme eine Kategorisierung
vor, indem ich access, parking, maxspeed dazu nehme. Am deutlichsten
wird es bei maxspeed: maxspeed=30 und
maxspeed:traffic_sign=DE:274-53. Da ist beim ersten lesen klar, um was
es geht.

Gruß Falk

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

Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)

[Falk Zscheile]

Am 3. April 2014 20:39 schrieb Florian Schäfer flor...@schaeferban.de:

 Am 03.04.2014 20:16, schrieb Falk Zscheile:

 Am 3. April 2014 00:38 schrieb Stephan Wolff s.wo...@web.de:

 Am 01.04.2014 10:14, schrieb Falk Zscheile:

 Im Falle eines Verkehrsschildes würde ich also mappen: noexit=yes,
 access:traffic_sign=DE:397

 Wenn man das Schild erfassen will (ich finde das eher unnötig), dann wäre
 mit traffic_sign=DE:397 der Inhalt vollständig beschrieben.

 Und was machst du, wenn auf der Straße gleichzeitig noch eine
 Geschwindigkeitsbegrenzung und ein Halteverbot stehen. Ich habe da
 eine Lösung: access:traffic_sign=DE:value und
 parking:traffic_sign=DE:value  und maxspeed:traffic_sign=DE:value

 @Stefan: Nein, siehe oben. Das Schild beschreibt, wie ausgeschildert ist,
 noexit, wie die Realität aussieht.

 @Falk: Siehe oben, ich würde Verkehrsschilder immer dort mappen, wo sie
 stehen (nicht am Ende der Sackgasse).

Wie gesagt, bei Straßennamen handhaben wir das anders und ich halte
das auch bei anderen (hier Verkehrs-) Schildern für sinnvoll. Ich
erinnere mich noch gut an die Klagen, von Leuten, die versucht haben
die Bedeutung von als Punkt eingetragenen Schildern auszuwerten. Das
hat bei Stoppschildern nicht funktioniert, das funktioniert bei
Ortseingangsschildern nicht ... Deshalb will ich nicht ein in meinen
Augen falsches Konzept übernehmen.

 Zum Schildertagging würde ich sagen, ich tagge
 traffic_sign=DE:value1;DE:value2;DE:value3 oder alternativ 3 Nodes nahe
 beieinander. Denn die Funktion des Schilds leitet sich aus dem Value ab.
 Das würde auch Missverständnissen vorbeugen. Vielleicht gibt es Schilder,
 die mancher in parking, ein anderer in access einordnen würde.

Was genauso wenig ausgewertet wird, wie mein System. Mit Aufzählungen
im value-Bereich tut man sich meines Wissens auch sehr schwer. Kennst
du eine Anwendung, die das mittlerweile auswertet? Ich nehme eine
Kategorisierung vor, indem ich access oder maxspeed dazu nehme. Gerade
bei der zunehmenden Flut von tags an Straßen finde ich das sehr
hilfreich.


 noexit=yes beschreibt, dass an diesem Punkt ein Weg blind endet, und
 ist
 für das Schild nicht nur überflüssig sondern falsch.

 Aha?  Übrigens heißt access nicht Zugangsbeschränkung sondern Zugang
 und darüber trifft traffic_sign=DE:397 sehr wohl eine Aussage.

 @Falk: Es könnte sein, dass Stefan meint, dass das Schild neben dem Weg am
 Anfang der Sackgasse steht und dort kein noexit=yes hinkommt.


Guter Hinweis! Danke :-)

Gruß Falk

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

Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)

[Falk Zscheile]

Am 3. April 2014 21:13 schrieb Florian Schäfer flor...@schaeferban.de:

 Am 03.04.2014 20:52, schrieb Falk Zscheile:

 Wie gesagt, bei Straßennamen handhaben wir das anders und ich halte
 das auch bei anderen (hier Verkehrs-) Schildern für sinnvoll. Ich
 erinnere mich noch gut an die Klagen, von Leuten, die versucht haben
 die Bedeutung von als Punkt eingetragenen Schildern auszuwerten. Das
 hat bei Stoppschildern nicht funktioniert, das funktioniert bei
 Ortseingangsschildern nicht ... Deshalb will ich nicht ein in meinen
 Augen falsches Konzept übernehmen.

 Aber Du möchtest doch wie ich das verstanden habe auch punktförmige Schilder
 mappen, oder?

Nein, das möchte ich nicht.

 Zum Thema mit den Straßennamen, siehe meine andere Mail zum Unterschied
 zwischen Aussage eines Schilds und Schild.

 Zum Schildertagging würde ich sagen, ich tagge
 traffic_sign=DE:value1;DE:value2;DE:value3 oder alternativ 3 Nodes nahe
 beieinander. Denn die Funktion des Schilds leitet sich aus dem Value ab.
 Das würde auch Missverständnissen vorbeugen. Vielleicht gibt es Schilder,
 die mancher in parking, ein anderer in access einordnen würde.

 Was genauso wenig ausgewertet wird, wie mein System.

 Was weder ein Argument für das eine, noch für das andere System ist.

Absolut richtig. Meines gefällt mir nur besser :-)

 Mit Aufzählungen
 im value-Bereich tut man sich meines Wissens auch sehr schwer. Kennst
 du eine Anwendung, die das mittlerweile auswertet?

 Ich habe vor einiger Zeit mal eine gebaut (zwar nicht im Zusammenhang mit
 Straßenschildern, sondern mit POIs) ;-P.
 Und so schwer wäre das auch nicht umzusetzen.


Gut zu wissen. Und schön zu hören, dass es Fortschritte gibt.

 Ich nehme eine
 Kategorisierung vor, indem ich access oder maxspeed dazu nehme. Gerade
 bei der zunehmenden Flut von tags an Straßen finde ich das sehr
 hilfreich.

 Die Kategorisierung ist aber durch den Value für traffic_sign schon
 impliziert. Du hättest dann Probleme mit so etwas wie
 maxspeed:traffic_sign=DE:250
 Das würde dann in etwa bedeuten: Die Höchstgeschwindigkeit ist, dass hier
 kein Fahrzeug durchfahren darf.

Ich gebe zu, dass Problem hätte man nicht, wenn man alles in eine
Aufzählung von traffic_sign packt. aber für sotewas gibt es ja keep it
right und ähnliches (falls sich meine Idee jemals durchsetzen sollte).
Mit meinem System des kategorisierenden Taggens von
Verkehrsschildern hat man aber zumindest die Chance Fehler bei der
Eintragung zu erkennen. Bei einer Aufzählung aller an der Straße
vorhandenen Verkehrsschilder sind die Möglichkeiten, um fehler zu
erkennen, ungleich geringer, weil der key hier nicht die Richtung für
den value angibt.

Dies führt zu einem generellen Problem bei so abstrakten Angaben wie
die StVO-Nummer von Verkehrsschildern. Bei amenity=secondary wird
jeder stutzig bei traffic_sign=DE:4711 nicht unbedingt.


 Übrigens, nur um es klarzustellen: Ich bin eigentlich kein Fan vom Tagging
 von Verkehrsschildern.

Das ist mir nicht entgangen :-)

 Wenn das aber gemacht wird, dann sollte die Art und
 Weise möglichst einheitlich sein und ein gewisser Konsens dazu herrschen,
 sonst wird es niemals ausgewertet werden.

Ich nehme die hier vorgebrachten Einwände mit Interesse zur Kenntnis,
auch wenn sie mich im Augenblick nicht überzeugen. Man muss ja auch
mal was ausprobieren und schauen, ob man damit mehr bestehende
OSM-Probleme löst als neue schafft :-)

Viele Grüße
Falk

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

Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)

[Falk Zscheile]

Hallo Florian,
vielen Dank für die Zusammenfassung. So etwas gibt es hier viel zu selten.

Am 31. März 2014 20:56 schrieb Florian Schäfer flor...@schaeferban.de:
 Am 30.03.2014 13:57, schrieb Florian Schäfer:

 A: Strikte Sackgassen auf öffentlichen Straßen (Zeichen 357)
 B: Durchlässige Sackgassen auf öffentlichen Straßen (Zeichen 357-50 oder
 357-51)
 C: Privatwege auf Privatgrundstücken (z.B. Hausauffahrten), die an dem
 einen Ende unverbunden sind
 D: Wege, die an Hauseingängen enden (Endnode ist Teil eines building-ways
 und hat entrance=main/yes)
 E: Wege, die Zufahrten zu Garagen sind (Endnode ist Teil eines
 building=garage-ways)


Bei dieser Zusammenfassung wird wieder einmal das Grundproblem von
OSM deutlich: Ein Tag wird mit viel zu vielen verschiedenen
Informationen belegt (siehe A-E), obwohl man die auch in
unterschiedlichen Tags erfassen könnte. In der Belegung eines Tags mit
zu vielen unterschiedlichen Informationen liegt meines Erachtens auch
ein wichtiger Grund für die vielen ergebnislosen Diskussionen in
Threads. Die wenigsten machen sich klar, dass es sich faktisch um
Doppelbedeutungen eines Tags handelt. Um diese herauszuarbeiten ist
ein Thread hilfreich, allerdings nur, wenn man das Ergebnis am Ende
auch zusammenfasst. Zusammenfassungen wie du sie gerade gemacht hast
sind daher sehr hilfreich, auch für künftige Diskussionen.

Gruß Falk

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

Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)

[Falk Zscheile]

Am 1. April 2014 09:51 schrieb NopMap ekkeh...@gmx.de:
 Hi!

 Deiner Darstellung muß ich einem wesntlichen Punkt deutlich widersprechen.


 Florian Schäfer-2 wrote
 Bei C habe ich herausgehört, dass dort das noexit=yes-Tag akzeptiert
 ist, aber nicht unbedingt von allen aktiv gesetzt wird.
 D und E waren noch nicht so ganz klar, insbesondere hat sich da gezeigt,
 dass das entrance-Tag an manchen Stellen präzisiert oder um Hilfstags
 ergänzt werden könnte

 Allgemein kann man glaube ich sagen, dass dieses Tag (ähnlich dem
 fixme=continue oder note=*) ein Tag nur zur Kommunikation unter den
 Mappern und zur Signalisierung von false-positives an die QA-Tools ist.

 noexit ist *kein internes Tag für Mapper* sondern stellt eine wertvolle
 Information dar, deren Anzeige auf Karten im Offroad-Bereich absolut
 nützlich ist.

Ich bin dazu übergegangen im Verkehrsbereich (zusätzlich) zu den
etablierten Tags von OSM auch explitzit das Straßenschild zu erfassen,
um der möglichen Doppelbedeutung von tags entgegenzuwirken.

Im Falle eines Verkehrsschildes würde ich also mappen: noexit=yes,
access:traffic_sign=DE:397 Damit ist jedem klar, dass es sich nicht um
eine interne Mappinginformation handelt, sondern um eine echte
Information. Leider funktioniert das nur wenn es explizit
ausgeschildert ist. Außerdem besteht das Problem, dass es mehrere
Accessinformationen auf Straßenschildern geben kann, die sich so nicht
abbilden lassen, weil es dann access:traffic_sign:#1 und
access:traffic_sign:# geben müsste. Access habe ich davor gesetzt,
weil es auch andere Verkehrsinformationen für die straße geben kann,
z.B. maxsspeed:traffic_sign=value

Gruß Falk

PS.: So handhabe ich es auch bei der
Radweg-/Fußweg-/-kombinations-/Poblematik. Mit einem ausdrücklich am
Weg gemappten Verkehrsschildinformation wird alles etwas klarer.

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

Re: [Talk-de] FOSSGIS-Konferenz: Lightning Talks

[Falk Zscheile]

Moin Frederik,

falls noch Platz ist und niemand sonst möchte, dann könnte ich sicher
auch etwas sagen :-)

Gruß
Falk

Am 19.03.14 schrieb Frederik Ramm frede...@remote.org:
 Hi,

falls jemand auf der FOSSGIS ist und das hier liest - bitte bei mir
 melden, wenn ihr einen Lightning-Talk halten wollt. Der
 OSM-Lighting-Talk-Slot ist am Donnerstag 13:30.

 Bye
 Frederik

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

 ___
 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] Hochsitze / Bitte um Entfernung von Daten

[Falk Zscheile]

Am 14. März 2014 08:56 schrieb Andreas Schmidt schmidt-postf...@freenet.de:

 Die Herren Hobbyschlachter müssen sich halt damit abfinden, dass ihre
 Freizeitbeschäftigung bei einem Teil der Bevölkerung nicht besonders
 hoch angesehen ist.
 Das widerrechtliche Beschädigen von Leitern, das ich ablehne, kann nicht
 mit Geheimhaltung verhindert werden.

 Ebenso wie Spaziergänger darauf achten müssen, nicht gegen Stahlseile
 ( http://abload.de/img/absperrung1ljsqy.jpg )
 zu laufen, die von einem Jäger quer über den Weg gespannt wurden,
 sollten Letztgenannte im eigenen Interesse die Stabilität ihrer
 Schießstützpunkte vor dem Erklettern prüfen. Das hat nichts mit OSM zu
 tun, das ist so.



Also bevor das jetzt hier zum Jägerbashing verkommt sollten wir
aufhören. Die Sachargumente wurden vorgetragen und haben breite
Zustimmung gefunden. In den letzten Beiträgen treten aber vermehrt
(also nicht in allen) Argumentationslinien wie (Alle) Jäger sind
schlecht, deshalb erst recht nicht auf. Das haben wir nicht nötig, um
unseren hier gefundenen Standpunkt zu vertreten.

Falk

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

Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten

[Falk Zscheile]

Am 13. März 2014 12:06 schrieb Frederik Ramm frede...@remote.org:
 Hallo,

die DWG war vor einiger Zeit mal in einen Edit-War involviert, in dem
 ein Nutzer Waldwege und ähnliches gelöscht hat, was er für schädlich
 hielt (nach dem Motto: da ist gar kein richtiger Weg, nur ein
 Trampelpfad, und das Wild wird durch die Wanderer verjagt usw.usw.).

 Die DWG hat den Nutzer damals gebeten, das eigenmäctige Löschen von
 solchen Daten zu unterlassen und einige Löschungen revertiert.

 Nun erhalte ich (als der User, der den Revert gemacht hat) eine
 Nachricht von dem, der damals die Löschungen vorgenommen hat:

 ==

 Sehr geehrter Nutzer,

 Sie haben bei OSM jagdliche Hochsitze im Bereich des Velber Holzes
 (südlich Harenberg) kartiert. Ich möchte Sie hiermit bitten, diese
 Punkte wieder zu entfernen, da es dadurch zu erheblichen Problemen
 kommt. Es gab bereits erfolgte Straftaten, die durch eine anonyme
 Organisation dort verübt wurde. Somit danke ich Ihnen für das
 kurzfristige entfernen. Bei Rückfragen danke ich Ihnen für eine
 Kontaktaufnahme.

 MfG, Fidibus21

 ==

 Ich weiss nicht ganz, wie ich darauf reagieren soll. Einerseits nervt es
 mich, dass er nicht locker lässt. Diese Hochsitze sind nunmal da, also
 können sie auch gemappt werden. Andererseits ist es ja eigentlich gerade
 erwünscht, wenn man mit Daten unzufrieden ist, dass man dann mit den
 anderen Mappern darüber spricht, statt alles gleich zu löschen.

 Ich finde das aber mit den Straftaten ein bisschen komisch, das
 klingt, als wollte man den Mapper unter Druck setzen und ihn zum
 Mittäter machen, wenn er nicht freiwillig seine Hochsitze löscht...


Bei Hochsitzen handelt es sich um jagdliche Einrichtungen. Deren
rechtlicher Status ist in den Landesjagdgesetzen geregelt. Im
niedersächsischen LJagdG heißt es in § 2 Abs. 2: Die
jagdausübungsberechtigte Person kann anderen das Betreten der
jagdwirtschaftlichen Einrichtungen verbieten und sie zum Verlassen
dieser Einrichtungen auffordern.

In § 41 Abs. 1 nds LJagdG heißt es: (1) Ordnungswidrig handelt, wer
1. entgegen § 2 Abs. 2 einem Verbot zuwiderhandelnd
jagdwirtschaftliche Einrichtungen betritt oder diese entgegen einer
Aufforderung nicht verlässt; [...]

Es handelt sich also um eine Ordnungswidrigkeit, wenn an dem Hochsitz
ein Schild Betreten verboten steht und man es zum Mappen trotzdem
betritt. Eine Straftat ist es nicht. Die Regeln sind von Bundesland zu
Bundesland etwas verschieden. Manchmal ist das Betreten generell
verboten, manchmal nur wenn ein Schild angebracht ist. Ein Verbot
solche Hochsitze zu erfassen und in einer Karte darzustellen ergibt
sich meines Erachtens nicht, so lange man sie nicht betritt.

Worauf die betreffende Person aber vermutlich hinaus will: Radikale
Tierschützer nutzen die Daten unter Umständen, um die jagdlichen
Einrichtungen zu beschädigen. Die Beschädigung ist eine Straftat (§
303 StGB). Für einem Mapper aber durch Erfassung der Daten eine
Beihilfe (§ 27 StGB) zur Sachbeschädigung zu konstruieren, halte ich
für sehr weit hergeholt.

Generell ist das bei Jägern ein heikles Thema. Da sie für ihr
Jagsausübungsrecht Geld bezahlen setzt sich leicht ein Anspruchsdenken
der Wald gehört mir durch. Das ist aber nicht bei allen Jägern so.
Je intensiver die Freizeitnutzung eines Waldes ist und je höher die
Jagdpacht, desto dünnhäutiger reagieren die meisten Jäger.

Gruß Falk

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

Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten

[Falk Zscheile]

Am 13. März 2014 13:20 schrieb Richard Z. ricoz@gmail.com:
 On Thu, Mar 13, 2014 at 12:51:22PM +0100, Falk Zscheile wrote:

 Worauf die betreffende Person aber vermutlich hinaus will: Radikale
 Tierschützer nutzen die Daten unter Umständen, um die jagdlichen
 Einrichtungen zu beschädigen. Die Beschädigung ist eine Straftat (§
 303 StGB). Für einem Mapper aber durch Erfassung der Daten eine
 Beihilfe (§ 27 StGB) zur Sachbeschädigung zu konstruieren, halte ich
 für sehr weit hergeholt.

 wäre mir nicht so sicher mit den Tierschützern - mindestens genauso oft
 kommt es wohl vor, daß da Konkurenz am Werk war.

Die meisten Wilderer haben einen Jagdschein, aber dass sich Jäger die
Hochsitze gegenseitig zersägen, davon habe ich noch nichts gehört.

 Nun ist so ein Hochsitz in der Regel eine Art lnadmark, wenn man die
 löscht oder zerstört kann die Orientierung erschwert sein.

Sicher, aber wenns dem lieben Frieden dient  kann man zumindest einmal
darüber nachdenken, ob man dem Jäger einen gefallen tun möchte. Man
muss es vielleicht auch nicht gleich in der Datenbank löschen, sondern
kann die Daten mit einem Tag versehen, dass normalerweise nicht
ausgewertet wird. Wenn es kein eigenjagdbezirk ist besteht zumindest
die Hoffnung, dass der Jagdausübungsberechtigte  irgendwann wechselt.
Jedenfalls haben wir das Recht Hochsitze zu mappen. Wie man auf die
wünsche der Jagdausübungsberechtigten reagiert muss vor Ort
entscheiden werden.

OT: Wer das jagdliche Thema vertiefen will, dem empfehle ich die
filmische Satire: Halali oder der Schuss ins Brötchen.

Gruß Falk

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

Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten

[Falk Zscheile]

Ich denke alle hier im Thread sind sich einig, dass Jäger keinen
Anspruch darauf haben, dass wir ihre Jagdeinrichtungen aus der
Datenbank nehmen. Aber bitte -- blicken wir doch ein wenig über den
Tellerrand. Wem ist geholfen wenn wir auf dieser Meinung beharren und
einen endlosen Editwar bekommen und Frederik dann jede Woche Hochsitze
wiederherstellen muss, damit sie dann wieder gelöscht werden können
...

Vielleicht kann eine teporäre Herausnahme (z.B. durch Änderung des
Keys) den Jäger davon überzeugen, dass seine Hochsitze auch ohne OSM
beschädigt werden und die Leute auch so in den Wald gehen. Immerhin
hat der Jäger angefragt, wenn auch nicht sehr höflich, und nicht
gleich Hand an die Daten gelegt.

Aber man kann das Löschen-Wiederherstell-Spiel natürlich auch spielen,
bis eine Seite die Lust verliert. Wir haben das Recht dazu!

Falk

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

Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten

[Falk Zscheile]

Am 13. März 2014 17:34 schrieb malenki o...@malenki.ch:
 On  13.03.2014 15:42, Falk Zscheile wrote:

 Vielleicht kann eine teporäre Herausnahme (z.B. durch Änderung des
 Keys) den Jäger davon überzeugen, dass seine Hochsitze auch ohne OSM
 beschädigt werden und die Leute auch so in den Wald gehen. Immerhin
 hat der Jäger angefragt, wenn auch nicht sehr höflich, und nicht
 gleich Hand an die Daten gelegt.

 Ehe man an so etwas denkt, würde ich um Raum-Zeit-Koordinaten
 zerstörter Hochsitze bitten und nachschauen, ob diese überhaupt oder zu
 welchem Anteil zum Zeitpunkt der Zerstörung in OSM eingetragen waren.

Das würde dich und mich überzeugen, aber niemanden, der schon fest
daran *glaubt* OSM sei die Wurzel seines Übels. Da helfen rationale
Argumente leider oft nicht weiter. Da müssen esoterischere Lösungen
gefunden werden ... oder eben auch nicht. Die Mehrheit geht hier ja
sehr eindeutig in Richtung drin lassen und gut. Seis drum, ich
wollte nur ein paar andere Lösungsstrategien aufzuzeigen.

Falk

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

Re: [Talk-de] Reihenhäuser / 3D-Tagging // Re: 1000 Hausnummern

[Falk Zscheile]

Am 9. März 2014 10:45 schrieb Peter Wendorff wendo...@uni-paderborn.de:
 Hallo Ralf,
 Selbst tagging NUR für den Renderer wäre im Grunde doch okay.
 Problematisch wird es, wenn NUR für den Renderer, aber GEGEN korrekte
 Daten oder GEGEN andere Anwendungen getagged wird.

 Das, wo taggen für (und natürlich insbesondere NUR für) den Renderer,
 kritisiert wird, betrifft vor allem  falsche Tags, um richtige
 Darstellungen zu erzielen, also:
[...]

Sehr schön erklärt. Das hätte ich auch so schreiben sollen. Leider
hatte meine polemische Seite die Regie bei der Antwort auf Ralfs
Posting übernommen.

Gruß Falk

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

Re: [Talk-de] Reihenhäuser / 3D-Tagging // Re: 1000 Hausnummern

[Falk Zscheile]

Am 9. März 2014 00:18 schrieb Ralf GESELLENSETTER r...@gmx.de:

 Und schließlich: 3D-Tagging ist Tagging NUR für den Renderer, oder?


Habe ich hier Ironie übersehen? Bei dir mag die Erde eine Scheibe
sein. Bei mir in der Gegend stehen auf der Scheibe immerhin noch
dreidimensionale Gebäude. Wieso sollen Tags, die versuchen die
dreidimensionale Wirklichkeit abzubilden, tagging für den Renderer
sein?

Gruß Falk

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

[Talk-de] Visualisierung von (notwendigen) Postdienstleistungen

[Falk Zscheile]

Hallo Liste,

wir ärgern uns in meinem Wohnort gerade über die Deutsche Post AG. Sie
hat (nach den bisher bekannt gewordenen Informationen) sehr spontan
ihre Filiale bei einem privaten Betreiber abgebaut, so das der Ort nun
ohne Filiale dasteht. Gibt es die OSM-Karte noch, mit der
Postniederlassungen und Briefkästen bzw. deren Einzugsradius
visualisiert werden? Nach der Post-Universaldienstleistungsverordnung
werden hierfür sehr präzise Vorgaben gemacht, die sich anhand einer
Karte gut überprüfen lassen. Falls es die Karte nicht mehr gibt --
kennt jemand Alternativen?

Danke  Gruß
Falk

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

Re: [Talk-de] Visualisierung von (notwendigen) Postdienstleistungen

[Falk Zscheile]

Am 7. März 2014 13:02 schrieb Benjamin Lebsanft benja...@lebsanft.org:
 Hallo Falk,

 so wie es aussieht, war der Betreiber der Seite des Postboxguesstimators
 ne Weile nicht aktiv:

 http://toolserver.org/~mazder/pboxguesstimator/?lat=48.72521lon=9.32674zoom=13layers=BTT

 Schade eigentlich. Alternativen kenne ich keine, die Postkarte ist ja
 auch schon ne Weile offline:

 http://post.openstreetmap.de/


Hallo Benjamin,

vielen Dank für die Info. Der Name Postboxguesstimator war mir
entfallen -- obwohl er eigentlich ziemlich originell ist. Schade, dass
es nichts fertiges mehr in der Richtung gibt.

Gruß Falk

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

Re: [Talk-de] Visualisierung von (notwendigen) Postdienstleistungen

[Falk Zscheile]

Am 7. März 2014

[beschrieben Johannes Kröger und Stephan (User SB79) einen Weg etwas
Postboxguesstimatorartiges zu erzeugen/wiederzubeleben.]

Oha, ich glaube da wage ich mich als NichtGISler und Nichtinformatiker
nicht allein heran. Ist vielleicht jemand auf der FOSSGIS und könnte
mir einer ruhigen Minute die Benutzung der Werkzeuge zeigen?

Danke  Gruß
Falk

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

Re: [Talk-de] Natural Wood = Forest Landuse

[Falk Zscheile]

Ich finde auch, dass die Unterscheidung von natural=wood und
landuse=forest wie wir sie jetzt haben ziemlicher Unfug ist. Das war
meiner Meinung nach auch nur eine Notlösung, weil man feststellte,
dass man schon beides in der Datenbank hat. um nicht in das richtig
oder falsch Schema zu verfallen hat man den Kompromiss ersonnen, das
eine sei ein Naturwald, das andere ein forstwirtschaftlich genutzter
Wald. Für das Grau dazwischen bleibt kein Raum. Auch lässt sich mit
diesem Tagging das Problem nicht wirklich lösen, das der eine nur Wald
sieht, ein anderer aber deutlich mehr. Das ist bei natural=wetland
geschickter gelöst: Da sieht einer nur sehr feuchte Erde und trägt
natural=wetland ein. Ein anderer erkennt aber, dass in dieser
feuchten Erde Bäume stehen und ergänzt wetland=swamp, ein anderer
sieht, das in der feuchten Erde Schilf steht und ergänzt
wetland=reedbed. Logisch gesehen ist für Schilf und sumpfiger Wald die
übergeodnete Kategorie waserdurchdrungenes Land. Es ermöglicht also
sowohl Laien als auch Profis etwas zum Datenbestand beizusteuern.
Bei natural=wood und landuse=forest habe wir diese Möglichkeit nicht,
da muss man sich gleich, wenn man einen grünen Flecken Erde auf dem
Luftbild sieht entscheiden ob das ein Naturwald ist oder ein Forst.
Eigentlich ein Ding der Unmöglichkeit außer man Kategoriesiert ganz
grob: Dschungel immer Naturwald, alles in Mitteleuropa Nutzwald
(Forst) -- dann kann mans aber auch gleich sein lassen, denn so eine
grobe Unterteilung nutzt niemandem wirklich. Und auf normalen
Landkarten (Jehova) sind sowieso alle Wälder nur grün ... Dabei gibt
es da so viele unterscheidungsmöglichkeiten: Nach Nutzung- oder
Bewirtschaftungsart (Hochwald, Mittelwald, Niederwald), nach
Vegetationsform (Laubwald, Mischwald, Nadelwald), Vegatationszonen
(Gebirge, Bergland, Hügelland, Tiefland), Bewuchshöhe/Altersklassen
(Dickung, Stangenholz, Baumholz, Altholz) ...

Kurzum ich sehe einen langfristigen Reformbedarf. Die Reform wird aber
wohl nicht ohne Mithilfe der OSM-Mapnikkarte zu haben sein. Ich höre
schon die Stimmen auf allen Kanälen: Mein Wald wird nicht mehr
gerendert, weil ihn irgendein nichtsnutziger, unwissender, bösartiger
und gemeiner User von landuse=forest zu natural=forest geändert hat.
Der hat doch gar keine Ahnung, mein tagging ist natürlich richtig, es
wird ja in der Mapnikkarte dargestellt [...] ansonsten kann man
natürlich auch versuchen das Schema nach unten aufzubohren, ohne
gleich natural=wood und landuse=forest zu verdammen. Vermutlich die
erfolgversprechendere Variante, da es der Mehrheit ja reicht, das ein
Wald grün ist :-)

Gruß Falk

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

Re: [Talk-de] Eintrag von Gewann-Namen

[Falk Zscheile]

Am 27. Februar 2014 23:16 schrieb Bernhard Weiskopf bweisk...@gmx.de:
 Hallo an alle,

 wie trägt man in OSM die Namen von Gewannen ein, dass sie in Mapnik
 angezeigt werden?


Wenn das Gewann nicht noch in einzelne Felder unterteilt ist, so würde
ich es einfach an das entsprechende Feld als name-Tag setzen.
Andernfalls hilft vielleicht auch eine site-Relation (?). Schließlich
gibt es noch place=locality name=value. Letzteres wird auch für Fälle
wie deinen gebraucht.

Gruß
Falk

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

Re: [Talk-de] Ziele [war: Eintrag von Gewann-Namen]

[Falk Zscheile]

Am 28. Februar 2014 11:59 schrieb Markus liste12a4...@gmx.de:

 OSM sammelt Geo-Daten welche die Wirklichkeit da draußen beschreiben.


 OSM ist eine *Weltkarte*.
 /Dafür/ werden Geo-Daten erhoben und in einer DB abgelegt.

Nein, OSM ist eine Datenbank, die geographische Informationen sammelt.

 *Karte und Daten* ist eine systemische Einheit.
Nein, Daten und Karte sind systematisch getrennt. Man kann aus den
Daten alles mögliche machen. Von Statistik bis Routing, ist alles
möglich. Karten sind nur ein kleiner, wenn auch der eingänglichste,
Anwendungsbereich.

 Das erfordert eine gezielte Zusammenarbeit zwischen denen die Daten sammeln
 und denen die sie anzeigen, bzw denen die die Karte nutzen :-)

nein, die Zusammenarbeit muss zwischen Datensammlern und Datennutzern
erfolgen. eine der großen Herausforderungen von OSM ist es, ein
Datenschema zu entwickeln, das mehr taugt, als eine Karte zu malen.
Das Problem ist: man kennt die konkrete Anwendung der Daten nicht.
Wenn man sich immer nur auf Karten fixiert (welche eigentlich --
Papierkarten, Onlinekarten, Routingfähig oder nicht) verbaut man sich
vielleicht andere Anwendungsmöglichkeiten. Man kann sollte das
Datenschema nicht unter dem Gesichtspunkt Kann man damit eine schöne
Karte malen? sehen sondern Bilde ich damit die Wirklichkeit
eindeutig und verständlich ab?

 eine mögliche Benutzung dieser Daten ist das Rendering mit Mapnik


 Mapnik ist /die Karte/ :-)

Nein, Mapnik ist ein Renderer und und die Karte auf openstreetmap.org
das Ergebnis einer Renderanweisung. Ich mag das Renderergebnis, wie es
auf opentopomap.de erscheint viel mehr :-) Die Karte auf
openstreetmap.org ist eine gute (!) Standartanwendung, aber nicht das
maß der Dinge.

 Selbstverständlich /kann/ man aus den Daten auch noch viele und tolle
 Spezialanwendungen machen: Spezialkarten, Routing, Statistik, ...

genau

 Und selbstverständlich brauchen Anwendungen sinnvolle Datenschemen als
 Grundlage. Deshalb sind Daten(-Struktur) immer als Einheit mit der geplanten
 Anwendung zu betrachten und zu verstehen - und zu entwickeln und zu
 verbessern.

Du meinst für jede Anwendung ein eigenes Datenschema? Übertrieben
würde das heißen, man muss Wege nicht verbinden, wenn man nur eine
Karte braucht. Die Leute, die Routing betreiben sollen möchten dann
bitte ein eigenes Schema haben, bei dem sie ihre Straßen verbinden.
Das kann es nicht sein. Ziel sollte schon die universelle Nutzbarkeit
der Daten sein ...

Gruß Falk


 Stil


 Ein einheitliches Erscheinungsbild hilft OSM als Marke zu etablieren.
 Dabei sind Ziele zu erfüllen wie schnelles Orientieren und Erkennen,
 schnelles präzises Finden, sinnvolle Verknüpfung von Information, etc.
 Iterativ und gemeinsam ist das Optimum zu finden.

 Dabei kann man gute Fremd-Beispiele nutzen und die besten Ideen daraus
 übernehmen.
 Es macht aber m.E. wenig Sinn, diese nur deshalb nachzuahmen, weil man sie
 gewohnt ist.

 Bei den iterativen Suchprozessen macht es auch Sinn, immer mal wieder etwas
 ganz anderes auszuprobieren - um die gefundenen Essenzen dann synergetisch
 in das Produkt zu integrieren.
 Es macht aber m.E. wenig Sinn, viele Skins zu haben.

 - - - -

 Zur Frage nach dem Rendering von Gewann-Namen:
 Namen von Gegenden helfen bei der Orientierung.
 Solche Namen auf der Karte zu haben ist ein sinnvolles Anliegen.

 Solange wir dafür kein brauchbares Konzept haben, werden Benutzer immer
 wieder versuchen, die Namen irgendwie so in die DB zu schreiben /damit/
 sie gerendert werden.

 Mit herzlichem Gruss,
 Markus

 ___
 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