Re: [Talk-de] Meine letzten Edits

[Peter Wendorff]

Hallo Michael,
overpass-Turbo nimmt (nach meinem letzten Stand) den sichtbaren 
Kartenausschnitt automatisch als Bounding-Box an.
Wenn du da also nur einen Ausschnitt anzeigst, in dem es keine 
entsprechenden Änderungen gibt, kommt von overpass-turbo nichts zurück.


Soweit rauszoomen, bis du die ganze Welt oder aber zumindest den 
Ausschnitt siehst, in dem du bearbeitet haben kannst, sollte helfen.


Gruß
Peter

Am 03.10.2016 um 17:31 schrieb mipo...@web.de:

Hallo,

ich bekomme von https://overpass-turbo.eu/ Rückmeldungen "Diese Karte ist leer (received empty 
dataset)", nachdem ich eine der beiden Abfragen (s.u.)dorthin kopiere und 
"Ausführen" klicke.

Wo ist mein Fehler?

Danke.
Michael

Abfrage gmbo / Gisbert:

[timeout:80];
// Datum ggf. anpassen
node
[tourism=caravan_site](newer:"2015-05-01T07:00:00Z")(user:gmbo)
  ({{bbox}})->.newnodes;
// Ausgabe
.newnodes out meta;


Abfrage Heinz-Jürgen - Tag weglassen:

[timeout:100];
// Datum ggf. anpassen
node
   (newer:"2016-08-01T07:00:00Z")(user:Heinz)
   ({{bbox}})->.newnodes;
// Ausgabe
.newnodes out meta;


___
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: [OSM-talk] Spoken street names

[Peter Wendorff]

Am 22.08.2016 um 19:21 schrieb Štefan Baebler:

Having TTS to hear the street names is very nice, but hearing them
correctly pronounced would be even better.

There was an attempt at it:
https://wiki.openstreetmap.org/wiki/Proposed_features/Phonetics

But AFAIK there was no outcome from that proposal.


Did anyone really investigate how bad using common phonetic rules PER 
LANGUAGE on osm names?
For many names that should work I think, at least when the right 
language is detected correctly.
That, on the other hand, could be hinted by using the corresponding 
name:[lang] tags (name:de, name:en, ...), probably even when the main 
language might be redundant.


regards
Peter

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

Re: [Talk-de] Help needed for mapping missing navigation data in Germany

[Peter Wendorff]

Hallo Nikhil,

ich habe mir eure osm-navigation-map mal angeguckt, und mir sind so ein 
paar Dinge aufgefallen:


- Reviewed by [OSM username]: Warum dann nicht mit login bei OSM 
verknüpft und so gesichert. Ich will niemandem was unterstellen, aber 
einen anderen Usernamen anzugeben ist nach meinem Geschmack zu einfach. 
(offensichtlich mit [1] schon bekannt und geplant)


- Warum muss der Benutzername mehrfach angegeben werden? (siehe auch 
erster Punkt).


- "prohibitory--no-entry--de" [2] ist offensichtlich noch nicht 
lokalisiert, allerdings finde ich das auch nicht im Code auf Github, was 
das sein soll. Wenn ich das richtig vermute, ist das in diesem Fall ein 
Fehler, bei dem mir die Rückmeldemöglichkeit fehlt, denn offensichtlich 
ist ein Bahnübergang (Andreaskreuz neben der Schranke gut zu erkennen) 
falsch erkannt worden, denn der Bahnübergang existiert in OSM bereits, 
der wäre also ein Duplikat.


- Was genau validiert man auf dieser Karte? In [3] gibt es einen 
"information--parking--de"-Punkt (offensichtlich auch noch nicht 
sinnvoll lokalisiert). Das Bild zeigt den Parkplatz südlich des 
Le-Mans-Walls, der sauber und ordentlich eingetragen ist. Ist das jetzt 
"valid" (Bilderkennung korrekt, Daten korrekt in OSM)), "Redundant" 
(Bilderkennung korrekt, aber schon seit langem in OSM) oder "Invalid" 
(hier fehlt sicher kein Parkplatz)?


- Warum gibt es den Button "Delete"? Was lösche ich damit? Oder soll das 
grau bedeuten, dass das gar nicht möglich ist grade?



Alles in allem sieht das schon recht gut aus, damit arbeiten würde ich 
aber erst, wenn mindestens das OSM-Login eingebaut ist.


Viele Grüße
Peter


[1] https://github.com/mapbox/osm-navigation-map/issues/45
[2] http://mapbox.github.io/osm-navigation-map/#18.76/51.71489/8.75186
[3] http://mapbox.github.io/osm-navigation-map/#19.01/51.71507/8.75039


Am 19.08.2016 um 11:08 schrieb Nikhil Prabhakar:

Hallo,

wir möchten euch für alle Gedanken und Vorschläge danken die uns erreicht
haben. Um die Bedenken und das Feedback der Community zu adressieren haben
wir einen detaillierten und überarbeiteten Plan für unsere Arbeitsabläufe
erstellt, wie wir auch schon in unserem Tagebuch-Post [1] angegeben haben.
Wir planen diesem während all unserer Arbeiten zu folgen.

Wir freuen uns über jedes Feedback und alle Vorschläge zu diesem
Arbeitsplan. Wir würden uns über euren Support und eure Mitarbeit bei
diesem Vorhaben sehr freuen und hoffen, dass wir das Ziel dieses
Mappingprojekts klar machen konnten: OpenStreetMap zur besten Karte zu
machen :)

[1] Tagebuch-Post -
https://www.openstreetmap.org/user/nammala/diary/39255#comment35719

PS: Wir haben den Bug-Report auf der OSM navigation map korrigiert. Ihr
könnt die Karte über http://mapbox.github.io/osm-navigation-map erreichen


Beste Grüße,
 Nikhil Prabhakar U
___
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: [OSM-talk] Freeing JavaScript on the OSM Homepage?

[Peter Wendorff]

Hi unaware,

there is an open issue [1] about that already since some months,
but you have to be calm and wait for it to happen - or help on your own 
by submitting a pull request for a (partial) solution.


regards
Peter

[1] https://github.com/openstreetmap/openstreetmap-website/issues/879


Am 20.01.2016 um 19:37 schrieb unaw...@sigaint.org:

Dear community,

I noticed some issues on the JavaScript of the OSM Homepage. Explicitly, I
am refering to
http://www.openstreetmap.org/assets/application-493a26542d1a58f893bae08f4aa9910495c3a14cfc60db9be9b878202547a7c1.js
and
http://www.openstreetmap.org/assets/index-31bba8593ce3fd4ccd6c585180f31149973b722e3839d9a1e294fdc406c86b6e.js
.

1. This "code" is unreadable and therefore can not be considered as free
software, even if it says being licensed under a free license.
2. Some of the licensing just says "MIT license" without giving a link to
the full license. This term is according to
https://www.gnu.org/licenses/license-list.en.html unclear.

I am explicitly missing links to the license at some parts of the "code"
and a link to a source code that is readable and trivial and does the same
as this "code", that can be edited and shared.

I assume most of you heared about the free software foundation and it's
goals and (mostly) identify with them? One of their goals is to free
JavaScript, see:
https://www.gnu.org/philosophy/javascript-trap.en.html
https://www.gnu.org/software/librejs/free-your-javascript.html

Question: has this been discussed already? What do you think of the goal
to free JavaScript for OSM? And who is able to do that? Personally I would
love to help if I were a programmer being able to do that...

Best regards

unaware









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




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

Re: [Talk-de] Neue Farben im osm.org Kartenstil?

[Peter Wendorff]

Hallo Manuel,

umgetagged werden muss natürlich nicht,
Tags sollten darstellen, was vorhanden ist, und sich gerade nicht an der 
Darstellung in einer Karte orientieren.


Gruß
Peter

Am 01.11.2015 um 11:22 schrieb Manuel Reimer:

Hallo,

ich hatte ja erste Bedenken ich habe beim Eintragen einen Fehler
gemacht, aber das scheint sich wohl über die ganze Karte durchzuziehen.

Aktuell werden die Straßen etwas "farbloser". Zumindest in meiner Region
gibt es so Langsam nurnoch weiße Straßen und die farbige Unterscheidung
geht verloren.

Woran liegt's? Mal wieder Anpassungen am Stil? Muss jetzt irgendwie
umgetaggt werden oder ist das mit den farblosen Straßen so gewollt?

Gruß

Manuel


___
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] Public Transport - Haltestelle ohne Linie / Austragen oder belassen

[Peter Wendorff]

Hallo Nzara,

mit dem Argument ist aber auch die Haltestelle ohne ausgehängtem oder 
irgendwo bekanntem Fahrplan nicht zwingend keine Haltestelle mehr - weil 
z.B. ein Busunternehmen seine Fahrgäste individuell informiert, dass und 
wann ihr Bus an dieser Haltestelle abfährt.


Warum ist also der Fahrplan, den man kennen muss, Indiz für eine als 
solche gültige (public-transport-)Haltestelle, das Haltestellenschild 
aber nicht?


Gruß
Peter

Am 13.10.2015 um 17:42 schrieb Nzara:

Für mich ist eine Haltestelle ein Ort, wo ein Bus fahrplanmässig hält.
Wenn kein Bus mehr hält, ist das ein Mast mit irreführender Bezeichnung.
Mit public_transport hat es jedenfalls nichts mehr zu tun.

Anderseits sehe ich, gerade in ländlichem Gebiet, fahrplanmässige
Haltestellen ganz ohne Infrastruktur - die lokale Bevölkerung weiss
einfach wo sie stehen muss. Hier sehe ich dann die public_transport tags
auch ohne Infrastruktur gerechtfertigt.

Aus der Tatsache, dass die Haltestelle in keiner Relation mehr
auftaucht, kann man nicht viel schliessen -- ausser dass sich noch
niemand die Mühe gemacht Buslinien vollständig in Relationen abzubilden.
In OSM kann man eben aus dem Fehlen von Daten nicht auf die
Nicht-Existenz in der Realität schliessen.

Gruss
Nzara

Am 12.10.2015 um 20:40 schrieb Florian Lohoff:


Hi,
mir ist hier ein Changeset aufgefallen in dem eine
Haltestelle/stop_position entfernt wurde die defakto existiert.
Also da steht ein Bushaltestellenschild.

Der User der die entfernt hat sagt das diese Haltestelle nicht mehr
angefahren wird. Jetzt bin ich eigentlich geneigt die trotzdem
in den Daten zu lassen - Defakto existiert dort ja eine Haltestelle.

Die ist dann halt in keiner relation.

Oder bin ich da auf dem Holzweg?

Am Ende kann man ja gar nicht verhindern das der nächste die wieder
einträgt.





___
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] Liste aller Kirchen in Deutschland

[Peter Wendorff]

Nicht einmal das alleine, denke ich.
Auch eine Kapelle wird ja als Platz der Verehrung/Anbetung genutzt, 
gerade die vielen Marien- und sonstwie-Kapellen der Katholiken.


Das ist deshalb, denke ich, nochmal eine andere Kategorie, die eher im 
katholischen Kirchenrecht verankert wäre - und ob man das in allgemeinen 
Tags in OSM abbilden kann/sollte, weiß ich nichtmal.


Gruß
Peter

Am 09.10.2015 um 11:12 schrieb Martin Koppenhoefer:



sent from a phone


Am 08.10.2015 um 23:51 schrieb Helmut Kauer :

in der katholischen Kirche wird ein Gebäude zur Kirche durch die Weihe.




ja, aber das betrifft das amenity=place_of_worship, nicht den Gebäudetyp, der 
mit Building ausgedrückt wird

Gruß
Martin
___
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] Liste aller Kirchen in Deutschland

[Peter Wendorff]

Hi,

bei deiner Abfrage fallen mir spontan die Varianten ein, die ich auch zu 
Kirchen zählen würde, die aber die Kirche nicht im Namen tragen:


- Dom, z.B. "Stephansdom" in Wien,
- Kathedrale, z.B. "Christuskathedrale"
- Basilika, z.B. "Liebfrauenbasilika"
- Münster, z.B. "Liebfrauenmünster" in Ulm

Gruß
Peter

Am 06.10.2015 um 21:04 schrieb Jo:

Ich werde auch mal versuchen mich zu vergallopieren...

Ich habe diesen Overpass API query erstellt:

[timeout:450];
area[name="Mönchengladbach"]->.country;
(
   node (area.country) ["name"~"[Kk]irche"];
   way (area.country) ["name"~"[Kk]irche"];
   relation (area.country) ["name"~"[Kk]irche"];
   node (area.country) ["building"="church"];
   way (area.country) ["building"="church"];
   relation (area.country) ["building"="church"];
);
out meta;

;

out meta;

Damit soll es möglich sein alle Kirche zu finden, auch die die noch nicht
völlig korrekt in OSM eingetragen sind, weil auch straßen und
bushaltestellen mit Kirche in den Namen gefunden werden.

Ich werde vorschlagen um gleich auch wikidata tags ein zu tragen. Die
meiste Kirchen haben auch Artikel auf Wikipedia, und wenn nicht ist es
ziemlich einfach ein Wikidata item zu erfassen, mittels:

http://tools.wmflabs.org/wikidata-todo/quick_statements.php

CREATE

LASTLde"Sankt Laurentiuskirche"
LASTDde"Kirche in Odenkirchen"
LASTLen"Saint Laurentius church"
LASTDen"church in Odenkirchen, Germany"
LASTP31Q16970# church
LASTP17Q183  # Germany
LASTP825Q17590# Lawrentius of Rome

(Zwischen LAST P... und Q... sind TAB Karakter, keine Leerzeichen)

https://www.wikidata.org/wiki/Q21072103

https://www.openstreetmap.org/way/293096035/history


Ziemlich mehr Arbeit, aber so wird es möglich sein um alle zurückzufinden
die nach demselber Heiligen genennt sind.

Polyglot (Mein Deutsch ist leider nicht so gut)



2015-10-06 19:21 GMT+02:00 Florian Lohoff :


On Tue, Oct 06, 2015 at 02:12:23PM +0200, dktue wrote:

Hallo zusammen,

ich möchte gerne alle Kirchen in Deutschland mit Hilfe der OSM-Daten
identifizieren. Leider ist das nicht ganz trivial, denn

 amenity=place_of_worship

ist auch für viele Gemeindehäuser und andere Entitäten getaggt.

Das offensichtliche

 building=church

hingegen ist leider nur wenig verbreitet.

Hat jemand eine Idee, wie ich automatisiert möglichst viele Kirchen
sicher identifizieren kann?


Ich nehme auf diese Mail bezug weil sich ja eine Wochenaufgabe
herauskristallisiert die ich noch nicht so ganz sehe.

Der Punkt ist das ein building=church sich auf die Gebäudeform bezieht.

Das muss nicht zwangsmäßig ja noch ein amenity=place_of_worship haben.
Dazu kann auch der amenity als POI auf einem Node innerhalb des Gebäudes
liegen und das Gebäude trägt eben das building=church (Ich bin ein
großer Freund davon POI informationen auf extra nodes abzulegen).

D.h. ich finde hier werden tag klassen vermischt.

Es geht um Kirchen - in ihrer Funktion oder als Gebäude?

Ich habe in der Nachbarschaft mind. 2 Kirchen die mittlerweile
"entweiht" und verkauft sind. Von aussen eindeutig als Kirche zu
identifizieren jedoch einmal ein Restaurant und das andere ist ein
Wohngebäude. Beide haben sogar noch einen Glockenturm etc ...

Ich hätte auf den beiden auch ein building=church gesetzt ...

D.h. wenn man das vernuenftig macht und POI und Gebäude trennt müsste
das ein

building=church
amenity=place_of_worship
place_of_worship=church

sein ... Damit kann man das auch "self-contained" trennen. D.h.
ein Gebäude mit building=church und innerhalb einen node
der eben den amenity trägt.

Oder vergallopier ich mich da gerade?

Flo
--
Florian Lohoff f...@zz.de
  We need to self-defense - GnuPG/PGP enable your email today!

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQIVAwUBVhQDF5DdQSDLCfIvAQoSEQ//WynvnF9kTPdfJ87L90QnvuIbOek/tZxh
CaNq89/qYS1GlRqQFrAc+NMZSj2NRxVhJ25j/ADunhp04+Y++Xiim/ibqvyx8QsY
UW9SPzQQKrtFQu7XhN1ZDN7CnNuPQgbubhHiHx9MPTx0166kdmX4C+1kg2/B0XKR
z764w/4p9PcsVEJ5+gXlfT+zeVHgsQw451GTEx5nKeHZgSZ+MBuzYbU7Rc2MvPbI
ew1TiosvGbJPL1Yk6YsLiq/0emoHakGqjNZ4Z/MHVpMbrBbMDEci9ss2/Dbhuynt
UpE8wVAxBCP8OXMlQXhprPkxb6dUvTJz4eCLSpXP1ZgblVsEB8K6OaY93w65Ookj
OfzQJWvGPlLH82MOaTrNNrZRPEq0n9j0ZVnsTzPwG8MpZa4XxPa8i0wyJ29o4HyR
I/vbrEN6SogePtSF9UVYDNMm/PQSNRNGTTlG+nE+XnOgfvzcJ3D1WI+H6hARRE8b
WNilcu1jNp93NOlHfo9b+UGZUSDmha3Pl3pkvwgG4jaPYzeNfULaRzNZF0GN1+jZ
z+lPJ5LQQ6dFnu67NyPE3Nrzl3mCT5wh+3c4TFW+dsmZGVl3aEIeYzMaA9YXlaqA
eAFLdlV70s11Sp6RovRsGCfH/BB9OHyosKsqaQLe0qGhmxgedU2TcC3E9BfdJtLs
4MBJ1B+/tY0=
=Q6iT
-END PGP SIGNATURE-

___
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] Kurz-URL

[Peter Wendorff]

Hallo Markus,

ich kann selbst kein Ruby, aber ich tippe auf [1].
Zumindest ist das das richtige GIT-Repository für den Code, und der
sieht so aus, als würd das passen ;)

Gruß
Peter

[1]
https://github.com/openstreetmap/openstreetmap-website/blob/d4d1527a92f23f973b405cea42bef8009ce9f4c4/lib/short_link.rb

Am 17.03.2015 um 11:12 schrieb Markus:
 OSM bietet auf der Kartenseite Kurz-URLs an.
 Wie funktioniert das?
 
 Wo finde ich den Code, der das Handling für OSM.org erledigt?
 
 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

Re: [Talk-de] App für Android

[Peter Wendorff]

zum Sammeln speziell von Hausnummern und Straßen find ich Keypadmapper3
immer noch ziemlich gut, manuelles korrigieren am Rechner hinterher ist
trotzdem notwendig, dafür ist die Bedienung im Vorbeigehen kein Problem.

Gruß
Peter

Am 16.02.2015 um 21:37 schrieb Michael:
 Hallo Ihr lieben Openstreetmapper!
 
 Ich bin jetzt ein neuer Besitzer eines Android Smatphones mit größerem
 Display.
 
 Welche Apps könnt Ihr empfehlen, speziell für OSM?
 
 Den MapFactor GPS Navigator habe ich schon installiert.
 
 Gibt es eine App um schnell mal einen Straßennamen oder eine Hausnummer
 einzutragen?
 
 Welche Apps sind speziell für Technikfreaks noch sinnvoll?
 
 
 Liebe Grüße
 
 Michael
 
 
 ___
 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: [OSM-talk] Error when Exporting from Share icon

[Peter Wendorff]

Hi,

What if the osm website would allow custom renderings within
predefined zoom levels by default, stitching together existing tiles in
that case, which should require much less resources than a complete
custom render, even when cutting down to non-tile boundaries.

For current browsers it should be possible to do that with javascript at
the browser a well.

If we still want to allow the custom zoom rendering, a fallback to the
current solution might be possible, but a UI that makes clear that some
predefined zoom levels are to be preferred might, I guess, solve most of
our requests by accident as most users probably aren't that specific
in the zoom they query for.

What do you think about that idea?

regards
Peter

Am 26.01.2015 um 13:40 schrieb Tom Hughes:
 On 26/01/15 12:00, Paul Norman wrote:
 On 1/26/2015 2:58 AM, Dave F. wrote:
 I don't know when it was last reviewed, but does this error have bit
 of a sensitive trigger? Has the server that runs the process been
 upgraded so it can handle a greater number of requests? If so, could
 the error's cut in point be relaxed?
 The thresholds for each server have been adjusted multiple times and
 will probably continue to be so. Even if the load cutoff is increased
 there will be times when individual render requests are rejected for a
 few days in a row - stylesheet updates being the main one. It is
 considered more important to update the map rendering than to do a
 custom render. Personally I don't have many problems generating a custom
 render from osm.org, but I'm on a different timezone and keep different
 hours, which makes it hard to compare. I also get directed to a
 different server much of the time.
 
 I suspect main difference is that you're hitting orm and Dave is hitting
 yevaud. There is an ops ticket open for our efforts to get yevaud
 upgraded to improve the performance:
 
 https://github.com/openstreetmap/operations/issues/5
 
 Tom
 


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

Re: [OSM-talk] [Imports] amenity=bicycle_repair_station :::: only 18 so far

[Peter Wendorff]

Hi,

Adding option 4, already used on many other imports:

Use some externa repository for manual checkup, as done e.g. for fuel
stations [1], where the list of fuel stations was spread via wiki and
some other tool I don't recall exactly.

This allows to verify the progress (let importing users add a link to
the objects after their import), and it allows to verify the data. I
remember we checked most of the items on different sources as well, like
websites and aerials (you see fuel stations on imagery usually).

regards
Peter

[1]
http://wiki.openstreetmap.org/wiki/Fuel_Station_Data_Germany#Tankpool24.de

Am 26.01.2015 um 19:14 schrieb Dave Corley:
 --
 
 Message: 5
 Date: Mon, 26 Jan 2015 18:27:43 +0100
 From: JB jb...@mailoo.org mailto:jb...@mailoo.org
 To: winfi...@gmail.com mailto:winfi...@gmail.com,  OpenStreetMap
 talk mailing list
 talk@openstreetmap.org mailto:talk@openstreetmap.org
 Subject: Re: [OSM-talk] [Imports] amenity=bicycle_repair_station 
 only 18 so far
 Message-ID: 54c6790f.1040...@mailoo.org
 mailto:54c6790f.1040...@mailoo.org
 Content-Type: text/plain; charset=UTF-8; format=flowed
 
 Le 26/01/2015 17:59, Jo a écrit :
  It would indeed be preferable to use OSM Notes for that purpose.
 Ho crap. Instead of importing 500 low-quality POI, just import 500
 low-quality notes…
 So that only the notes DB is a dump, but not the main one.
 Sorry for the bad energy, but please do not consider the note feature as
 a second level one. And for the fun, please close the 10 closer to your
 location :-)
 
 
 As I see it there are 3 options here
 
 1. Do an import, but its not accurate enough for an import - 500 POI's
 will never be fully vetted. 
 
 2. Add a note so that someone can map it either from imagery or a ground
 survey - 500 notes will get checked by individual mappers. 
 
 3. Do nothing, stick the data in a drawer and never use it - 500 pieces
 of data never get used by anyone
 
 To me the only logical choice is #2 when you data is not accurate enough
 for an import but the data itself is useful and something which is wanted 
 
 All that is needed is a disclaimer added to the note something to the
 effect of This note is based off an inaccurate source. The bicycle
 repair station is located somewhere within 30 meters of this note. If
 you can easily identify the station, please map it and close this note.
 If note, please add a comment saying it needs a ground survey. 
 
 This doesn't need to be very complicated. 
 
 Dave
 
 
 ___
 talk mailing list
 talk@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk
 


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

Re: [Talk-de] Tag:highway=traffic_signals / wiki page inkonsistnet

[Peter Wendorff]

Ich weiß nicht genau, wie Router das momentan zählen, aber Probleme sehe
ich eigentlich höchstens bei geteilten Richtungsfahrbahnen an einer oder
beiden Straßen. Ansonsten tagge ich:

1) highway=traffic_signals am Kreuzenden Knoten der beiden Straßen, mit
der Interpretation: Diese Kreuzung ist (für den Hauptfahrweg) durch eine
Ampel geregelt)
2) highway=crossing, crossing=traffic_signals an der Querung (für
Fußgänger und/oder Radfahrer), also meist leicht abseits des kreuzenden
Nodes der beiden Hauptfahrwege.

Die Folge:
- Fußgängerquerungen lassen sich so präziser beschreiben, insbesondere
da, wo nicht an allen vier Armen der Kreuzung eine direkte Querung
möglich ist, als wen man die mit am mittelpunkt der Kreuzung einträgt
- Das Routing für Autofahrer muss jetzt nur noch eine Verkehrsampel
berücksichtigen. Einziges Problem: Wird auch eine Fußgängerquerung
(crossing=traffic_signals) ohne eingetragener Ampel
(highway=traffic_signals) alleine mit Zeitverlust bestraft werden
Ampeln noch teurer als bisher, da sie nun meist 3fach gezählt werden.

Ansonsten bzw. nichtsdestotrotz halte ich es für die korrekteste Lösung.

Gruß
Peter

Am 03.11.2014 um 21:19 schrieb chris66:
 Am 03.11.2014 15:12, schrieb Martin Koppenhoefer:
 
 Zu der Wikiseite möchte ich anmerken, dass das hier im Falle von Abbiegern
 von primary auf secondary die Ampel zweimal zählt:
 http://wiki.openstreetmap.org/w/images/d/dc/Traffic_signals_example_3.png
 
 Mir fällt hier auch keine Ampelpositionierung ein, so dass bei jeder
 Abbiegung jeweils nur einem Ampel im Weg liegt.
 
 Davon abgesehen sollten Navis hier etwas mehr Fuzzy Logik anwenden
 also z.B. eine zweite Ampel innerhalb von 10 Meter Wegstrecke
 nicht noch einmal für die Penalty zählen.
 
 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] OSM quo vadis - OSM-Account für Workshop

[Peter Wendorff]

Hallo Markus,

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.

Gruß
Peter

Am 23.09.2014 um 10:20 schrieb Markus:
 Hallo Stephan,
 
 Wir müssen bei OSM nicht jeden haben.
 
 Doch: OSM - die freie Weltkarte
 ist ein Projekt von freien Bürgern für freie Bürger :-)
 
 Die Herausforderung ist:
 - simple Frontends
 - intuitiv bedienbare GUI-Editoren
 - intuitiv bedienbare Qualitätswerkzeuge
 - verständliches nachvollziehbares Datenschema
 - verständliche gut organisierte Doku
 
 Nur Menschen mit lokalem Wissen können die Datenbasis verbessern.
 
 Wir müssen aufpassen, dass OSM nicht nur für IT-Nerds nutzbar ist,
 denn diese in Kombination mit lokalem Wissen sind dünn gesät ;-)
 
 (aber ds sprengt jetzt diesen Thread etwas)
 
 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

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

[Peter Wendorff]

Hallo Frank,
daran ist natürlich nichts falsch, und ich tu das selbst, wo ich kann -
aber je nach Kompetenz des Neulings, und darunter insbesondere
Lesekompetenz, erfordert das mehr oder weniger enge Betreuung.
Manchmal kann man Leute an lokale mapper verweisen, manchmal kann man
das selbst in die Hand nehmen - und manchmal wird das scheitern.

Auf einer Messe gehen Leute dann aber ja zügig weiter. Wenn da nicht
(wie bereits erwähnt) direktere Kontakte für später vermittelt werden,
ist eben niemand da, der bei Fragen hilft, sobald die Leute dann auf
einmal alleine dransitzen.
Gerade was das Mappen angeht ist OSM doch immer noch etwas, wo man recht
viel lesen muss, gerade am Anfang. Was bedeutet welcher Tag?
Die Presets von iD und JOSM nehmen einem hier schon recht viel ab, aber
eben doch nicht alles.
Am Stand hat einem eben doch keiner gezeigt, was ein Konflikt ist, warum
ich Routen kaputtmache und der validator mich davor warnt etc..

Ich weiß von einigen, die an solchen nachträglichen Problemen
gescheitert wären. Das lässt sich meines Erachtens nur entweder durch
einen dauerhafteren Kontakt zu erfahreneren Mappern, oder aber dadurch
beheben, dass der Neuling aktiv nachfragt oder recherchiert, ohne
direktem Kontakt zwangsläufig textuell, und das erfordert die von mir
vorher geforderte grundlegende Lesekompetenz.

Wie gesagt: Mit direkter Betreuung sieht das wieder anders aus, aber ich
bezweifle, dass die normalerweise funktioniert (bin da aber vielleicht
auch ländlich geprägt).

Gruß
Peter

Am 23.09.2014 um 11:18 schrieb 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
 


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

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

[Peter Wendorff]

Am 21.09.2014 um 21:07 schrieb Norbert Kück:
 Hallo Markus,
 
 am 21.09.2014 20:26 schrieb Markus:
 Also eine passende wegwerf-email besorgt und damit registriert.
 Aber OSM will mir eine Bestätigungsmail schicken - und die kommt bei
 mir natürlich nicht an...
 Wieso natürlich? Wenn Du beim Anbieter keine Weiterleitung auf Deine
 Adresse eingerichtet hast, musst Du die Nachricht auf seiner Website
 abholen.
 
 Wegwerfadressen sind übrigens nicht gut, weil sie die
 Benachrichtigungsfunktion von OSM (User zu User) unmöglich machen.
 
 Was nun?
 Das Problem hatte ich nicht, weil ich unter eigener Domain viele
 E-Mail-Konten einrichten kann.
 
 Vermutlich kannst Du Dich bei OSM einloggen, um die E-Mail-Adresse zu
 ändern - wäre ja blöd,  nur wegen eines Tippfehlers einen Account zu
 verbrauchen. Einige Kost-Nix-Anbieter haben eine Alias-Funktion, auch GMX?
Hat GMX auch.

Gruß
Peter

 
 Gruß
 nk
 
 ___
 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: [OSM-talk] Incorrect speed limit anonymous notes - who is behind that?

[Peter Wendorff]

Hi Per,
thanks for your reply to the thread here.

My suggestion regarding GPS traces would be twofold:

1) it would be great to have more gps traces alltogether in general, so
a general upload of traces would be ideal, but it requires teaching the
users about the danger of it, and uploading traces should probably be
under a collective account of your company to obfuscate personal home
locations and such. Another idea here would be to cut the first and last
parts of traces to obfuscate this.

2) Whenever a speed limit has been submitted the note you create from
that should ideally link to the corresponding gps track. This would
enable to get the direction directly (no heading necessary) and - if the
speed is included by at least relative timestamps in the trace - the
speed limit might be better to locate if the driver adjusts his speed
according to the current limit (which often is the case I think).

Both of this requires a really careful information of the user as those
data in theory may contain or leak private information.

regards
Peter

Am 08.09.2014 um 17:05 schrieb Per Rosengren:
 Hi all!
 
 I work together with Erik Matsson who also have written in this
 thread (in August). For those of you who haven’t read his message, we
 work at Appello that owns the navigation application Wisepilot. It is
 through Wisepilot those anonymous notes have been posted.
 
 First of all, thanks for your input. All ideas about how we can
 improve the quality of the notes are very much appreciated.
 
 We have made some first changes on the server side of our application
 based on your input. We will also make further improvements as we are
 releasing new client versions.
 
 We have changed so that only registered and authenticated users are
 allowed to post notes for now. Hopefully we can later allow anonymous
 notes to be posted again when we have made some more improvements to
 prevent spam notes (sanity checks, more useful info in the notes and
 provide the users with more information about what happens when they
 post a note).
 
 Notes about wrong/missing speed limit now looks like in the example
 below (always in English). We changed the message to make it clearer
 that the reported speed is what it should be changed to in the map
 data. We also made it clear that it is reported using Wisepilot and
 added a link to our site if someone wants to contact us. = 
 Reported and assumed correct speed limit is 30 km/h. Reported using
 Wisepilot map reporter Created by www.appello.com =
 
 If a user tries to report speed limits like 15, 25, 35 km/h we ignore
 the note and do not post it (still possible when mph). Also, in
 upcoming releases of the client we will try to make something smart
 so that km/h or mph is automatically selected depending on the user’s
 position (at least make it more clear what one is reporting).
 
 Like Andreas Vilén suspected, our default position was sometimes used
 when posting a note. It is users who have not yet gotten a real GPS
 fix (probably in combination with that they do not understand the
 reporting functionality). In coming releases of our client we will
 add a check in the clients that it is not a simulated position but a
 real GPS fix (we also think of adding the GPS accuracy to the note).
 To prevent old clients from reporting the default positions we now
 ignore notes with a position that is near the default position.
 
 In coming client releases we will also check the heading and add that
 to the notes as well (like Christian Quest suggested, N, NW, etc).
 
 If you have ideas related to sharing GPS traces it would be
 interesting to hear about them, as this is a feature we plan to add.
 
 Don’t hesitate to contact us if you have questions or ideas of how we
 can make things better.
 
 Best regards, Pelle
 
 
 -- Per Rosengren Deputy Head of Engineering
 
 Location: Appello | Göteborg | Sweden Phone: +4670-6858253 Mail:
 per.roseng...@appello.commailto:per.roseng...@appello.com Web:
 www.appello.comapplewebdata://D15576C0-CD44-42A9-B5CC-684A0DB0D998/www.appello.com%20

 
 
 [Description: cid:image001.png@01CD2D3A.F4FA4D50]
 
 
 
 
 
 ___ talk mailing list 
 talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
 


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

Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

[Peter Wendorff]

Hi Janko,
something like that was proposed on the wikidata side already if I
remember right.
The idea was to store some kind of query on wikidata, e.g. the
Overpass-Permanent-ID [1], which would be used exactly as you say:
it can fetch the arbitrary object(s) that match and should match;
independent of changing OSM object ids, splits or other stuff like that.

I don't find the right page where that happend, probably my memory is
corrupted ;)

regards
Peter

[1] http://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID

Am 31.08.2014 um 16:46 schrieb Janko Mihelić:
 Hi Frederik, great post.
 
 I always thought wikidata tags would be a first step to a new database that
 OSM needs, and which would be something like Wikidata is to Wikipedia. A
 database that classifies and categorizes elements in OSM. In my opinion a
 slightly modified version of Wikibase could be enough. It would have
 combinations of tags and areas where that category applies.
 
 If we had a database item in our potential OSM-wikibase that said all
 primary highways with ref 55 in the UK and then offload the proprietary
 identifiers there, I think no one would mind.
 
 Another problem this potential database solves is the often quoted
 relations aren't categories. We could make an item HSBC ATM machines
 and add a few tags that define an element as a HSBC ATM machine
 (amenity=atm + operator=HSBC, or amenity=atm + ref:HSBC=34 or whatever)
 
 Even wikidata tags that we are discussing could be deprecated if we had
 such a database. We would have our own identifiers (O3489 instead of
 Q23489) and those identifiers would link to wikidata as well as to other
 databases.
 
 If we don't make our own database that categorizes our tags and elements,
 someone else will do it. In this case, it's Wikidata, which is better then
 the rest because it is crowdsourced, it has an open license for it's data,
 and it has opensource software for it's database and user interface. So if
 I'm not mistaken, we could fork their project if that was needed. But if I
 could choose, we would have our own.
 
 Janko Mihelić
 
 2014-08-30 23:40 GMT+02:00 Frederik Ramm frede...@remote.org:
 
 Hi,

 On 08/29/2014 08:10 PM, Rob Nickerson wrote:
 Lets just step back and reflect on this for a minute.

 My overarching concern is that if this import is done, future imports
 will use the but we also have Wikidata links argument for justification.

 What we have here is a third-party database whose object identifiers we
 add to OSM as tags in order to make linking things easier.

 This is something that has often been requested by people but never been
 granted on a large scale because we always said that it would be an
 abuse of our database and our mapper's patience to offload everyone's
 and their dog's linking requirements onto us.

 Imagine every single stretch of road being tagged with three different
 proprietary (or at least competing) identifiers of traffic information
 providers, or similar payload tacked onto OSM.

 I'm not saying no to a Wikidata import but I would like the proponents
 to state clearly what makes this import special - why this and not, for
 example, Ordnance Survey TOIDs or IDs of Mapillary photos?

 I would like to define high hurdles for such an import. The import costs
 us a lot (in terms of mappers having to spend time to understand the
 tags and know how to handle them when they edit an object, more quality
 checks, etc.), and it must be proven - or at least expected - to offset
 that cost by making itself useful. It's ok of this particular import
 clears the hurdles but at least I can then use the hurdles if the next
 guy in line comes along and wants to import his keys too.

 Also, I note that Rob wrote:

 We have our own restrictions (verifiable on the ground, not changing to
 frequently) in OSM. A link to wikidata allows us to continue with these
 restrictions but still allow people to get at interesting non-geographic
 data.

 And Andrew said:

 A few more points: This isn’t a deletionists’ charter and we shouldn’t
 rush to unload any tagging onto Wikidata without discussing the removal
 very carefully.

 I am personally very much in favour of unloading non-geo-database
 tagging elsewhere. We started with marking restaurants (useful) and
 recording their names (also useful), classing them into fast-food or
 proper restaurants, then tagging what cuisine they have and how to
 contact them for booking a table, and meanwhile we're recording whether
 they have vegan food and what their opening times are and whetehr you
 can pay with bitcoin. We don't currently have anywhere to offload that
 information which is all useful for certain use cases, but once we have
 a working integration, I should very much hope that stuff like the menu
 and the opening times will be recorded either in OSM or in Wikidata but
 not both.

 Allow me one question in that matter as a Wikidata ignorant though: Are
 there any notability rules in Wikidata? For example, if 

Re: [OSM-talk] Introducing Fix waterway direction

[Peter Wendorff]

Am 28.08.2014 um 21:48 schrieb Peter Barth:
 Hi,
 
 Christoph Hormann schrieb:
 Great to see the waterways are getting some attention. Does this only 
 analyze SRTM elevations at start and end point or are the surrounding 
 waterways considered?  
 
 currently start and end point only. I have code to do more, but for the
 easy tasks that was not necessary as I have a fairly high number of true
 positives.
 
 If a waterway meets another waterway at one side 
 but is unconnected at the other for example this is usually a strong 
 indicator for the direction independent of the elevations data (which 
 is only helpful usually in mountain areas).
 
 Actually I found many streams where start and end point are not
 connected to anything at all. However, for those cases (not mountain
 areas) the aerials didn't help neither in most cases ;) But as I'd like
 to get a mostly complete waternetwork for another project, I'm planning
 on extending the challenge at some point.
 
 In terms of usability it would of course be good if you could see the 
 direction in MapRoulette so you can verify the data without actually 
 loading it in the editor.
 
 Serge suggested this, too. But I did never understand what the direction
 would tell the user? Does it denote the current way's direction or the
 supposed correct direction? How would the user know? And my biggest
 concern is, that in many cases you need aerial anyway to be really sure.
 
 Anyways, would be happy to add this, once I got, how this should be done
 :)
You may add arrows in both directions, color-coded for assumed and
current (and explained in the challenge description on the top right)

regards
Peter

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

Re: [OSM-talk] Incorrect speed limit anonymous notes - who is behind that?

[Peter Wendorff]

Hi,
A distinction between field notes and armchair IMHO goes too far.
Instead a kind of field flag might help, which can be seen as this
note has to be reviewed by someone with detailled on-the-ground
knowledge or being present on the ground.

On the other hand there's the problem of an increasing number of notes.
I see two different problems here.

1) Too many notes I cannot solve: Motivation goes down, and I start to
close notes just to get rid of them although they are neither solved nor
correctly identified as being invalid.
This is an individual problem for each (maintaining) mapper. I would
like to see something like hide this node for me, perhaps with an
optional ...until it is changed or commented by someone else. This
would allow armchair mappers to clean up the notes as far as possible
without being disturbed by irrelevant notes being processed already.

2) What is the purpose of notes?
There are private notes of mappers for themself to fix problems later;
often these aren't explained in detail as the mapper relies on his
memory to understand it. Those might be solved by allowing private
notes as mentioned by others.
There are bug notes, where something is wrong in the map in contrast
to missing notes, where something is missing. Both may be valuable,
some for locals, some for armchair mappers, some for both, and others
for nobody.
The distinction between armchair and field is difficult. Of course
there are Germans or HOT-people who armchair-map somewhere else in the
world or something like that, but I don't think it would solve the
issue. I think, although those don't call themself armchair-mappers,
most of these issues arise where someone checks his own city, or the
region around for bugs. Bugs where the mapper might go to in the field
if necessary, if not now, then in the next weeks or months, becoming a
field mapper by doing that. Moreover most armchair mappers (I hope) are
field mappers in their local area. It would therefore require to decide
about my own field mapping area versus the rest of the world to show
or hide the one or the other set of nodes.

To conclude: I think there's the chance for improvement of the notes
system, but closing notes should be done with care, and only where it is
clear that the note is either solved or unsolvable/wrong.

regards
Peter

Am 10.08.2014 um 14:10 schrieb Matthijs Melissen:
 I see a lot of comments like this. The underlying problem seems to be
 that it is not clear whether notes are meant for armchair mappers, or
 for surveyors in the field.
 
 I think both types of notes are useful: that way the notes can serve
 as a two-way communication between mappers in the field (for example
 novices who don't know how to edit the map themselves) and armchair
 mappers (who might want to communicate with mappers in the field if
 they are unable to do a field check themselves at that moment).
 
 So the solution might be very simple: make two types of notes, 'desk'
 notes and 'field' notes. The desk notes can be handled by armchair
 mappers. The field notes need a check in the field. Notes created by
 anonymous users should be desk notes by default, and if information is
 missing, the armchair mapper should be able to turn it into a field
 note.
 
 The notes JB refers seem to be field-type notes. I think they are
 useful, and I think it's not helpful if armchair mappers try to close
 all of them without doing a survey.
 
 Anyone think a split in field and desk notes is a good idea?
 Implementation of this should be easy.
 
 -- Matthijs
 
 On 10 August 2014 11:50, JB jb...@mailoo.org wrote:
 Hello,
 I think I will reopen the debate here, by asking a simple question: how many
 of those saying hey, let this note open, it does no harm to anybody have
 actually browsed a country for its opened notes and tried to close them? How
 many have done the same with openstreetbugs during its last year of life?
 If you have not, let me tell you, loud and clear: the note database will
 become unusable soon. When you browse 10 notes and are forced to leave 9
 open because it does provide no clean information, you just stop trying.
 That is why during OSB close up, I found so many notes of that kind
 (continue the path, this is wrong, this does not exist, etc.), that where
 just not clear enough, or where just too old (the correction had been done
 without OSB), and most of them where more than 2 years old. And this is why
 OSB was a mess in the end.
 I have tried to keep the DB clean in France, am still trying by beeing less
 narrow-minded, but I just see its quality decreasing every day.
 So I do not have the exact number, but adding some 10s of little valued
 notes every week saying this speed limit may be wrong, some of them added
 by error (not along a highway) does not seem an improvement to the notes DB
 to me.
 JB.


 Le 10/08/2014 09:42, Martin Koppenhoefer a écrit :


 Il giorno 09/ago/2014, alle ore 13:56, Norbert Wenzel
 norbert.wenzel.li...@gmail.com ha scritto:

 

Re: [Talk-de] shop=pharmacy Tag enfernen, wenn amenity=pharmacy vorhanden

[Peter Wendorff]

Hi,
der Wheelmap-Visitor sollte meines Wissens nur für
wheelchair=yes|no|limited eingesetzt werden. Natürlich taucht der
trotzdem als letzter Bearbeiter auf, wenn die wheelmap amenity=pharmacy
auch nur als solches erkennt und bearbeiten lässt, aber ich bezweifle,
dass sie der Ursprung der Tags ist.

Gruß
Peter

Am 04.08.2014 um 09:27 schrieb Andreas Goss:
 Ich hatte mir nach dem Kommentar im Diary das Ganze mal etwas genauer
 angeschaut und es scheint vorallem in Deutschland vorzukommen.
 http://www.openstreetmap.org/user/AndiG88/diary/23443#comment27423
 
 Bei genauerem hinsehen wurde dann auch klar warum: wheelmap_visitor
 
 Von daher jetzt meine Frage, wäre es in Ordnung, wenn ich in Deutschland
 mit einem mass edit überall den shop=pharmacy Tag entferne, WENN
 amenity=pharmacy vorhanden ist? Siehe:
 
 http://overpass-turbo.eu/s/4rC
 
 
 http://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dpharmacy
 __
 openstreetmap.org/user/AndiG88
 wiki.openstreetmap.org/wiki/User:AndiG88‎
 
 
 ___
 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] shop=pharmacy Tag enfernen, wenn amenity=pharmacy vorhanden

[Peter Wendorff]

Das versteh ich jetzt nicht,
Dein Bild zeigt vier davon, die alle vor der Bearbeitung durch
wheelmap_visitor schon amenity=pharmacy als Tag besaßen.

Inwiefern wäre jetzt wheelmap_visitor die Quelle des Tags, wenn nur ein
völlig anderes Tag, nämlich wheelchair=* hinzufügen, und das Objekt
sonst unverändert mit dem vorher schon vorhandenen amenity=pharmacy
belassen?

Gruß
Peter

Am 04.08.2014 um 10:21 schrieb Andreas Goss:
 Einfach mal zufällig reingeklickt: http://i.imgur.com/xDpZ3Bh.png
 
 Nicht die einzig Quelle dieses Tags, aber vermutlich der Grund warum
 Deutschland hier besonders hervorsticht.
 
 Hi,
 der Wheelmap-Visitor sollte meines Wissens nur für
 wheelchair=yes|no|limited eingesetzt werden. Natürlich taucht der
 trotzdem als letzter Bearbeiter auf, wenn die wheelmap amenity=pharmacy
 auch nur als solches erkennt und bearbeiten lässt, aber ich bezweifle,
 dass sie der Ursprung der Tags ist.

 Gruß
 Peter
 
 
 ___
 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] shop=pharmacy Tag enfernen, wenn amenity=pharmacy vorhanden

[Peter Wendorff]

Hi,
mea culpa, entschuldigt bitte; hatte irgendwie nur nach amenity=pharmacy
geguckt, und das war ja schon da (evtl. in der irrigen Annahme, dass
jemand das wegnähme, wenn er was alternatives dazu einfügt)

Gruß
Peter

Am 04.08.2014 um 12:27 schrieb Holger Jeromin:
 Peter Wendorff wrote on 04.08.2014 11:16:
 Das versteh ich jetzt nicht,
 Dein Bild zeigt vier davon, die alle vor der Bearbeitung durch
 wheelmap_visitor schon amenity=pharmacy als Tag besaßen.

 Inwiefern wäre jetzt wheelmap_visitor die Quelle des Tags, wenn nur ein
 völlig anderes Tag, nämlich wheelchair=* hinzufügen, und das Objekt
 sonst unverändert mit dem vorher schon vorhandenen amenity=pharmacy
 belassen?
 
 Guck nochmal genauer hin. Zusätzlich mit wheelchair kam der shop hinzu.
 
 Siehe auch:
 http://osm.mapki.com/history/node.php?id=904149172
 
 definitiv ein bug der behoben werden muss, wenn er überhaupt noch
 aktuell ist. Ist immerhin über 3 Jahre her.
 


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

Re: [OSM-talk] Incorrect speed limit anonymous notes - who is behind that?

[Peter Wendorff]

Sorry,
there are QA tools to detect where speed limits are missing?
Can you give me a link?
And - if it's not self explaining: how should that work? I don't see any
way to detect missing speed limits in the data beyond cases where those
are implicit defaults, like 100 on non-trunk roads away from built up
areas in Germany (which is complicated enough to derive from the data),
or 130 for trunk roads (although most often there are lower limits), or
50 in cities (as the most often down-signed default).

So if there is any QA tool that detects that, I fear it uses third party
sources, a reporting system similar to the notes feature, but using a
different channel, or it is restricted to some cornercases only. I doubt
there is something like that which could make notes about speed limit
errors in osm obsolete.

IMHO notes are to be checked in person on the ground usually. If there's
nobody in France to do that, yes, then notes will remain in the database
for a long time, but basically they stay correct: Here is something
missing or wrong, please check that on the ground.

regards
Peter

Am 29.07.2014 um 11:09 schrieb JB:
 I don't necessarily want to analyse once more how the notes are opened,
 closed or not closed and to what aim, nor analyse the end of
 OpenStreetBug life and the quality of the remaining bugs, but in France,
 I have never ever seen anyone comment on someone else's note (or «
 resurvey »). The only comments I have seen were from the note opener,
 when prompted by a potential corrector.
 
 So a note which indicates « probably 90km/h here » or « speed limit is
 not 0km/h » may remain there for years (yes, years), demotivate
 potential note closers, never be closed. I do not think they participate
 to a high quality note db. There are quality assessments tools around
 that allow contributors to detect where speed limits are missing.
 
 JB, with perhaps some bad faith in there, but not that much.
 
 
 Le 29/07/2014 10:19, Steve Doerr a écrit :
 On 29/07/2014 08:32, JB wrote:

 Anyway, as for most notes concerning speed limits, if you do no have
 the beginning and the end of the limit, at least in France, the
 information is quite useless.

 Are we all armchair mappers now? Surely the note should prompt someone
 local to go out to the location and find out where the speed limit
 starts and ends?

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


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

Re: [OSM-talk] Incorrect speed limit anonymous notes - who is behind that?

[Peter Wendorff]

Hi Shaun,

if I understand these maps correctly, they show streets without a
maxspeed tag, but not msising maxspeed restrictions under the assumption
of a national default or something like that (although it seems not so
show any missing maxspeed in Germany, so there might be something like
that applied).

If maxspeed is and should be applied on any street, this works, but only
until speed limits change.
If you imply the default according to highway class and location, it
fails as many roads do follow these defaults and cannot be counted as
missing, nor is it possible to decide where else a maxspeed is missing
then.

In any case reporting missing maxspeeds will work only until the speed
limit is changed on the ground as it is even more difficult (if
possible) to detect where there are errors (!) in existing speed limits.

regards
Peter

Am 29.07.2014 um 13:10 schrieb Shaun McDonald:
 Hi Peter,
 
 The following ITO Map shows missing maxspeed tags where there isn’t any 
 purple (mph maxspeed) or dark green (km/h maxspeed) colour:
 http://www.itoworld.com/map/125?lon=-0.08316lat=51.51851zoom=14open_sidebar=map_keyfullscreen=true
 
 If you want to see the current speed limits see:
 http://www.itoworld.com/map/124?lon=-0.08316lat=51.51851zoom=14open_sidebar=map_keyfullscreen=true
 
 Clicking the maps gives more info in the sidebar.
 
 Shaun
 
 Disclaimer: Employee of ITO World who produce the maps above.
 
 On 29 Jul 2014, at 11:49, Peter Wendorff wendo...@uni-paderborn.de wrote:
 
 Sorry,
 there are QA tools to detect where speed limits are missing?
 Can you give me a link?
 And - if it's not self explaining: how should that work? I don't see any
 way to detect missing speed limits in the data beyond cases where those
 are implicit defaults, like 100 on non-trunk roads away from built up
 areas in Germany (which is complicated enough to derive from the data),
 or 130 for trunk roads (although most often there are lower limits), or
 50 in cities (as the most often down-signed default).

 So if there is any QA tool that detects that, I fear it uses third party
 sources, a reporting system similar to the notes feature, but using a
 different channel, or it is restricted to some cornercases only. I doubt
 there is something like that which could make notes about speed limit
 errors in osm obsolete.

 IMHO notes are to be checked in person on the ground usually. If there's
 nobody in France to do that, yes, then notes will remain in the database
 for a long time, but basically they stay correct: Here is something
 missing or wrong, please check that on the ground.

 regards
 Peter

 Am 29.07.2014 um 11:09 schrieb JB:
 I don't necessarily want to analyse once more how the notes are opened,
 closed or not closed and to what aim, nor analyse the end of
 OpenStreetBug life and the quality of the remaining bugs, but in France,
 I have never ever seen anyone comment on someone else's note (or «
 resurvey »). The only comments I have seen were from the note opener,
 when prompted by a potential corrector.

 So a note which indicates « probably 90km/h here » or « speed limit is
 not 0km/h » may remain there for years (yes, years), demotivate
 potential note closers, never be closed. I do not think they participate
 to a high quality note db. There are quality assessments tools around
 that allow contributors to detect where speed limits are missing.

 JB, with perhaps some bad faith in there, but not that much.


 Le 29/07/2014 10:19, Steve Doerr a écrit :
 On 29/07/2014 08:32, JB wrote:

 Anyway, as for most notes concerning speed limits, if you do no have
 the beginning and the end of the limit, at least in France, the
 information is quite useless.

 Are we all armchair mappers now? Surely the note should prompt someone
 local to go out to the location and find out where the speed limit
 starts and ends?



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



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


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

Re: [Talk-de] Bltzer auf Weg oder nicht?

[Peter Wendorff]

Hallo Ronnie,

also im Code des OsmandMapCreators sehe ich eine Auswertung genau der
enforcement-Relationen, nämlich hier [1].

Ich würde das so interpretieren, dass Relationen (Z. 127) mit
type=enforcement und enforcement=maxspeed (Z. 138) besitzen, durchaus
berücksichtigt werden sollten, und zwar werden alle Nodes (keine Ways
etc!, Z. 144) mit er Rolle from (Z. 140) mit einem
speedCamera-Attribut ausgezeichnet.

Dieser Code ist jedoch erst seit dem 1. März 2014 in github,
möglicherweise sind deine/eure Tests, dass Osmand das nicht unterstützt,
deshalb veraltet.

Vielleicht lohnt es sich also, mit einer aktuellen Karte, notfalls mit
dem osmandmapcreator aus dem git-repository selbst erzeugt, nochmal zu
testen.

Gruß
Peter


[1]
https://github.com/osmandapp/OsmAnd-tools/blob/2d7f1eefea915e5f619cd19c297434122b0d7ab8/OsmAndMapCreator/src/net/osmand/data/preparation/IndexRouteCreator.java#L125

Am 21.07.2014 09:08, schrieb Ronnie Soak:
 Hallo,
 
 deutsches [1] und englisches [2] Wiki divergieren hinsichtlich der
 Benutzung des highway=speed_camera tags.
 
 Auf der englischen Seite steht, das tag gehört an die Kamera (= an ihren
 Aufstellungsort), deren Bezug zu einem Weg dann per relation
 (type=enforcement) dazu.
 
 Im deutschen Wiki wird die Relation zwar erwähnt, dafür fehlt der Hinweis,
 die Kamera an ihrem eigentlichen Platz zu mappen.
 Stattdessen gibt es unten einen Absatz, der beschreibt man möge doch auf
 einen Knoten auf dem Weg mappen, damit OSMAND damit umgehen kann.
 
 Könnte ich da mal ein Meinungsbild haben, ob das jetzt
 
 a) plumpes Taggen für einen speziellen Router ist und aus dem Wiki entfernt
 werden sollte
 
 b) zwar plumped tagging für eine speziellen Router ist, aber aus anderen
 Gründen trotzdem vernünftig ist und man das drinlassen sollte (als deutsche
 Sonderlösung gekennzeichnet)
 
 c) die Funktionsfähigkeit von OSMAND wichtig genug ist, unser Taggingschema
 daran anzupassen und auch die internationale Community anzusprechen um es
 im engl. Wiki zu ändern.
 (Ja, ich meine das Ernst.)
 
 
 Gruss,
 Chaos
 ___
 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?

[Peter Wendorff]

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.
Abbiegebeschränkungen kann man rendern, muss man aber nicht - die sind
insbesondere fürs Routing interessant.
Tagging-Schemata für Adressen (über Hausnummern hinaus; also z.B.
associated street, addr:street, addr:postcode, addr:city, ...) sind,
wenn überhaupt notwendig, für die übliche Karte uninteressant in der
Darstellung, aber eine gute Sache für Geocoding, Suche und ähnliches.

Wenn man das - wie du vorschlägst  - mit einem (!) Rendering-Vorschlag
abtut, kann man nur eine Karte berücksichtigen. Die nächste Karte
benutzt Symbolpatterns statt Farben, die wieder nächste muss noch im
Vier-Farb-Druck oder in Graustufen funktionieren, und noch eine andere
beschränkt sich auf dieses eine Feature und hat deshalb überhaupt kein
Problem, eine konfliktfreie Darstellung zu finden.

Gruß
Peter

Am 08.07.2014 07:16, schrieb Markus:
 Moin Henning,
 
 gute Idee:
 osm-Dateien ins wiki laden
 oder man taggt ein Beispiel in OSM
 Service Render mir mal die folgende osm-Datei in render-style
 
 Zu jedem Tagging-Vorschlag
 gehört immer auch ein *Rendering-Vorschlag*
 mit Rendering-Regeln, Icons, Flächen-Farben und -Mustern.
 
 Nur so kann man sehen, wie das Grün vom Campingplatz mit dem Grün
 von Wald, Wiese, Fussballplatz, Kinderspielplatz, etc. zusammenspasst.
 Und was es für einen Unterschied macht, welche Flächen man wie
 übereinander zeichnet oder ausschneidet (Teilmenge, Schnittmenge,
 Vereinigungsmenge, A ohne B, Differenzmenge).
 
 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

Re: [Talk-de] Reisebüro mit DB-Kartenverkauf. Wie eintragen?

[Peter Wendorff]

Hallo Manuel,
das würde ich gar nicht mit eintragen - sonst müsstest du das konsequent
gleich für jede Flug- und Fernbusgesellschaft, Reederei und
Bahngesellschaft etc. eintragen; und Gebühren sind bei vielen wenn nicht
allen Reisen, die du übers Reisebüro buchst, vorhanden - ob die dann
Gebühr genannt werden oder die Provision direkt eingepreist ist, ist ja
irrelevant.
Sogar die Bahn-Schalter selbst nehmen ja Aufpreise gegenüber dem Kauf am
Automaten.

Das dürfte sich praktisch nicht abbilden lassen; insofern würd ichs
weglassen.

Gruß
Peter

Am 05.07.2014 11:17, schrieb Manuel Reimer:
 Hallo,
 
 viele Reisebüros (in Deutschland) bieten auch Beratung zu Bahnfahrten an
 und verkaufen auch Bahntickets.
 
 Gibt es schon einen Taggingvorschlag wie man das bei einem Reisebüro mit
 hinterlegen kann?
 
 Zumindest das Reisebüro, bei dem ich bisher meine Tickets gekauft habe,
 verlangt seit neuestem auch eine Gebühr für den Kartenverkauf und
 Fahrplanauskünfte. Wie würde man diese Gebühr hinterlegen?
 
 Danke im Voraus
 
 Gruß
 
 Manuel
 
 
 ___
 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: [OSM-talk] Come back Osmarender, all is forgiven!

[Peter Wendorff]

Hi,
I agree that the render-all-approach is useful in some cases, but - on
which ones?
In low zoom levels (z0-15) it tends to get overwhelmingly cluttered by
features while on the other hand lots of them have to be dropped at
random because of geometric restrictions - there's limited space on the
canvas, and nothing will change that.

In high zoom levels I would like to see something like that, but usually
that's beyond z18, probably even beyond z19.

Perhaps we shouldn't cry to get osmarender back but instead to get a
vector rendering solution for high zoom levels, rendering in the browser
and allowing the user to define what should be rendered and what should
not. I'm not entirely sure how that would look like, but a long list
(with filtering capability) of items to show or hide might be a starting
point, and if you really want you could check all and get your unusable
cluttered map - but you may be able to specify exactly what you want to
see rendered  (and, who knows, perhaps even how it's diplayed).

regards
Peter

Am 23.06.2014 13:56, schrieb SomeoneElse:
 There have been lots of changes to the standard style sheet recently
 (e.g. [1]).  The resulting map looks much nicer (farmland and other
 landuse much less glaring, names that really make no sense to be shown
 on a general map aren't).
 
 There have however been some unintended consequences of the changes.  A
 number of abandoned railways near me were edited from abandoned to
 disused; I'm guessing that it might be because of the recent changes. 
 Changeset comments along the lines of changed to X so that it renders
 and I know we're not supposed to tag for the renderer but what's the
 point in mapping a feature which then doesn't appear are relatively
 common.
 
 The question, I suspect is what is the Standard style on the OSM
 website for?  It used to be for mappers, but a nice rendering; one that
 you might actually use as a punter too.  Back when Osmarender [3]
 existed, that was the if you want to see everything render, look at the
 instead option.  The removal of features (see [2]) that people actually
 use means that the Standard style isn't really for mappers any more -
 it's a nice (very nice, actually) generic map style, but not one that
 you can use to make sure that what you've mapped is technically
 correct (e.g. joined polygons up properly).
 
 So, where's the replacement for Osmarender?  I'm sure that someone,
 somewhere, will have created a CartoCSS style file that is much closer
 to show everything than openstreetmap-carto currently is. Currently
 for my own use I'm still using the standard style but at database update
 adding back in some of the recent removals (see [4] - it also does some
 England and Wales rights-of-way stuff). However, as the standard style
 becomes nicer it's becoming increasingly clear that it's not the best
 place to start from.  The question is, what is?
 
 Cheers,
 
 Andy
 
 [1] https://lists.openstreetmap.org/pipermail/talk/2014-June/069959.html
 
 [2] https://github.com/gravitystorm/openstreetmap-carto/pull/542
 
 [3] http://wiki.openstreetmap.org/wiki/Osmarender
 
 [4]
 https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua
 
 
 ___
 talk mailing list
 talk@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk
 


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

Re: [OSM-talk] Worldwide non-surveyed tag edits

[Peter Wendorff]

Hi,
I think two issues are mixed here that shouldn't be.

One thing is the question about mechanical edits, the other thing is
more about unifying edits.

The latter occurs most often on mechanical edits, but it seems the two
issues are seen as equal what I don't think they are.

I would combine both to algorithmic edits.
It's not different wether I use overpass, josm selection by filters and
beyond that mouse and keyboard to change all tags from A to B or to
delete objects that correspond to a certain condition or if I do that
using a fully automatted script.
In both cases it's dangerous to make a mistake. And in neither case I
can or do any individual check for each object.

In both cases - but, yes, even more on the bot/script way of doing that
stuff, is the danger to make errors.
The first error class is a technical one, which is more likely on the
script approach then on the nearly-manual mass editing.

The other class of errors occurs earlier: When deciding to make an edit.

Changing amenity=restaurante to amenity=restaurant (no idea if that's a
common real-world bug) seems to be clearly a good way to achieve, and
there are typos that are definitivly typos. But where does a typo get a
semantical difference?

Sometimes even people unify stuff by look-alike semantical identity,
which, looking more closely on the issue isn't. In these cases we have a
problem in the tagging perhaps, but not at first a problem of synonymous
tags, but about IF they have the same meaning.

To conclude:
There are IMHO at least two reasons why large scoped edits should be
discussed and therefore be in some kind of policy:
If you fail on a large edit, you break a large amount of data.
That's why you should let others look and verify what you're going to
1) make sure no technical bug appears
2) make sure you didn't oversee something, e.g. a different meaning of a
tag or tag combination.

regards
Peter

Am 11.06.2014 15:06, schrieb Jochen Topf:
 On Mi, Jun 11, 2014 at 01:55:41 +0200, Christoph Hormann wrote:
 On Wednesday 11 June 2014, Jochen Topf wrote:

 I think the mechanical edits policy has stepped over the line here.
 A mechanical edit is one where somebody uses a special program that,
 based on some simple criteria, does *automatic* changes. Using
 existing tools like JOSM and XAPI to find problems, looking at them
 manually and doing edits, is not a mechanical edit and should not
 fall under that policy.

 And i think it does not.

 The policy is probably not worded in the clearest possible way but it 
 has always been my interpretation that the key question is if the 
 modifications made to the database are individually verified by the 
 mapper, not if you use some fancy filtering to find those objects you 
 want to modify.
 
 I think we are probably in agreement here. My looking at them manually might
 be a very bad wording, but it meant the same as your much better individually
 verified.
 
 But the policy first disallows all of this and then makes the exception if 
 you
 check each individual action caused by this then its okay. Thats the wrong 
 way
 around. It means I have to defend myself when doing this. It means I have to
 prove that I am not doing anything wrong. Of course I have to verify that what
 I am doing is okay, that is the default anyway. But we are still measuring
 with two different sticks if we single out edits based on filters or whatever
 and not treat them like edits based on 20 year old sat images or whatever.
 
 Jochen
 


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

Re: [Talk-de] Falsches Kartenmaterial Google statt OSM

[Peter Wendorff]

Hallo Helmut,
die Karten die da angezeigt werden sind dann auch OSM-Karten, das große
google-Logo kommt von der Javascript-Bibliothek, die die für die Anzeige
nutzen.
Die Attribution für OSM fehlt aber schlichtweg, was nicht okay ist.

Gruß
Peter

Am 29.05.2014 11:11, schrieb Helmut Kauer:
 Griaß eich,
 
 bin gerade auf /http://www.deine-berge.de/[1] gelandet. Dort kann man 
 bei den Karten OSM abrufen und landet bei google. Hab den 
 Seitenbetreiber bereits angemailt.
 
 Gruß Helmut
 


___
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

[Peter Wendorff]

Danke für den Link,

Fazit: OSM schneidet schon verdammt gut ab. Selbst bei deren eigener
Zählung Co-Sieger; und wenn der Tippfehler nicht gewesen wäre (bei dem
sie durchaus recht haben, was die Benutzerfreundlichkeit angeht), und
wenn sie nicht ausgerechnet den Openrouteservice erwischt hätten als
Routenplaner, dann wäre OSM eindeutig als Sieger daraus hervorgegangen.

Natürlich ist die Stichprobe zu klein - aber ich würde das positiv
sehen: Wir als OSM sind schon verdammt gut mittlerweile. ;)

Gruß
Peter

Am 24.05.2014 21:25, schrieb Andreas Goss:
 http://www.daserste.de/information/ratgeber-service/internet/sendung/wdr/sendung-vom-24052014-100.html

 
 
 ##
 
 Direktlinks:
 
 Alternativen zu Google-Maps: 
 http://www.daserste.de/information/ratgeber-service/internet/sendung/wdr/sendung-vom-24052014-106.html

 
 
 Deeplink: Open Source: 
 http://www.daserste.de/information/ratgeber-service/internet/sendung/wdr/sendung-vom-24052014-110.html

 
 
 
 ___ 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: [OSM-talk] OSM France BANO project... openaddresses in France

[Peter Wendorff]

Hi Christian,
The BANO data is licensed under ODbl, but the database does not conform
to the Contributor terms, right?

That's why importing or adding it to OSM is not possible IMHO.

Adding it to (the osm installation of) nominatim on the other hand is a
bad idea, I think:
IMHO nominatim.openstreetmap.or should rely on OSM as a data source as
pure as possible. Adding different data sets might be useful to add
information not possible or out of scope of the osm database (like
importance factors using the wikipedia links), but BANO is a different
thing.

If the BANO addresses are free and open enough for OSM, we should
encourage to work on bringing them to the OSM database itself (provided,
they are GOOD enough as well). How should anybody in France get
motivation to collect more addresses for the osm database itself, if
anything is available in BANO already?

Nominatim as well as the maps presented by the project on osm.org IMHO
should show the strengths of OSM, and not lie about it by presenting
stuff that's not part of OSM (like addresses from different databases).

regards
Peter

P.S: Of course this is not meant to deal with the software as such, but
for the installations/instances officially part of OSM. Feel free to
set up an BANO nominatim server to show the strength of BANO instead.


Am 24.05.2014 11:57, schrieb Christian Quest:
 I'm happy to announce that we have finished our first building phase of the
 BANO (Base d'Adresses Nationale Ouverte) the first french adresses dataset
 available under an open license (ODbL).
 
 It contains data from:
 - OSM
 - available opendata datasets
 - automatically collected cadastre data
 
 The first experimental dataset are available for download at
 http://bano.openstreetmap.fr/data/ as:
 - shapefiles
 - csv files
 - github projet based on the csv files (this allows to have diff and
 archives of all versions) on https://github.com/osm-fr/bano-data
 
 This dataset has even been published on our national opendata portal:
 https://www.data.gouv.fr/dataset/base-d-adresses-nationale-ouverte-bano
 
 The global database contains around 17M addresses, and the current output
 dataset is around 12M addresses.
 
 It would be really great if this dataset could be added to Nominatim to
 extend its geocoding capabilities in France where we only have around 2M
 addresses currently.
 
 We're not pushing the community to import these data in OSM, but to fill
 the holes in street names first.
 
 
 
 ___
 talk mailing list
 talk@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk
 


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

Re: [OSM-talk] OSM France BANO project... openaddresses in France

[Peter Wendorff]

Hi Christian,
(shortening the last message to comment on some parts only)

Am 24.05.2014 16:04, schrieb Christian Quest:

 BANO is not designed to be used as an import source for OSM.
 It uses sources (opendata, cadastre) that can be imported in OSM.
 These sources have been used over the past years and will still be used to
 add addresses in OSM, one at a time, or street by street which will take
 years before completion.
 
 So, BANO is there to allow to use all the available address data right now
 without having to wait years to get them cleanly added to OSM.
I agree - but why should anybody add the data manually to osm if it's
even not visible any more where data is missing, as in Nominatim both
sources look the same.

 This has one good side effect... reduce the pressure on massive address
 imports in OSM and give us the opportunity to improve the quality thru
 survey prior to add it to OSM.
I agree if you propose BANO as a data source for any private or third
party setup of nominatim or openstreetmap data, but I oppose it to be
used in the projects instances.

Mappers detect errors and missing data while using these instances. I
add missing streets occasionally after I failed to find them in OSM -
using the map renderings, nominatim or other tools.
I wouldn't even detect that they are missing when nominatim would return
the results from another source.

 2014-05-24 12:58 GMT+02:00 Peter Wendorff wendo...@uni-paderborn.de:
 Adding it to (the osm installation of) nominatim on the other hand is a
 bad idea, I think:
 IMHO nominatim.openstreetmap.or should rely on OSM as a data source as
 pure as possible. Adding different data sets might be useful to add
 information not possible or out of scope of the osm database (like
 importance factors using the wikipedia links), but BANO is a different
 thing.

 If the BANO addresses are free and open enough for OSM, we should
 encourage to work on bringing them to the OSM database itself (provided,
 they are GOOD enough as well). How should anybody in France get
 motivation to collect more addresses for the osm database itself, if
 anything is available in BANO already?

 
 I'm pushing the french community to be more motivated on having all streets
 and all streets name in OSM (BANO allowed us to detect 40% missing streets
 or street names) more than adding addresses without surveying them.
Great - but I fear, the availability of third data sources like BANO
through the usual tools destroys motivation again, the motivation get's
an extrinsic one, because the intrinsic need of mappers to get rid of
errors and missing results using OSM is missing due to results returned
out of the BANO data.

 I agree to motivate to collect BETTER address data... it we collect the
 same data with the same quality level it looks to me more losing our time
 than anything else.
Mappers are better than you might think.
Collecting the same data with the same quality level is not possible.
1) the data is checked in reality = so survey on the ground increases
quality with respect to errors.
2) the data is correct at the date of the survey = where it is done
it's more up to date than any imported data, but of course only where it
is done.
3) When a mapper goes out to add streets and house numbers, it's easy to
collect any other stuff where there is no other data source available.
post boxes, benches, vending machines, opening hours, surface of the
streets and much more stuff that increases quality. In contrast
importing data is restricted to the data contained in the data source.

 P.S: Of course this is not meant to deal with the software as such, but
 for the installations/instances officially part of OSM. Feel free to
 set up an BANO nominatim server to show the strength of BANO instead.
 
 In that case remove geonames and TIGER address search from
 osm.org Nominatim instance.

On osm.org Genonames is a different search result set, distinct from
Nominatim, there are two different query results returned.
This is a good way to go, and yes, it might an idea to do the same with
BANO - but that's not what you proposed: it's not adding the BANO data
to Nominatim.

regards
Peter

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

Re: [Talk-de] Hausnummern-Mapping

[Peter Wendorff]

Am 24.05.2014 10:17, schrieb Bernhard Weiskopf:
 Von: Andre Hinrichs [mailto:andre.hinri...@gmx.de]
 1.) Fehlende Hausnummern: 
 
 Manchmal steht die Hausnummer nicht am Haus, sondern nur klein in der Nähe
 des Briefkastens.
stimmt
 
 Oft helfen Internet-Suchmaschinen:
 1. Namen an der Klingel oder am Briefkasten gelesen - Danach suchen
 2. Suche nach vermuteten Hausnummern
 Irgendwo (Telefon-Verzeichnisse oder sonstwo) werden weitere Adressdaten
 damit verknüpft gefunden.
Diese Informationen sind nur meistens entweder falsch oder nicht als
Quelle erlaubt.
Ich weiß - theoretisch kann man hier Einzelfall und damit zu geringe
Menge übernommener Daten annehmen, aber das gälte eben nur im
Einzelfall; Internetsuche als Quelle zu nutzen läuft, auf OSM insgesamt
gesehen, eben doch zu einer Übernahme zu vieler Daten hinaus, und damit
wäre das nicht mehr erlaubt.

Gruß
Peter

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

Re: [Talk-de] Hausnummern-Mapping

[Peter Wendorff]

Einfach Mapping-Spaziergang nach Müllabfuhr-Kalender planen ;)

Gruß
Peter

Am 24.05.2014 12:23, schrieb Michael Reichert:
 Hallo,
 
 Am 24.05.2014 12:18, schrieb simson.gert...@gmail.com:
 Noch ein Geheimtipp:
 Häufig steht die Hausnummer auch auf der Mülltonne (entweder ganz groß
 oder auch als kleiner Aufkleber vom Entsorgungsunternehmen) und kann
 eine vermutete Hausnummer bestätigen.
 
 Wenn man an die Mülltonne einigermaßen legal rankommt (und die nicht
 weit im Privatgrundstück steht, das man nicht betreten darf), wäre das
 eine Option.
 
 Ich glaube aber, dass man beim Mülltonnenmappen noch auffälliger ist,
 als nur mit Klemmbrett oder Smartphone unterwegs zu sein.
 
 Viele Grüße
 
 Michael
 
 
 
 
 ___
 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

[Peter Wendorff]

Am 18.05.2014 15:37, schrieb Wolfgang Hinsch:
 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.
 
 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.
Aber das sind offizielle Namen.
Das Gelände ist dann ein Privatgelände des Kleingartenvereins, der
deshalb die Namenshoheit über die darüber verlaufenden Privatwege hat.
Es gibt auch Städte, in denen 30 Restaurants mit dem Namen McDonalds
existieren - ganz offiziell.

 Gegenargument der meisten Mapper dürfte sein: Dann steht der Name aber
 nicht in der Karte. 
 
 Das ist einerseits Mapping für den Renderer versus Mapping für den
 Router, andererseits On The Ground steht der Name dran, aber er ist On
 The Ground ebenfalls nur gültig im lokalen Bereich, nicht etwa
 gemeindeweit.
Du nimmst hier eine willkürliche Perspektive mit dem Fokus asuf die
Gemeinde an.
International haben wir auch Fernstraßen, die vermutlich mehrfach
vorkommen, und etliches mehr.

 Vielleicht könnte man durch ein Ticket erreichen, dass bei fehlendem
 Name-Tag an Verkehrswegen auf ein loc_name-Tag geprüft und dieses in
 Z17-19 angezeigt wird.
loc_name ist der lokal genutzte Name, aber es wird ja nicht regional
bzw. nicht-lokal dann gar kein Name genutzt. Es geht doch nicht darum,
mit loc_name einen über-lokal genutzten Namen zu vermeiden, sondern eine
Verdrängung dessen zu vermeiden.

Wenn etwas einen Namen hat, sollte es auch in OSM einen Namen haben -
und nicht nur einen official_, log_ oder alt_name.

Gruß
Peter

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

Re: [OSM-talk] OSM France BANO project... openaddresses in France

[Peter Wendorff]

I agree that it's unlikely to drop the share-alike clause in future.
But nevertheless there may be another license, and this has to be
possible even for imports.

In fact, third data sources must agree to be published under ODBL (as
that's the current license) and the owner has in fact to agree with the
Contributor terms, which includes the relicensing term as stated there.

It's not the importing osm user alone who has to agree to the CT, but
the vendor of the imported data as well. If they do, import can be done.
If not, then not.

The contributor terms basically state that anyone who agrees is aware of
and allows the data imported to osm to be relicensed later under some
conditions to any license that fulfills some other conditions.

This IMHO (but I am not a lawyer) includes CC-0 and PD, and as far as I
know includes licenses requiring attribution - with the waiver that
attribution for each contributor may be given indirectly by linking to
the general osm copyright page. It may not include any license with any
additional restrictions.

CC-BY as such allows the licensor to define how attribution must be
given, so it may be okay for imports - or not.
CC-BY-SA without modifications is not okay as the share-alike does not
include any other license (sometimes apart from later versions of
cc-by-sa itself).

regards
Peter

Am 16.05.2014 10:22, schrieb Pieren:
 On Fri, May 16, 2014 at 7:57 AM, Jean-Marc Liotier j...@liotier.org wrote:
 
 We are not going to comply with hypothetical licenses that may or may
 not appear in the future.
 
 +1
 We already get feedbacks from contributors refusing to change the
 share-alike condition. And I cannot imagine that OSM will forbid
 external sources fully compatible with the current licence just for
 the hypothetical case of a possible licence change in the future.
 Or try to change the licence now. It would be interesting to see if
 you will find 2 third of active contributors accepting to remove the
 share-alike attribution.
 Or in a similar way you consider imports and by honesty, inform the
 current contributors that if they don't accept to remove the
 share-alike in the future, they should stop now.
 
 Pieren
 
 ___
 talk mailing list
 talk@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk
 


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

Re: [OSM-talk] This has to stop: User Diaries Spam

[Peter Wendorff]

Hi David,
that's right and that's why I would prefer a good way to moderate the
diaries directly, too.
But nevertheless the value of a spam entry in the diaries is increased
by tools like this because deletion would require deletion at at least
two places.

regards
Peter

Am 15.05.2014 00:33, schrieb David Earl:
 Just to say, @osmblogs is not the diaries, it is just a conversion of the
 osm aggregate blogs RSS feed, using ifttt.com. If spam were not in the RSS
 feed it would not be on twitter either.
 
 David
 
 
 
 ___
 talk mailing list
 talk@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk
 


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

Re: [OSM-talk] Command-line program to remove untagged, unconnected nodes from .osm file

[Peter Wendorff]

Unfortuately you're wrong here, as it does not keep untagged, but
connected nodes.

regards
Peter

Am 14.05.2014 11:16, schrieb Dominik George:
 Hi,
 
 I am trying to find a way to get rid of untagged, unconnected nodes in a
 .osm file. I know JOSM can do this but I need a command-line application.
 I've been trying to do it with osmosis and osmfilter without success
 (pattern *=* not allowed). Any ideas?
 
 If your data file is well-formed, a simple grep will do:
 
   grep -v node .*/
 
 Cheers,
 Nik
 
 
 
 ___
 talk mailing list
 talk@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk
 


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

Re: [Talk-de] 3D-Mapping

[Peter Wendorff]

Am 07.05.2014 18:20, schrieb Thorsten Alge:
 
 Ich wuerde jemanden, der sehr viel Aufwand in Details steckt und auch
 offensichtlich ausreichend Grundwissen beim Editieren besitzt, nicht
 gleich an den Pranger stellen.
 Sonst landen wir in der gleichen Situation wie Wikipedia.

 Sehe ich auch so. Neben Worst-of-OSM wäre ein Art-in-OSM Blog eig. auch
 ganz cool. Diese easter-eggs könnte man meiner Meinung nach ruhig ein
 dreivirtel Jahr belassen - ist ja immer nett über sowas zu stolpern. Und
 einen Export + Screenshot kann man ja dann in dem Blog auch
 längerfristig Archivieren.
 
 Denke so viel künstlerisches Talent sollte man auch positiv würdigen und
 eine Zeit lang belassen. Nur wenn es tatsächlich Probleme bereitet
 sollte man früher agieren.
-10

Diese Easter-Eggs sind nicht immer nur Häuser, sondern gerne auch mal
zusätzliche oder falsche Straßen, nicht routingfähige Strecken oder
sonst was - vorgestern gab es im Chat das Beispiel, wo jemand rund um
ein Haus einen Parkplatz-Weg als Autobahn eingetragen hat, sah hübsch
aus, war aber eben völlig falsch.

Ein dreiviertel Jahr drinlassen bedeutet, dass die Daten für 9 Monate
falsch in der Datenbank stehen, falsch auf der Online-Karte und falsch
im Routing liegen. Dass sie für vermutlich ein weiteres Jahr auf den
meisten Offline-Navis falsch drauf sind, und ein weiteres Jahr auf
gedruckten Karten.
Jeder Tag, den die Daten falsch in der Datenbank stehen, vervielfacht
die Anzahl der offline-Daten, die aus den falschen Daten erzeugt
werden, und nichtmal alle Mapper aktualisieren osmand-Karten und
ähnliches alle paar Wochen.

Gruß
Peter

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

Re: [Talk-de] Mapnik nicht für MOB AC und Oruxmap

[Peter Wendorff]

Hallo tshrub,

die Tile-Usage Policy gibt es schon ziemlich lange, das ist vermutlich
nicht das Problem.
Für Anwendungen, die sehr wenig oder durch sehr wenige genutzt werden,
fällt das aber nicht unbedingt sofort auf, ein Grund, warum Mobac und
Orux maps zunächst bei dir funktioniert haben dürften.

Seitens OSM ist das völlig in Ordnung: Das Projekt sagt zur Nutzung der
Kacheln ganz klar, dass das massenhafte herunterladen nicht erlaubt ist.
Wer da nicht hingehört hat, das sind die Entwickler von Mobac und Orux -
zumindest eben zunächst.
Die sind dann darauf hingewiesen worden und irgendwann wurden die
Anwendungen gesperrt. Würde OSM das nicht tun, wären die Server
irgendwann überlastet oder nicht mehr finanzierbar, weil jeder exzessiv
die Daten nutzen würde wie er möchte.

Insofern: Ja, die Sperre kommt von OSM, aber Nein: nicht unerwartet oder
unangekündigt, und nicht unvorhersehbar.

Was das mit neuen Geräten zu tun hat, weiß ich nicht - die Sperre von
OSM hat jedenfalls nichts mit deinem Gerät zu tun, sondern alleine mit
genau den beiden Programmen.

Zu kurz gedacht ist das - und nimm mir das nicht übel - höchstens von
dir und eben von den Entwicklern der Anwendungen:
Von dir, weil Du dir (bisher) keine Gedanken darüber machst, warum diese
Sperren notwendig sein könnten, sondern dich gleich bei OSM beschwerst
(die Apps wären die richtigere Anlaufstelle, obwohl dir hier sicher auch
geholfen wird, wenn jemand helfen kann und du konkrete Fragen stellst -
z.B. hast du schon einen Grund für die Fehlfunktion deiner Anwendung und
eine mögliche Lösungsstrategie (update) gekriegt).
Von den Entwicklern der Anwendung, weil sie nicht mit so großen
Nutzerzahlen gerechnet haben ursprünglich - oder, weil sie die Usage
Policy bewusst ignoriert haben.

Zu kurz gedacht von OSM wäre, wenn jeder Tiles in beliebiger Menge
herunterladen könnte; denn dann bestünde die Möglichkeit, dass die
Server für niemanden mehr bezahlbar bliebe, was im Endeffekt schlimmer
ist als ein paar Anwendungen auszusperren, die sich meinen über Regeln
hinwegsetzen zu können.

Gruß
Peter

Am 30.04.2014 10:52, schrieb tshrub:
 Am 30.04.2014 08:42, schrieb Simon Poole:


 Am 30.04.2014 02:45, schrieb tshrub:
 ...
 Kennt jemand ggf. eine Möglichkeit, Mapnik in o.g. wieder nutzen zu
 können?

 Aktuelle Versionen der Apps zu nutzen.

 Alte Version der Apps sind gesperrt weil Sie sich nicht an die tile
 usage policy gehalten haben,
 logisch ... die gabs wohl noch nicht so
 
 
 IMHO sollen bei den beiden erwähnten
 Programmen das bei neueren Version behoben sein.
 beim MOB AC habe ich ein Update gemacht - ohne Ergebnis bzgl.
 Problems. Vielleicht müsste man ihn einmal komplett inkl. Einstellungen
 von der Platte löschen ...
 
 Allg. ist das aber Seitens OSM nicht ok. Kommt der Dongel nicht von da?
 Wieso sehe ich nicht, was ich online sehe kann auf den Geräten?
 Das lief doch vorher. Wieso wird man gezwungen, neue Geräte zu kaufen?
 M.E. hier zu kurz gedacht.
 
 Gruß, t.
 
 
 
 



 ___
 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 mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

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

[Peter Wendorff]

Nochmal hallo.

Nachdem die Diskussion ja doch nicht so eindeutig verläuft wie ich
zunächst erwartet hätte (gegen die Übersetzung des Wortes Tag bzw.
Tags, hier noch ein paar weitere Argumente:

- Das Wiki ist teilweise übersetzt, normalerweise wird aber auch hier
und auch auf den deutschsprachigen Seiten der Begriff Tag verwendet,
soweit ich das sehe. Da damit die primäre Dokumentations-Resource für
Mapper keine Übersetzung verwendet, sollte IMHO auch eine Software wie
JOSM keine Übersetzung verwenden.
- Im Gespräch mit anderen Mappern - ob im Chat, im Forum, auf den
Mailinglisten oder anderswo wird üblicherweise das Wort Tag einfach
genutzt. Zugegeben: Das sind meist Mapper, im Durchschnitt vermutlich
auch eher erfahrenere - trotzdem sind Anfänger auch hier mit dem Wort so
konfrontiert.

Deshalb halte ich die Übersetzung für falsch. Die Fachsprache von OSM
existiert, und sie gezielt vor Anfängern zu verstecken hilft meines
Erachtens nicht. Wenn sie tatsächlich die Einstiegshürde verringern
sollte (möglich, aber ich würde nicht darauf wetten), dann wird die
Hürde zwischen Anfänger und Fortgeschrittenem entsprechend höher.

Gruß
Peter

Am 27.04.2014 13:59, schrieb Frederik Ramm:
 Hallo,
 
gerade ist mir aufgefallen, dass mein JOSM, wenn ich ihn auf Deutsch
 einstelle, die Tags neuerdings als Schlagwörter bezeichnet.
 
 Findet irgendjemand das gut (bzw. findet irgendjemand das besser als
 Eigenschaften)? Gibt es irgendwo, unabhängig vom konkreten Fall JOSM,
 einen Konsens oder zumindest eine Diskussion dazu? Gibt es andere
 Software oder Dokumentation im OSM-Umfeld, in der Tags als
 Schlagwörter bezeichnet werden?
 
 Bye
 Frederik
 


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

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

[Peter Wendorff]

Hi,
ist mir bisher noch nicht aufgefallen, aber halte ich für irreführend.
Tags im Allgemeinen können Schlagwörter sein, in OSM sind sie mehr als
das, sie sind Attribute.
Ein Schlagwort ist eben keine Eigenschaft, kein Attribut, sondern eher
eine Assoziation, ein Suchbegriff oder ähnliches.

Das Ziel in OSM wäre ja im Grunde eine eindeutige Beziehung Tag(s) -
Eigenschaft(en), wo man also aus den Tags Eigenschaften der Realität
ableiten kann und andersherum aus der Realität die
notwendigen/sinnvollen Tags ableiten könnte.

Wären Tags Schlagworte, dann wäre beide Richtungen dieser Beziehung
undeutlicher als sie sein sollten.
In der Realität sind manche Tags so schwammig definiert oder so
schwammig interpretiert, dass der Begriff schon fast stimmt - aber das
sind schnell genau die Diskussionsfälle, die schwieriger anzuwenden und
noch schwieriger zu mappen sind, wenn man gute OSM-Daten erzeugen will.
Insofern halte ich Schlagwort für die denkbar falsche Angabe, erst Recht
im Editor, wo es falsche Vorstellungen gerade bei unerfahrenen Mappern
wecken könnte.

Gruß
Peter

Am 27.04.2014 13:59, schrieb Frederik Ramm:
 Hallo,
 
gerade ist mir aufgefallen, dass mein JOSM, wenn ich ihn auf Deutsch
 einstelle, die Tags neuerdings als Schlagwörter bezeichnet.
 
 Findet irgendjemand das gut (bzw. findet irgendjemand das besser als
 Eigenschaften)? Gibt es irgendwo, unabhängig vom konkreten Fall JOSM,
 einen Konsens oder zumindest eine Diskussion dazu? Gibt es andere
 Software oder Dokumentation im OSM-Umfeld, in der Tags als
 Schlagwörter bezeichnet werden?
 
 Bye
 Frederik
 


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

Re: [Talk-de] Mapnik ohne Richtungspfeile

[Peter Wendorff]

Dieses ewige Gejammere geht mir auf den Sack, sorry.

Im alten Stil wurden ähnlich wie jetzt immer wieder neue Wünsche
geäußert: Bitte dies darstelle, bitte jenes darstellen.
Das Einarbeiten dieser Wünsche wurde denen, die es überhaupt tun, zu
kompliziert, weil die Stildateien immer größer und unhandlicher wurden.

Es hätte also drei Möglichkeiten gegeben:
1) Jemand anderes hätte die Arbeit übernommen - das ist zumindest sehr
lange nicht passiert
2) Der Stil wäre einfach nicht mehr geändert worden (damit hätten wir
das gleiche Problem wie jetzt bei jedem neuen Tag oder Taggingschema)
3) Man packt das ganze neu an und macht dabei diverse Dinge sauberer und
aus dem Grunde auf Dauer besser handhabbar.

Da (1) und (2) nicht passiert ist, sich aber jemand an (3) herangewagt
hat, gibt es jetzt also einen neuen Stil, an dem lange gearbeitet wurde,
bevor er öffentlich sichtbar gemacht wurde, und der erstaunlich nah am
alten Layout dran ist.

Der Wechsel ist vom August 2013. Seitdem sind laut GitHub 500
Fehlermeldungen und Verbesserungsvorschläge eingereicht und davon über
die Hälfte erledigt worden, immerhin von einer Reihe von Leuten, vn
denen insbesondere Andy (gravitystorm) und dann mit großem Abstand
math1985 aktiv sind.

Die Stile sind - insbesondere technisch gesehen - nicht identisch. Das
ist gewollt und richtig so.

Früher wurde der name-Tag immer dargestellt. Wenn Platz auf der Karte
ist und ein Objekt einen Namen hat, dann zeige den Namen.
Um dann gezielt zu sagen: Aber Namen von Parkbänken sollen eben gerade
nicht dargestellt werden, weil die (außer vielleicht in z19) sonst alles
andere verstecken, hätte man das sozusagen ändern müssen in Zeige alle
Namen, solange die nicht zu einer Parkbank gehören. Aus einer einfachen
Regel wird bei ein paar Dutzend solcher Ausnahmen dann schnell ein
schwerfälliges, langsam berechnetes etwas, und herauszufinden, wo man
eine Änderung einpflegen muss, ist schwer.

Stattdessen ist viel Arbeit reingesteckt worden, um ein möglichst
ähnliches Kartenbild andersherum zu erreichen:
Statt: Rendere alle Namen außer [lange liste von ausnahmen] soll also
jetzt da stehen Rendere namen von [lange liste von Dingen, deren Namen
dargestelllt werden müssen - und, was noch besser ist: das lässt sich
jetzt shcön aufteilen in mehrere Regeln:
Rendere Namen von Grenzen schön jeweils 'innen',
Rendere Namen von Geschäften
Zeige Hausnummern in Schriftart X und Größe Y, Geschäfts-Namen aber in
X und Größe W

und so weiter.

Das macht das Pflegen des Stils einfacher, aber neben der Frage: was
lässt man bewusst weg (und guckt mal, ob jemand hinterher danach fragt),
ist die Umformulierung nicht so einfach, denn Rendere alles außer...
erfordert nur ein Wissen über die Ausnahmen, während Rendere genau...
voraussetzt, dass man letztlich jedes Tag, das man darstellen will,
kennt und angeben kann.

Insofern ist gewollt, gut und richtig, dass wir alle Auffälligkeiten wie
fehlende Beschriftungen etc. melden und mitteilen. Sich aber zu
beschweren, vorher sei alles besser gewesen setzt meiner Meinung nach
voraus, das zu beweisen. Ich vermute, der alte Mapnik-Stil ist heute
langsamer in der Darstellung (ganz wage Vermutung aus den mir bekannten
technischen Unterschieden, was Datenbank-Abfragen angeht), und er ist
bestimmt in 'nem halben oder ganzen Jahr auch besser als der alte.

Nein: Die Maintainer des alten Stils wollten nicht mehr daran
weiterarbeiten und hätten das vermutlich auch nicht mehr besonders aktiv
gemacht. Um also die Behauptung aufzustellen, dass der neue Stil
dauerhaft schlechter ist als der alte, und euch damit die Rechtfertigung
zu verdienen, möglicherweise zu meckern, bitte ich dann darum, Fehler im
alten Stil zu korrigieren - der Code ist auch da frei verfügbar.

Ansonsten: Fehler finden ist gut, Fehler melden auch - dafür gibt's den
Bugtracker bei Github; Fehler laut an alle rauszuschreien aber nicht da,
wo sie behoben werden könnten, hilft aber kaum, sorry.

Gruß
Peter


[1] https://github.com/gravitystorm/openstreetmap-carto/graphs/contributors

Am 24.04.2014 21:56, schrieb Dirk Sohler:
 Holger Jeromin schrieb:
 http://bl.ocks.org/tyrasd/raw/6164696/#17.00/50.75168/6.02481

 Vorher war die Grenzbeschriftung total nutzlos, jetzt sehr hilfreich.
 
 Also entweder gut beschriftete Grenzen und komplett unbeschriftete
 Tunnel, oder beschriftete Tunnel und eher schlecht beschriftete Grenzen.
 
 … und ein Stück weiter oben das Labyrinth und die Taverne sind auch
 unbeschriftet. Nur wegen schönen Bäumen und grenzen Lohnt das imho
 nicht bei all den Nachteilen.
 
 Grüße,
 Dirk
 
 
 
 ___
 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] Mapnik ohne Richtungspfeile

[Peter Wendorff]

Am 25.04.2014 09:53, schrieb Andreas Labres:
 On 23.04.14 21:42, Peter Körner wrote:
 Das kann man halt auch anders formulieren: An wie viele Objekte wurde kein
 name eingetragen (sondern note, description, ...), weil's auf der Karte doof
 ausschaute. 
 
 Schon, aber name ist definiert als der /darzustellende/ Name. 
? Wo ist das so definiert?

Ich versuch mal aus dem Wiki zu zitieren:

[1]: To provide details of the name for a feature included in
OpenStreetMap. - nix mit Darstellung,
[1]: Key name: The common default name. (Note: For disputed areas,
please use the name as displayed on e.g. street signs for the name tag.
- auch da steht nichts von Darstellung für die Karte.

Deutsche Seite zum Key Name:
[2] Der Schlüssel name dient dazu, den Namen eines Objekts in
OpenStreetMap anzugeben - auch da steht nichts zur Beschriftung eines
Objekts in der Karte, sondern es geht um den Namen des Objekts.
[2] Key name: Die allgemeine Bezeichnung - halte ich für zu schwammig
übersetzt und zu leicht falsch zu interpretieren, aber trotzdem steht
auch hier nichts von der Darstellung oder dem darzustellenden Namen.

Aber da Namen ja wirklich eine komplexere Sache sind, gibt es ja noch
die allgemeine Seite zum Thema, auch da wieder Englisch [3], Deutsch [4]
und andere:

[3] sagt: We use name=* to tag the name of things. We tag names of
roads, pubs, railway stations, parks, buildings and anything which has a
name. See more at Map Features#Name -nix mit Darstellung.
[3] stellt außerdem klar, dass keine Abkürzungen verwendet werden sollen.
[3] sagt ganz deutlich: Name is the name only. The names should be
restricted to the name of the item in question only and should not
include categories, types, descriptions, addresses or notes. If
something really doesn't have a name, don't add one to OpenStreetMap.,
und hier kommen wir zum Kern des Problems: ein Name ist ein Name ist ein
Name - keine Beschreibung, keine Bezeichnung, um beschreibend auf etwas
zu verweisen, sondern ein Name.

 Insofern ist's
 schon ok, dass ein Renderer, der möglichst alle Namen darstellen will (so 
 Platz
 ist), die dann eben auch darstellt. Und wenn's ein Name sein soll, der
 definiert, aber nicht dargestellt werden soll, gibt's dafür z.B. loc_name 
 (IMO).
Wer sagt denn so 'nen Blödsinn?
loc_name ist für den lokal bekannten Namen. Wenn ich eine Karte von
meinem Dorf machen möchte, will ich den loc_name darstellen - zusätzlich
oder statt des überregional bekannten, und genau dafür ist der da.
Entscheidet doch bitte nicht beim Mappen, wie ihr Dinge dargestellt
sehen wollt, entscheidet, was ihr da eintragt. Wenn ihr den Namen
eintragt, gehört der in name. Wenn es zusätzlich(!) einen lokal
verwendeten Namen gibt, gehört der in loc_name; wenn es zusätzlich
einen internationalen Namen gibt, dann kommt der in int_name - und so
weiter.
Deine Aussage: ...wenn's ein Name sein soll, der definiert, aber nicht
dargestellt werden soll,... vermischt die Zuständigkeiten: Wenn Du auf
die Darstellung Einfluss nehmen willst, beteilige dich am Render-Stil,
wenn Du mappen willst, mappe die Tatsachen.
Es gibt beim Mappen immer auch Entscheidungen zu treffen, was korrekt
ist und was nicht. Die Darstellung in EINER oder einer Handvoll Karten
ist jedenfalls keine, die meines Erachtens gültig ist.
 
 Vielleicht ein blödes Beispiel, aber POIs, für die der Renderer (konkret
 osm.org) kein Icon hat, stellt er
 * wenn er eine Adresse hat mit der Hausnummer
 * wenn nicht, dann nicht
 dar. Führt dann dazu, dass in einer Mall oder Einkaufsstraße zig mal die
 Hausnummer steht... Wäre es nicht sinnvoll, wenn dort wenigstens die Namen 
 stünden?
Für Geschäfte ja, aber das führt dann zu einer sinnvollen Regel, Stelle
Namen von shop=* grundsätzlich dar, nicht zu Stelle alle Namen dar.

Stell dir vor, diese Mall hat aus einer Laune heraus aufgestellte Bänke
alle benannt. Diese Namen werden von niemandem benutzt, nicht zur
Orientierung verwendet und gar nichts, sie stehen aber auf kleinen
Schildern an der Bank (und sind in dem Fall mal nicht die Widmung, die
es ja oft gibt, aber die kein Name ist).

Wäre es nicht sinnvoll, in der Mall alle Namen von Geschäften, aber eben
gerade keinen Namen von Bänken zu sehen?
Bei unserer Renderertechnik würden alle Namen zudem meist dazu führen,
dass einige zufällig weggelassen würden - aus Platzgründen. Willst Du
die Karte dann wirklich ein paar Bänke mit Namen anzeigen lassen, die
Läden nebenan aber nicht - nur weil da der Zufall und die genaue
Platzierung in Kombination mit evtl. der Objekt-ID (wegen der
Reihenfolge, in der Objekte durch den Renderer verarbeitet werden) das
so entschieden hat?

Sorry, aber meldet doch einfach Features, deren Namen dargestellt werden
sollen - aber an der richtigen Stelle, und ohne Gejammer, dass die da
oben beim Style-Code immer alles schlechter machen würden.

Gruß
Peter

[1] http://wiki.openstreetmap.org/wiki/Name
[2] http://wiki.openstreetmap.org/wiki/DE:Key:name
[3] http://wiki.openstreetmap.org/wiki/Names
[4] 

Re: [Talk-de] Mapnik ohne Richtungspfeile

[Peter Wendorff]

Am 25.04.2014 11:52, schrieb Martin Koppenhoefer:
 
 
 Am 25/apr/2014 um 10:25 schrieb Peter Wendorff
 wendo...@uni-paderborn.de:
 
 The names should be restricted to the name of the item in question
 only and should not include categories, types, descriptions,
 addresses or notes. If something really doesn't have a name, don't
 add one to OpenStreetMap.,
 
 
 wobei das manchmal auch mMn zu restriktiv gesehen wird, z.B. bei
 Restaurants, da ist der Name oft einschl. einer Kategoriebezeichnung
 (zBGasthaus zum Ochsen und nicht nur (je nach Fall kommt das zwar
 auch vor) zum Ochsen). Macht ja auch keinen Sinn, z.B. name=für
 angewandte Kunst zu taggen, wenn es name=Museum für angewandte
 Kunst heißen sollte. 
Beim Gasthaus zum Ochsen kann ich mir beides vorstellen - sowohl, dass
das Gasthaus zum Ochsen heißt als auch, dass es Gasthaus zum Ochsen
heißt.
Ein Museum für angewandte Kunst, das irgendwo den Namen für
angewandte Kunst trägt, musst Du mir zeigen (in dem speziellen Fall
würd ich es dem Museum als angewandte Kunst durchgehen lassen, beim
Museum für Völkerkunde würd ich die Verantwortlichen des Namens für
Völkerkunde mal zum Psychiater schicken.


 Bei Ministerien, Museen oder Universitäten
 lässt das kaum einer weg, bei Restaurants und Cafés aber öfters.
Die Universität Paderborn heißt aber auch Universität Paderborn - und
nicht Universität, und die Leipniz Universität Hannover heißt auch
nicht Leipzig oder Leipzig Hannover, sondern genau so: Leipniz
Universität Hannover.

Eine Kneipe kann auch einfach Die Kneipe oder Kneipe heißen - aber
nur weil es eine Kneipe ist, heißt sie noch nicht so - und auch nicht,
weil die Säufer um die Ecke eben in die Kneipe gehen.

Trotzdem ist ein Name ein Name, und nicht eine Bezeichnung, die man zur
Kommunikation nutzt. Manchmal ist das nicht eindeutig, manchmal ist es
nicht so richtig gut vor Ort zu erkennen - aber gegen Fehler sagt ja
auch niemand was.

Ich gebe dir recht: manchmal wird das zu restriktiv gesehen, ABER ich
schränke das ein: manchmal wird zu viel nachträglich als Fehler
behandelt und der entsprechende Mapper dementsprechend angeschrieben.
Die Grundsätze, was ein Name ist, sollten wir dagegen eher zu restriktiv
als zu offen beschreiben - zusammen mit der zwangsläufigen
Interpretation von Mappern kommt dann eher was sinnvolles dabei raus,
als wenn man alle Toleranzen direkt offiziell erlaubt (beachtet die
Anführungszeichen).

Gruß
Peter

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

Re: [OSM-talk] Labeling Features

[Peter Wendorff]

Hi again,
yes, ignore them.
JOSM warns about nearly everything - especially anything that might be a
common mistake.
If you would edit in your home town you would know the labels, and as
they are very important information, josm asks you to add them.
But if you're not able to, just ignore it.

The same holds for other warnings as well, but make sure you know what
JOSM talks about as sometimes it's useful to spot errors you made before.

regards
Peter

P.S.: I don't know how, but you managed to send your response to the
talk-list address. For others: see Khushdeeps missing mail below.

Am 15.04.2014 04:37, schrieb khushi malhotra:
 Hi Peter,
 
 Thanks for your reply. To follow up, when I try to upload the completed
 task, I get a warning message under the Validation Results tab in JOSM,
 which says no labels have been provided for the  I digitized. Should I just
 ignore these messages and continue to upload?
 
 Thanks,
 Khushdeep
 
 
 On Mon, Apr 14, 2014 at 3:15 PM, Peter Wendorff
 wendo...@uni-paderborn.dewrote:
 
 Hi Khushdeep,
 welcome to OSM.
 There is no information about street names and such in aerial imagery.
 Tracing from imagery is therefore done when you got the information out
 of the images. Labels are not part of these tasks.

 Of course if you were there, mapping as a local, not remotely, you
 should of course add as much information as possible, especially street
 names and so on, but as a remote mapper this is usually impossible and
 for that reason not part of the tasks.

 Perhaps the HOT guidelines should be adjusted if they don't make that
 clear.

 regards
 Peter

 Am 14.04.2014 21:00, schrieb khushi malhotra:
 Hi everyone,

 I am new to HOT, and I tried to complete one of the mapping tasks for the
 CAR region. Here is my question:

 I digitized a few roads and buildings, but I did not understand where to
 get information to label the digitized features, as I did not see any
 labels for roads or buildings on the imagery data (which I expected would
 have them). I did not want to mark the task as completed without first
 labeling the features correctly. Where can I get this information? I use
 Bing, OSM and MapQuest Aerial.

 I've checked OSM documentation, but I am unable to find the answer.
 Please
 pardon my ignorance!

 Thanks for your feedback!
 Khushdeep



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



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

 


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

Re: [OSM-talk] Labeling Features

[Peter Wendorff]

Hi Khushdeep,
welcome to OSM.
There is no information about street names and such in aerial imagery.
Tracing from imagery is therefore done when you got the information out
of the images. Labels are not part of these tasks.

Of course if you were there, mapping as a local, not remotely, you
should of course add as much information as possible, especially street
names and so on, but as a remote mapper this is usually impossible and
for that reason not part of the tasks.

Perhaps the HOT guidelines should be adjusted if they don't make that clear.

regards
Peter

Am 14.04.2014 21:00, schrieb khushi malhotra:
 Hi everyone,
 
 I am new to HOT, and I tried to complete one of the mapping tasks for the
 CAR region. Here is my question:
 
 I digitized a few roads and buildings, but I did not understand where to
 get information to label the digitized features, as I did not see any
 labels for roads or buildings on the imagery data (which I expected would
 have them). I did not want to mark the task as completed without first
 labeling the features correctly. Where can I get this information? I use
 Bing, OSM and MapQuest Aerial.
 
 I've checked OSM documentation, but I am unable to find the answer. Please
 pardon my ignorance!
 
 Thanks for your feedback!
 Khushdeep
 
 
 
 ___
 talk mailing list
 talk@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk
 


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

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

[Peter Wendorff]

Hi,
im Prinzip eine Möglichkeit - aber funktioniert die unterschiedliche
Farbgebung für unbekannte Sportarten vernünftig, was die Erkennbarkeit
auf der Karte angeht?

Mit eingezeichneten Linien ist ein Fußballplatz bzw. ein Tennisplatz
jeweils als solcher erkennbar; aber ohne?
Bei unbekannten oder nicht unterstützten Sportarten sind Sportplätze
jetzt auch noch farblich unterschieden. Zumindest sollte dann ein
Sport-Icon drauf oder sowas in der Art.

Gruß
Peter

P.S.: Irgendwelche Einwände,  Rugby/Football-Diamanten auch mit Linien
einzuzeichnen? Ja, das wäre nochmal spannender in Sachen Ausrichtung ;)

Am 08.04.2014 12:26, schrieb Sven Geggus:
 Holger Jeromin mailgm...@katur.de wrote:
 
 Hat einen Aschefussballplatz, der wird leider nicht rotbraun
 gerendert :-)
 
 Hm, die Regeln sehen so aus und sind unverändert aus dem
 französischen Stil übernommen:
 
 Style name=sports-surface filter-mode=first Rule 
 maxscale_zoom16; Filter([angle_diff] gt; 85) and ([angle_diff]
 lt; 95) and ([sport] = 'soccer') and ([surface] = 'grass')/Filter 
 PolygonSymbolizer fill=#54a854 / /Rule Rule 
 maxscale_zoom16; Filter([angle_diff] gt; 85) and ([angle_diff]
 lt; 95) and ([sport] = 'tennis') and ([surface] = 'grass')/Filter 
 PolygonSymbolizer fill=#54a854 / /Rule Rule 
 maxscale_zoom16; Filter([angle_diff] gt; 85) and ([angle_diff]
 lt; 95) and ([sport] = 'tennis') and ([surface] = 'clay')/Filter 
 PolygonSymbolizer fill=#cc7e66 /
  /Rule /Style
 
 Vielleicht sollte man das einfach in soetwas umändern:
 
 Style name=sports-surface filter-mode=first Rule 
 maxscale_zoom16; Filter([angle_diff] gt; 85) and ([angle_diff]
 lt; 95) and ([surface] = 'grass')/Filter PolygonSymbolizer
 fill=#54a854 / /Rule Rule maxscale_zoom16; 
 Filter([angle_diff] gt; 85) and ([angle_diff] lt; 95) and
 ([surface] = 'clay')/Filter PolygonSymbolizer fill=#cc7e66 /
  /Rule /Style
 
 Dann wäre die Sportart egal.
 
 Gruss
 
 Sven
 


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

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

[Peter Wendorff]

Am 03.04.2014 16:38, schrieb chris66:
 Am 03.04.2014 10:01, schrieb Manuel Reimer:
 
 Was mich daran stört: Ich hätte gerne die normale Straßenlinie erhalten.

 Ist highway=pedestrian auf die Fläche überhaupt korrekt? Darf die Fläche
 an die zuführenden Straßen angeschlossen sein? 
 
 Sie muss angeschlosssen werden, sonst funktioniert das Routing nicht
 mehr. Geroutet wird übrigens
...bei allen momentan bekannten auf OSM-Daten eingesetzten Routern
 am Rand der Fläche entlang.
Ein Routing über Plätze wäre denkbar, Algorithmen existieren dafür (aus
anderen Bereichen).
Auch ein entsprechendes Preprocessing, das aus Plätzen für den Router
Kreuzungen macht, ist durchaus im Rahmen des Möglichen.

 Kann ich den Wegverlauf
 einfach als weiteres highway=pedestrian in Form einer Linie oben
 drüberlegen? Wo gehört dann der name dran?
 
 Ist unschön, aber verbessert das Routing.
Wir taggen nicht falsch für den Router! (genausowenig wie für's Rendering).

Eigentlich müsste man das gerade bei Plätzen konsequent durchziehen,
jedenfalls überall da, wo keine eindeutigen Wege über den Platz
existieren (Rinnstein links und rechts der Fahrbahn oder ähnliches).

Nur so wird irgendwann ein Router-Entwickler anfangen, sich darum zu
kümmern.

 Wichtig: Fläche mit Linie verbinden, sonst gibt
 es Routing-Inseln.
Richtig.
 
 Den Namen würde ich an die Linie machen.
Die Frage halte ich generell für die schwierigste dabei.
Wenn die Marktstraße über den Marktplatz führt, gebe ich dir recht.
Wenn die Marktstraße durch den Marktplatz unterbrochen wird, dann nicht
(und dann ist eine Linie über den Marktplatz auch nicht auf einmal
Marktplatz).
Wenn die Marktstraße zum Marktplatz führt und die Rathausstraße auf der
anderen Seite weitergeht - welchen Namen würde bei dir dann die Linie
bekommen?

KORREKT ist die Linie nur, wenn sie als Straße existiert (und zwar
unterscheidbar vom Platz; bei Fußgängerzonen oft nicht der Fall).

Gruß
Peter

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

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

[Peter Wendorff]

Am 03.04.2014 21:16, schrieb Martin Koppenhoefer:
 
 
 Am 03/apr/2014 um 18:48 schrieb Peter Wendorff
 wendo...@uni-paderborn.de:
 
 Wir taggen nicht falsch für den Router! (genausowenig wie für's
 Rendering).
 
 
 yep, richtig allerdings schon auch für den Router. Wieso hältst Du
 das für falsch? 
Gegen eine existierende (!) lineare Spur über den Platz habe ich nichts,
das würd ich auch eintragen - also wenn die z.B. markiert ist, durch
Bordsteine, Rinnsteine, Straßenmarkierung etc.

Falsch halte ich es, wenn es sich um offene Plätze handelt, bei denen
Autos eben einfach nur die gerade Linie zwischen Ein- und Ausgang
nutzen, ohne dass dies vorgeschrieben oder markiert wäre - gerade beim
Marktplatz in der Fußgängerzone durchaus denkbar und üblich.
 Wie tagst Du dann ohne linearen way eine
 Einbahnstraße in der Fußgängerzone?
Wenn es eine Einbahnstraße ist, dann gibt es üblicherweise auch einen
definierten Fahrweg und der kann als solcher ja auch wie üblich
eingetragen werden.
Ist aber die Durchfahrt verboten oder nur für Lieferverkehr erlaubt,
gibt es einen solchen Fahrweg z.T. eben nicht, sondern der Platz ist
bzgl. der Nutzung durch Fahrzeuge auf der ganzen Fläche gleichwertig,
dann ist eben auch ein Weg drüber in OSM fehl am Platz, der in dem Fall
nämlich nur den Router zufriedenstellt, der die direkte Verbindung
zwischen Ein- und Ausfahrtspunkt dann nicht berechnen muss, sondern
vorgekaut kriegt.

Gruß
Peter

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

Re: [OSM-talk] Foursquare and OSM Note Instructions

[Peter Wendorff]

Hi,
IMHO missing stuff is some kind of error and it might be correct to
store that information in a note.
But it's more complex than just add a note and we'll do the rest.

Adding a note even as a personal note for adding it later is a valid
action, if e.g. don't have the time to do more now or don't have an
editor at hand - provided I'm going to resolve that myself later.

Adding a note that something is missing in some place is valid, if I
know that there's something missing, but don't exactly know where it is
(only very rough location, only know that there's one shop missing, but
don't know any details yet,...). Here the note is a temporal thing to be
replaced after an on-the-ground visit.

Adding a note where adding the feature itself is too complex for my own
experience (e.g. holes in buildings missing (multipolygons), route
relations with missing detours...) is valid.

What's not wanted - but better than nothing - are examples like the ones
you refer to in your later mail: here is address x, here's my
business: foo-store, ..., these should be as simple to be added
directly as to add the note, and therefore yes, it would be better the
people would add them directly to the osm database instead.

On the other hand it depends...
OSM has lot's of contributors joining osm, adding their own business as
a single-node item, and never doing more.
If we motivate these people to add more stuff around, e.g. to improve
routing to their business, to get a better looking map around their
business or something like that it's great, but if we have more mappers
that don't come back at all, why should that be preferred over adding a
note, that there's a business missing?
I prefer a note over a florist mapped as supermarket, as it's easier to
solve the note (if all necessary information is included) than to find
errors in wrong data like that.

tl;dr: it's not as easy as to say register and add yourself, it's more
complex, but missing stuff is an error in OSM, something that has to be
fixed and in general *might be* valid use cases for an osm note.


regards
Peter

Am 28.03.2014 03:50, schrieb Jason Ward:
 Hi Team,
 
 I've been doing some SuperUser edits in 4sq recently and poked my head into
 the OSM page they hold on their site (https://foursquare.com/about/osm) and
 its slightly at odds with the messaging I have been using when resolving
 notes I have deemed as irrelevant to use and I thought I'd clarify with
 this group to see whether I need to:
 
 a) Adjust my messaging when resolving notes [1]; OR
 b) Don't resolve notes that indicate something should be added or is an
 ommission; OR
 c) Ask 4sq to amend their copy to better reflect OSM Note usage.
 
 So.  The OSM Wiki [2] for notes indicates in its first para that notes are
 for errors and I have taken that quite literally when assessing notes and
 in resolving something that is missing from OSM I have indicated that
 notes are for errors.  My behaviour may be having a negative effect on
 these note authors coming from 4sq so I'm keen to ensure I don't
 unecessarily turn people away from OSM if I shouldn't be.
 
 Any thoughts here?  Is the first para in the OSM Wiki at odds with the Dos
 and Don't section on the same page?  One suggests errors and the other
 suggest errors and missing information.
 
 
 [1]: I usually resolve Notes with Business Details suggesting that they are
 for Errors rather than Ommissions.
 [2]: http://wiki.openstreetmap.org/wiki/Notes
 
 
 Cheers,
 
 Jason
 
 
 
 ___
 talk mailing list
 talk@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk
 


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

Re: [OSM-talk] Foursquare and OSM Note Instructions

[Peter Wendorff]

Well, it's not errors only, but notes of course.
My argument goes into: it might be useful to add a note *about* an
error, too.
It's best to fix errors immediately, of course; but it's better to
document them for later to fix than to do nothing and forget about it.

Therefore notes are like an issue tracker, containing tasks to be done
(like resurvey at arrival of new imagery), bugs to fix (like shop has
been closed; intersection is a roundabout now,...) and enhancements
(here the business X is missing).
Anything fits into notes as it would fit into an issue tracker; but like
in an issue tracker it's best t solve issues directly, which might even
make opening the issue in the tracker (opening the note in osm) obsolete
at all.

The Foursquare (and similar) case for trivial notes like business
missing here is address X is like a typo in a UI translation file of
a software: it is more easy to fix it than to file an issue - at least,
when you have an account already and know how to use the tools.

Our own todo list is perfect to add to the notes - but it requires to
write notes in a way that others can understand, because it's a PUBLIC
issue tracker. The same way I can add my personal tasks in a software
project to the global issue tracker I can do it with notes, too - it
must be clear what is to be done, and it should not be more work with an
issue tracker than it would be without.

regards
Peter

Am 28.03.2014 10:03, schrieb Jóhannes Birgir Jensson:
 Perhaps it is because English is not my native language but I understand
 a Note to be a comment, whether about missing data or wrong data or in
 fact, as I've sometimes done, a note about imagery missing for a future
 imagery refresh.
 
 I mapped my hometown last summer and one part of it was missing good
 imagery, so I added a note there (a cluster of 3 newly built streets)
 which was something like imagery missing - resurvey when updated which
 I then resolved a few weeks back when I noticed the imagery had been
 updated for that part. Thus these notes form a sort of to-do list where
 the doing can't be done at this point in time.
 
 It is quite curious to name them Notes when they are then understood to
 be Errors. Or are they Notes?
 
 --Jói
 
 Þann 28.03.2014 08:32, JB reit:
 Err, some thoughts after some heavy note-closing in France.

 Le 28/03/2014 09:14, Peter Wendorff a écrit :

 Adding a note even as a personal note for adding it later is a valid
 action, if e.g. don't have the time to do more now or don't have an
 editor at hand - provided I'm going to resolve that myself later.
  Dos and don'ts section does not validate this in the wiki : « Don't
 use it to put your personal notes here. ». Rather use personal stuff
 like gpx files or whatever. Many personal notes just get forgotten
 (where is this filtering tool showing _my_ notes? Ha, doesn't exist, I
 forgot…)

 Adding a note that something is missing in some place is valid, if I
 know that there's something missing, but don't exactly know where it is
 (only very rough location, only know that there's one shop missing, but
 don't know any details yet,...). Here the note is a temporal thing to be
 replaced after an on-the-ground visit.
  Sure, but I've never seen an answer to a note asking for
 re-surveying, excepted for the creator when asked for details. In my
 opinion, just congesting the database.

  Don't want to go too fast, as I presenting some work done on notes
 in France at SotM-FR next week-end, but forecast some additional info
 on my diary page afterwards.
  JB.

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


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

Re: [Talk-de] OSM-Blog ist manchmal schwierig zur verfolgen ;-)

[Peter Wendorff]

Vielleicht sollte man den Twitter-Bot an der Stelle abschwächen und
moderieren, so dass neue User erst eine Twitterfreigabe kriegen nach
Prüfung durch bereits geprüfte andere Mapper oder so.

Gruß
Peter

Am 27.03.2014 09:04, schrieb Christoph:
 Ja das spam Problem auf dem Blog ist in diesem schon mehrfach
 angesprochen worden.
 
 Die Admin versuchen Spam accounts maximal schnell rauszuwerfen,
 allerdings kanndas - wie das Beispiel zeigt - schwierig sein.
 
 Blöd ist das die Tweets dann trotzdem in Twitter stehen bleiben.
 
 
 Sent from my iDingens
 
 Am 27.03.2014 um 07:37 schrieb Elstermann, Mike
 mike.elsterm...@itc-halle.de:
 
 Siehe hier: http://geoobserver.wordpress.com/2014/03/27/osm-blog/ 
 Schönes WE und Happy Mapping ;-) 
 ___ 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 mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] OSM-Blog ist manchmal schwierig zur verfolgen ;-)

[Peter Wendorff]

Hi,
ich denke, es sind zwei Dinge, die man angehen könnte:
1) Spam in den blogs,
2) Spam aus den Blogs auf Twitter.

Während Spam in den Blogs zwar blöd ist und nervt, beschränkt sich der
weitgehend (ich weiß; RSS-Feeds gibt's auch, trotzdem) auf ein
Pull-Medium: Den sehe ich dann, wen ich da nachgucke.
Auf Twitter dagegen würde es für mich eher dazu führen, eben diesem
Twitter-Account nicht mehr zu folgen.

Insofern kann man das im Grunde als zweistufige Veröffentlichung betrachten:
a) user X schreibt etwas in seinen user-blog
b) der blog-artikel wird durch den bot getwittert.

Natürlich wäre es gut, schon bei (a) hinreichend zu filtern. Da der Blog
aber immerhin unter der Kontrolle von OSM steht, ist das auch
nachträglich noch möglich, während man aus Twitter nichts mehr
rauskriegt ohne weiteres.

Deshalb wäre mein Vorschlag (und IFTTT spricht da erstmal nicht dagegen
und könnte weiter eingesetzt werden mit einer zusätzlichen Bedingung)
der folgende:
a') user X schreibt etwas in seinen user-blog
a2) andere osm-user können den blog-post als spam oder nicht-spam
markieren (nicht bewerten, nur als spam markieren).
b') der bot twittert, und zwar: wenn der user keine spam-bewertung hat
und mindestens eine positive Bewertung hat, dann ja. Wenn der Blogpost
positiv bewertet wurde (und noch nicht als Spam), dann ja. Sonst nein.
Auslösendes Event dabei ist einerseits das schreiben eines blogposts und
zweitens die Einordnung eines Posts als Spam oder nicht.

Ich weiß, dass dafür eine entsprechende Bewertungsfunktion in die blogs
eingebaut werden müsste; aber die Logik fürs Twittern zumindest wäre
unproblematisch, und die Bewertung würde über die Meldungen von
Spam-Accounts im Wiki hinaus eine komfortablere Möglichkeit für die
Moderation durch authorisierte User/Admins erlauben.

Die von dir genannten Heuristiken kann man auch nutzen, klar; aber
Heuristiken haben immer die Tendenz, schiefzugehen; sei es ein
Offline-Tool, das dann meine gesammelten blogposts aus dem Urlaub
hintereinanderweg in meinem userblog veröffentlicht, seien es ähnliche
Inhalte, die durch ein heiß diskutiertes Zitat mit kurzen Kommentaren
dazu immer wieder auftauchen oder ähnliches.

Spamfilterung muss automatisch gehen, aber so ganz automatisch geht es
eben meist noch nicht, und gerade fürs Twittern würde ich persönlich
weniger Tweets mit einem viel geringeren Spam-Anteil bevorzugen.

Gruß
Peter

Am 27.03.2014 10:38, schrieb Andreas Labres:
 On 27.03.14 09:42, Peter Wendorff wrote:
 Vielleicht sollte man den Twitter-Bot an der Stelle abschwächen und
 moderieren, so dass neue User erst eine Twitterfreigabe kriegen nach
 Prüfung durch bereits geprüfte andere Mapper oder so.
 
 Naja, ich glaub nicht, dass das realistisch umsetzbar ist. Das wird über IFTTT
 automatisch rausgehaut und fertig.
 
 Wenn, dann müßte man beim Erstellen der Blogs ansetzen und dort so eine Art
 Auto-Moderation machen, also zu prüfen
 - werden von einem User zu viele Blogs in kurzer Zeit erzeugt - sperren
 - werden im Zeitraum von verschiedenen Usern öfter Blogs mit ähnlichem Inhalt
 erzeugt - sperren
 - werden Inhalte von schon gesperrten Usern von anderen wieder erzeugt - 
 sperren
 
 Aber wie immer, Spamfilterung muss automatisch gehen.
 
 /al
 
 ___
 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] Aktuelle Anleitung OSM mit Mapnik rendern?

[Peter Wendorff]

Hallo Manuel,
passt vermutlich nicht ganz ideal, weil es eher auf Tileserver abzielt,
aber die Software ist ja weitgehend dieselbe, insofern hilft dir [1]
vielleicht weiter.

Gruß
Peter

[1] http://switch2osm.org/

Am 24.03.2014 06:57, schrieb Manuel Reimer:
 Hallo,
 
 gestern hat mir das beständige Weigern des OSM-Tileserver, mir den
 gewünschten Ausschnitt als SVG zu erzeugen, einige Stunden Zeit gekostet.
 Ganz davon abgesehen, dass ich letztlich eine Zoomstufe nehmen musste, die
 eigentlich nicht optimal ist. Das Teilen-Interface in der Webseite scheint
 kaputt zu sein. Beim rauszoomen wird der Maßstab korrigiert, beim Reinzoomen
 aber nicht. Selbst der korrigierte Wert rendert kein SVG, dass der
 Darstellung in der Webseite entsprechen würde.
 
 Um bei Bedarf einen Ausschnitt nach SVG zu rendern, möchte ich deshalb
 einmal versuchen einen eigenen kleinen Render-Server aufzusetzen. Ich hatte
 sowas schonmal am Laufen, aber das ist lange her und hat damals auch nicht
 wirklich zufriedenstellend funktioniert. Wo finde ich eine aktuelle
 Anleitung dafür? Laufen muss das ganze letztlich auf einem Linux-System.
 
 Danke im Voraus
 
 Gruß
 
 Manuel
 
 
 ___
 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: [OSM-talk] Newbie alert

[Peter Wendorff]

Am 19.03.2014 18:03, schrieb Bryce Nesbitt:
 On Thu, Mar 13, 2014 at 2:53 AM, SomeoneElse 
 li...@mail.atownsend.org.ukwrote:
 
 Bryce Nesbitt wrote:

 The entry level editor could reasonably limit new users to entry level
 edits.
 Messing with anything with a relation is not a first edit kind of
 activity.
 What if the entry level editor said hey, this is too complex, map
 something else
 and gain some experience and come back to this section.

 The barrier is still low.


 Saying you can't update anything that involves a relation rules out
 rivers and streams (borders), roads (turn restrictions), and many types of
 landuse and buildings (multipolygons).  I don't think that it's feasible.
 
 
 You've taken the proposal farther than I intended.
 Certainly adjusting the geometry of a boundary should be just fine for
 everyone.
 
 ---
 Let's take Stack Exchange, a Question  Answer site, as a possible model.
  A new user can vote up *any* answer.  However, it requires a reputation
 level of something like 100 to vote *down* a question.   This reflects that
 voting down has some social cost, and it takes some time for new users to
 become familiar with the community norms.
 
 ---
 For OpenStreetMap the moment a new user *deletes* a member of a border
 relation something might pop up:
 *Feature locked: this type of edit requires more editing experience. Please
 see here for details.*
Some remarks here:
1) it's not possible to pop up anything as the editor not necessarily
knows anything about the user at the time of the edit, this is known
only when uploading - and then it's too late. In contrast it's perfect
for a new user to change a local copy of osm, as long as it's not uploaded.
 
 Not only have you prevented a messy deletion, you've given the new user
 something to strive for (unlocking the capability).
You have made some of the new users to leave as they don't want to edit
any relation, they wanted to fix the street - and they never cared about
the turn restriction, which shouldn't have been changed by their edit.
They wanted to fix the street, but didn't know or didn't want to do
anything with the bus route.

 I dispute that this is any sort of barrier to a new editor.  A new editor
 (particularly a non-geek editor) may well feel
 comforted that they are in an environment where the sharpest knives are
 locked away, at least until they are ready to use them.
 And you're teaching at a teachable moment.
If it were that easy I would agree. Unfortunately we don't have knives
and spoons in our toolbox, we have only a spoon, but the data we are
working on, the food we eat when editing the data, contains salad (ways
and nodes independent of relations) as well as chilli (the relations
with their content) and unfortunately cherries as well - where you don't
know if the stone is left inside or not. Newbies don't expect the stone
to be hidden in the cherry, the don't expect to break anything by only
changing a way; and it's hard to explain why some streets are allowed to
be edited and others are not. Why some buildings are allowed to add and
others are not (as they are part of an associated-street relation for
example).

 ---
 Another possible model is OK Cupid, where users must pass a short quiz to
 access features.  For OpenStreetMap that could mean a quick educational
 quiz on relations.  A user trying to make an edit that requires relation
 experience would be directed to the quiz.  The moment they answer the
 questions correctly their account is permanently unlocked with regard to
 relation editing.
 In this approach one quiz would handle all editing platforms, and the
 rejection of an edit would happen at the API level.  The editors would only
 need to format the API error message for viewing (perhaps with a i18n layer
 for translations).
Knowing about relations does not necessarily mean to know how to detect
them in any editor or how to prevent breaks inside - and the other way
around.

regards
Peter

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

Re: [Talk-de] Mein Forum-Account gesperrt?

[Peter Wendorff]

Hi Fred,
ich befürchte, das ist ein anderes, größeres Problem und hat absolut
nichts mit dir zu tun.

Ich bin im Forum nicht eingelogged und bekomme dieselbe Meldung, die
angegebene mailadresse sieht auch nicht korrekt aus (@na1400.info).
Sieht also eher nach einem fetten Problem mit der Forendomain oder dem
Server aus als nach einem bösen Admin, der dich gesperrt hat.

Insofern komm wieder runter, niemand von OSM will dir was böses und ich
vermute, auch niemand hat dich gesperrt.

Gruß
Peter

Am 18.03.2014 09:46, schrieb Fred Jelk:
 Was zum Teufel?
 Wieso wurde mein Account im Forum gesperrt? Ich habe noch nie gespammt
 oder sowas...
 http://i.imgur.com/Tw39dum.png
 
 Langsam aber sicher nervt mich das Ganze hier: Gegen Spammer wird nicht
 vorgegangen (oder zum Teil bleibt Spam x Tage lang vorhanden - vorallem
 in den Blogs). Aber andererseits werde ich gesperrt... wegen was
 eigentlich? Ich habe höchstens mal (etwa vor 1 Jahr oder sogar länger)
 das eine oder andere Programm/Projekt oder GPS-Empfänger oder Artikel
 über OSM in den News mal gepostet. Aber sicher nicht gespammt...
 
 
 Naja, zum Glück gibt es andere OpenSource-Projekte (hat dann zwar nichts
 mit OSM zu tun, aber mir kann es egal sein). Wenn die Sperre bis heute
 Nachmittag noch aktiv ist, bin ich weg von OSM. So kann man auch Leute
 vergraulen. Ich habe in OSM mehrere 1000 Edits. Das meiste in meiner
 Gegend ist von mir. Aber soll sich halt jemand anders um diese Gegend
 kümmern.
 Danke an denjenigen Deppen, der mich gesperrt hat!
 
 ___
 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] Mein Forum-Account gesperrt? Geht anscheinend wieder

[Peter Wendorff]

Hi,
einzeln freischalten sollte nicht notwendig sein; es handelt sich wohl
um ein Problem mit IP-basierten Sperren in Kombination mit einem NAT-Proxy.

Bei einigen hilft wohl Shift+F5 bzw. das Leeren des Browsercaches.

Gruß
Peter

Am 18.03.2014 13:16, schrieb Fred Jelk:
 Bei mir geht's wieder. Und auch bei vielen anderen - es sind jedenfalls
 viele online.
 
 Möglicherweise müssen sie alle User einzeln freischalten (was mich zwar
 wundern würde), und es wurden zuerst jene freigeschaltet, die sich per
 Mail beschwerten. Rest erfolgt nach und nach (reine Spekulation
 meinerseits).
 
 
 Am 18.03.2014 13:07, schrieb chris66:
 Am 18.03.2014 12:29, schrieb Fred Jelk:
 Forum ist wieder online.
 Nack.

 Unfortunately everyone receives a 'you are banned' message. This is an
 error! We are working hard on a solution. Sorry for any inconvenience.

 Entzugsgrüße,
 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
 


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

Re: [Talk-de] 3D: Wie Gebäude am Hang taggen?

[Peter Wendorff]

Hi,
Obwohl die Daten ungenau sind, wäre aber doch eine erste Näherung
zumindest die, bei Anwendung von Höhendaten das 3D-Modell da auf
Bodenhöhe (entsprechend dem Geländemodell zu platzieren, wo der Eingang
sitzt.
Angenommen, jemand würde ein gebäude mit kellern eintragen, würde das
dadurch passen.
Angenommen, das Gebäude stünde an einem sehr gleichmäßigen Hang, der
dadurch tatsächlich durch die vorhandenen Daten abbildbar wäre, würde es
auch noch passen.

Tut das soweit schon irgendein 3D-Renderer?

Gruß
Peter

Am 17.03.2014 16:19, schrieb Martin Koppenhoefer:
 Am 17. März 2014 13:44 schrieb Manuel Reimer manuel.s...@nurfuerspam.de:
 
 Gibt es denn wenigstens einen Renderer, der bereits irgendwelche
 Geländedaten mit einbezieht?

 
 
 bei den bisher frei verfügbaren Quellen wie SRTM und Aster gibt es
 jedenfalls sicher keine Hoffnung, dass damit solche Details wie ein halb
 eingegrabenes Gebäude wiedergegeben werden könnten (Zu geringe Auflösung).
 Es gibt aber durchaus Renderer, die diese Quellen miteinbeziehen, aber das
 hilft eher bei der Orientierung im großmaßstäblicheren Einsatz, nicht bei
 der Ansicht des einzelnen Gebäudes.
 
 Gruß Martin
 ___
 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] Notes-RSS-Feed

[Peter Wendorff]

Hallo Andreas,
Die verlinkte API-Seite enthält sowieso sofort eine permanente
Weiterleitung zur Webseite per 304.

Insofern geht der Link letztlich nicht mehr in die API, obwohl du
natürlich recht hast, dass das auch in den Feeds behoben werden sollte,
um zusätzliche Seitenaufrufe zu ersparen.

Was das Erwirken einer Änderung angeht:
Den Code der Webseite inklusive API findest Du unter [1], da gibt's dann
auch einen Issue-Tracker [2].

Idealerweise findest und behebst du den Fehler* natürlich direkt ;)
alternativ kannst du auch per Ticket darauf aufmerksam machen.

Gruß
Peter

* ein Fehler ist es ja eben nicht, denn es entspricht mit der
Weiterleitung vollständig dem HTTP-Protokoll.


[1] https://github.com/openstreetmap/openstreetmap-website/
[1] https://github.com/openstreetmap/openstreetmap-website/issues

Am 15.03.2014 18:20, schrieb Andreas Neumann:
 Moin,
 
 wo muss ich mich melden, um im Notes-RSS-Feed[0] der API eine Änderung
 zu erwirken? Mich nervt etwas, dass die Links zu den Notes in die API
 geht und nicht zur Website.
 Oder gibt es einen RSS-Feed für Notes in einem Gebiet, der dieses
 Feature bietet?
 
 MfG Andreas
 
 [0] z.B.
 http://api.openstreetmap.org/api/0.6/notes.rss?bbox=10.824,50.636,10.968,50.75
 
 
 
 ___
 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: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike

[Peter Wendorff]

Hi Jukka,
although I'm curious about an answer from someone who's more competent
in the legal things, I'm not sure with your argument here.

ODBL does not require Share-Alike for produced works.
The map, even when based on OSM data is a produced work.
Therefore even if the map is based on osm data, it's not share-alike,
and any data based on the map IMHO cannot be share-alike too.

Let's assume the opposite:
- The map is a produced work and may be published on any license (more
restrictive as well as more open than ODBL), so let's assume the map is
CC-BY (without Share-Alike),
- Then from CC-BY it follows that anyone could derive other stuff from
that map without being obliged to follow any share-alike clause.

So if anyone would require data gathered on top of an osm map to be
share-alike, he's wrong (or ODBL contradicts itself in this example in
some way).
As I assume the ODBL to be checked many times, I assume yet that
therefore your implication chain to be wrong and new data collected on
top of an osm based produced work is not tainted with share-alike from ODBL.

Nevertheless I am not a lawyer, so someone else may proove me wrong If I am.

You mention Google Maps as a possible alternative to prevent this
problem. I disagree here, too. If you're talking about a substantial
amount of data derived from (or above) an OSM based map, the same would
be forbidden with google maps data, too. As the terms of service of
google state (German version):

Sofern Sie zuvor keine schriftliche Genehmigung von Google bzw. dem
Anbieter der betreffenden Inhalte erhalten haben, dürfen Sie (a) den
Inhalt weder ganz noch teilweise kopieren, übersetzen, abändern oder
abgeleitete Werke daraus erstellen

translated by me: without written permission of Google or the affected
data providers your are not allowed to copy (in parts or as a whole),
translate or modify the content or produce derived works from it.

Therefore the same as for OSM holds for any content of Google Maps, and
you probably should think about using Google as an alternative from a
legal point of view.

regards
Peter

Am 14.03.2014 14:17, schrieb Jukka Rahkonen:
 Simon Poole wrote:
 
 One thing I would like to hear about in this context of this discussion,
 are examples of concrete use cases that are not happening because of
 share alike and that are in general things that the community would like
 to support (so not evil corp can't take the data now and keep it).
 Concrete in the sense that they are uses that really would happen if
 share alike would be dropped, not we can build a straw man that shows
 how bad share alike is.
 
 Hi Simon,
 
 We have considered that we cannot use OpenStreetMap as a background map in
 any of the applications where users are sending location aware information
 back to administration. For showing existing data it would be OK but not
 for gathering data from users because user could locate a place corner of
 Annankatu and Merimiehenkatu http://osm.org/go/0xPLoLTa0?m= by looking at
 the OSM map. The interpretation of ODbL is that this location is derived
 from OSM data and thus the database of the administration would become
 ODbL. It could be OK in some use cases but some data are confidential and
 ODbL is not an option. Therefore we do not use OSM at all. We use our own
 services and Google Maps.
 
 This is a concrete example. However, changing the interpretation of ODbL
 into georeferencing locations by looking at OSM map does not yield a
 derivative database would not necessarily change the situation in Finland
 any more because since 2012 most raster and vector data from the National
 Land Survey of Finland have been open data under attribution-only license.
 Because of this using the data is simple. This has also helped OSM because
 raster maps and aerial images can be utilized for digitizing and vector
 data imports have started this year.
 
 Jukka Rahkonen-
 
 
 
 
 ___
 talk mailing list
 talk@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk
 


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

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

[Peter Wendorff]

Hi,
momentan aktiv ist er ja offensichtlich rund um Hannover, da gibt's
doch, soweit ich weiß, einen recht aktiven Stammtisch [1], der sich laut
Wiki morgen trifft.
Eventuell bietet es sich an, da einen Kontakt herzustellen, die Leute
vom Stammtisch vorzuwarnen und ihn dahin einzuladen.

Was die Sache angeht:
- Dürfen nicht gemapped werden ist schonmal fraglich bis unmöglich;
aber worauf bezieht er sich da?
- Straftaten: was für Straftaten? Wie motiviert? Inwiefern durchs
Mapping erst möglich gemacht oder erleichtert?

Die Argumentation der Straftaten ist die des
Internet-in-Suchmaschinen-Filterns: Wenn Google keine Kinderpornos
anzeigt oder Provider die bekannten Domains sperren, gibt es bestimmt
auch keine mehr...

Andererseits klingt das ja nach jemandem, der entweder offizielle
Funktion hat oder aber als Jäger, Förster etc. darin involviert ist.
Entsprechender Kontakt kann ja eigentlich nicht schaden.

Gruß
Peter

[1] http://wiki.openstreetmap.org/wiki/Stammtisch_Hannover

Am 13.03.2014 12:06, schrieb Frederik Ramm:
 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...
 
 Bye
 Frederik
 
 
 ___
 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] Bodendenkmal wie geht das? (nachtrag)

[Peter Wendorff]

Am 11.03.2014 15:15, schrieb Caronna:
 Am 07.03.2014 20:52, schrieb Peter Wendorff:
 Hallo Steffen,

 ich weiß kein Tag dafür; eventuell muss man auch ein neues dafür
 erfinden; aber eine Burg ist ein Gebäude (und ohne Gebäude keine Burg),
 eine Ruine hat zumindest Reste davon (also meist zumindest Mauern oder
 Mauerreste).


 ich war mal vor Ort!
 Es ist noch einiges zu erkennen, viel mehr als in der Zeitung stand.
 Reste von der Wallanlage sind deutlich zu erkennen.
 Ich hab mal eine Foto bei Wikipedia reingestellt
Link?

Gruß
Peter

___
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

[Peter Wendorff]

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:
- Wer das Sandloch auf dem Golfplatz als Strand einträgt, macht was
falsch - das ist kein Strand, sondern ein Sandloch-auf-dem-Golfplatz.
- Wer eine Straße mit access=no kennzeichnet, um zu verhindern, dass
Routing-Programme Autos vor der eigenen Haustür vorbeiführen, macht was
falsch.
- Wer eine Firma, die Einkaufswagen herstellt, als Supermarkt einträgt,
damit ein entsprechendes Icon auf der Karte auftaucht, der macht was
falsch, denn das ist kein Supermarkt, sondern ein Einkaufswagen-Hersteller.

Wer aber Daten zum dreidimensionalen Aussehen von Häusern einträgt, der
trägt zunächst mal Fakten ein, die für sich genommen sinnvoll sind.
Theoretisch könnte man sich sogar vorstellen, danach zu routen: Folgen
Sie der Straße bis zum einzigen Haus mit Walmdach auf der linken Seite,
und gehen Sie dann rechts querfeldein...

Gruß
Peter

Am 09.03.2014 00:18, schrieb Ralf GESELLENSETTER:
 Am 08.03.2014 21:10, schrieb Martin Koppenhoefer:
 +1, reihenhäuser würde ich als aneinanderhängende Einzelhäuser mappen
 
 In diesem Schema gibt es sogar side_hipped (Typ 2.2):
 http://wiki.openstreetmap.org/wiki/DE:OSM-4D/Roof_table
 
 Vielleicht könnte es Sinn machen, für jede Siedlung eine
 Default-Definition für das Aussehen der Häuser festzulegen.
 Oder man greift wie oben angegeben auf einen Code zurück,
 mit dem die gängigsten Hausarten schnell beschrieben werden können.
 
 Und schließlich: 3D-Tagging ist Tagging NUR für den Renderer, oder?
 
 Gruß
 Ralf
 
 ___
 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] Bodendenkmal wie geht das?

[Peter Wendorff]

Wobei das Bodendenkmal natürlich KEINE Burg ist, denn sie existiert ja
nicht mehr, wenn ich die Mail richtig verstanden habe.

Insofern bitte nicht als Burg eintragen, und IMHO auch nicht als Ruine.

Gruß
Peter

Am 07.03.2014 13:53, schrieb Archer:
 In OpenStreetMap sind so viele Daten enthalten, dass es unmöglich ist,
 alles auf einer Karte darzustellen. Die Macher der Standardkarte von
 openstreetmap.org haben sich wohl dagegen entschieden, Burgen darzustellen.
 Verbesserungsvorschläge für den Kartenstil auf openstreetmap.org kann man
 hier einbringen: https://github.com/gravitystorm/openstreetmap-carto/issues
 
 Die Karte von openstreetmap.de stellt alte Burgen als Symbol dar, wenn sie
 richtig getaggt wurden: http://openstreetmap.de/karte.html Außerdem gibt es
 noch die Geschichtskarte, die ebenfalls auf OpenStreetMap-Daten basiert,
 hier werden historische Objekte besonders hervorgehoben:
 http://geschichtskarten.openstreetmap.de/historische_objekte/
 
 Bitte beachte, dass Burgen mit historic=castle + castle_type=defensive +
 (falls Ruine): ruins=yes getaggt werden, siehe hier:
 http://wiki.openstreetmap.org/wiki/Historical_Objects/Map_Properties
 
 Außerdem sollten im Namen eines Objektes auch wirklich nur der Name und
 keinerlei darüber hinausgehende Informationen wie Wüstung, Bodendenkmal
 o.ä. stehen. Das sollte man über weiterführende Tags abbilden, siehe auch:
 http://wiki.openstreetmap.org/wiki/DE:Names#name_ist_nur_der_Name
 
 Für geschützte Gebiete gibt es folgendes Taggingschema:
 http://wiki.openstreetmap.org/wiki/DE:Tag:boundary%3Dprotected_area
 
 Gruß Archer
 
 
 Am 7. März 2014 12:26 schrieb Caronna eifelhu...@gmx.de:
 
 Hallo, ich brauchte noch mal Hilfe.
 Simmerath hat ein Bodendenkmal unter Schutz gestellt:
 http://www.openstreetmap.org/#map=19/50.58976/6.31062
 in Josm hab ich das eingetragen, auch in Potlach ist da nun zu erkennen,
 nur in OSM nicht.

 Ich habe es mal als Kreis dargestellt, weil ich dachte ein Punkt kommt
 nicht so einfach durch.
 Problem ist auch das das Bodendenkmal, eine alte Burganlage, so gut wie
 nicht zu erkennen ist (soll vor 20 Jahren noch anders gewesen sein, Gräbern
 sollen noch deutlich zu erkennen gewesen sein, evtl auch Mauerreste)

 Eigentlich hätte ich den Ort gerne durch eine Schraffierung
 gekennzeichnet, finde aber nicht dazu.

 Grüße aus der Eifel
 Steffen

 ___
 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 mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Bodendenkmal wie geht das?

[Peter Wendorff]

Hallo Steffen,

ich weiß kein Tag dafür; eventuell muss man auch ein neues dafür
erfinden; aber eine Burg ist ein Gebäude (und ohne Gebäude keine Burg),
eine Ruine hat zumindest Reste davon (also meist zumindest Mauern oder
Mauerreste).

Vielleicht hat jemand eine Tag-Idee für dich, sonst such dir ein Neues.
Und ja: dargestellt wird das dann immer noch nicht vermutlich; aber
nicht alles kann und sollte auf der osm-mapnik-Karte auftauchen; dann
wär die zu voll.

Gibt es dazu vielleicht 'ne Hinweistafel oder so? dann könnte man
darüber vielleicht zu einer Lösung kommen.

Gruß
Peter

Am 07.03.2014 17:10, schrieb Caronna:
 Am 07.03.2014 14:20, schrieb Peter Wendorff:
 Wobei das Bodendenkmal natürlich KEINE Burg ist, denn sie existiert ja
 nicht mehr, wenn ich die Mail richtig verstanden habe.

 Insofern bitte nicht als Burg eintragen, und IMHO auch nicht als Ruine.


 schwer zu sagen! das geübte Auge soll das noch erkennen können!
 War wohl eine Motte, also eine Ringanlage mit Befestigung aus Holz.
 
 Ist nicht ganz unbedeutend.
 
 Wie würdest dus denn eintragen?
 
 Grüße aus der Eifel
 Steffen
 
 ___
 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: [OSM-talk] No Changeset Comments from iD

[Peter Wendorff]

IMHO commit comments are very useful if done right.
Some comments are as useless as no comment (e.g. changes, more
changes and so on), but asking/reminding/triggering users to give a
comment at least increases the ratio of given comments; and hopefully
that could increas the ratio of useful comments, too.

regards
Peter

Am 06.03.2014 07:53, schrieb Clifford Snow:
 Why do I see so many new mappers make edits without a commit comment? Is it
 because iD doesn't prompt for a commit message? iD issue 1488 is open but
 not acted upon. I wonder why. Is it because the developers don't think
 commit comments are needed?
 
 I'm wondering what the community thinks. Are commit comments needed?
 
 Clifford
 
 
 
 ___
 talk mailing list
 talk@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk
 


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

Re: [Talk-de] Wald aufteilen um Namen anzuzeigen?

[Peter Wendorff]

Das liegt daran, dass zu viele zu lange Multipolygone falsch getagged
haben und die Render das als Fallback entsprechend angewandt haben.
Faktisch dennoch ein Bug und als solchen würd ich ihn auch behandeln.

Das Problem dürfte allerdings eher in osm2pgsql als an Mapnik oder dem
Kartenstil liegen - oder aber an dessen Konfiguration im
osm-default-style-Setup.

Am besten also:
Bug-report beim osm-default-style und bei osm2pgsql; entweder wird das
im style auf osm2pgsql geschoben, oder bei osm2pgsql gibt es eine
Konfigruation, um das umzustellen, und darüber wird das Problem gelöst.

Letzte und schlechteste Variante: Die Admins entscheiden sich bewusst,
den Fehler in Kauf zu nehmen und wollen das fallback für viele andere
Fälle beibehalten, in denen tatsächlich fälschlicherweise an inner/outer
die Tags der Relation drangepappt oder wiederholt worden sind.

Gruß
Peter

Am 04.03.2014 13:49, schrieb Martin Koppenhoefer:
 Am 4. März 2014 13:41 schrieb Manuel Reimer manuel.s...@nurfuerspam.de:
 
 Stimmt im Prinzip. Bevor ich aber irgendwelche Flächen ohne landuse
 rumstehen lassen würde, würde ich hier die kleine Redundanz in Kauf nehmen
 und ergänzend zum Multipolygon allen Untereinheiten noch ein
 landuse=forest geben.

 
 
 Im Prinzip ja, leider sind die Multipolygon-Relationen vollkommen
 unberechenbar und interpretieren teilweise aus eigener Kraft, dass ein
 tag nicht sein soll wo es ist (z.B. wenn man ein Loch hat, welches die tags
 des Multipolygons hat, dann wird das als Loch gerendert und die tags des
 Objekts werden offenbar weggeworfen, Beispiel:
 http://www.openstreetmap.org/way/263521637 auch ein Hinzufügen von
 building:part=yes hat leider nichts geändert, es bleibt ein Loch im
 Rendering).
 
 Gruß Martin
 ___
 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] Eintrag von Gewann-Namen

[Peter Wendorff]

Am 28.02.2014 00:08, schrieb Bernhard Weiskopf:
 Hätte ich gerne geschrieben, ich habe aber keine (im Wiki definierten)
 Regeln gefunden.
 
 Gruß Bernhard
 
 PS: Ich will für die Benutzer taggen (tagging for users)

Super Einstellung - aber die Benutzer der Tags sind
- Entwickler von Routern
- Entwickler von Karten-Designs
- Entwickler von anderen Anwendungen, die das nutzen.

Deren Produkte werden dann von anderen Nutzern wiederum genutzt, und das
sind die, die du meinst.
Das Taggen für letztere ist aber unmöglich ohne Absprache mit den
Entwicklern (ersteren Benutzern); und ein falsches oder ungenaues
Taggen, damit es dargestellt wird, ist zwar für ein paar der letzteren
Nutzer aber gegen erstere.

Für die Nutzer taggest du, wenn Du korrekt taggst, genau so wie die Tags
es aussagen.
Noch mehr für die Nutzer kannst Du tun, wenn Du das so machst, dass es
mit der Absicht der Entwickler zusammenpasst.
Wenn also ein Entwickler auf seiner Karte Gewanne darstellen will,
soll er das können, indem er und du die selben Regeln und Tags dafür
benutzt. Wenn ein Entwickler das aber nicht will, soll er auch das aus
den Tags herauslesen können.

Gruß
Peter

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

Re: [Talk-de] Keine Namen in Mapnik und anderen Karten

[Peter Wendorff]

Hallo Bernd,
entschuldige bitte - das war tatsächlich Bernhard - Schande über mein
Haupt; In der Thread-Ansicht war das so weit nach rechts gerutscht, dass
ich nur noch auf das Bern| geachtet habe. :/

Gruß
Peter

Am 26.02.2014 16:01, schrieb Bernd Wurst:
 Ich mach ja kein Tofu normalerweise aber hier kann ich nicht Sachbezogen
 antworten:
 
 Du legst mir in den Mund, dass ich irgendwas über irgend einen
 Goetheplatz geschrieben hätte. Habe ich nie. Ich weiß nichts von einem
 Goetheplatz.
 
 Lass das bitte.
 
 
 Am 26.02.2014 11:57, schrieb Peter Wendorff:
 Am 26.02.2014 11:20, schrieb Bernd Wurst:
 Hallo Peter.

 Zunächst: Watch your tone. Ehrlich.


 Am 26.02.2014 11:00, schrieb Peter Wendorff:
 Hallo Bernd,
 was hältst Du davon, konkrete Probleme zu verlinken, damit man konkrete
 Fragen stellen kann, was da was ist oder sein soll.
 Dass ein Name am Goetheplatz fehlt, hattest du geschrieben.

 Nein, habe ich nicht geschrieben.
 Stimmt, du hattest nur gefragt (Mail von gestern, 25.2., 23:12):
 Wie trägt man zukünftig den Goetheplatz ein, damit der Name des allseits
 bekannten Platzes auf der Karte erscheint?
 Ich nehme an, der Name von area = yes wird dann nicht mehr angezeigt.

 Vielleicht hab ich da also einen konkreten Fehlerfall reininterpretiert,
 den es nicht einmal gab oder gibt - dann entschuldige ich mich für den
 Ton (erlaube mir aber, die Frage zu stellen, was du damit eigentlich
 erfragen wolltest).

 Dass das zusammen mit highway=pedestrian und area=yes korrekt gerendert
 werden sollte, hast du hier auch schon lesen können.

 Ja, betrifft mich aber null komma gar nicht.
 Sondern? Was betrifft dich denn dann? Denn die Frage hast du ja schon
 gestellt, zumindest ist die Mail bei mir so eingegangen. Was genau du
 brauchst, hast du ja nicht geschrieben - ich weiß nur, dass es um
 irgendeinen der Goetheplätze geht, die es gibt.

 Wer aber sollte jetzt ein Ticket aufgrund einer Fehlermeldung aufmachen,
 die nur auf Hörensagen beruht, weil niemand außer dir das direkt
 überprüfen kann (denn Goetheplatz gibt's schon ganz schön häufig).

 Ich habe nur von einigen Waldwegen gesprochen. Eigentlich sind es alle
 Waldwege. Ich kann dir hunderte Links schicken. Oder du schaust einfach
 irgend einen x-beliebigen Waldweg an.
 Das Waldweg-Thema ist ein anderes und doch geklärt - da fehlt noch die
 Render-Regel, die beim Catch-All weggefallen ist, da kann man gucken, ob
 es ein Ticket gibt und bei Bedarf eins erstellen, einen Patch einreichen
 etc., darauf habe ich mich aber nicht bezogen.

 Also: Gib uns einen Link und es wird jemand versuchen, dir zu helfen -
 jedenfalls ist das meistens der Fall.
 Soviel also zu deiner Frage was denn noch.

 Die Frage war ganz konkret: Was ist bei einem normalen Weg denn außer
 name noch nötig um ein Redering des Namens zu erwirken. Dass es *kein*
 area-Tag geben soll konnte man hier heraus lesen. Aber meine Wege haben
 kein area-Tag.
 das area-Tag ist nicht ausschlaggebend fürs Rendering; es ist aber
 notwendig, um ein lineares feature als Fläche darzustellen.

 waldwege: Da fehlt die Rendering-Regel, Goetheplatz: da fehlt das Wissen
 darüber, was da überhaupt drangetagged ist - und das verweigerst du ja
 weiterhin (oder es interessiert dich tatsächlich nicht mehr).

 Meine Mutmaßung ist ja, dass hier der Style von highway=* auf einige
 wenige explizit eingetragene Werte eingeschränkt wurde. Das kann man
 machen, muss dann aber auch alle etablierten Werte berücksichtigen.
 Bisher scheint track kein gültiger Wegtyp in diesem Sinne zu sein.

 Ich seh's irgendwie nicht ein, für ein Problem einen Bugreport [1] auf
 zu machen das derart offensichtlich ist. Wer das verbockt hat, soll sich
 bitte auch darum kümmern dass das gefixed wird.
 Ich glaube, bei konkreten Fehlermeldungen (wie gesagt: ich red vom
 Goetheplatz) würde das jemand übernehmen; spätestens auf eine direkte
 Bitte hin. Aber aus wagen Aussagen ein Ticket zu bauen ist etwas mehr
 Arbeit als sich bei github anzumelden.

 Wer das verbockt hat hat im Zuge dessen etliche andere Fehler behoben
 und damit die Gesamtlage im Rendering eher verbessert; zumindest aber
 langfristig eine richtige Grundlage gelegt, um gezielt eine korrekte
 Darstellung genau da zu erzielen, wo sie gewünscht wird.

 Wenn Du mit github ein Problem hast, frag doch einfach freundlich nach,
 beschreibe das Problem konkret und so, wie du es auch in ein Ticket
 schreiben würdest, und bitte darum, dass daraus jemand ein Ticket macht,
 ich bin sicher, dass dir das nicht verwehrt wird.

 Gruß
 Peter

 ___
 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 mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Update JOSM Mappaint Style Coloured Streets 2.0

[Peter Wendorff]

+1
insbesondere würde das auch Tippfehler in Straßennamen einzelner
Adressen visualisieren.

Gruß
Peter

Am 26.02.2014 22:50, schrieb Florian Lohoff:
 On Wed, Feb 26, 2014 at 09:38:39PM +0100, Gertrud Simson wrote:
 Außerdem gibt es jetzt eine alternative Version, in der statt des ersten
 der letzte Buchstabe des Straßennamens ausgewertet wird. Dies ist geeignet
 für Länder, wo viele Straßen mit dem gleichen Buchstaben beginnen (z.B. in
 Frankreich Rue ...).
 
 Ich würde ein MD5 oder aehnlichen Hash verwenden über den Straßennamen
 und darauf das meinswegen erste Zeichen.
 
 Damit ist es egal an welcher stelle des strings eine veränderung
 eintritt.
 
 Flo
 
 
 
 ___
 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] Access-Tags

[Peter Wendorff]

Hallo Christian,
ich gebe dir nur zum Teil recht; die Tabelle war mir im Übrigen neu.

Zunächst eine Frage: Welche Anwendung hält sich an diese Tabelle?
Und gleich darauf aufbauend: gibt es eine maschinenlesbare Version, oder
muss jede Anwendung jede mögliche Änderung der Tabelle wieder manuell
einbauen?
Eine solche Tabelle ist wertlos, wenn Routing-Software sie nicht einsetzt.

Offensichtlich gibt es aber irgendein Projekt, dass sie einsetzt, aber
nicht auf der Seite genannt wird - die Formulierung designated - same
as yes but this road can optionally be prefered by some of your
metrics. deutet jedenfalls darauf hin.

Abgesehen davon ist ein Kernproblem der default-Frage nicht geklärt: Wie
erkenne ich als Mapper (!), ob ich bei einer bestimmten Straße nochmal
nachgucken sollte, was gilt, oder ob die default-Werte gelten?

Dass Routingsoftware die Default-Werte annimmt ist ja schön und gut -
aber wie unterscheidet man zwischen default und fehlend? Das ist nämlich
leider nicht möglich.
Für die Routingsoftware ist das egal - die muss mit fehlenden Daten
irgendwie halbwegs sinnvoll umgehen können und entsprechend defaults
annehmen; aber besser wäre es, wenn die Route nicht auf Annahmen,
sondern auf vorhandene Daten gestützt werden könnte.

Blöderweise gibt es aber eben mehrere verschiedene default-Semantiken:

1) Was nimmt Routingsoftware X an, wenn keine Angabe in den Daten steht?
   Diese Frage lässt sich mit einer solchen Tabelle dokumentieren und
   beantworten; notwendig dafür wäre aber auch die Angabe der Router,
   die sich danach richten, denn natürlich ist es keine völlig
   unsinnige Entscheidung, highway=track nur im Notfall in die
   Auto-Route mit einzubeziehen, womit es meist access=destination
   entsprechen dürfte.
2) Was ist ohne besondere Ausschilderung gültig?
   Bezieht sich neben den access-Tags insbesondere auch auf
   Geschwindigkeitsbegrenzungen, hat aber mit OSM und dem Mapping
   eigentlich wenig zu tun, sondern entspricht weitgehend (1) für
   Software, die sich an die Regeln hält.

Was ausgeschildert dransteht würde ich aber immer auch so eintragen.
Wenn an einer Straße innerorts (in DE) ein Tempo-50-Schild dransteht,
dann trage ich das so auch ein - obwohl innerorts per default 50 gilt.
Denn falls irgendwann die Geschwindigkeit generell auf 30 gesenkt werden
sollte, gelten bestehende Schilder mit 50 weiterhin. Es ändern sich also
die Regeln genau für die Fälle, wo dies nicht dransteht.

Aus den Gründen finde ich die Tabelle einen guten Ansatz - aber nur,
wenn die Erklärung dazu passt, und die fehlt bisher. Wer großflächig an
Bundes- und Landstraßen maxspeed=100 tagged, nur weil kein Schild
dransteht, erzeugt Probleme für mögliche Anpassungen der
Höchstgeschwindigkeit, z.B. auf 70, was jetzt schon auf einem großteil
der Landstraßen gilt.

Gruß
Peter

Am 27.02.2014 11:22, schrieb chris66:
 Am 27.02.2014 07:58, schrieb Manuel Reimer:
 
 Also eigentlich ein access = yes um alles zu erschlagen. Im Wiki wird von
 der Kombination access = yes aber abgeraten. Wie ist es also richtig und
 vollständig wenn man einen Waldweg mit oben genannten Schildern taggen will
 ohne unnötig viel Tag-Wirrwarr zu produzieren? Gilt bei Access-Tags alles
 was nicht verboten ist, ist erlaubt oder muss alles was erlaubt ist dran
 stehen? Wenn letzteres: Muss dann auch an jedem highway = residential die
 ganze Access-Tag-Flut dranstehen und wenn nein: Warum nicht?
 
 Moin,
 es gibt im Wiki eine Tabelle[1] mit den default-access-rights pro
 Wegklasse.  Das Setzen expliziter Tags ist also nur bei abweichenden
 Beschränkungen notwendig.
 
 Das OSM Verkehrszeichentool unterstützt bei der Findung der korrekten
 Tags:
 
 http://osmtools.de/traffic_signs/?signs=260,1026-37
 
 Chris
 
 [1]
 http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions
 
 
 
 
 ___
 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] Access-Tags

[Peter Wendorff]

Am 27.02.2014 12:59, schrieb Falk Zscheile:
 Denn die Zugangsregeln nach den LWaldG variieren von Bundesland zu
 Bundesland.
Bewusst provokant:
Mit dem Argument kann man aber auch die Defaults für Staaten weglassen -
denn auch die variieren von Staat zu Staat.
Oder andersrum: So wie es eine Tabelle für Defaults pro Staat gibt,
könnte es auch eine verfeinerte Tabelle für weitere Gliederungsebenen
geben, in Deutschland eben Bundesländer.

Nur sinkt die Wahrscheinlichkeit, dass Anwendungen so etwas in dem
Detailgrad unterstützen, natürlich weiter.

Gruß
Peter

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

Re: [Talk-de] Keine Namen in Mapnik und anderen Karten

[Peter Wendorff]

Hallo Bernd,
was hältst Du davon, konkrete Probleme zu verlinken, damit man konkrete
Fragen stellen kann, was da was ist oder sein soll.
Dass ein Name am Goetheplatz fehlt, hattest du geschrieben.
Dass das zusammen mit highway=pedestrian und area=yes korrekt gerendert
werden sollte, hast du hier auch schon lesen können.

Wenn das nicht korrekt dargestellt wird, ist das meines Erachtens ein
Fehler im aktuellen Rendering - dann muss man eine entsprechende
Fehlermeldung machen; auch dazu wäre ein konkreter Verweis auf eine
Stelle in der Karte sinnvoll.

Wer aber sollte jetzt ein Ticket aufgrund einer Fehlermeldung aufmachen,
die nur auf Hörensagen beruht, weil niemand außer dir das direkt
überprüfen kann (denn Goetheplatz gibt's schon ganz schön häufig).

Also: Gib uns einen Link und es wird jemand versuchen, dir zu helfen -
jedenfalls ist das meistens der Fall.

Soviel also zu deiner Frage was denn noch.

Gruß
Peter

Am 26.02.2014 08:46, schrieb Bernd Wurst:
 Hallo.
 
 Am 26.02.2014 08:31, schrieb Walter Nordmann:
 Bernhard Weiskopf wrote
 Wie trägt man das jetzt ein? Genügt name = ... nicht mehr?
 Ja, name=* reicht nicht mehr aus - und das ist gut so!
 
 Ja, aber selbst highway=... und name=... reicht scheinbar nicht aus? Was
 denn noch? render_this_name=yes oder wie? :-)
 
 
 
 ___
 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] Keine Namen in Mapnik und anderen Karten

[Peter Wendorff]

Am 26.02.2014 11:20, schrieb Bernd Wurst:
 Hallo Peter.
 
 Zunächst: Watch your tone. Ehrlich.
 
 
 Am 26.02.2014 11:00, schrieb Peter Wendorff:
 Hallo Bernd,
 was hältst Du davon, konkrete Probleme zu verlinken, damit man konkrete
 Fragen stellen kann, was da was ist oder sein soll.
 Dass ein Name am Goetheplatz fehlt, hattest du geschrieben.
 
 Nein, habe ich nicht geschrieben.
Stimmt, du hattest nur gefragt (Mail von gestern, 25.2., 23:12):
 Wie trägt man zukünftig den Goetheplatz ein, damit der Name des allseits
 bekannten Platzes auf der Karte erscheint?
 Ich nehme an, der Name von area = yes wird dann nicht mehr angezeigt.

Vielleicht hab ich da also einen konkreten Fehlerfall reininterpretiert,
den es nicht einmal gab oder gibt - dann entschuldige ich mich für den
Ton (erlaube mir aber, die Frage zu stellen, was du damit eigentlich
erfragen wolltest).

 Dass das zusammen mit highway=pedestrian und area=yes korrekt gerendert
 werden sollte, hast du hier auch schon lesen können.
 
 Ja, betrifft mich aber null komma gar nicht.
Sondern? Was betrifft dich denn dann? Denn die Frage hast du ja schon
gestellt, zumindest ist die Mail bei mir so eingegangen. Was genau du
brauchst, hast du ja nicht geschrieben - ich weiß nur, dass es um
irgendeinen der Goetheplätze geht, die es gibt.

 Wer aber sollte jetzt ein Ticket aufgrund einer Fehlermeldung aufmachen,
 die nur auf Hörensagen beruht, weil niemand außer dir das direkt
 überprüfen kann (denn Goetheplatz gibt's schon ganz schön häufig).
 
 Ich habe nur von einigen Waldwegen gesprochen. Eigentlich sind es alle
 Waldwege. Ich kann dir hunderte Links schicken. Oder du schaust einfach
 irgend einen x-beliebigen Waldweg an.
Das Waldweg-Thema ist ein anderes und doch geklärt - da fehlt noch die
Render-Regel, die beim Catch-All weggefallen ist, da kann man gucken, ob
es ein Ticket gibt und bei Bedarf eins erstellen, einen Patch einreichen
etc., darauf habe ich mich aber nicht bezogen.

 Also: Gib uns einen Link und es wird jemand versuchen, dir zu helfen -
 jedenfalls ist das meistens der Fall.
 Soviel also zu deiner Frage was denn noch.
 
 Die Frage war ganz konkret: Was ist bei einem normalen Weg denn außer
 name noch nötig um ein Redering des Namens zu erwirken. Dass es *kein*
 area-Tag geben soll konnte man hier heraus lesen. Aber meine Wege haben
 kein area-Tag.
das area-Tag ist nicht ausschlaggebend fürs Rendering; es ist aber
notwendig, um ein lineares feature als Fläche darzustellen.

waldwege: Da fehlt die Rendering-Regel, Goetheplatz: da fehlt das Wissen
darüber, was da überhaupt drangetagged ist - und das verweigerst du ja
weiterhin (oder es interessiert dich tatsächlich nicht mehr).

 Meine Mutmaßung ist ja, dass hier der Style von highway=* auf einige
 wenige explizit eingetragene Werte eingeschränkt wurde. Das kann man
 machen, muss dann aber auch alle etablierten Werte berücksichtigen.
 Bisher scheint track kein gültiger Wegtyp in diesem Sinne zu sein.
 
 Ich seh's irgendwie nicht ein, für ein Problem einen Bugreport [1] auf
 zu machen das derart offensichtlich ist. Wer das verbockt hat, soll sich
 bitte auch darum kümmern dass das gefixed wird.
Ich glaube, bei konkreten Fehlermeldungen (wie gesagt: ich red vom
Goetheplatz) würde das jemand übernehmen; spätestens auf eine direkte
Bitte hin. Aber aus wagen Aussagen ein Ticket zu bauen ist etwas mehr
Arbeit als sich bei github anzumelden.

Wer das verbockt hat hat im Zuge dessen etliche andere Fehler behoben
und damit die Gesamtlage im Rendering eher verbessert; zumindest aber
langfristig eine richtige Grundlage gelegt, um gezielt eine korrekte
Darstellung genau da zu erzielen, wo sie gewünscht wird.

Wenn Du mit github ein Problem hast, frag doch einfach freundlich nach,
beschreibe das Problem konkret und so, wie du es auch in ein Ticket
schreiben würdest, und bitte darum, dass daraus jemand ein Ticket macht,
ich bin sicher, dass dir das nicht verwehrt wird.

Gruß
Peter

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

Re: [Talk-de] Keine Namen in Mapnik und anderen Karten

[Peter Wendorff]

Hallo Bernhard,
warum sollte area=yes, name=foo denn gezeichnet werden?
area=yes sagt schließlich nichts anderes aus, als dass ein OSM-Objekt,
das nicht aufgrund irgendwelcher anderer Attribute eindeutig als Linie
oder Fläche zugeordnet werden kann, definitiv eine Fläche ist.
So kann man dicke Stadtmauern, Hecken, Wälle, Deiche etc. als Fläche
einzeichnen.
Mehr tut area=yes aber nicht, und wenn das tatsächlich DER Indikator in
Mannheim ist, um die benannten Blöcke darzustellen, dann ist das ein
Problem.

Für einen Platz wie den Goetheplatz kommt das name-Tag aber eigentlich
auch nicht vom area=yes, sondern vom highway=residential, oder
highway=pedestrian, denn die werden mit Namen gerendert (sowie einige
andere highway-Werte auch). area=yes entscheidet allerdings darüber, ob
der Name entlang der Linie (nämlich z.B. bei einer ringförmigen Straße)
oder auf der Fläche (eben bei Plätzen oder als Fläche eingetragenen
Straßen) auf der Karte erscheinen soll.

DASS der Name dargestellt wird, hat aber mit area=yes|no nichts zu tun.

Der Goetheplatz ist also highway=pedestrian, wenn er Fußgängerzone ist,
amenity=parking, wenn es sich um einen Parkplatz handelt, alternativ
Marktplatz oder was auch immer - was es eben ist.
Wenn kein Tag passt, brauchen wir dafür ein Neues, aber das hat mit dem
Rendern der Namen nicht viel zu tun (obwohl dann eben neuerdings für ein
neues Tag auch eine neue Render-Regel notwedig wäre, und das ist gut so).

Gruß
Peter


Am 25.02.2014 23:12, schrieb Bernhard Weiskopf:
 In Mannheim ist Mapnik zurzeit kaum noch zu gebrauchen.
 
 Die Wohnstraßen der Vororte tragen noch Namen. Aber die Quadrate der
 gesamten Innenstadt sind namenlos und die Straßen in den
 Naherholungsgebieten zwischen den Vororten (highway = track) werden nun auch
 namenlos angezeigt, obwohl sie Straßennamen tragen, bei Fußwegen (path oder
 footway) mit Namen genauso.
 
 Sogar bei öffentlichen Zufahrtswegen zu Höfen (highway = service) wird der
 Straßenname nicht mehr angezeigt.
 
 Wie trägt man zukünftig den Goetheplatz ein, damit der Name des allseits
 bekannten Platzes auf der Karte erscheint?
 Ich nehme an, der Name von area = yes wird dann nicht mehr angezeigt.
 
 Bernhard
 
 
 -Ursprüngliche Nachricht-
 Von: Frederik Ramm [mailto:frede...@remote.org]
 Gesendet: Dienstag, 25. Februar 2014 22:35
 An: talk-de@openstreetmap.org
 Betreff: Re: [Talk-de] Keine Namen in Mapnik und anderen Karten

 Hi,

 On 25.02.2014 22:18, Bernhard Weiskopf wrote:
 Kennt jemand den Grund, warum die Karten kaum noch Texte enthalten
 sollen?

 Das ist eine Suggestivfrage. Es gibt keinen Grund, warum die Karten kaum
 noch Texte enthalten sollen, denn die Karten sollen nicht kaum noch Texte
 enthalten.

 Unser Mapnik-Stylesheet hat historisch eine sogenannte catch-all-Regel
 für Dinge mit Namen enthalten. Diese Regel besagte, vereinfacht gesagt:
 Egal was es ist, wenn es einen Namen hat, dann schreib ihn irgendwie
 hin.

 Das führte immer wieder zu seltsamen Stilblüten in den Karten -
 irgendjemand zeichnet z.B. ein boundary=air_traffic,
 name=Flugbeschränkungsgebiet R123, und obwohl Mapnik keine Render-
 Regeln für Flugbeschränkungsgebiete hat, hat er trotzdem schön irgendwo
 entlang einer unsichtbaren Linie Flugbeschränkungsgebiet R123
 geschrieben.

 Das war unerwünscht; erwünscht ist vielmehr (in aller Regel), dass Namen
 nur für exakt die Objekte auf der Karte erscheinen, die selbst auch
 gezeichnet werden.

 Dazu müssen also die catch-all-Regeln entfernt und durch spezielle
 Beschriftungsregeln für genau die gezeichneten Objekte ersetzt werden.

 Das ist im großen und ganzen auch gelungen, aber einige Labels sind dabei
 unter die Räder gekommen - die meisten unabsichtlich; in einigen Fällen
 war es vielleicht wirklich nicht beabsichtigt, einen bestimmten Objekttyp
 einzuzeichnen.

 Also, langer Rede kurzer Sinn: Keine Panik, sie sind nicht hinter Dir her,
 und
 über kurz oder lang wird das alles wieder gut.

 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
 


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

Re: [Talk-de] Der VRR Stellt sich vor

[Peter Wendorff]

Hallo Christoph,
generell interessiert wär ich schon, aber ich sträube
mich noch ein bisschen vor dem Aufwand mit Anfahrt
aus Paderborn und Abends zurück. ;)

Eingetragen hab ich mich vor allem deshalb nicht bisher,
weil noch einige Termine offen sind für die Woche,
auf die ich keinen Einfluss habe; das sollte sich aber
bis Dienstag erledigt haben.

Außerdem bin ich als nun eigentlich kein Vertreter der
lokalen Community.

Ich trag mich aber mal als vielleicht ein vorerst.

Gruß
Peter



Am 22.02.2014 17:53, schrieb Christoph (TheFive@OSM):
 Hi,
 
 der VRR (Verkehrsverbund Rhein Ruhr) möchte enger mit OSM Zusammenarbeiten, 
 und hat uns angeschrieben.
 
 Die Einladung ging schon über diverse lokale Mailinglisten und ist auch schon 
 im Forum geposted worden.
 
 Da die Teilnahme von OSM noch Potential nach oben hat, nutze ich noch einmal 
 Talk-DE damit das auch überall
 ankommt.
 
 Organisation unsererseits findet hier:
 http://wiki.openstreetmap.org/wiki/VRR/Zusammenarbeit
 Statt, da ist auch das Einladungsschreiben.
 
 Der VRR hätte gerne in 4 Tagen eine erste Rückmeldung ob wir als Hunderschaft 
 oder mit 1nem Abgesandten kommen.
 
 
 
 Christoph 
 
 
 
 ___
 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: [OSM-talk] Not attaching polygons to roads

[Peter Wendorff]

Hi Frederik,
I agree - but only in parts.
If the other mapper shares nodes between the road and the field, and the
field is surrounded (and tagged as such) with a fence, so the field is
e.g. landuse=farmland, barrier=fence, then this is an error in the map
as it states that the fence is in the middle of the street or it's not
possible to decide where relative to the street the fence is.

In this case dividing them without adding new features IMHO is fixing a
bug in the map data, and joining a fence with a way along several nodes
in a line is an error - if not vandalism when doing it repeatingly while
igoring personal messages according to the same issue.

Nevertheless of course you're right: Changing the way of mapping without
adding value/improvement (!) is not okay.

regards
Peter

Am 20.02.2014 23:40, schrieb Frederik Ramm:
 Hi,
 
 On 20.02.2014 23:04, Dave F. wrote:
 There's a general consensus that attaching polygons to ways that
 represent roads was a bad idea.
 
 Not really.
 
 There is not a consensus but a ceasefire. Everyone is free to map this
 as they like, and to change it if there's a need - e.g. someone else has
 connected the field to the road, now you want to map the fence, so you
 need to split it apart. That's ok. Similarly, someone re-doing the whole
 area from better imagery or whatever has every right to map as he
 pleases - if they thing they can be more efficient by joining
 boundaries, more power to them.
 
 What is *not* ok is one person cleaning up after the other without
 actually adding any other improvement.
 
 I.e. if the other guy has connected the fields and the roads and you
 have been *only* pulling them apart without contributing anything else
 to the area in question, then you should have let them be; on the other
 hand, if the other guy has merged fields and roads that previously were
 separate, then they shouldn't have done that.
 
 This whole question is essentially a matter of taste, and you are
 allowed to map according to your taste, and discouraged from enforcing
 your taste for others.
 
 Bye
 Frederik
 


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

Re: [OSM-talk] Not attaching polygons to roads

[Peter Wendorff]

Am 21.02.2014 10:44, schrieb Pieren:
 On Fri, Feb 21, 2014 at 9:19 AM, Peter Wendorff
 wendo...@uni-paderborn.de wrote:
 
 If the other mapper shares nodes between the road and the field, and the
 field is surrounded (and tagged as such) with a fence, so the field is
 e.g. landuse=farmland, barrier=fence, then this is an error in the map
 as it states that the fence is in the middle of the street or it's not
 possible to decide where relative to the street the fence is.
 
 That's maybe an original issue with landuse polygons. Once you go to
 this level of details (fence), the border line between landuse's is
 not a clear sharp line. As suggested by Shaun, once you add fences and
 detach the farmland, you should also fill the gap created and make the
 landuse=highway. 
 People detaching landuse from road lines are most of
 the time doing half of the job.
I may agree here, but in OSM I think doing half the job is better than
mapping wrong stuff.
OSM is a database, not (only) a map, and there isn't something like
once you go to this level of details.
Let's extend the example slightly:
Let there be from left to right a field, a fence, a street, a hedge and
a park.
Let the fence in addition be not around the field, but only at the
borderline to the street (so it's not a tag on the field polygon any
more, while the hedge surrounds the park (where entrances are mapped as
such on nodes).

Now Mapper A starts mapping with low detail from aerial imagery: he
draws a polygon for the field, another polygon for the park, and a way
for the street, and tags it as landuse, leisure and highway
respectively. He omits the fence and the wall.

As you said, this is perfectly valid (although it's a little bit ugly to
detect that it's not a park directly beside a field, because you would
have to create the corresponding buffer for the highway for that; it's
not possible to calculate the exact area of the field, as we're wrong by
6 meters for half the street width.)

Mapper B is on the ground a while later and recognizes that there's a
fence and a hedge.
Adding the hedge seems to be easy: she adds the barrier=hedge-tag to the
park.
Adding the fence is easy, too, but how to do this? She definitively has
to draw a new way as there's no geometry matching the fence. But where?
By the rules applied in this scenario up to now it would be fine to
add the fence as a way sharing the nodes that are already shared by
park, highway, hedge and field.
But what happens when doing this?
There is a set of nodes that is hedge and fence. Might be possible: I
would interpret this as a fence inside a hedge, which is possible and
well known in the wild. But what's the matter with the highway? well...
then the highway must be in between the hedge with fence and the field
with the wall...
Well - wait... it could be a fence on top of a wall instead - now the
fence is on the other side of the way...
Or it could be a fence in the middle of the street - strange...

In fact the map says, there's a fence, a wall and a street's center line
at the same position.
Independent of the level of detail I would assume for the application
this is simply wrong, and keep in mind: the coordinates are in a level
of detail of 10cm or better, with no way to see what level of detail is
ment by any particular mapper with any particular object.

Let's invite Mapper C. He - as you suggests would like to clean up the
mess produced by A and B, and it's going to be hard work.
Without being on the ground it seems to be possible to detach the park
with the hedge from the way on the first glance, but damn it - what to
do with the wall? Isn't it wrong to detatch the fence if it might be
possible that in fact the fence is on top of the wall? If so it would be
necessary to detatch the fence, too and let fence and wall share nodes.
If not, this would create a different but completely wrong situation.
So nothing can be made better without being on the ground.

C decides to take his bike and and ride a whole day to that place as
unfortunately there's no active mapper any more (A and B stopped mapping
months ago). Now he knows what's the situation on the ground and has to
detatch lines from each other, stumbling over several ugly issues in the
osm editor software available:
- How to select one of many ways sharing the same nodes?
- how to minimize breaking object history - but remapping everything
would be more simple to do.

If A and B would have drawn lines in parallel, leaving a gap for the
highway in between it would be much easier.
 Changing the way of mapping without adding value/improvement (!) is
 not okay.
 
 At least, new contributions shouldn't decrease the quality.
+10,
but filling the map without empty gaps isn't a good measurement of quality.

regards
Peter

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

Re: [Talk-de] D-A-CH

[Peter Wendorff]

Hallo Frederik,
wie groß ist denn der Nachteil beim Zusammenbauen? Das Script, das Du
angibst, ist ja erstmal nicht so besonders kompliziert; wie viel
Laufzeit und Speicher kostet es, entsprechende Extrakte zusammenzubauen?

Naiv und ohne Details des osmosis-codes zu kennen müsste doch eigentlich
(wenn man voraussetzen kann, dass die Versionen aller Objekte in allen
Teilextrakten zusammenpassen) einmal durch alle osm/pbf-Dateien geparst
werden, während die bereits übernommenen ObjektIDs gespeichert sind.

Das ist also weitgehend lineare Laufzeit in der Größe der
Eingabedateien; und wenn man möchte, kann man statt einer Ergebnisdatei
ja auch direkt die weitere Verarbeitung - DB-Import etc. anhängen.

Eine Umsetzung für unterschiedliche Shells (notfalls einschließlich
Windows) sollte auch machbar sein.

Wenn also der Overhead zumindest bestimmter Nachbarextrakte nicht zu
groß ist, ist es vielleicht eine Überlegung wert, so 'ne Art
Download-Paket-Option anzubieten: Man lade DE, A, CH in einen Ordner, in
dem auch das merge-Script liegt und starte das Script (das kann für
langsame Netzwerkverbindungen bei Bedarf auch schon während des
downloads loslaufen); der Rest ergibt sich von selbst.

Oder übersehe ich dabei was wichtiges?

Gruß
Peter

P.S.: Deshalb sind natürlich manche Extrakte, gerade für Kontinente etc.
trotzdem sinnvoll, weil es bei denen für die Speicherung der schon
übernommenen Objekte schon für einen nicht allerneuesten Heim-PC elend
viel Speicher braucht...

Am 20.02.2014 23:25, schrieb Frederik Ramm:
 Hallo,
 
 On 20.02.2014 21:59, Christian H. Bruhn wrote:
 Ist der Bedarf nach DACH-Daten tatsächlich so groß? Oder wollen die
 Leute nicht eher BYBWACH?
 
 Das ist ja schon das Alpen-Extrakt ;)
 
 Der Bedarf nach DACH ist zumindest der am häufigsten geäußerte. Ich
 hab mich bislang immer geziert, weil ich wusste, dass dann natürlich all
 die Fragen nach Benelux, Deutschland+Polen, Ostsee-Anreinerstaaten und
 und und kommen.
 
 Im Grunde kann man sich benachbarte Regionen mit Osmosis zusammenbauen,
 hier z.B. ein Skript für ein
 Benelux+Niedersachsen+Nordrheinwestfalen+Rheinlandpfalz-Extrakt:
 
 SCHNIPP
 
 #!/bin/sh
 
 set -e
 
 BASE=http://download.geofabrik.de/europe;
 PIECES=germany/niedersachsen germany/nordrhein-westfalen
 germany/rheinland-pfalz belgium netherlands luxembourg
 OUTPUT=meinfile.osm.pbf
 OSMOSIS=/srv/osmosis/bin/osmosis
 
 # hierunter nix aendern
 
 NUM=0
 MERGE=
 OSMOSISFLAGS=
 export NUM MERGE OSMOSISFLAGS
 
 for p in $PIECES
 do
NUM=`expr $NUM + 1`
wget -qO$NUM.osm.pbf $BASE/$p-latest.osm.pbf
OSMOSISFLAGS=$OSMOSISFLAGS --read-pbf $NUM.osm.pbf $MERGE
MERGE=--merge
 done
 $OSMOSIS $OSMOSISFLAGS --write-pbf $OUTPUT
 
  SCHNAPP
 
 Das sollte eigentlich auch die wegen Überschneidung doppelten Ways
 richtig rauswerfen.
 
 Bye
 Frederik
 


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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

[Peter Wendorff]

Ähm?
Sorry, kann mir irgendjemand erklären, wie Dirk das hier meint? Ich
versteh's immer noch nicht.
Ich versuch noch einmal, meine Verständnisschwierigkeiten zwischen den
Zeilen deutlich zu machen.

Am 17.02.2014 18:51, schrieb Dirk Sohler:
 Peter Wendorff schrieb:
 Und wie kommen dann die Kacheln zum Browser des Nutzers?
 
 Die entsprechenden Daten werden über die API abgerufen, die
 entsprechende Kachel verlinkt, und der Browser stellt sie dar.
Wer ruft jetzt welche Daten wo ab? Wie sieht der Link aus, den der
Browser dann aufruft, bevor er die daraus bezogene Kachel darstellt?

 Es geht hier AUSSCHLIEẞLICH um den Abruf der Daten für die
 entsprechende Kachel aus der API. Nicht um das Einbinden, den URL, oder
 das Rendern der Wbesite im Browser. Da ist eine komplett andere
 Baustelle.
Nein, ist es nicht, denn der Abruf der Daten aus der API, wie du es
bezeichnest, ist doch genau die Kachel. Der Abruf passiert gerade - und
zwar ausschließlich - über die URL, die eingebunden wird; der
entsprechende Schlüssel müsste also an die URL angehängt werden, und
damit für den Browser ersichtlich sein (sagte ich das nicht bereits?).

Die zwei möglichen technischen Alternativen, die ich sehe, sind:
1) Sitzungsschlüssel zwischen Server und serverseitiger Anwendung (bzw.
Server und closed-source-komponente) aushandeln, damit dann clientseitig
den Key verschlüsseln. Aufwand: Das ganze durchs CDN propagieren etc.,
und bei langem Aufenthalt auf der Seite muss der Schlüssel auch noch
regelmäßig neu ausgehandelt werden, damit er nicht geklaut werden kann;
2) Der jeweilige Webserver muss als Proxy für die auf seinen Seiten
ausgelieferten Tiles fungieren, also nicht mehr der Browser läd von
tile.osm.org, sondern der webserver von meineseite.de läd von
tiles.osm.org und gibt die Kacheln dann unter tiles.meineseite.de
weiter. Machbar, aber problematisch, was a) Traffic insgesamt b)
komplexität auf OSM-Administrationsseite, c) Aktualität von Kacheln und
vor allem d) Komplexität für den kleinen Webseitenbetreiber, der mal
eben eine Karte einbinden will, angeht.
Insbesondere letzteres ist immer noch ein häufig genutztes Argument für
die Google-Maps-API, obwohl das bisher nicht mehr stimmt - mit der
Lösung wäre das nur allzu wahr.

 P.S.: Ja, man kann das ohne lösen,  indem tatsächlich die
 Webseiten-Serveranwendung direkt mit dem Tileserver redet,
 verschlüsselt ein Sitzungstoken aushandelt
 
 Na ja, oder eben dass in der Konfiguration des Wbeservers – bzw. genau
 genommen in dem Teil der Webanwendung, die auf dem Server, außerhalb
 des Zugriffs durch den USer, der API-Key hinterlegt ist.
Du hast immer noch nicht erklärt, wie der API-Key dann ohne Zugriff des
Users dazu führen soll, dass eben der User die Kacheln sehen kann -
warum die beiden mir einleuchtenden Varianten, die du da im Kopf haben
könntest, nicht funktionieren, hab ich oben erklärt.

Gruß
Peter

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

[Peter Wendorff]

Also kannst Du Anwendung und Browser voneinander unterscheiden?
Spannend...
Am UA-String ja offensichtlich nicht, denn dann könnte ja auch weiterhin
jede Anwendung sich einen Browser-UA-String suchen und den nutzen, ohne
dass das ein Problem wäre.

Abgesehen davon: Was ist ein Browser, was eine Anwendung?
Ist eine Facebook-App ein Browser, wenn sie Links verfolgt? Ist
Thunderbird ein Browser, weil man auch innerhalb von Thunderbird unter
Nutzung der Gecko-Engine Webseiten direkt öffnen kann?
Ist ein Browser-Plugin für Mails noch ein Browser? ist ein
Browserplugin, das die vorhandene Adressbuchfunktion um eine Karte
erweitert, die die Kontakte darauf darstellt?

Inwiefern würde eine solche Lösung das Verfahren einfacher,
fälschungssicherer, sinnvoller oder sonst irgendwie erstrebenswerter machen?

Gruß
Peter

Am 16.02.2014 12:27, schrieb Dirk Sohler:
 Christoph schrieb:
 Verstehe ich das richtig ?
 Du möchtest jedem user einen account verpassen? Das muss dann
 konsequenterweise auch bei Browsernutzung passieren.
 
 Jedem User, der eine Anwendung != Browser benutzt, die auf die API
 zugreift.
 
 Grüße,
 Dirk
 
 
 
 ___
 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] Mapnik Administration blockt QLandkarteGT

[Peter Wendorff]

Hallo Dirk,
das ist uns und auch den Admins schon klar, dass man das umgehen kann.
Und auch, dass mutwillige Sabotage, zu der ich das zählen würde, damit
nicht ausschließen kann.

Die Pflicht zu einem gültigen UA-String hat aber nicht in erster Linie
den Hintergrund, böswillige Nutzer wie dich ;) direkt zu kriegen,
sondern gutwillige Entwickler, die zurecht erstmal davon ausgehen, dass
sie testweise und für Software, die mal eine Handvoll Kacheln braucht,
die öffentlichen osm-kacheln nutzen dürfen, darauf hinweisen zu können,
dass ihre Software eben wohl doch nicht nur eine Handvoll Kacheln zieht.

Insbesondere ist eben auch nicht ein Programm betroffen, was ähnlich zu
einem Browser genau die Kacheln herunterläd, die zur Darstellung der
Karte gebraucht werden - solange das Programm nicht verkauft wird, ist
dies eine analoge und normalerweise tolerierte Anwendung (vorausgesetzt,
die Attributierung ist korrekt).

Hier geht es aber um ein Programm, das unter anderem den Massenhaften
Download tausender Kacheln erlaubt, und genau das ist nicht mehr erlaubt.

Wenn Du persönlich wget anweist, sich als Firefox oder sonstwas
auszugeben, verstößt Du persönlich genauso gegen die Tile Usage Policy,
denn die besagt ganz eindeutig, dass ein sinnvoller, korrekter UA
gesendet werden soll, der die Identifikation der Anwendung erlaubt. Mit
gesundem Menschenverstand weißt vermutlich auch du, dass damit nicht
gemeint ist, dass sich ScrapeOSM (tm) als wget ausgeben darf, selbst
wenn es sich um ein Shellscript handelt, das wget für den eigentlichen
Download nutzt.

Da jetzt weiter zu diskutieren hilft auch nicht besonders - ganz
auszuschließen ist Missbrauch nicht, sicher; aber nur weil nicht jeder
Diebstahl aufgeklärt wird, verlangst du ja auch im Strafrecht nicht,
Diebstahl zu erlauben, oder?

Es geht nicht um die einwandfreie Identifikation eine Clients, sondern
um das Finden von möglicherweise ungünstig programmierten Anwendungen,
und wie du am Beispiel von QLandkarte merkst, scheint auch die
Weigerung, einen sinnvollen UA-String anzugeben, nicht sicher vor dem
Block zu schützen.

Du hast immer noch keine Alternative ohne Account-Pflicht (die ja, wie
wir bereits festgestellt haben, auch nicht funktioniert, solange online
ohne Account Kacheln dargestellt werden können sollen) vorgestellt. Bis
dahin brauchen wir glaub ich kaum weiterzudiskutieren.

Gruß
Peter

Am 16.02.2014 12:39, schrieb Dirk Sohler:
 Simon Poole schrieb:
 - zu behaupten, dass eine Massnahme nicht funktionieren kann
 
 Bitte genau lesen. Ich wies jedenfalls völlig richtig darauf hin, dass
 der User-Agent nicht dazu geeignet ist, einen zugreifenden Client
 (anders als ein Token oder besser ein Useraccount) einwandfrei zu
 identifizieren, und daher als alleiniges Erkennungsmerkmal schlicht
 ungeeignet ist.
 
 Ich könnte wget anweisen, sich als „wget/1.15“ auszuweisen, oder aber
 auch als „Skynet/1.0“ oder als ein aktueller Firefox. In allen drei
 Fällen kann ich massenhaft scriptgesteuert Kacheln runterladen, bis die
 Leitung glüht, und im letzten Fall kann ich nicht mal gesperrt werden
 (IPs lassen sich wechseln), und alle drei Varianten ist der
 entstandene Traffic sogar ein paar Byte je Abruf größer als ohne UA.
 
 Die Maßnahme an sich funktioniert in einem gewissen Rahmen, nur stützt
 sie sich auf etwas, das vom Konzept her von Grund auf als technisch
 komplett unverifiziert einzustufen ist.
 
 Grüße,
 Dirk
 
 
 
 ___
 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] Mapnik Administration blockt QLandkarteGT

[Peter Wendorff]

Am 16.02.2014 15:13, schrieb Dirk Sohler:
 Peter Wendorff schrieb:
 Also kannst Du Anwendung und Browser voneinander unterscheiden?
 
 Mittels anwendungsspezifischem Token, der aufgrund der API nur durch
 entsprechende Header übermittelt werden kann eher, als über einen
 simplen String, in den jeder reinschreiben kann, was er will.
Wenn jemand fälschen will, dann ist das auch da kein Problem, den Token
zieh ich mir eben von osm.org direkt.
Dazu gehört dann außerdem noch die Authentifizierung über alle
Tilecache-Instanzen etc pp - nicht grade wenig Aufwand für minimal mehr
Hilfe.
 
 
 Abgesehen davon: Was ist ein Browser, was eine Anwendung?
 
 Stelle dich doch bitte nicht bitte dümmer, als du bist.
 
 Hier: Browser = Das Ding, mit dem du im WWW (!= „das Internet“) Seiten
 aufrufen kannst, und eben auch die OSM-Seite;
also:
Firefox, Thunderbird, Thunderbird-Adressbuch mit OSM-Karten-Erweiterung
(gibt's die? wär praktisch...),
Internet-Explorer, jede Anwendung, die die entsprechende
IE-ActiveX-Komponente benutzt, um Webseiten darzustellen,
wget (cool, kann www-Seiten aufrufen...),
...
 und Anwendung: Spezielles
 Programm, das zum Abruf der OSM-Kacheln über die OSM-API verwendet
 wird, ohne darüber hinaus andere Dienste im Internet (vgl. WWW) nutzen
 zu können.
Okay, also wenn meine App Twitternachrichten und OSM-Kacheln darstellt,
ist es demnach ein Browser?

 
 Ist [beliebige Anwendung] ein Browser, wenn sie Links verfolgt?
 
 In dem hier verwendeten Zusammenhang ist eine Anwendung dann ein
 Browser, wenn sie die WWW-Seite benutzt. Wenn sie die API benutzt,
 nein. 
Und wo ist der Unterschied zwischen WWW-Seite und API?
Du bist ja derjenige, der mit Umgehungsmöglichkeiten argumentiert.
Wenn ich also www.osm.org mit entsprechendem permalink aufrufe und alle
damit verbundenen Kacheln mit runterlade, ist das wieder ok? wenn ich
das hundertmal tue, auch?

Aber da du nur provozieren willst, brauche ich dir das sicher
 nicht zu erklären, da du es bereits weißt.

Ich will nicht provozieren.
Du kritisierst eine seit langem angewandte Praxis, die weitgehend
funktioniert; und hängst die auch noch an einem Fall auf, der
offensichtlich ja eben sogar gefunden wurde.
Du äußerst aber Kritik, ohne einen funktionierenden und mit vertretbarem
Aufwand umsetzbaren Gegenvorschlag anzubringen.

 Inwiefern würde eine solche Lösung das Verfahren einfacher,
 fälschungssicherer, sinnvoller oder sonst irgendwie erstrebenswerter
 machen?
 
 Die Vorteile eines anwendungsspezifischen Tokens sind, sofern der Token
 geheim bleibt (Closed-Source oder sonstwie verschlüsselt, und nicht
 einfach so durch andere Nutzbar, oder über Sniffer aus den übertragenen
 Datenpaketen auslesbar), dass die Anwendung zuverlässig identifiziert
 werden kann.
CLosed-Source - cool, also auch noch alle OpenSource-Software im
OSM-Ökosystem rausschmeißen, weil damit das System nicht funktioniert.
Ich glaube, du hast das Grundprinzip immer noch nicht verstanden, und
das heißt Fairness und Offenheit.

Das Tool von Github kann keiner mal eben forken, weil das Token nicht
drin ist (und nicht drin sein kann, denn sonst wär das ja nicht mehr
verschlüsselt), dafür muss man sich zusätzlich bei OSM anmelden -
wunderbar... - aber irgendwie eben nicht Offen.

 Die Vorteile eines „Accountzwangs“ bei einer Anwendung (vgl. Definition
 weiter oben) ist, dass man eindeutig einen Useraccount identifizieren
 kann, und man diesen Gezielt sperren kann. Natürlich kann ein Anwender
 sich einfach einen neuen Account anlegen, aber ein Entwickler kann auch
 seiner Anwendung den Firefox-UA-String verpassen.
 
 Aber mal andersherum gefragt: Inwiefern ist alleinig die Auswertung
 eines simplen Strings fälschungssicher? Was hindert einen Entwickler,
 der alle Tiles runterladen will eher daran, das technisch umzusetzen?
 Ein beliebig änderbarer String, eine App-Registrierung um einen Token
 zu bekommen, oder die Notwendigkeit eines Useraccounts?
Abgesehen vom Aufwand auf dem Server, um die Token-Lösung einzusetzen -
wie würdest du das für, sagen wir, JOSM umsetzen wollen? Steht der Token
im Code und damit im SVN? Steht der Token nur im Build und auch da
Verschlüsselt? Wie passt das dann mit OpenSource zusammen? Soll sich
jeder Entwickler, der mal einen Patch einreicht, extra registrieren?

Und wenn ja, dann haben wir entsprechend hunderte Registrierungen, was
hindert dich als denjenigen, der sich hier als der Böse aufspielt, der
alles aushebeln kann, daran, deine Anwendung hundertmal zu registrieren
und und den Token immer wieder zu wechseln?

Sorry, irgendwie überzeugt mich das noch nicht.

Gruß
Peter

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

[Peter Wendorff]

Am 16.02.2014 16:34, schrieb Dirk Sohler:
 Peter Wendorff schrieb:
 Du hast immer noch keine Alternative ohne Account-Pflicht
 […] vorgestellt.
 
 Anwendungsspezifischer Token (oder Entwicklerspezifischer API-Key), wie
 bereits mehrfach erwähnt.
Wie bereits mehrfach erwähnt untauglich, solange du keine Lösung für den
Overhead in der Infrastruktur und zusätzlich gerade bei
OpenSource-Software für folgende Probleme präsentierst:

- Wie verhinderst Du, dass Leute wie Du dann hundert API-Keys für eine
Anwendung nutzen?
- Wie verhinderst Du, dass sich alle Entwickler, die in JOSM mal was
committen, einen eigenen entwicklerspezifischen API-Key haben müssen?
bzw. wenn Du das nicht für notwendig hältst,
- wo steht der API-Key in einer OpenSource-Anwendung, wenn nicht im
Quelltext-Repository?

Gruß
Peter

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

[Peter Wendorff]

Am 16.02.2014 17:13, schrieb Dirk Sohler:
 Peter Wendorff schrieb:
 Am 16.02.2014 16:34, schrieb Dirk Sohler:
 Anwendungsspezifischer Token (oder Entwicklerspezifischer API-Key),
 wie bereits mehrfach erwähnt.

 Wie bereits mehrfach erwähnt untauglich, solange du keine Lösung für
 den Overhead in der Infrastruktur […] präsentierst:
 
 Sicherheit und Komfort schließen sich leider gegenseitig aus :(
 
 
 - Wie verhinderst Du, dass Leute wie Du dann hundert API-Keys für eine
 Anwendung nutzen?
 
 Genau so, wie die OSM-Admins aktuell Missbrauch verhindern: Gar nicht.
Also bietest Du als Alternative für ein nur sehr eingeschränkt
funktionierendes System ein System, was genauso eingeschränkt
funktioniert, aber zusätzlichen Organisationsoverhead benötigt - hüpsch...
 
 
 - Wie verhinderst Du, dass sich alle Entwickler, die in JOSM mal was
 committen, einen eigenen entwicklerspezifischen API-Key haben müssen?
 
 Bereits nötiger User-Account.
Häh? Ich red von JOSM-Entwicklern, die am JOSM-Code arbeiten, nicht die
mit JOSM osm-Daten hochladen.
JOSM ist hier nur ein Beispiel von vielen Programmen, die irgendwo
OSM-Tiles benutzen, QLandkarteGT passte nur deshalb nicht, weil da ja
offensichtlich praktisch nur ein Entwickler dransitzt.

 - wo steht der API-Key in einer OpenSource-Anwendung, wenn nicht im
 Quelltext-Repository?
 
 Anwendungen müssen eine Funktion behalten, über die der Anwender
 entweder selbst einen API-Key eingeben kann, oder ein vorhandener
 Useraccount kann für den Zugriff auf die API verwendet werden.
Also nicht für jeden Entwickler einen Key, sondern sogar für jeden User.
Wie sieht das dann jetzt mit Privacy aus? Du möchtest also jeden
einzelnen User tracken können (denn nichts anderes tust du damit).

Gruß
Peter

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

[Peter Wendorff]

Am 16.02.2014 20:26, schrieb Dirk Sohler:
 Frederik Ramm schrieb:
 Und genau diese Leute sind auch die, die trivialerweise Deine API
 Key-Vorschläge umgehen. Was soll denn an dem API Key besser sein
 
 Einen API-Key muss man beantragen, ggf. mit Authentifizierung 
Wie soll die funktionieren?

Mit Mailadresse? gut, krieg ich tausende, und irgendwer muss sich darum
kümmern, darunter die fake- und wegwerfadressen rauszufiltern - das
Problem haben wir schon mit dem UA-String, also verbessert es nicht.

Mit Persönlichen Daten? Post-Ident? Und das auch noch weltweit? Viel
Spaß. Abgesehen vom finanziellen ein enormer logistischer Aufwand.
oder
 sonstiger Validierung, und ist mit wesentlich mehr Aufwand verbunden,
 als ein paar Zeichen in eine Variable zu schreiben.
Eben: Der Aufwand ist immens, sobald man ernsthaft authentifizieren
wollte, und da den vermutlich niemand wirklich machen will (und außerdem
ja auch noch die Webseiten funktionieren sollen). Die Fragen in
Kombination mit OpenSource-Software haben wir ja an anderer Stelle
bereits angerissen.

Welche Lösung genau schlägst Du vor, und warum ist sie besser als die
(natürlich nicht perfekte) aktuelle Vorgehensweise?

Betrachte dabei:
- Aufwand auf Administrativer Seite von OSM (technisch und ständig
personell)
- Kosten auf beiden Seiten (OSM und Entwickler und Nutzer entsprechender
Anwendungen)
- Vereinbarkeit mit Offenheit von OSM und so weiter.

Ich weiß, ich hab die Frage schon mehrfach gestellt in diesem Thread,
aber bisher flamest du weiter über den ach so schlechten status-quo,
ohne diese Frage zu beantworten.

Gruß
Peter

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

[Peter Wendorff]

Am 16.02.2014 22:59, schrieb Dirk Sohler:
 Henning Scholland schrieb:
 Was wäre denn jeweils die dahinterstehende Anwendung?
 
 Die PHP- Python- Ruby- oder Wasauchimmer-Anwendung, die dafür sorgt,
 dass beim Aufruf eine Seite generiert und an den Browser gesendet wird.
 
 
 Wenn der nun an jeden Tileaufruf ein key=12345 dran hängt hilft das
 genau 0,0 mehr als die aktuelle Methode.
 
 Darum wird das auch in der dahinterstehenden Anwendung erledigt. Da
 bekommt der Nutzer nichts von mit.
Ach?
Und wie kommen dann die Kacheln zum Browser des Nutzers?

Bisher kriegt der Browser von der Webanwendung auf dem Server den
Befehl, Kartenkacheln von einem anderen Server (nämlich dem
osm-tileserver) abzurufen und anzuzeigen.

Wenn der Webserver den key=12345 dranhängt, du sonst aber nichts
änderst, dann bekommt also in Zukunft der Browser (!) den Befehl,
Kacheln von einem anderen Server abzurufen, und dabei den key=12345 zu
benutzen.
Ach so... stimmt, dann weiß das also der Browser, und ach so, dann weiß
ich als böser Angreifer das aber auch, weil was der Browser tut, kann
ich mir angucken; und ich muss damit nichtmal einen Browser im engeren
Sinne benutzen; ein HTTP-Aufruf reicht.

Denken wir also mal nach: Dan kriegt also der Nutzer doch was davon mit.

Gruß
Peter

P.S.: Ja, man kann das ohne lösen,  indem tatsächlich die
Webseiten-Serveranwendung direkt mit dem Tileserver redet, verschlüsselt
ein Sitzungstoken aushandelt, nur dieses an den Browser sendet und in
der Server-Server-Kommunikation dann aushandelt, welche Kacheln wie
dabei heruntergeladen werden dürfen/sollen, aber abgesehen davon, dass
das nun wirklich irre aufwändig ist, funktioniert es nicht für statische
Webseiten, die zwar eine Slippy-Map anzeigen, aber eben keinen
serverseitigen Code ausführen; und damit gerade für die kleinen Seiten,
die durchaus gewollt erlaubt sind, zum Teil unbrauchbar.

 
 
 Grüße,
 Dirk
 
 
 
 ___
 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] Mapnik Administration blockt QLandkarteGT

[Peter Wendorff]

Am 17.02.2014 01:23, schrieb NopMap:
 
 Hi!
 
 Um mal wieder einen konstruktiven Vorschlag ins Spiel zu bringen: Es wäre
 technisch möglich, einen korrekten User Agent und eine Entlastung der Server
 miteinander zu verbinden.
 
 Das könnte so ähnlich funktionieren wie auf meinem Server:
 - eine Massendownloader-Applikation identifziert sich mit ihrem User Agent
 - der Server leitet alle Aufrufe mit den User Agents bekannter Downloader
 z.B. mit einem Rewrite auf eine andere URL um, die nur vorhandene Tiles
 ausliefert aber kein Rendern auslöst. Das erzeugt keine nennenswerte Last
 - Aufrufe mit fehlenden oder unbekannten Agents oder Browser laufen normal
 weiter und werden wie gehabt ab einer bestimmten Anzahl von Anfragen
 gedrosselt
 
 Vorteile:
 - Server wird von unnötigen Renderanfragen entlastet
 - korrekter User Agent und Kooperation werden belohnt
 - in vorgerenderten oder häufiger angesehenen Gebieten liegen die Tiles
 sowieso auf dem Server rum
 
 Nachteil:
 - Funktioniert nicht in den höchsten Zoomleveln
Weiterer Nachteil:
Funktioniert nur, solange tatsächlich die Render-Queue das (einzige)
Argument ist, die Usage Policy so auszulegen wie sie ausgelegt ist.

Wenn es zusätzlich darum geht, den Traffic auf sinnvolle Anwendungen zu
beschränken, hilft das natürlich nicht. Da kenne ich aber die Kosten
oder Sponsoring-Regelungen der entsprechenden Serverstandorte nicht, ob
das ausreicht.

Gruß
Peter

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

[Peter Wendorff]

Am 15.02.2014 12:45, schrieb Dirk Sohler:
 hike39 schrieb:
 Mit Version 1.7.6 von QLandkarteGT stellt der Entwickler die
 Unterstützung von OSM-Karten ein.
 
 Pfui :(
 
 
 Die Brgründung:
 .
 here is a quick release to end the OSM misery. I am still not
 convinced that transmitting the user-agent string does really help to
 prevent any misuse. […]
 
 Damit hat er KOMPLETT recht. Der User-Agent sagt absolut rein GAR
 NICHTS darüber aus, welcher Client auf den Server zugreift, da der
 User-Agent ohne weiteres verändert werden kann.
Richtig ist vermutlich, dass es Missbrauch nicht verhindert.
Unabsichtlichen Missbrauch verhindert es jedoch schon, denn einige
Entwickler kommen ja erst durch die Blockade auf die Idee, dass da
Server dahinterstecken, die nicht unlimitiert sind, und dass ein
Missbrauch in gewissem Ausmaß zu vermeiden ist.

Die OSM-Tiles sind eben gerade kein Freibier-Service für alle
einschließlich Entwickler, die ihren Kunden genrne kostenlose Karten
ohne Mehraufwand anbieten wollen.

Was hat QLandkarte noch für Layer?
Nur die OpenCycleMap - na hübsch...
da ist ja die Aussage von der Webseite nur minimal übertrieben  to
display your GPS data on a variety of maps.
Klar, das geht - aber dafür jedesmal die TMS-URL selbst raussuchen? Das
kann doch auch nicht die Lösung sein; zumal die Anwendung dabei ja
trotzdem blockiert bleiben dürfte für alle TMS, die entsprechende
Vorgaben machen.

 
 Die Verantwortlichen bei OSM sollten sich das aussperren anhand eines
 simplel zu manipulierenden Strings noch mal gut überlegen, wenn sie
 weiterhin ernst genommen werden wollen.
Niemand sagt, dass das System so bombensicher ist. Natürlich kann auch
das umgangen werden, aber hier gibt es gibt nunmal zwei konfliktierende
Probleme dabei:
Variante 1) gar nicht blockieren: halten die Server nicht aus.
Variante 2) Anwendungen blockieren, die Missbrauch betreiben - das wird
gemacht. Notwendig ist dafür die Identifikation der Anwendung, mehr wird
nicht gefordert; das ist dem QLandkarte-Entwickler offensichtlich zu viel.
Variante 3) User identifizieren mit allem drum und dran - das ist zum
Glück nicht die angewandte Variante, denn die hätte tatsächlich in
Sachen Datenschutz etc. enorme Probleme.

Meine Version von QLandkarteGT hat OSM noch mit drin, aber wenn OSM in
Zukunft rausfliegt, dann müsste eigentlich auch die OpenCycleMap, die
einzige andere vorkonfigurierte Karte, demnächst rausfliegen - denn die
Usage Policy von Andy Allan [1] ist in der Hinsicht identisch: Your
application must provide honest http referer and/or user-agent headers

[1] http://www.thunderforest.com/terms/

Im Ergebnis dürfte rein rechtlich QLandkarte damit weitgehend ohne
Karten dastehen, nur setzt Andy die Regeln für die OCM offensichtlich
nicht so streng durch, und wie das mit anderen Karten ist, weiß ich nicht.

Den Admins einen Vorwurf zu machen halte ich an der Stelle aber für
falsch - zumindest, wenn kein gangbarer Alternativweg aufgezeigt wird,
und den sehe ich bei euch nicht.

 Ich hoffe, jemand forkt QLandkarteGT, und baut die OSM-Unterstützung
 wieder ein. Am besten mit durch den User änderbarem User-Agent-String,
 um zukünftigen bekloppt-heiten der OSM-Admins entgegenzuwirken.
Wie gesagt: Eine Lösung für die OSM-Infrastruktur wäre besser, als
Admins als bekloppt darzustellen - die machen das genauso freiwillig wie
du freiwillig mappst (vermute ich), und machen dabei einen ziemlich
guten Job. Bekloppt wäre, wenn sie einfach alles blockieren, weil
irgendwer Mist baut. Bekloppt wäre aber erst recht, wenn sie gar nichts
blockierten und auf der Webseite keine Kacheln mehr ankämen, weil die
Server überlastet sind.

Nicht bekloppt ist, sinnvolle Regeln aufzustellen und diese auch anzuwenden.
Sinnvollere Regeln zu fordern ist okay, aber nicht, ohne da auch
konkrete Vorschläge zu machen. Mir fallen keine ein - dir ja
offensichtlich schon; ich bin gespannt.

Gruß
Peter

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

[Peter Wendorff]

Hi,
klar - aber die online-Karten-Funktion ist damit faktisch tot.

Gruß
Peter

Am 15.02.2014 16:58, schrieb Michael Reichert:
 Hallo,
 
 Am 15.02.2014 16:53, schrieb Peter Wendorff:
 Was hat QLandkarte noch für Layer? Nur die OpenCycleMap - na 
 hübsch... da ist ja die Aussage von der Webseite nur minimal 
 übertrieben  to display your GPS data on a variety of maps.
 
 In QLandkarteGT kann man auch Karten im Garmin-Format (ohne
 Kopierschutz) anzeigen, z.B. die Freizeitkarte.
 
 Viele Grüße
 
 Michael
 
 ___
 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] OSM --- Wikipedia

[Peter Wendorff]

Hallo Steffen,
für eigentlich alle Karten gilt, dass die sich nicht direkt live an der
Haupt-Datenbank von OSM bedienen, schon bei den Daten nicht.
Bis deine Änderungen also in einer Karte X auftauchen, muss folgendes
Passieren:
- Du musst hochgeladen haben (okay, davon gehen wir mal aus)
- Der OSM-Server muss die Änderung veröffentlicht haben, das passiert
etwa einmal pro Minute sowie einmal am Tag
- Wenn der Server, der die Karte X rendert, aktuell ist, versucht er,
jede Minute die Änderungsdatensätze einzulesen, einige wenige machen das
eben aber auch mit den täglichen. Wenn deine Änderung also in den
Updates ist, und die sind hier gelesen worden, dann liegt das in der
Datenbank für die Wikipedia-Karte
- Die Wikipedia-Karte wird jetzt wieder von einer Render-Software
erstellt. Die wiederum erkennt, wo sich in der Datenbank was geändert
hat und rendert nacheinander die Betroffenen Kacheln neu. Wenn sich also
grade viel ändert, kann auch das wieder etwas dauern.

Letztendlich ist das bei den Karten auf osm.org immer das gleiche, aber
da das eben alles unterschiedliche Server und Systeme sind, die Last
unterschiedlich und so weiter, kann sich das durchaus deutlich
unterscheiden.

Gruß
Peter

Am 08.02.2014 14:26, schrieb Caronna:
 weis das jemand?
 Ich habe in OSM ne Änderung vorgenommen, OSM hat die auch nach n paar
 Augenblicken angezeigt.
 Wikipedia zeigt ja auf Wunsch auch die OSM Karte an, nur Änderungen
 dauern wohl mehr als etwas länger, gibt es da ein Grund für? greift
 WIkipedia nicht direkt aus OSM zu und lagert die Karten zwischen?
 
 Grüße aus der Eifel
 Steffen
 
 
 ___
 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] Mapnik Administration blockt QLandkarteGT

[Peter Wendorff]

Hallo Alex,

Ja, das ist bei osm.org letztlich genauso.

Kacheln in detaillierteren Zoomstufen werden auf Abruf gerendert. Also:
Wenn Du da hinsurfst, wird die Kachel in die Render-Queue reingeschoben,
die Software erzeugt ein Bild und das wird ausgeliefert.
Ja, da wird auch was gespeichert und bei erneutem Abruf direkt wieder
ausgeliefert, aber vieles kommt eben durchaus direkt (Abwägung zwischen
Speicherplatz und Rechenlast).

Wenn Du im Browser surfst, hast Du einen begrenzten Bildschirm.
Selbst bei einer HD-Auflösung von 1920x1080 und einer Karte im Vollbild
sind das gerademal rund 8*4=32 Kacheln, die du gleichzeitig sehen kannst.
Mit wildem verschieben des Kartenausschnitts wirds etwas mehr, aber das
hält sich im Rahmen.

Wenn Du jetzt aber Deutschland siehst und die Software läd z.B. bis z17
alle Kacheln, die dahinterliegen mit runter, sind das exponentiell
mehr Kacheln (mit jedem zoomlevel vervierfacht sich ja die Anzahl, und
das überlastet natürlich auf Dauer die Server.

Software, die das tut, wird deshalb blockiert, wenn sie dadurch den
Serverbetrieb stört oder zu stören droht; und auf Serverseite sind dabei
auch gute von schlechten Nutzern einer Software nicht zu
unterscheiden - es wäre also technisch nicht möglich, die App X nur für
Funktion Y zu blockieren, Funktion Z aber zuzulassen.

Die Daten sind frei, und wer eine solche Funktionalität anbieten will,
soll entweder einen Renderer in die Software einbauen oder sich irgendwo
einkaufen, was Serverlast für Download und Rendering angeht.

Du meinst nun, die vorgerenderten Kacheln wären besser als das, was du
lokal auf dem Smartphone erzeugst, und lädst die Kacheln auch noch
selbst runter: Nichts spräche dagegen, wenn du dir stattdessen die Daten
runterladen und die Kacheln lokal am Desktop rendern würdest, um sie
dann aufs Smartphone zu ziehen, und es spricht auch nichts dagegen, wenn
z.B. QLandkarte genau das unterstützen würde.

Gruß
Peter

Am 07.02.2014 16:15, schrieb Alexander Lehner:
 
 
 On Fri, 7 Feb 2014, Sven Geggus wrote:
 
 hike39 ho...@hike.de wrote:

 Was ist Eure Meinung hierzu. Muss man demnächst damit rechnen, dass
 OSMAnd, OSMPad, Locus und wie die Apps alles heissen auch blockiert
 werden?

 Das Problem ist nicht die Onlinenutzung, das Problem ist der Massenhafte
 Kacheldownload, dennd er zerstört das Konzept des on demand rendering.

 Ich verwende für meine Tourenplanung (Fahrrad und Wandern) das Programm
 Viking. Das lädt wie ein Browser Kacheln nur on Demand runter. Sowas darf
 IMO nicht geblockt werden.

 Als Admin von tile.openstreetmap.de ist mir aber insbesondere locus
 auch
 schon negativ aufgefallen. da werden tiles nicht nur on demand geladen
 sondern massenhaft untergeladen.
 
 tangoGPS bzw. foxtrotGPS machen das ebenfalls so (Region auswaehlen,
 angeben bis zu welcher Zoomstufe man tiles runterladen will).
 
 Ich nutze diese Programme sehr gern auf meinem 'Smartphone', weil die
 fertig gerenderten Karten einfach schoener sind als die lokal gerenderten.
 Zu Hause die Kacheln runterladen und beim Mountainbiken im Wald, wo's
 kein UMTS gibt, hat man die Karten parat. Ist schon nett.
 
 @Sven: Worin besteht das Problem des On-Demand Rendering bei
 Massendownloads? Da kenne ich den Mechanismus dahinter zu wenig.
 Ist das bei openstreetmap.org genauso?
 
 Die Datenmenge kann es wahrscheinlich nicht sein, das sind 100-400MB,
 die laedt man sich einmal im Vierteljahr runter und gut ists.
 
 A.
 
 
 ___
 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] St.-ZickeZacke-Str.

[Peter Wendorff]

Ich weiß nicht, ob du das mitgekriegt hast, aber Dr. steht auch im
Englischen nicht nur für Drive. Zugegeben - da heißt es dann Doctor,
nicht Doktor...

Ob die Kirche Sankt Maria in Deutschland zu Santa Maria oder Saint Maria
werden sollte, selbst in einer anderen Sprache, halte ich im übrigen für
Diskussionswürdig, oder würdest Du anstatt Saint Paul’s Cathedral in
London Sankt Paul's Cathedral in deiner deutschen Sprachausgabe hören
wollen? Entweder doch vermutlich Sankt Pauls-Kathedrale, oder aber den
Eigennamen Saint Paul’s Cathedral - aber nicht so 'nen komischen Mix
weil die TTS natürlich nur teilweise übersetzen kann (und wird).
Klar: Lässt sich durch Angabe unterschiedlicher name:[lang]-Werte lösen
- aber wenn die nicht da sind, hilfts eben nicht.

Richtig ist: Wenn du der TTS-Engine per Software mitteilen kannst, in
welcher Sprache der Name geschrieben ist, dann kann sie darauf eingehen,
für Webseiten auf Deutsch kann man dazu den englischen Eigennamen der
Kirche in ein entsprechendes html-Tag mit lang=en kapseln. Für den
Name-Tag ist das schon schwieriger, weil die Sprache nicht bekannt ist.
Das geht also nur, wenn die Sprache durch die Namensgleichheit mit einem
lokalisierten name-Tag identifiziert werden kann; und da dann auch die
Abkürzungen unterschiedlich sind, wär ich mir bei z.B. einer
südamerikanischen Kirche nicht sicher, ob der Name jetzt im Original
Spanisch, Portugisisch oder Deutsch ist, lässt sich anhand des St aber
nicht unbedingt ablesen - die Frage, in welcher Sprache der Text sich
insgesamt bewegt, ist eben gerade bei Eigennamen KEIN Hinweis darauf,
was korrekt wäre im Kontext des Namens.

Gruß
Peter

Am 06.02.2014 18:46, schrieb Fabian Schmidt:
 
 Am 05.02.14 schrieb Peter Wendorff:
 
 Eine TTS-Software, sie in dem Sinne gut ist wie du dir das vorstellst,
 gibt es vermutlich nicht, was nicht an der Faulheit der Entwickler
 liegen dürfte.
 
 Für TTS muss ich wissen, in welcher Sprache ich mich bewege. Dann kann
 ich je nach Sprache auch wahlweise Dr.-Doktor oder Dr-drive expandieren.
 
 Siehe dafür http://mary.dfki.de:59125/
 - Sprache bits3-hsmm de male hmm
   Willkommen in Dr.-Wendorff-Stadt!
   (aus St. wird scht)
 - Sprache cmu-bdl-hsmm en_US male hmm
   Welcome to Mulholland dr!
   (aus St. wird saint)
 
 
 Gruß, Fabian.
 
 
 ___
 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] St.-ZickeZacke-Str.

[Peter Wendorff]

Und wie viel Auswertung verlangst du für jede Software?
Wir sind uns doch einig, dass es nicht schwieriger für Mapper ist, die
ausgeschriebene Fassung in den name-Tag zu schreiben.
Für Software ist es einfach, eine vorhandene Langform bei Bedarf abzukürzen.
Damit eine Software - egal welche - die Kurzform korrekt verlängern
kann, muss sie
1) die Sprache kennen, das ist nur selten direkt der Fall,
alternativ
1a) aus der Lage die Sprache erraten - das geht, erfordert aber eine
entsprechende Heuristik sowie eine geometrische Abfrage, wo der Name auf
der Welt vorkommt,
2) Kommt ein Name mit einer entsprechenden Abkürzung in einem Gebiet
vor, in dem eigentlich eine andere Sprache vorherrscht, so muss der
Mapper dies wissen und entgegen deiner Regel die Langform eintragen,
weil jede Heuristik oder Sprachsuche sonst fehlschlagen muss.

Mit (2) wird deine Regel also zu:
Die Langform in name schadet nicht, aber für bestimmte Abkürzungen (im
Deutschen mindestens Dr. für Doktor, St. für Sankt und Str. für Straße,
wobei bei einem str am ende des Wortes auf keinen Fall der Punkt
vergessen werden darf), ist es in Ordnung die Abkürzung als Abkürzung zu
belassen, weil wir von Softwareentwicklern entsprechende
Auswertungsintelligenz erwarten.

Alleine für deine erste Näherung (und dass das auch nur eine Näherung
ist, betonst du ja), braucht jede Software also entweder eine Verbindung
zum Netz oder eine Datenbank, die eine Zuordnung zwischen Land und
Sprache(n) zu bilden.
Das erfordert aber schon, dass ich zu dem Namen das Land kenne, sonst
brauch ich auch noch eine Zuordnung von Koordinatenbereichen zum Land
(oder direkt zur Sprache), denn im Zweifelsfall gibt es in den OSM-Daten
keine Informationen zum Land, weil diese z.B. nur eine Stadt abdecken,
und auch addr:country nicht belegt ist.

Noch mal: Ich weiß, dass das möglich ist; erst Recht mit Referenz auf
fremde Quellen; aber wofür OSM nutzen, wenn wir hinterher wikipedia,
ethnologue.com und alles mögliche andere brauchen, um die Daten nutzen
zu können.

Ich hab nichts dagegen, Daten einzusparen, wo sie wirklich sinnlos sind
- z.B. in der aktuellen und wiederkehrenden Diskussion um
Mengen-Relationen; aber hier ist es sehr wenig bis gar kein Aufwand, der
viel bis sehr viel Aufwand auf anderer Seite spart und außerdem in OSM
alleine eine eindeutige Situation schafft, die keinen
Interpretationsspielraum braucht, erst recht keine Drittquellen.

Gruß
Peter

Am 06.02.2014 23:20, schrieb Fabian Schmidt:
 
 Am 06.02.14 schrieb Peter Wendorff:
 
 Ich weiß nicht, ob du das mitgekriegt hast, aber Dr. steht auch im
 Englischen nicht nur für Drive. Zugegeben - da heißt es dann Doctor,
 nicht Doktor...
 
 Probier es aus: das DFKI interpretiert Welcome to Dr. Mulholland! als
 Doctor.
 
 Klar: Lässt sich durch Angabe unterschiedlicher name:[lang]-Werte lösen
 - aber wenn die nicht da sind, hilfts eben nicht.
 
 Entweder interpretiere ich die Sprache richtig, dann weiß ich, was die
 Abkürzung heißt. Oder ich spreche den Namen falsch aus und hab damit ein
 größeres Problem als mit dem Unterschied Saint - Sankt.
 
 Für den
 Name-Tag ist das schon schwieriger, weil die Sprache nicht bekannt ist.
 Das geht also nur, wenn die Sprache durch die Namensgleichheit mit einem
 lokalisierten name-Tag identifiziert werden kann;
 
 Einfacher ist, anderswo anhand der Sprachgrenzen rauszufinden, was denn
 dort gesprochen werden kann, in erster *Näherung* schau ich bei
 ethnologue.com o.ä., welche Hauptsprache es in dem Land gibt.
 
 wär ich mir bei z.B. einer südamerikanischen Kirche nicht sicher, ob
 der Name jetzt im Original Spanisch, Portugisisch oder Deutsch ist,
 lässt sich anhand des St aber nicht unbedingt ablesen
 
 San und São haben kein t, die Sprachgrenze in Südamerika ist sehr klar,
 und warum sollte der Name deutsch sein?
 
 
 Gruß, Fabian.
 
 
 ___
 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] St.-ZickeZacke-Str.

[Peter Wendorff]

Geht es nur um zwei Fälle?

Es gibt in diesem Thread im Grunde zweieinhalb Meinungen, würde ich sagen:
1) on-the-ground: ich trage ein, was auf dem Schild steht
2) on-the-ground übersetzt: ich trage ein, was auf dem Schild steht,
aber in der ausgeschriebenen Fassung
2,5) on-the-ground manchmal übersetzt: ich trage ein, was auf dem Schild
steht, aber in der ausgeschriebenen Fassung - außer bei str. am Ende
oder Dr. und St. am Anfang.

Variante (1) und (2,5) haben beide das Problem, dass eine Kurzform eben
nicht ohne zusätzliches Wissen (und auch nicht mit generellen Regeln) in
die Langform übersetzt werden kann.
Ich beschränke mich bei den Beispielen mal auf die für (2,5)
problematischen, damit ist (1) auch widerlegt.

Ich weiß, dass ich hier Beispiele konstruiere, aber du behauptest ja,
die Verlängerung wäre eindeutig.

Die Draco-Malfoy-Straße, abgekürzt Dr.-Malfoy-Str.
Der Drees-Müller-Platz, abgekürzt Dr.-Müller-Pl.
Die Stefan-Effenberg-Gasse, abgekürzt. St.-Effenberg-Gasse
Der Stefan-Radoslav-Platz, abgekürzt St.-Radoslav-Platz
...

beliebig erweiterbar.

Echte Beispiele:

Stefan-Zweig-Straße, u.a. in Leipzig:
http://open.mapquestapi.com/nominatim/v1/search.php?polygon=1q=Stefan-Zweig-Stra%C3%9Fe,+Leipzig

Ich weiß - die Abkürzungen wären doof, aber über Sinn oder Unsinn von
Schildern wollten wir uns ja nicht streiten, und denen trau ich vieles zu.
Ich weiß auch, dasss Stefan oft mit S abgekürzt wird und nicht mit St,
aber Fehler auf Schildern sind auch keine besonders seltene Ausnahme.

Gruß
Peter


Am 05.02.2014 13:42, schrieb Martin Raifer:
 Ich möchte noch einmal die eigentlich schon in meinem Anfangsposting in
 den Raum gestellte These/Frage wiederholen:
 
 Wieso schreiben wir in OSM Straßennamen nicht wie ihn praktisch Jeder in
 Texten schreiben würde? So, wie er in Tageszeitungen vorkommt, so wie er
 in Enzyklopädien vorkommt, so wie er in Broschüren vorkommt, so wie er
 auf offiziellem Briefpapier vorkommt, so wie er am Straßenschild stehen
 würde wenn dort nicht aus Platzgründen abgekürzt werden müsste, …?
 
 Es ist meiner Meinung nach nicht sinnvoll Mappern irgendwelche von der
 Realität abweichende Regeln aufzudrücken, die weder intuitiv sind noch
 aus anderen Gründen gerechtfertigt. Vor allem nicht für so etwas
 alltägliches wie den Namen eines Dinges hinzuschreiben. KISS [2]
 
 Es geht doch praktisch fast nur um zwei Fälle: St. und Dr.. Beides
 sind in gewisser Weise Titel von Personen, die im echten Leben fast
 immer abgekürzt werden. Verwechslungen können unter Berücksichtigung des
 Kontextes (Name eines Ortes oder Straße) ausgeschlossen werden. (z.B.:
 St. steht laut Duden [1] für Sankt, Stück oder Stunde. Letztere beiden
 können bei Straßen oder Orten nicht vorkommen.)
 
 Liebe Grüße
 Martin
 
 [1] http://www.duden.de/rechtschreibung/St_
 [2] https://de.wikipedia.org/wiki/KISS-Prinzip
 
 ___
 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] St.-ZickeZacke-Str.

[Peter Wendorff]

Am 05.02.2014 18:01, schrieb Martin Raifer:
 Text-to-Speech
 
 Gute Text-to-Speech Software sollte aber mit diesen Abkürzungen locker
 umgehen können. Und wenn nicht, dann bedarf es für die jeweilige
 Anwendung schlicht eines Post-Processing Schritts, der die Abkürzungen
 entsprechend expandiert.
Gute Text-to-Speech-Programme können auch nicht ohne weiteres St. zu
wahlweise Santa, Santo, Sankt oder Saint expandieren, und auch dann
müsste die Text-To-Speech-Engine herausfinden, dass es sich um eine
Örtlichkeit handelt, sonst ist auch noch Stück unter den Möglichkeiten.

Über den deutschen Sprachraum hinaus kommen noch Street, Strada und
vermutlich etliche mehr dazu; dann entsprechend auch Drive für den
Doktor und vieles mehr.

Eine TTS-Software, sie in dem Sinne gut ist wie du dir das vorstellst,
gibt es vermutlich nicht, was nicht an der Faulheit der Entwickler
liegen dürfte.

Gruß
Peter

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

Re: [Talk-de] St.-ZickeZacke-Str.

[Peter Wendorff]

Hi,
ich glaube, niemand will verbieten, die Kurzform in name zu erfassen,
die Frage ist aber doch, was ist das Ziel?

Eine St.-Hedwig-Kirche ist besser als eine namenlose Kirche, aber eine
Sankt-Hedwig-Kirche wäre eben noch besser - Gründe sind bereits
mehrfach genannt in diesem Thread.

Wenn jetzt jemand die St.-Hedwig-Kirche einträgt, kann das jemand
anderes verbessern, wenn er mehr weiß.
Wenn aber jemand die St.-Hedwig-Kirche einträgt, obwohl er den langen
Namen weiß, dann ist das schade.
Deshalb ist es eben sinnvoll, das auch als Regel aufzustellen: Nach
Möglichkeit bitte die ausgeschriebene Fassung des Namens in name eintragen.

Ich trage auch einen möglicherweise falschgeschriebenen Namen ein, wenn
mir jemand aus dem Kopf sagt, wo ein bestimmtes Geschäft ist, aber den
Namen nur im Wortklang kennt; wenn ich einen Verdacht habe, eben mit
fixme (sonst aber auch ohne). Genauso würde ich ein St.-Sowieso
eintragen, wenn ich die Langfassung eben nicht aus eigenem Wissen daraus
erzeugen kann.

Gruß
Peter

Am 04.02.2014 00:24, schrieb Falk Zscheile:
 Am 3. Februar 2014 21:19 schrieb Florian Schäfer florian-schae...@gmx.net:
 Am 03.02.2014 17:38, schrieb Martin Koppenhoefer:

 Allein schon daher bin
 ich für die ausgeschriebene Schreibweise im tag name (wg.
 internationaler
 Konsistenz/gleichem Vorgehen, s.o.), es gibt aber noch mehr Beispiele.

 +1

 Ein weiteres Beispiel wäre da die St.-Exupéry-Straße, der ich neulich auch
 begegnet bin.
 Da ist es durch die Bekanntheit des Namensgebers noch relativ einfach, aber
 wie wäre es mit der St.-Denis-Straße, St.-Martin-Straße oder
 St.-Paul-Straße? Die gibt es teilweise entweder als Sankt-Straße oder als
 Saint-Straße (insbesondere im französischen Grenzbereich).

 Ich finde auch, dass der eindeutige (= ausgeschriebene) Name ins name-Tag
 gehört, alles andere in short_name u.Ä.

 
 Hier ist doch gerade das Problem: Ein Mapper, der vor dem
 Straßenschild steht und St.-Denis-Straße liest kann nicht sagen, ob
 St. ein Saint oder ein Sankt ist. Deswegen kann er nur
 St.-Denis-Straße eintragen. Ein anderer, der sich daran stört kann
 das dann klarstellen, indem er long_name richtig ausfüllt.
 
 Dieses vorgehen hat drei Vorteile:
 1. Der Erfasser vor Ort (on the ground) muss sich keine weiteren
 Gedanken um die Bedeutung der Abkürzung (hier St.) machen, er kann
 dies anderen überlassen. Es ist für ihn also einfach, Daten auch in
 Regionen zu erfassen, die er nicht so gut kennt.
 2. Die Differenzierung zwischen verschiedenen Namensvarianten in der
 Erfassung im Datenschema erleichtert die Arbeitsteilung: Einer kann
 sich um die Erfassung vor Ort kümmern, ein anderer Straßenlisten
 auswerten. Dass sich beide nicht in die Quere kommen Da stand aber
 St. Schon, aber St. heißt immer Sankt und soll ausgeschrieben
 werden., dafür sorgt die Erfassung in unterschiedlichen Tags: name,
 long_name und ggf. auch short_name.
 3. Der Datenauswerter hat die Wahl, welche der beiden Infos er für
 sich und seine Anwendung am Besten geeignet hält.
 
 Falk
 
 ___
 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