[Talk-de] Fusswege innerhalb Gebäude: Wie tagg en?

[Stefan Keller]

Schaut mal auf diese Gebäude in Hannover
(http://www.openstreetmap.org/?lat=52.35364&lon=9.72461&zoom=17&layers=B000FTF)
und in Rapperswil (http://tinyurl.com/no3uwq):
Da sind Wege zu sehen, die innerhalb Gebäuden verlaufen!

Realisiert wurde dies mit "highway=footway", was auf der Hand liegt.
Wenn diese mit dem Straßennetz außerhalb des Gebäudes verbunden sind,
ist technisch bereits ein einfaches Indoor-Routing möglich (vgl.
Thread auf OSM-Dev "Q. about indoor routing: Overlaying way-graphs,
tags for floor, stairway, escalator, lift?" vom 8. Mai 2009).

Mein 'Problem' ist nun, dass solcherart betroffene Gebäude optisch
überladen aussehen (mind. im Mapnik und Osmarender) - ganz besonders,
wenn man sich Fusswege in mehreren Stockwerken vorstellt!

Frage: Gibt es Meinungen dazu, bzw. konkrete Ideen für zusätzliche
Tags zu Fusswege (=> innerhalb Gebäude), so dass eine Chance besteht,
diese anders oder gar nicht zu rendern - und trotzdem für das Routing
v.Vf. stehen?

- S.

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

Re: [Talk-de] Fusswege innerhalb Gebäude: Wie tagg en?

[Stefan Keller]

Sven schrieb:
> Gps ist ja unter besten Bedingungen 3-4 m genau, in Gebäuden..
> Das kann man eigentlich vergessen.
> Höchstens mit Trägheitsnavigation könnte das etwas werden.

Ich experimentiere mit Positionierung über WLAN (sog. Fingerprints):
Siehe http://www.gis.hsr.ch/wiki/IndoorWPS
Das funktioniert oft raumgenau und genauer, d.h. 4 bis 10 m

LG, S.

Am 29. Juni 2009 16:23 schrieb Sven Sommerkamp :
> Am Montag, 29. Juni 2009 16:01:55 schrieb Stefan Keller:
>> Schaut mal auf diese Gebäude in Hannover
>> (http://www.openstreetmap.org/?lat=52.35364&lon=9.72461&zoom=17&layers=B000
>>FTF) und in Rapperswil (http://tinyurl.com/no3uwq):
>> Da sind Wege zu sehen, die innerhalb Gebäuden verlaufen!
>>
>> Realisiert wurde dies mit "highway=footway", was auf der Hand liegt.
>> Wenn diese mit dem Straßennetz außerhalb des Gebäudes verbunden sind,
>> ist technisch bereits ein einfaches Indoor-Routing möglich (vgl.
>> Thread auf OSM-Dev "Q. about indoor routing: Overlaying way-graphs,
>> tags for floor, stairway, escalator, lift?" vom 8. Mai 2009).
>>
>> Mein 'Problem' ist nun, dass solcherart betroffene Gebäude optisch
>> überladen aussehen (mind. im Mapnik und Osmarender) - ganz besonders,
>> wenn man sich Fusswege in mehreren Stockwerken vorstellt!
>>
>> Frage: Gibt es Meinungen dazu, bzw. konkrete Ideen für zusätzliche
>> Tags zu Fusswege (=> innerhalb Gebäude), so dass eine Chance besteht,
>> diese anders oder gar nicht zu rendern - und trotzdem für das Routing
>> v.Vf. stehen?
> Es gab gerade den Vorschlag mit dem Namensraum.
> Aber wie soll das mit dem Routing gehen?
>
> Gps ist ja unter besten Bedingungen 3-4 m genau, in Gebäuden..
> Das kann man eigentlich vergessen.
> Höchstens mit Trägheitsnavigation könnte das etwas werden.
>>
>> - S.
>>
>
> Gruß Sven S:
>> ___
>> Talk-de mailing list
>> Talk-de@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-de
>
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>

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

[Talk-de] Vortrag an der INTERGEO ueber OSM mit zweideutigem Titel

[Stefan Keller]

An der INTERGEO gibt es einen Vortrag mit dem Titel "OpenStreetMap -
Warum noch Lizenzen zahlen?" (vgl.
http://www.intergeo.de/de/downloads/kongress_programm_donnerstag.pdf).
Dabei möchten die beiden Referenten vom Landesamt Stuttgart und von
megatel (Bremen) offenbar nicht etwa den Vorteil der (CC-BY-SA-)freien
OSM Daten hervorheben, sondern wohl v.a. die Nachteile aufzählen...
Falls das der Fall ist, kann ich nur feststellen, dass OpenStreetMap
offensichtlich wirklich ernst genommen wird.

- S.

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

Re: [Talk-de] Fusswege innerhalb Gebäude: Wie tagg en?

[Stefan Keller]

"indoor=yes" klingt für mich sinnvoll.
-S.

Am 29. Juni 2009 16:15 schrieb Carsten Gerlach :
> Hallo,
>
> Am Montag 29. Juni 2009 16:01:55 schrieb Stefan Keller:
>> Frage: Gibt es Meinungen dazu, bzw. konkrete Ideen für zusätzliche
>> Tags zu Fusswege (=> innerhalb Gebäude), so dass eine Chance besteht,
>> diese anders oder gar nicht zu rendern - und trotzdem für das Routing
>> v.Vf. stehen?
>
> man könnte ein zusätzliches Tag "indoor=yes" (oder so ähnlich) anhängen. Allen
> Anwendungen steht dann frei, dieses Tag zu berücksichtigen oder auch nicht.
>
> Grüße, Carsten
>
>
> --
> Hier ist mein öffentlicher GPG-Schlüssel:
> http://daswaldhorn.funpic.de/gpg.html
> =
> www.stopptdievorratsdatenspeicherung.de
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>
>

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

Re: [Talk-de] Vortrag an der INTERGEO ueber OSM mit zweideutigem Titel

[Stefan Keller]

> und wie kommst Du zu dieser Annahme?

Es wären meines Wissens eine der ersten (europäischen)
Vermessungsbehörden und der ersten kommerziellen
Geodaten-vertreibenden Firmen, die sich für kostenlose Lizenzen von
Geodaten einsetzen.

Aber schön wär's ja. Weist du genaueres?

-S.

P.S. Leider kann ich nicht an die INTERGEO (habe dann an der
www.ogrs2009.org zu tun).

Am 2. Juli 2009 17:20 schrieb Jörg :
> Stefan Keller wrote:
>> An der INTERGEO gibt es einen Vortrag mit dem Titel "OpenStreetMap -
>> Warum noch Lizenzen zahlen?" (vgl.
>> http://www.intergeo.de/de/downloads/kongress_programm_donnerstag.pdf).
>> Dabei möchten die beiden Referenten vom Landesamt Stuttgart und von
>> megatel (Bremen) offenbar nicht etwa den Vorteil der (CC-BY-SA-)freien
>> OSM Daten hervorheben, sondern wohl v.a. die Nachteile aufzählen...
>
> und wie kommst Du zu dieser Annahme?
>
> Gruß, Jörg
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>

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

[Talk-de] Parkplatz einzeln als Punkt (nicht Flaeche): Wie?

[Stefan Keller]

Frage zum Tagging (Schema):
Ich plane Parkplätze als Punkte zu erfassen - zunächst in der Schweiz
und angefangen mit Behinderten-Parkplätze.
Ich möchte diese je einzeln als Punkte verwalten - und nicht als
Flächen und auch nicht als Punkte, die für ein ganzes Parkplatzareal
stehen (wie in http://wiki.openstreetmap.org/wiki/Parkplatz
angegeben):
=> Meinungen / Vorschläge dazu?

Grüsse, S.

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

[Talk-de] Wie Indoor-Wege mit 'normalen' Wegen verbinden (level)? Neues zu indoor=yes?

[Stefan Keller]

1. Tagging-Frage im Hinblick auf Routing:
Wie könnte man Indoor-Wege mit „normalen“ (= Outdoor) Wegen verbinden,
so dass klar wird, auf welchem Stockwerk (level) der „normale“ Weg
einmündet? => Relation?

2. Apropos Indoor:
Ist dieser OSM-Wiki-Eintrag noch aktuell (indoor=yes und level=A)?
http://wiki.openstreetmap.org/wiki/Indoor

Liebe Grüsse, S.

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

Re: [Talk-de] Wie Indoor-Wege mit 'normalen' Wegen verbinden (level)? Neues zu indoor=yes?

[Stefan Keller]

Hallo Fabian

> also einmünden sollte der weg immer auf dem selben level, es sei denn es

Das Problem ist beidseitig:
* Der Outdoor-Weg hat z.T. keine level-Angabe.
* Der Indoor-Weg hat mit indoor=yes und level=A zwar solche, ist aber
nicht klar welcher Level "nach aussen" führt (vgl. auch Gebäude am
Hang).

LG, S.

Am 27. September 2010 12:59 schrieb Fabian :
>
>
> Stefan Keller wrote:
>> 1. Tagging-Frage im Hinblick auf Routing:
>> Wie könnte man Indoor-Wege mit „normalen“ (= Outdoor) Wegen verbinden,
>> so dass klar wird, auf welchem Stockwerk (level) der „normale“ Weg
>> einmündet? => Relation?
>
>
> also einmünden sollte der weg immer auf dem selben level, es sei denn es
>  ist der weg in eine fallgrube.
> Indoor laesst es sich dann ganz gut an fahrstuehlen und deren etage
> orientieren. wenn der eingang hoeher liegt als das umgebende
> straßenlevel sollte eigentlich eine treppe oder rampe hinauffuehren.
>
>
>>
>> 2. Apropos Indoor:
>> Ist dieser OSM-Wiki-Eintrag noch aktuell (indoor=yes und level=A)?
>> http://wiki.openstreetmap.org/wiki/Indoor
>
> warum nciht? verwende allerdings lieber
> http://wiki.openstreetmap.org/wiki/Level
> das eine laesst sich in das andere umwandeln aber als relation lassen
> sich etagen-relation besser bauen in josm
>
>>
>> Liebe Grüsse, S.
>>
>> ___
>> Talk-de mailing list
>> Talk-de@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-de
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>

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

Re: [Talk-de] Parkplatz einzeln als Punkt (nicht Flaeche): Wie?

[Stefan Keller]

Matthias schrieb:
> Es sollte entweder Punkt oder eine Fläche vorhanden sein.
> Beides ist falsch weil es z.B. doppelt beim Suchen auftauchen würde.
> Dazu kommt, das eine Fläche höherwertiger ist als ein Punkt, also sind
> Flächen einzelnen Punkten vorzuziehen.

Meinst du nun Fläche (wie anhin) als ganzes Parkplatzareal oder auch
Fläche für einen einzelnen Parkplatz?

Mir geht es auf jeden Fall um einzelne Behinderten-Parkplätze - auch
wenn es 20 nebeneinander sind (was mindestens in der Schweiz nicht oft
vorkommt).

Für Rollstuhlgänger wäre es tatsächlich nützlich, wenn sie als Flächen
vorlägen, dann sähe man ob man seitlich aussteigen könnte, etc.
Aufwand und Nutzen stehen bei Flächen jedoch kaum im Verhältnis zu
einander (gegeben, dass z.B. noch kaum alle Gebäude erfasst sind).

Denkbar wäre daher eher ein Attribut, das den Behinderten-Parkplatz
(Node) weiter charakterisiert bzw. typisiert (wie das bei den
Wanderwegen gemacht wurde).

Gruss, S.


Am 27. September 2010 16:01 schrieb Matthias Versen :
> Hallo !
>
>> Ich plane Parkplätze als Punkte zu erfassen - zunächst in der Schweiz
>> und angefangen mit Behinderten-Parkplätze.
>> Ich möchte diese je einzeln als Punkte verwalten - und nicht als
>> Flächen und auch nicht als Punkte, die für ein ganzes Parkplatzareal
>> stehen (wie in http://wiki.openstreetmap.org/wiki/Parkplatz
>> angegeben):
>
> Es sollte entweder Punkt oder eine Fläche vorhanden sein.
> Beides ist falsch weil es z.b. doppelt beim suchen auftauchen würde.
> Dazu kommt das eine Fläche höherwertiger ist als ein Punkt, also sind
> Flächen einzelnen Punkten vorzuziehen.
>
> Matthias
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>

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

[Talk-de] FOSSGIS 2013 - Noch bis 30. April Frühbucher-Rabatt!

[Stefan Keller]

Liebe Mapper

Neuigkeiten und Hintergründe zu Technologien und Entwicklungen aus den
Bereichen Open-Source-Geo-Software und freien Geodaten werden dieses Jahr
auf der FOSSGIS 2013 Rapperswil in der Schweiz präsentiert. Die FOSSGIS-
 und deutschsprachige OpenStreetMap-Konferenz 2013 – die größte
deutschsprachige Anwenderkonferenz auf diesen Gebieten – findet vom 12. bis
14. Juni 2013 statt.

Mehr als 60 Vorträge für Einsteiger, Experten und Entwickler, Hands-On
Workshops und Anwendertreffen geben einen Einblick in aktuelle
Anwendungsmöglichkeiten und Neuigkeiten. Der Themenbogen spannt sich von
der Datenaufbereitung in OpenStreetMap, über den Aufbau
Geodateninfrastrukturen bis hin zu Technologien zur Prozessierung und
Darstellung von umfangreichen Geodaten. Damit spiegelt sich auch der Trend
der steigenden Durchdringung des Internets mit Karten und Geodaten wieder.
Über die gleichzeitig stattfindende Firmenausstellung ist ein direkter
Kontakt zu Dienstleistern, die professionelle Unterstützung bieten, möglich.

Zusätzlich zum fachlich orientierten Austausch in Community-Sessions und
Entwicklertreffen findet ein Social-Event statt, um den Austausch aller
Beteiligten - vom Benutzer über Entwickler und Mapper bis zum Entscheider -
zu intensivieren und gegenseitig von Ideen und Herausforderungen zu lernen.

Die Konferenzgebühr beläuft sich für die gesamten drei Konferenztage auf
140,- EUR. Frühbucher zahlen bis 30.04.2013 nur 120,- EUR. Zudem können
auch in diesem Jahr wieder zahlreiche Workshops besucht werden. Die
Teilnahmegebühr für Workshops beträgt 100,- EUR (Frühbucher 90,- EUR) pro
Teilnehmer und Workshop. Alle Einnahmen gehen vollständig in die
Finanzierung der Konferenz.

Da bis zu 400 Teilnehmer erwartet werden, ist eine Registrierung bis zum 4.
Juni 2013 notwendig. Das Programm, Anmeldeformular und andere
organisatorische Informationen finden sich auf der Konferenzseite unter [
www.fossgis.de/konferenz/2013/].

Die FOSSGIS-Konferenz 2013 wird vom gemeinnützigen Verein FOSSGIS e.V, der
deutschen OpenStreetMap Community und der Open Source Geospatial Foundation
(OSGeo) in Zusammenarbeit mit HSR Hochschule für Technik Rapperswil
(Schweiz) durchgeführt.

Ihr FOSSGIS-Konferenz-Organisationsteam

-- 

P.S. Es haben sich bereits 50 Teilnehmende und 25 Sponsoren angemeldet!

...
FOSSGIS 2013, Die Konferenz für Open Source GIS mit OpenData und
OpenStreetMap erstmals in der Schweiz!
12.-14. Juni, HSR, Rapperswil, [www.fossgis.de/konferenz/2013/]
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] FOSSGIS 2013 - Noch bis 30. April Frühbucher-Rabatt!

[Stefan Keller]

Grad gesehen:
FOSSGIS 2013 - Die vierte deutsche OSM-Konferenz!
http://wiki.openstreetmap.org/wiki/FOSSGIS_2013
Wer kommt? Mitfahrgegenheiten dort eintragen!

LG, Stefan




Am 24. April 2013 02:27 schrieb Stefan Keller :

> Liebe Mapper
>
> Neuigkeiten und Hintergründe zu Technologien und Entwicklungen aus den
> Bereichen Open-Source-Geo-Software und freien Geodaten werden dieses Jahr
> auf der FOSSGIS 2013 Rapperswil in der Schweiz präsentiert. Die FOSSGIS-
>  und deutschsprachige OpenStreetMap-Konferenz 2013 – die größte
> deutschsprachige Anwenderkonferenz auf diesen Gebieten – findet vom 12. bis
> 14. Juni 2013 statt.
>
> Mehr als 60 Vorträge für Einsteiger, Experten und Entwickler, Hands-On
> Workshops und Anwendertreffen geben einen Einblick in aktuelle
> Anwendungsmöglichkeiten und Neuigkeiten. Der Themenbogen spannt sich von
> der Datenaufbereitung in OpenStreetMap, über den Aufbau
> Geodateninfrastrukturen bis hin zu Technologien zur Prozessierung und
> Darstellung von umfangreichen Geodaten. Damit spiegelt sich auch der Trend
> der steigenden Durchdringung des Internets mit Karten und Geodaten wieder.
> Über die gleichzeitig stattfindende Firmenausstellung ist ein direkter
> Kontakt zu Dienstleistern, die professionelle Unterstützung bieten, möglich.
>
> Zusätzlich zum fachlich orientierten Austausch in Community-Sessions und
> Entwicklertreffen findet ein Social-Event statt, um den Austausch aller
> Beteiligten - vom Benutzer über Entwickler und Mapper bis zum Entscheider -
> zu intensivieren und gegenseitig von Ideen und Herausforderungen zu lernen.
>
> Die Konferenzgebühr beläuft sich für die gesamten drei Konferenztage auf
> 140,- EUR. Frühbucher zahlen bis 30.04.2013 nur 120,- EUR. Zudem können
> auch in diesem Jahr wieder zahlreiche Workshops besucht werden. Die
> Teilnahmegebühr für Workshops beträgt 100,- EUR (Frühbucher 90,- EUR) pro
> Teilnehmer und Workshop. Alle Einnahmen gehen vollständig in die
> Finanzierung der Konferenz.
>
> Da bis zu 400 Teilnehmer erwartet werden, ist eine Registrierung bis zum
> 4. Juni 2013 notwendig. Das Programm, Anmeldeformular und andere
> organisatorische Informationen finden sich auf der Konferenzseite unter [
> www.fossgis.de/konferenz/2013/].
>
> Die FOSSGIS-Konferenz 2013 wird vom gemeinnützigen Verein FOSSGIS e.V, der
> deutschen OpenStreetMap Community und der Open Source Geospatial Foundation
> (OSGeo) in Zusammenarbeit mit HSR Hochschule für Technik Rapperswil
> (Schweiz) durchgeführt.
>
> Ihr FOSSGIS-Konferenz-Organisationsteam
>
> --
>
> P.S. Es haben sich bereits 50 Teilnehmende und 25 Sponsoren angemeldet!
>
>
> ...
> FOSSGIS 2013, Die Konferenz für Open Source GIS mit OpenData und
> OpenStreetMap erstmals in der Schweiz!
> 12.-14. Juni, HSR, Rapperswil, [www.fossgis.de/konferenz/2013/]
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] FOSSGIS 2013 - Noch bis 30. April Frühbucher-Rabatt!

[Stefan Keller]

Hallo Malenki

Gute Frage! Bitte bei Patrick (im Cc:) melden.

LG, Stefan


Am 26. April 2013 22:14 schrieb malenki :

> Am Wed, 24 Apr 2013 02:27:40 +0200
> schrieb Stefan Keller :
>
> > [...] FOSSGIS 2013 Rapperswil in der Schweiz präsentiert. [...]
> > Die größte deutschsprachige Anwenderkonferenz auf diesen Gebieten –
> > findet vom 12. bis 14. Juni 2013 statt.
>
> Wo klicken potentielle Helfer? Oder haben sich schon im Vorfeld genug
> gemeldet?
>
> Gruß
> Thomas
>
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] FOSSGIS 2013: Jetzt anmelden (noch bis 30. April Frühbucher) und Jugendherberge reservieren

[Stefan Keller]

Liebe Mapper

Jetzt an die FOSSGIS 2013, 12.-14. Juni, an der HSR in Rapperswil (Schweiz)
anmelden!

Man sagt, die HSR hätte den schönsten Campus der Schweiz und Rapperswil sei
wie Mittelmeer am Zürichsee. Wir rechnen mit vielen Teilnehmenden, denn wir
haben bereits über 50 Anmeldungen und die Sponsorenliste wird immer
grösser.

Freut euch besonders auch auf den Social Event (Abendveranstaltung) am 12.
Juni ab ca. 18:30 Uhr auf dem Bauernhof Bächlihof Jona/Jucker Farm. Dieser
liegt in Fussdistanz zur Hochschule und Bahnhof/Schiffsstation entlang dem
See.

Noch bis 30. April gibt es Frühbucher-Rabatt und noch hat es Platz in allen
Workshops. Die Jugendherberge, die neben besagtem Bauernhof liegt, teilte
mir soeben mit, dass noch 11 Betten in 4er Zimmern frei sind. Natürlich
gibt es auch andere Übernachtungsmöglichkeiten!

Liebe Grüsse,
Stefan

P.S. OpenStreetMap ist übrigens gleich zweimal mit einem Projektstand
vertreten, einmal am "Hauptstand" der FOSSGIS/OSGeo/OSM und einmal mit
einem Stand der Swiss OpenStreetMap Association. Interessenten können sich
hier informieren: http://wiki.openstreetmap.org/wiki/FOSSGIS_2013

..**..**
..**.
FOSSGIS 2013, Die Konferenz für Open Source GIS mit OpenData und
OpenStreetMap
erstmals in der Schweiz! 12.-14. Juni, HSR, Rapperswil,
http://www.fossgis.de/**konferenz/2013/
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] FOSSGIS 2013 mit interessanten Keynotes!

[Stefan Keller]

Liebe alle

Die Eröffnungsveranstaltung der FOSSGIS 2013 steht - und verspricht
interessante Keynotes und Lightning Talks!

* Stefan Keller, HSR: Eröffnung (Moderator)
* Herrmann Mettler, HSR: Begrüssung des Rektors
* Erich Zoller, Stadtpräsident von Rapperswil-Jona: Grussworte
* Emmanuel Belo, CampToCamp: Neue Webmapping-Trends (Keynote Goldsponsor)
* Marc Wick, GeoNames.org: Freie Geonamen (Keynote)
* Simon Poole, OSMF+SOSM: OpenStreetMap (Keynote)
* Dann folgen (aktuell) acht Lightning Talks, u.a. mit WebGL

Herzlichst,
Stefan

P.S. Nicht vergessen: Bei der FOSSGIS anmelden! Nur noch heute
Frühbucher-Rabatt!

---
* FOSSGIS 2013 - die Konferenz für Open Source GIS mit OpenData und
OpenStreetMap erstmals
  in der Schweiz! 12.-14. Juni, HSR, Rapperswil,
http://www.fossgis.de/konferenz/2013/
* Zeit vertreiben und etwas Nützliches tun? Kort spielen und freie Geodaten
erfassen!
  http://www.kort.ch bzw. direkt http://play.kort.ch (für
Chrome/iPhone/Android)
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Neuer OSM Flyer

[Stefan Keller]

http://wiki.openstreetmap.org/wiki/Flyers_and_posters#Flyers

LG, Stefan

-- 

...
FOSSGIS 2013 - Die Konferenz für Open Source GIS mit OpenData
und OpenStreetMap erstmals in der Schweiz! 12.-14. Juni, HSR, Rapperswil
http://www.fossgis.de/konferenz/2013/



Am 20. Mai 2013 17:56 schrieb Tobias Hobmeier :
> Hi hi,
>
> wir wollten uns einen eingenen Flyer basteln und suchen quasi als
> Inspirationsquelle den aktuellen OSM flyer am besten als Sourcecode
> äquivalent :-D
> hat jemand einen link für mich?
>
> Gruß Tobi
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

[Talk-de] Call for Papers: PgConf.DE 2013

[Stefan Keller]

Hallo!

PGConf.DE 2013 ist die Fortsetzung der Deutschsprachigen PostgreSQL
Konferenz 2011. Die diesjährige PGConf.DE wird am wird am 8. November im
Rheinischen Industriemuseum in Oberhausen stattfinden. Gleich im
Anschluß findet über das Wochenende die OpenRheinRuhr am gleichen
Veranstaltungsort statt - mit OSM-Beteiligung (vgl. Wiki).

Es werden Themen für PostgreSQL Anwender, Entwickler und Mitwirkende
sowie für Entscheidungsträger behandelt. Mehr Informationen über die
Konferenz gibt es auf der Webseite unter:

http://2013.pgconf.de/

Wir akzeptieren nun Vorschläge für Vorträge. Bitte beachte, das wir
sowohl Vorträge in Englisch wie auch in Deutsch akzeptieren.

Jeder Vortrag wird 45 Minuten dauern und kann jedes beliebige für
PostgreSQL relevante Thema beinhalten. Einige Vorschläge für Themenbereiche:

  • Entwickeln von Anwendungen für PostgreSQL
  • Administration von großen und skalierenden
PostgreSQL Installationen
  • Fallstudien von PostgreSQL Installationen
  • PostgreSQL Werkzeuge und Hilfsprogramme
  • Erweiterungen (PostGIS, FTS, ...)
  • PostgreSQL Hacking
  • Community & Benutzergruppen
  • Tunen der Datenbank oder des Servers
  • Migrieren von anderen Systemen
  • Skalieren / Replikation
  • Benchmarking & Hardware
  • Produkte die PostgreSQL verwenden

Natürlich werden Einreichungen aus anderen, PostgreSQL relevanten
Bereichen ebenfalls akzeptiert.

Die Vorschläge müssen bis zum 15. September 2013 eingereicht werden. Die
ausgewählten Sprecher werden bis zum 25. September 2013 informiert.

Bitte nutze das Events-System von PostgreSQL.EU um einen Vortrag
einzureichen:
https://www.postgresql.eu/events/speakerprofile/pgconfde2013/

Leg dort zuerst ein Speaker Profile an. Falls Du bereits ein solches
Profil hast, überprüfe bitte deine Angaben und aktualisiere sie
gegebenenfalls. Mit dem Profil kannst Du über diese Web-App einen oder
mehrere Vorträge für PGConf.DE 2013 einreichen. Sollte die App nach
einem Login verlangen, nutze bitte Deinen postgresql.org community account.

Die Vorträge werden von einem Ausschuss in Betracht gezogen und ein
Zeitplan wird zum Start der Konferenz hin veröffentlicht.

Der Call for Papers ist ebenfalls im Web verfügbar unter:

http://2013.pgconf.de/cfp

Eintrittskarten für die Deutsche PostgreSQL Konferenz 2013 werden
ebenfalls für die OpenRheinRuhr 2013 gültig sein.

Wir freuen uns von dir zu hören und sehen uns in Oberhausen im November!

Stefan Keller

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

Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM

[Stefan Keller]

Falls es wirklich um "offizielle" Definitionen von Farben geht, kann
ich den Vorschlag von Chris Hormann nur unterstützen.

CIE-L*a*b* ist medium- und geräte-unabhängig und wird mittlerweile von
für fast jedes Gerät erhältlichen Kalibrierungsprogrammen sowie von
verbreiteten Grafikprogrammen (z.B. Illustrator) unterstützt.

Tatsächlich muss aber auf die teils umständliche Umrechnung
hingewiesen werden. Um das zu erleichtern, geben wir jeweils
gleichzeitig die sRGB und CMYK-Werte an - aber nur als Anhaltspunkt.

Leider kennen selbst Druckereibetriebe CIE-L*a*b nicht - wohl mangels
Ausbildung aber auch weil es für sie bequemer ist, proprietäre (d.h.
copyrightgeschützte und kostenpflichtige!) Farbpaletten anzubieten,
nach denen sich der Kunde dann zu richten hat...

Einen konzeptionellen Überblick über die Eignung der verschiedenen
Farbsysteme gibt [1] und eine Linksammlung zum Thema gibt es hier [2].

LG, Stefan

[1] http://www.brawer.ch/articles/farbenili/farbenili.pdf
[2] https://delicious.com/sfkeller/color


Am 26. Mai 2013 21:08 schrieb Tobias Conradi :
> 2013/5/26 Henning Scholland :
>> Hallo,
>> sollte man die Umrechnung in ein Farbmodell nicht besser dem Auswerter
>> überlassen?
>>
>> Henning
> Dann müsste OSM die Eingabe der offiziellen Definition erlauben und
> der Auswerter müsste fähig sein, diese Umrechnung durchzuführen.
>
> Ersteres ist wohl momentan nicht möglich (wenn doch - wo kann man CMYK
> oder RAL speichern?), und letzteres schließt wohl einige Auswerter aus
> (ich kann CMYK oder RAL nicht einfach bestimmen).
>
> --
> Tobias Conradi
> Rheinsberger Str. 18
> 10115 Berlin
> Germany
>
> http://tobiasconradi.com
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

[Talk-de] Kort Game Reloaded!

[Stefan Keller]

Liebe Mapper,

In den letzten Monaten haben wir hart gearbeitet, um das Kort Game zu
verbessern. Kort ist ein standortbasiertes Web-App für Mobiles (Open
Source) bei dem OpenStreetMap-Fehler spielerisch gelöst und überprüft
werden. Es ist unseres Wissens eines der ersten Projekte das
Gamification, Crowd Sourcing und Web-Anwendungen kombiniert.

Es gibt neu folgende Funktionen:
* Aufträge und Überprüfungen erscheinen in einer Karte.
* "Sneak Peek"-Funktion, um mehr als nur die nächsten Aufträge zu sehen.
* "News Tab", um Informationen vom "Hauptquartier" zu erhalten.
* Registrieren mit Facebook-Account (zusätzlich zu OpenStreetMap und Google)
* Neuer Typ "Restaurants mit fehlenden Küche" (derzeit nur in der Schweiz).

Ein weitere Funktion arbeitet noch im Hintergrund bis es aktiviert
wird am 12. Juni - also gerade noch rechtzeitig, wenn die FOSSGIS
2013-Konferenz (http://www.fossgis.de/konferenz/2013/) seine Türen an
der HSR in Rapperswil öffnet.

Herzlichst
Stefan und das Kort Development Team
http://play.kort.ch (Chrome/iOS/Android - noch kein Firefox)

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

Re: [Talk-de] Kort Game Reloaded!

[Stefan Keller]

Hallo.

Kort unter Chrome sollte gehen.
Kam in den letzten 24 Stunden die Frage "Neue Version verfügbar..."?
Zeigt die Version (im Tab "Über Kort") => Version 2.029 an?
Ev. hilft ein Reload der ganzen URL http://play.kort.ch .
Wenn das nichts hilft, den Cache des Browsers über die Einstellungen
leeren (ist ein Phänomen einiger Web Apps).

LG, Stefan


Am 29. Mai 2013 19:41 schrieb Ronnie Soak :
> Ist das Spiel denn momentan überhaupt noch aktiv? Weder mit Chrome noch dem
> Android-Browser sehe ich Aufträge oder Checks auf der Karte.
> Nicht in meiner Umgebung, nicht bei einer Stichprobe in Frankfurt und auch
> nicht in Winterthur, sollte es nur in der Schweiz funktionieren.
>
> Habe ich da ein technisches Problem oder gibt es da einfach nichts zu tun?
>
> Gruss,
> Chaos
>
>
>
> Am 29. Mai 2013 03:13 schrieb Stefan Keller :
>
>> Liebe Mapper,
>>
>> In den letzten Monaten haben wir hart gearbeitet, um das Kort Game zu
>> verbessern. Kort ist ein standortbasiertes Web-App für Mobiles (Open
>> Source) bei dem OpenStreetMap-Fehler spielerisch gelöst und überprüft
>> werden. Es ist unseres Wissens eines der ersten Projekte das
>> Gamification, Crowd Sourcing und Web-Anwendungen kombiniert.
>>
>> Es gibt neu folgende Funktionen:
>> * Aufträge und Überprüfungen erscheinen in einer Karte.
>> * "Sneak Peek"-Funktion, um mehr als nur die nächsten Aufträge zu sehen.
>> * "News Tab", um Informationen vom "Hauptquartier" zu erhalten.
>> * Registrieren mit Facebook-Account (zusätzlich zu OpenStreetMap und
>> Google)
>> * Neuer Typ "Restaurants mit fehlenden Küche" (derzeit nur in der Schweiz).
>>
>> Ein weitere Funktion arbeitet noch im Hintergrund bis es aktiviert
>> wird am 12. Juni - also gerade noch rechtzeitig, wenn die FOSSGIS
>> 2013-Konferenz (http://www.fossgis.de/konferenz/2013/) seine Türen an
>> der HSR in Rapperswil öffnet.
>>
>> Herzlichst
>> Stefan und das Kort Development Team
>> http://play.kort.ch (Chrome/iOS/Android - noch kein Firefox)
>>
>> ___
>> Talk-de mailing list
>> Talk-de@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-de
>>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Kort Game Reloaded!

[Stefan Keller]

Hallo André

Du meinst die Basiskarte? Die kommt von den Machern von Leaflet
(CloudMade). Die haben sicher einen Kummerkasten.
Die Fehlerdaten werden nächtlich von Keepright aktualisiert.
Die abgeschlossenen Lösungen (meist 3 Überprüfungen) werden in
Echtzeit überprüft, ob sie nicht schon gelöst wurden.

LG, Stefan


Am 29. Mai 2013 23:05 schrieb André Reichelt :
> Hallo Stefan,
> wie oft werden denn bei Euch die Kartendaten neu eingespielt? Weil das,
> was ich hier vor Ort angezeigt bekomme, ist mindestens einen Monat alt.
>
> Gruß
> André
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Kort Game Reloaded!

[Stefan Keller]

Hallo Ruben

Was meinst du genau?
Ungetaggte Wege sind ja gerade der Grund, warum Keepright (und damit
das Kort Gam) das als Fehler meldet, der Strassentyp fehle...

LG, Stefan


Am 30. Mai 2013 03:06 schrieb Ruben Kelevra :
> Wollte mich schon hierdrüber beschweren:
>
> http://s1.directupload.net/file/d/3271/xilydai5_png.htm
>
> Weils ein Fußweg zu einem Haus ist, das war aber ein ungetaggter Weg,
> denke sowas sollte euer Programm ignorieren :)
>
>
>
> LG Ruben
>
> 2013/5/29 André Reichelt :
>> Hallo Stefan,
>> wie oft werden denn bei Euch die Kartendaten neu eingespielt? Weil das,
>> was ich hier vor Ort angezeigt bekomme, ist mindestens einen Monat alt.
>>
>> Gruß
>> André
>>
>> ___
>> Talk-de mailing list
>> Talk-de@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-de
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Kort Game Reloaded!

[Stefan Keller]

Der eigene Standort wird mit einem blauen Punkt angezeigt und kommt
vom Browser Interface.
Das Kort Game zeigt aktive Aufträge & Überprüfungen 5 km um den
eigenen Standort.
Das bleibt auch beim Rauszoomen so.
Mit der neuen Sneak Peek kann man sich auch Aufträge & Überprüfungen
anderswo anzeigen lassen.
Da sehe ich in Deutschland und Frankreich überall Daten...
Laut dem HTML5-Framework, das wir verwenden werden folgende Geräte unterstützt:
http://www.sencha.com/products/touch/features/
Ich hoffe, das hilft.

LG, Stefan


Am 30. Mai 2013 08:29 schrieb Ronnie Soak :
> Die Update-Frage kam heute. Jetzt steht unter  "about"  2.0.33
> Leider immer noch keine Aufträge.
> Reload bringt leider nichts.
> Ich habe das auch unter einem nagelneuen Android versucht, bei dem der
> Browser garantiert noch nier kort.ch gesehen hat.
>
> Gibt es eine Zoomlevel-Grenze, bis zu der Aufträge angezeigt werden, oder
> könnte ich auf ganz Deutschland herauszoomen und müsste
> dann garantiert irgendwo Aufträge sehen? Bei mir ist da nämlich gar nichts.
>
> Gruss,
> Chaos
>
>
> Am 29. Mai 2013 20:36 schrieb Stefan Keller :
>
>> Hallo.
>>
>> Kort unter Chrome sollte gehen.
>> Kam in den letzten 24 Stunden die Frage "Neue Version verfügbar..."?
>> Zeigt die Version (im Tab "Über Kort") => Version 2.029 an?
>> Ev. hilft ein Reload der ganzen URL http://play.kort.ch .
>> Wenn das nichts hilft, den Cache des Browsers über die Einstellungen
>> leeren (ist ein Phänomen einiger Web Apps).
>>
>> LG, Stefan
>>
>>
>> Am 29. Mai 2013 19:41 schrieb Ronnie Soak :
>> > Ist das Spiel denn momentan überhaupt noch aktiv? Weder mit Chrome noch
>> dem
>> > Android-Browser sehe ich Aufträge oder Checks auf der Karte.
>> > Nicht in meiner Umgebung, nicht bei einer Stichprobe in Frankfurt und
>> auch
>> > nicht in Winterthur, sollte es nur in der Schweiz funktionieren.
>> >
>> > Habe ich da ein technisches Problem oder gibt es da einfach nichts zu
>> tun?
>> >
>> > Gruss,
>> > Chaos
>> >
>> >
>> >
>> > Am 29. Mai 2013 03:13 schrieb Stefan Keller :
>> >
>> >> Liebe Mapper,
>> >>
>> >> In den letzten Monaten haben wir hart gearbeitet, um das Kort Game zu
>> >> verbessern. Kort ist ein standortbasiertes Web-App für Mobiles (Open
>> >> Source) bei dem OpenStreetMap-Fehler spielerisch gelöst und überprüft
>> >> werden. Es ist unseres Wissens eines der ersten Projekte das
>> >> Gamification, Crowd Sourcing und Web-Anwendungen kombiniert.
>> >>
>> >> Es gibt neu folgende Funktionen:
>> >> * Aufträge und Überprüfungen erscheinen in einer Karte.
>> >> * "Sneak Peek"-Funktion, um mehr als nur die nächsten Aufträge zu sehen.
>> >> * "News Tab", um Informationen vom "Hauptquartier" zu erhalten.
>> >> * Registrieren mit Facebook-Account (zusätzlich zu OpenStreetMap und
>> >> Google)
>> >> * Neuer Typ "Restaurants mit fehlenden Küche" (derzeit nur in der
>> Schweiz).
>> >>
>> >> Ein weitere Funktion arbeitet noch im Hintergrund bis es aktiviert
>> >> wird am 12. Juni - also gerade noch rechtzeitig, wenn die FOSSGIS
>> >> 2013-Konferenz (http://www.fossgis.de/konferenz/2013/) seine Türen an
>> >> der HSR in Rapperswil öffnet.
>> >>
>> >> Herzlichst
>> >> Stefan und das Kort Development Team
>> >> http://play.kort.ch (Chrome/iOS/Android - noch kein Firefox)
>> >>
>> >> ___
>> >> Talk-de mailing list
>> >> Talk-de@openstreetmap.org
>> >> http://lists.openstreetmap.org/listinfo/talk-de
>> >>
>> > ___
>> > Talk-de mailing list
>> > Talk-de@openstreetmap.org
>> > http://lists.openstreetmap.org/listinfo/talk-de
>>
>> ___
>> Talk-de mailing list
>> Talk-de@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-de
>>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Kort Game Reloaded!

[Stefan Keller]

Am 30. Mai 2013 11:04 schrieb Ronnie Soak
> Welche Keepright-Fehler werden denn zu Aufträgen?

* Autobahn ohne Bezeichner (Keepright: Motorway without reference)
* Objekt ohne Namen (Keepright: Object without a name)
* Fehlendes Tempolimit (Keepright: Missing speed limit)
* Typ des Wegs unbekannt (Keepright: Type of track unknown)
* Kultstätte/Kirche ohne Religion (Keepright: Place of worship without religion)
* Sprache des Namens unbekannt (Keepright: Language of the name unknown)
* Strasse ohne Namen (Keepright: Street without a name)
* Restaurants ohne Küchenangabe (EOSMDBOne: ab V.2)

Siehe auch FAQ: http://bit.ly/11qRV4d .

> Bei mir (Erfurt, Thüringen) gibt es wie gesagt weder Aufträge noch Checks,
> allerdings durchaus noch einige Fehler bei Keepright.

Du hast recht, da fehlen Daten im Kort Game. Als ob eine ganze Region
(hier: 5) gemäss Gebiets-Schema http://keepright.ipax.at/planet.jpg
fehlt. Dem muss ich nachgehen.

LG, Stefan

Am 30. Mai 2013 11:04 schrieb Ronnie Soak :
> Welche Keepright-Fehler werden denn zu Aufträgen?
> Könnte man dann vergleichen, ob bei Keepright entsprechende Fehler in der
> Nähe sind, die dann eigentlich bei KRT als Aufträge auftauchen müssten?
>
> Bei mir (Erfurt, Thüringen) gibt es wie gesagt weder Aufträge noch Checks,
> allerdings durchaus noch einige Fehler bei Keepright. Allerdings nicht
> unbedingt aus allen Keepright-Kategorien.
>
> Also da müsst ihr aus Spiel-Sicht aber noch dran arbeiten. Das ist ja ein
> riesen Motivationskiller wenn man das zum ersten mal öffnet und gar nichts
> zu tun hat.
>
> Gruss,
> Chaos
>
>
>
> Am 30. Mai 2013 09:36 schrieb Markus Semm :
>
>> Hallo,
>> bei mir werden auch keine Aufgaben angezeigt im Zentrum von Berlin.
>> Mit der alten Version waren da noch reichlich Aufgaben zu sehen.
>> Windows7, korrekte Anzeige meiner eigenen Position, Chrome, alles laufend
>> aktualisiert.
>>
>> -Ursprüngliche Nachricht-
>> Von: Stefan Keller [mailto:sfkel...@gmail.com]
>> Gesendet: Donnerstag, 30. Mai 2013 09:25
>> An: Openstreetmap allgemeines in Deutsch
>> Betreff: Re: [Talk-de] Kort Game Reloaded!
>>
>> Der eigene Standort wird mit einem blauen Punkt angezeigt und kommt
>> vom Browser Interface.
>> Das Kort Game zeigt aktive Aufträge & Überprüfungen 5 km um den
>> eigenen Standort.
>> Das bleibt auch beim Rauszoomen so.
>> Mit der neuen Sneak Peek kann man sich auch Aufträge & Überprüfungen
>> anderswo anzeigen lassen.
>> Da sehe ich in Deutschland und Frankreich überall Daten...
>> Laut dem HTML5-Framework, das wir verwenden werden folgende Geräte
>> unterstützt:
>> http://www.sencha.com/products/touch/features/
>> Ich hoffe, das hilft.
>>
>> LG, Stefan
>>
>>
>> Am 30. Mai 2013 08:29 schrieb Ronnie Soak :
>> > Die Update-Frage kam heute. Jetzt steht unter  "about"  2.0.33
>> > Leider immer noch keine Aufträge.
>> > Reload bringt leider nichts.
>> > Ich habe das auch unter einem nagelneuen Android versucht, bei dem der
>> > Browser garantiert noch nier kort.ch gesehen hat.
>> >
>> > Gibt es eine Zoomlevel-Grenze, bis zu der Aufträge angezeigt werden, oder
>> > könnte ich auf ganz Deutschland herauszoomen und müsste
>> > dann garantiert irgendwo Aufträge sehen? Bei mir ist da nämlich gar
>> nichts.
>> >
>> > Gruss,
>> > Chaos
>> >
>> >
>> > Am 29. Mai 2013 20:36 schrieb Stefan Keller :
>> >
>> >> Hallo.
>> >>
>> >> Kort unter Chrome sollte gehen.
>> >> Kam in den letzten 24 Stunden die Frage "Neue Version verfügbar..."?
>> >> Zeigt die Version (im Tab "Über Kort") => Version 2.029 an?
>> >> Ev. hilft ein Reload der ganzen URL http://play.kort.ch .
>> >> Wenn das nichts hilft, den Cache des Browsers über die Einstellungen
>> >> leeren (ist ein Phänomen einiger Web Apps).
>> >>
>> >> LG, Stefan
>> >>
>> >>
>> >> Am 29. Mai 2013 19:41 schrieb Ronnie Soak <
>> chaoschaos0...@googlemail.com>:
>> >> > Ist das Spiel denn momentan überhaupt noch aktiv? Weder mit Chrome
>> noch
>> >> dem
>> >> > Android-Browser sehe ich Aufträge oder Checks auf der Karte.
>> >> > Nicht in meiner Umgebung, nicht bei einer Stichprobe in Frankfurt und
>> >> auch
>> >> > nicht in Winterthur, sollte es nur in der Schweiz funktionieren.
>> >> >
>> >> > Habe ich da ein technisches Problem oder gibt es da einfach nichts zu
>> >> tun?
>> >>

Re: [Talk-de] Kort Game Reloaded!

[Stefan Keller]

Am 30. Mai 2013 20:55 schrieb Ruben Kelevra :
> Er sagt aber "Straße ohne Namen" aber die "Straße" hat keinen
> Highway-Tag, entsprechend ist es keine Straße.

Danke für den Hinweis. Und man kann solche "falschen Positive"
Keepright melden, von denen wir die Fehlerdaten holen.

Wenn das stimmt, dann kannst du "Nicht lösbar" antworten.

Um welchen Weg handelt es sich denn genau? Ich sehe dort lauter
highway=footway wie z.B. diesen
http://www.openstreetmap.org/browse/way/217362208

LG, Stefan

Am 30. Mai 2013 20:55 schrieb Ruben Kelevra :
> Er sagt aber "Straße ohne Namen" aber die "Straße" hat keinen
> Highway-Tag, entsprechend ist es keine Straße.
>
>
> LG Ruben
>
> 2013/5/30 Stefan Keller :
>> Hallo Ruben
>>
>> Was meinst du genau?
>> Ungetaggte Wege sind ja gerade der Grund, warum Keepright (und damit
>> das Kort Gam) das als Fehler meldet, der Strassentyp fehle...
>>
>> LG, Stefan
>>
>>
>> Am 30. Mai 2013 03:06 schrieb Ruben Kelevra :
>>> Wollte mich schon hierdrüber beschweren:
>>>
>>> http://s1.directupload.net/file/d/3271/xilydai5_png.htm
>>>
>>> Weils ein Fußweg zu einem Haus ist, das war aber ein ungetaggter Weg,
>>> denke sowas sollte euer Programm ignorieren :)
>>>
>>>
>>>
>>> LG Ruben
>>>
>>> 2013/5/29 André Reichelt :
>>>> Hallo Stefan,
>>>> wie oft werden denn bei Euch die Kartendaten neu eingespielt? Weil das,
>>>> was ich hier vor Ort angezeigt bekomme, ist mindestens einen Monat alt.
>>>>
>>>> Gruß
>>>> André
>>>>
>>>> ___
>>>> Talk-de mailing list
>>>> Talk-de@openstreetmap.org
>>>> http://lists.openstreetmap.org/listinfo/talk-de
>>>
>>> ___
>>> Talk-de mailing list
>>> Talk-de@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-de
>>
>> ___
>> Talk-de mailing list
>> Talk-de@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-de
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Kort Game Reloaded!

[Stefan Keller]

Hallo Ronnie

Nun gibt es wieder Daten für ganz Deutschland!

LG, Stefan


Am 30. Mai 2013 15:05 schrieb Stefan Keller :
> Am 30. Mai 2013 11:04 schrieb Ronnie Soak
>> Welche Keepright-Fehler werden denn zu Aufträgen?
>
> * Autobahn ohne Bezeichner (Keepright: Motorway without reference)
> * Objekt ohne Namen (Keepright: Object without a name)
> * Fehlendes Tempolimit (Keepright: Missing speed limit)
> * Typ des Wegs unbekannt (Keepright: Type of track unknown)
> * Kultstätte/Kirche ohne Religion (Keepright: Place of worship without 
> religion)
> * Sprache des Namens unbekannt (Keepright: Language of the name unknown)
> * Strasse ohne Namen (Keepright: Street without a name)
> * Restaurants ohne Küchenangabe (EOSMDBOne: ab V.2)
>
> Siehe auch FAQ: http://bit.ly/11qRV4d .
>
>> Bei mir (Erfurt, Thüringen) gibt es wie gesagt weder Aufträge noch Checks,
>> allerdings durchaus noch einige Fehler bei Keepright.
>
> Du hast recht, da fehlen Daten im Kort Game. Als ob eine ganze Region
> (hier: 5) gemäss Gebiets-Schema http://keepright.ipax.at/planet.jpg
> fehlt. Dem muss ich nachgehen.
>
> LG, Stefan
>
> Am 30. Mai 2013 11:04 schrieb Ronnie Soak :
>> Welche Keepright-Fehler werden denn zu Aufträgen?
>> Könnte man dann vergleichen, ob bei Keepright entsprechende Fehler in der
>> Nähe sind, die dann eigentlich bei KRT als Aufträge auftauchen müssten?
>>
>> Bei mir (Erfurt, Thüringen) gibt es wie gesagt weder Aufträge noch Checks,
>> allerdings durchaus noch einige Fehler bei Keepright. Allerdings nicht
>> unbedingt aus allen Keepright-Kategorien.
>>
>> Also da müsst ihr aus Spiel-Sicht aber noch dran arbeiten. Das ist ja ein
>> riesen Motivationskiller wenn man das zum ersten mal öffnet und gar nichts
>> zu tun hat.
>>
>> Gruss,
>> Chaos
>>
>>
>>
>> Am 30. Mai 2013 09:36 schrieb Markus Semm :
>>
>>> Hallo,
>>> bei mir werden auch keine Aufgaben angezeigt im Zentrum von Berlin.
>>> Mit der alten Version waren da noch reichlich Aufgaben zu sehen.
>>> Windows7, korrekte Anzeige meiner eigenen Position, Chrome, alles laufend
>>> aktualisiert.
>>>
>>> -Ursprüngliche Nachricht-
>>> Von: Stefan Keller [mailto:sfkel...@gmail.com]
>>> Gesendet: Donnerstag, 30. Mai 2013 09:25
>>> An: Openstreetmap allgemeines in Deutsch
>>> Betreff: Re: [Talk-de] Kort Game Reloaded!
>>>
>>> Der eigene Standort wird mit einem blauen Punkt angezeigt und kommt
>>> vom Browser Interface.
>>> Das Kort Game zeigt aktive Aufträge & Überprüfungen 5 km um den
>>> eigenen Standort.
>>> Das bleibt auch beim Rauszoomen so.
>>> Mit der neuen Sneak Peek kann man sich auch Aufträge & Überprüfungen
>>> anderswo anzeigen lassen.
>>> Da sehe ich in Deutschland und Frankreich überall Daten...
>>> Laut dem HTML5-Framework, das wir verwenden werden folgende Geräte
>>> unterstützt:
>>> http://www.sencha.com/products/touch/features/
>>> Ich hoffe, das hilft.
>>>
>>> LG, Stefan
>>>
>>>
>>> Am 30. Mai 2013 08:29 schrieb Ronnie Soak :
>>> > Die Update-Frage kam heute. Jetzt steht unter  "about"  2.0.33
>>> > Leider immer noch keine Aufträge.
>>> > Reload bringt leider nichts.
>>> > Ich habe das auch unter einem nagelneuen Android versucht, bei dem der
>>> > Browser garantiert noch nier kort.ch gesehen hat.
>>> >
>>> > Gibt es eine Zoomlevel-Grenze, bis zu der Aufträge angezeigt werden, oder
>>> > könnte ich auf ganz Deutschland herauszoomen und müsste
>>> > dann garantiert irgendwo Aufträge sehen? Bei mir ist da nämlich gar
>>> nichts.
>>> >
>>> > Gruss,
>>> > Chaos
>>> >
>>> >
>>> > Am 29. Mai 2013 20:36 schrieb Stefan Keller :
>>> >
>>> >> Hallo.
>>> >>
>>> >> Kort unter Chrome sollte gehen.
>>> >> Kam in den letzten 24 Stunden die Frage "Neue Version verfügbar..."?
>>> >> Zeigt die Version (im Tab "Über Kort") => Version 2.029 an?
>>> >> Ev. hilft ein Reload der ganzen URL http://play.kort.ch .
>>> >> Wenn das nichts hilft, den Cache des Browsers über die Einstellungen
>>> >> leeren (ist ein Phänomen einiger Web Apps).
>>> >>
>>> >> LG, Stefan
>>> >>
>>> >>
>>> >> Am 29. Mai 2013 19:41 schrieb Ronnie Soak <
>>> chaoschaos0...@googlemail.com>:
>>> >

Re: [Talk-de] TSP Routing auf OSM Basis?

[Stefan Keller]

Hallo Ralf

Unser Tourpl macht das (Python) mit Daten für die Schweiz: www.tourpl.ch

LG, Stefan


Am 27. Mai 2013 20:29 schrieb RalfGesellensetter :
> Hallo, ich suche eine Software,
>
> die zu gegebenen Adressen die günstigste Route
> bestimmt. ORS optimiert nicht die Reihenfolge der
> Vias, kann also das Problem des "Handungsreisenden"
> nicht lösen.
>
> Unter [1] gabe es keine konstruktive Antwort,
> wer weiß mehr?
>
> Danke
> Ralf
>
> 1. 
> http://gis.19327.n5.nabble.com/quot-Travelling-salesman-quot-Router-auf-OSM-Datenbasis-td5309072.html
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM

[Stefan Keller]

Hallo,

Damit der Thread nicht irgendwie so stehen bleibt:
OSM ist primär eine Geodatenbank mit Vektor- bzw. Topologie-Daten und
Attributen (Tags).
Man erfasst was man in der Realität draussen sieht.
Farben spielen da noch kaum eine Rolle - höchstens bei
(Orientierungs-)Tafeln und Wegweisern.
Farbe kommt erst ins Spiel, wenn die Geodaten für einen bestimmten
Zweck (Zielpublikum? Papier/Bildschirm?) gerendert werden.
Die Startseite (Slippy Map) von OSM.org ist da nur eine Möglichkeit
unter vielen Projekten, die OSM mehr oder weniger nahe stehen.

LG, Stefan

2013/5/27 Tobias Conradi :
> 2013/5/27 Sven Geggus :
>> Die Bahnlinien hier in der Gegend haben alle die selbe Farbe: rostig braun.
>
> "Bahnlinie": http://de.wikipedia.org/wiki/Linie_(Verkehr)
>
> "hier in der Gegend":
> http://geggus.net/sven/sven.shtml
> 76227 Karlsruhe
>
> Test:
> http://www.kvv.de/fileadmin/user_upload/kvv/dokumente/netz/liniennetz/2013/L0SCHI_APR13_Internet.pdf
> gibt: Grün, Gelb, Rot, Blau
>
> Du meintest vielleicht Schienen:
> http://de.wikipedia.org/wiki/Schiene_(Schienenverkehr)
>
> --
> Tobias Conradi
> Rheinsberger Str. 18
> 10115 Berlin
> Germany
>
> http://tobiasconradi.com
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Offizielle Definitionen der Linienfarben - KVV

[Stefan Keller]

Hallo,

Bei OSM gibt es keine "offiziellen" Farben.
Mehr noch wie es eigentlich auch keine "offiziellen" Tags (Attribute) gibt.
Wenn überhaupt, müsste genauer erläutert werden für was genau die
Farben dienen (Zweck? Papier/Monitor?).
Siehe Diskussion "CMYK und RGB Farben - Standardisierung in OSM" hier.

LG, Stefan

Am 27. Mai 2013 17:38 schrieb Tobias Conradi :
> Mail an: i...@kvv.karlsruhe.de
> CC an: talk-de@openstreetmap.org
> ---
>
> Sehr geehrte Damen und Herren,
>
> für die Linienfarben in Berlin-Brandenburg liegen bei OpenStreetMap
> offizielle Definitionen der Linienfarben vor:
>
> http://wiki.openstreetmap.org/w/images/a/a7/Linienfarben_SPNV.PDF
>
> Es wurde bestätigt, dass die CMYK-Werte verbindlich sind.
>
> Wie sind die Linienfarben beim KVV defniert, könnten Sie dazu ein
> Dokument bereitstellen?
>
> Mit freundlichen Grüssen
> Tobias Conradi
>
> --
> Tobias Conradi
> Rheinsberger Str. 18
> 10115 Berlin
> Germany
>
> http://tobiasconradi.com
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] CMYK / RGB - Versuch einer Zusammenfassung

[Stefan Keller]

Hallo Tobias

Danke für die Zusammenfassung.
Mir ist nicht klar, für was genau diese Farben-Normierung dient
(Zweck? Papier/Monitor?).
Siehe auch die Diskussion "CMYK und RGB Farben - Standardisierung in OSM" hier.

LG, Stefan


Am 31. Mai 2013 19:42 schrieb Tobias Conradi :
> 1)
> Es gibt Personen, die wollen nur grobe Angaben, rot/gelb/grün usw.
> bzw. wohl die Web-Color-Equivalente, red/yellow/green etc., vielleicht
> noch erweitert bis zur Liste der benannten Farben in CSS3:
>
> http://www.w3.org/TR/css3-color/#svg-color
>
> 2)
> Es gibt Personen, die wollen die Originaldefinitionen festhalten, d.h.
> z.B. Werte in CMYK oder RAL.
>
> 3)
> Es gibt Personen, die wollen die Originaldefinitionen in CIELAB
> umrechnen und dann so ablegen.
>
> 4)
> Es gibt Personen, die wollen die Originaldefinitionen eindeutig in RGB
> umrechnen und dann so ablegen.
>
> 5)
> http://wiki.openstreetmap.org/wiki/Key:colour
> erlaubt 1) und 4).
>
> 6)
> Von den Personen, die nur eine grobe Angabe ablegen wollen, kamen
> Erläuterungen, dass man die Farbe gar nicht so genau erfassen kann,
> z.B.
> http://lists.openstreetmap.org/pipermail/talk-de/2013-May/102492.html
>
> 7)
> Wenn die Farbwerte der Personen aus Gruppe 4) in den Unschärfebereich
> wie in 6) genannt fallen, würde eine Notation nach 4) auch für die
> Personen OK sein, die sich für 1) mit der Begründung aus 6)
> entschlossen haben.
>
>
> --
> Tobias Conradi
> Rheinsberger Str. 18
> 10115 Berlin
> Germany
>
> http://tobiasconradi.com
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition

[Stefan Keller]

Hallo

Um es nochmals zu betonen: Bei der Datenerfassung mit OSM geht es
nicht darum Pläne (bzw. deren Inhalte) zu erfassen, sondern das was
man draussen sieht und mit GPS und Kamera festhalten kann.

Eine S-Bahn-Linie ist natürlich immer auch beschriftet typischerweise
mit einer Zahlen-/Buchstaben-Kombination und einer gut von anderen
S-Bahnlinien unterscheidbaren Hintergrundfarbe. Primär wird aber der
Name erfasst, z.B. "S5", oder "S-7". Dieses Attribut (Tag) kann man
dann auf verschieden Arten nutzen - und letztlich auch darstellen -
von mir aus mit den "offiziellen" Farben des Bahnbetreibers.

Das ist dann aber sog. Styling-Information, die eher zum Kartenprodukt
gehört. Dieses Wiki hier beschreibt aber meiner Meinung nach nicht
Kartenprodukte, sondern dokumentiert primär OSM-Objekte der
OSM-Datenbank.

LG, Stefan

Am 2. Juni 2013 00:22 schrieb Tobias Conradi :
> On Sat, Jun 1, 2013 at 8:36 PM, Martin Koppenhoefer
>  wrote:
>> mein Punkt war, wenn man sich schon die Mühe macht, und nachforscht bzw. wie 
>> hier eine Anfrage beim Betreiber stellt (was ich auf keinen Fall erwarten 
>> würde), dann kann man das Ergebnis auch so in OSM eintragen, und nicht nur 
>> das in ein anderes Farbsystem gewandelte, insbesondere wenn die Konversion 
>> irreversibel ist.
>>
>> Wenn colour nicht der tag ist, dann vielleicht official_colour oder so.
>
> OK! :-)
>
> --
> Tobias Conradi
> Rheinsberger Str. 18
> 10115 Berlin
> Germany
>
> http://tobiasconradi.com
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Offizielle Definitionen der Linienfarben - KVV

[Stefan Keller]

Hallo Tobias

Am 5. Juni 2013 00:38 schrieb Tobias Knerr :
> Wie auch dort geht dein Kommentar wegen des zugrundeliegenden
> Missverständnisses am Thema vorbei.

Farbe als Attribut zu erfassen ist ein sog. "Smell", d.h. ein Hinweis
auf einen potentiellen Fehler.
Geht's darum, die OeV-Linie auf einem Papier (RAL/CMYK sind ja
Druckfarben) darstellen zu können, ohne das Transportunternehmen zu
kennen?
Das muss ich nochmals genauer anschauen. Ein Blick auf's ÖPNV-Schema
[1] (Attribut color) bringt leider auch keine Klarheit.

> Diese Farbangabe ist etwas, das bereits existiert und in OSM lediglich
> eingetragen würde - nichts das erst durch den OSM-Renderer bestimmt wird.

Es gibt m.E. keinen (offiziellen) OSM-Renderer. Und warum "würde"?

LG, Stefan

[1] http://wiki.openstreetmap.org/wiki/%C3%96PNV_Schema



Am 5. Juni 2013 00:38 schrieb Tobias Knerr :
> Am 05.06.2013 00:09, schrieb Stefan Keller:
>> Bei OSM gibt es keine "offiziellen" Farben.
>
> Es geht um das Eintragen derjenigen Farbe, die der Betreiber einer Linie
> offiziell vergibt und selbst z.B. auf Nummerntafeln an den Wagen,
> Anzeigetafeln an Haltestellen oder in Netzplänen verwendet.
>
>> Siehe Diskussion "CMYK und RGB Farben - Standardisierung in OSM" hier.
>
> Wie auch dort geht dein Kommentar wegen des zugrundeliegenden
> Missverständnisses am Thema vorbei.
>
> Diese Farbangabe ist etwas, das bereits existiert und in OSM lediglich
> eingetragen würde - nichts das erst durch den OSM-Renderer bestimmt wird.
>
> Gruß,
> Tobias
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

[Talk-de] Kort Game mit neuer Aktion/Kampagne dieses Wochenende!

[Stefan Keller]

Liebe Mapper,

Pünktlich zur FOSSGIS startete das Kort-Team eine neue Funktion: Die
Kort-Aktion!

Wer in sich der Deutschschweiz aufhält, sollte Ausschau halten nach
Aufträgen und Überprüfungen mit einem Stern. Diese ergeben doppelte
Koins. Alle anderen aufgepasst: Bald gibt es weitere
Aktionen/Kampagnen.

Die  Aktion/Kampagne  geht morgen Sonntag, 16. Juni 2013, zu Ende;
also nichts wie los! Weitersagen, v.a. auch an GeoCacher :-)

Stefan & das Kort-Team
www.kort.ch bzw. http://play.kort.ch!

[1] Link zum Vortrag vom 13.6.2013 an der FOSSGIS:
http://www.fossgis.de/konferenz/2013/programm/events/541.de.html

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

Re: [Talk-de] Kort Game mit neuer Aktion/Kampagne dieses Wochenende!

[Stefan Keller]

Hallo Markus

Schön, dass du an die FOSSGIS 2013 gekommen bist! Entschuldige mich,
dass ich als Hauptverantwortlicher nicht mehr Zeit für Gespräche
hatte.

Ja, die Bedenken des automatischen Zurückschreibens werden immer
wieder hervorgebracht und wir nehmen sie ernst. Bei näherem Hinschauen
verlieren sie sich meist. Es war übrigens nicht nur Frederik, der dies
in diesem konkreten Fall entspannt sieht, sondern ein paar weitere
gestandene Mapper im Saal.

Meine Aussage dazu ist, dass ich noch dieses Jahr das automatische
Zurückschreiben vorhabe. Ich plane dies mit dem Usernamen "KortGame"
zu tun, werde voraussichtlich zusätzlich mitloggen und es vorher
ankündigen.

Es ist übrigens zwar richtig, dass 25.000 Aufträge erledigt wurden. Da
aber pro erledigtem Auftrag drei bis fünf(!) Überprüfungen gefordert
sind, sind es "erst" 700 Änderungen, die bereit sind, hochgeladen zu
werden (unter Berücksichtigung unlösbarer Aufträge). Die aktuellste
Statistik ist hier [1].

Beachte bitte auch, dass die 700 ("mühsam"? erledigten) Aufträge jetzt
schon in die Datenbank zurückgeschrieben werden können, wenn man die
Lösungen mit Hilfe der Seite [2] in die DB integriert - so wie das bei
vielen etablierten OSM-Dateneintegrationssprojekten gehandhabt wird.

LG, Stefan

P.S. Ich frage mich bei dieser Gelegenheit, ob fünf Überprüfungen von
unabhängigen Usern nicht viel zu hoch angesetzt ist, wenn man bedenkt,
dass Jedermann/-frau erhebblch grösseren Unsinn als ein einziger Tag
eintragen kann - und das ohne Vier-Augen-Kontrolle.

[1] http://www.kort.ch/statistics.php
[2] http://www.kort.ch/proposals.php



Am 15. Juni 2013 17:13 schrieb Markus Semm :
> Hallo Stefan,
>
> auf der Fossgis wurde diese Woche von den Kort-Entwicklern im Rahmen der 
> Projektpräsentation gesagt, dass die bislang fast 25.000 Änderungen, die 
> Nutzer von Kort bislang vorgenommen haben, noch gar nicht an OSM übertragen 
> wurden, wohl wegen grundsätzlicher Bedenken hinsichtlich einer automatischen 
> Änderung von Daten in OSM, die die schweizer Community vorgetragen hat.
> Frederik hat zwar in der selben Session darauf hingewiesen, dass er das Thema 
> "automatisierte Updates" im Fall Kort entspannt sieht (und ich schließe mich 
> dem an), vom Kort-Team kam aber dann keine Aussage mehr, ob und wann die 
> mühsam von mir und vielen anderen recherchierten Daten zurückfließen ins OSM.
>
> Kannst Du dazu etwas Konkretes sagen?
>
> Gruß
> Markus
>
> -Ursprüngliche Nachricht-
> Von: Stefan Keller [mailto:sfkel...@gmail.com]
> Gesendet: Samstag, 15. Juni 2013 17:03
> An: Openstreetmap allgemeines in Deutsch
> Betreff: [Talk-de] Kort Game mit neuer Aktion/Kampagne dieses Wochenende!
>
> Liebe Mapper,
>
> Pünktlich zur FOSSGIS startete das Kort-Team eine neue Funktion: Die
> Kort-Aktion!
>
> Wer in sich der Deutschschweiz aufhält, sollte Ausschau halten nach
> Aufträgen und Überprüfungen mit einem Stern. Diese ergeben doppelte
> Koins. Alle anderen aufgepasst: Bald gibt es weitere
> Aktionen/Kampagnen.
>
> Die  Aktion/Kampagne  geht morgen Sonntag, 16. Juni 2013, zu Ende;
> also nichts wie los! Weitersagen, v.a. auch an GeoCacher :-)
>
> Stefan & das Kort-Team
> www.kort.ch bzw. http://play.kort.ch!
>
> [1] Link zum Vortrag vom 13.6.2013 an der FOSSGIS:
> http://www.fossgis.de/konferenz/2013/programm/events/541.de.html
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Kort Game mit neuer Aktion/Kampagne dieses Wochenende!

[Stefan Keller]

Hallo Frederik

Am 15. Juni 2013 21:17 schrieb Frederik Ramm :
...
> *Gegen* ein automatisches Zurueckschreiben spricht unter anderem ein
> "principiis obsta"-Argument - wenn Kort das jetzt darf, wem muessen wir das
> dann noch alles erlauben, und werden es in jedem Fall gruendlich

Wir nennen das "Präzedenzfall" und ich verstehe das.

...
> Ich glaube, es waere gut, wenn diese geplante naechste Projektphase bei Kort
> mit automatischem Hochspielen der Anderungen in Abstimmung mit der Data
> Working Group gestartet werden wuerde und wenn man das allgemein als
> "Erprobungsphase" deklarieren koennte; so wird Dritten klar, dass das Modell
> nicht ohne Ruecksprache nachgeahmt werden soll. Eventuell kann die Community
> dann gemeinsam zu einem Konsens kommen, welche Art von Edits auf welche
> Weise "durch Proxy" gemacht werden duerfen und welche nicht.

Gute Vorschlag.

Wenn ich das richtig sehe, geht die Kommunikation über dich [*] - oder
gibt es einen Verteiler?

LG, Stefan

*) http://www.osmfoundation.org/wiki/Data_Working_Group



Am 15. Juni 2013 21:17 schrieb Frederik Ramm :
> Hallo,
>
>
> On 15.06.2013 20:31, Stefan Keller wrote:
>>
>> Ja, die Bedenken des automatischen Zurückschreibens werden immer
>> wieder hervorgebracht und wir nehmen sie ernst. Bei näherem Hinschauen
>> verlieren sie sich meist. Es war übrigens nicht nur Frederik, der dies
>> in diesem konkreten Fall entspannt sieht, sondern ein paar weitere
>> gestandene Mapper im Saal.
>
>
> Ich habe mich zu der Frage nicht geaeussert; es war Jochen, der zum Mikrofon
> griff und meinte, man sollte die Edits doch einfach zurueckschreiben.
>
> Meine persoenliche Haltung zu der Frage ist ein bisschen zwiegespalten.
>
> *Fuer* ein automatisches Zurueckschreiben spricht, dass die Daten in aller
> Regel vermutlich wirklich eine gute Qualitaet haben, da sie von mehreren
> ueberprueft worden sind, und es sind ja auch nicht irgendwelche Imports,
> sondern wirklich extra fuer OSM erfasste Daten.
>
> *Gegen* ein automatisches Zurueckschreiben spricht unter anderem ein
> "principiis obsta"-Argument - wenn Kort das jetzt darf, wem muessen wir das
> dann noch alles erlauben, und werden es in jedem Fall gruendlich
> recherchierte, mehrfach ueberpruefte, relativ vandalismus-sichere Daten
> sein, oder werden andere mit dem Argument "Kort darf das doch auch"
> ploetzlich auch weitreichende Anderungen von geringerer Qualitaet zu
> rechtfertigen versuchen? Das muss man im Auge behalten.
>
> Im allgemeinen sind unsere Hauptargumente gegen "Eintragungen durch Proxy"
> die folgenden:
>
> 1. Die Nutzer, die die Aenderungen vornehmen, sind/werden keine OSM-Nutzer.
> Sie sind Nutzer einer anderen Plattform, wissen im Extremfall nicht einmal
> was von OSM, fuehlen sich nicht als OSM-Contributors. Salopp gesagt, wir
> haben ihre Daten, aber nicht ihr Herz. Auch unsere Statistik kommt
> durcheinander - wir koennen dann nicht mehr zuverlaessig ermitteln, wie
> viele Leute mit welcher Intensitaet in einem bestimmten Bereich an OSM
> arbeiten.
>
> 2., und das folgt direkt aus 1., wir haben keine Moeglichkeit, die Nutzer zu
> kontaktieren. Haette es Kort schon vor 5 Jahren gegeben, wie haetten wir
> dann die Kort-Mitspieler erreichen koennen, um sie um Zustimmung zum
> Lizenzwechsel zu bitten? Oder wenn irgendwo doch mal etwas eingetragen wird,
> was andere Mapper falsch finden, wen koennen sie dann anschreiben mit einer
> Rueckfrage?
>
> 3. Wenn wir feststellen, dass mit einem Nutzer-Acccount urheberrechtlich
> geschueztes oder sonstwie problematisches Material hochgeladen wird, so
> muessen wir im Extremfall alle Edits dieses Nutzers revertieren. Es waere
> schade, wenn sowas mit einem "Gateway"-Account passiert.
>
> Im konkreten Fall ist der Punkt 1 relativ wenig relevant, denn wir haben
> gehoert, dass die allermeisten Kort-Spieler tatsaechlich OSM-Beitragende
> sind. Die Punkte 2 und 3 lassen sich vielleicht im konkreten Fall umschiffen
> oder zumindest abmildern.
>
> Ich glaube, es waere gut, wenn diese geplante naechste Projektphase bei Kort
> mit automatischem Hochspielen der Anderungen in Abstimmung mit der Data
> Working Group gestartet werden wuerde und wenn man das allgemein als
> "Erprobungsphase" deklarieren koennte; so wird Dritten klar, dass das Modell
> nicht ohne Ruecksprache nachgeahmt werden soll. Eventuell kann die Community
> dann gemeinsam zu einem Konsens kommen, welche Art von Edits auf welche
> Weise "durch Proxy" gemacht werden duerfen und welche nicht.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Kort Game mit neuer Aktion/Kampagne dieses Wochenende!

[Stefan Keller]

Hallo Henning

Am 15. Juni 2013 23:06 schrieb Henning Scholland :
> Dann verstehe ich nicht, warum die Mapper dann nicht gleich die Daten in OSM
> eintragen, wenn sie via Kort vor Ort das Fehlen des Objektes bemerkt haben.
> Dann wäre ja der automatische Upload hinfällig. ;-)

Natürlich weil es Spass macht, sich (z.B. beim Warten/Pendeln) mit dem
Handy die Fehler von Kort servieren zu lassen.
Und weil man sich so mit anderen direkt messen kann (siehe dazu auch
die neue Highscore mit der eigenen Platzierung).

LG, Stefan

Am 15. Juni 2013 23:06 schrieb Henning Scholland :
>
> Am 15.06.2013 21:17, schrieb Frederik Ramm:
>>
>> Im allgemeinen sind unsere Hauptargumente gegen "Eintragungen durch Proxy"
>> die folgenden:
>>
>> 1. Die Nutzer, die die Aenderungen vornehmen, sind/werden keine
>> OSM-Nutzer. Sie sind Nutzer einer anderen Plattform, wissen im Extremfall
>> nicht einmal was von OSM, fuehlen sich nicht als OSM-Contributors. Salopp
>> gesagt, wir haben ihre Daten, aber nicht ihr Herz. Auch unsere Statistik
>> kommt durcheinander - wir koennen dann nicht mehr zuverlaessig ermitteln,
>> wie viele Leute mit welcher Intensitaet in einem bestimmten Bereich an OSM
>> arbeiten.
>>
>> [...]
>>
>> Im konkreten Fall ist der Punkt 1 relativ wenig relevant, denn wir haben
>> gehoert, dass die allermeisten Kort-Spieler tatsaechlich OSM-Beitragende
>> sind.
>
> Dann verstehe ich nicht, warum die Mapper dann nicht gleich die Daten in OSM
> eintragen, wenn sie via Kort vor Ort das Fehlen des Objektes bemerkt haben.
> Dann wäre ja der automatische Upload hinfällig. ;-)
>
> Henning
>
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Kort Game mit neuer Aktion/Kampagne dieses Wochenende!

[Stefan Keller]

Hallo Henning

Am 16. Juni 2013 14:19 schrieb Henning Scholland :
...
> Frederiks Aussage war: Die meisten KORT-Spieler sind Mapper, ergo ist es
> nicht so schlimm, wenn die Verbesserungen via Proxy zu OSM fließen. Wenn dem
> so ist, stelle ich die Frage, warum das dann überhaupt nötig ist und diese
> Mapper den Fehler nicht direkt beheben. Wenn dem nicht so ist, sehe ich hier
> keinen Grund, warum man KORT anders behandeln sollte als andere Projekte.

So wie es jetzt ist - mit den Validierungen ohne direktes Einfliessen
zu OSM - ist eine direkte Konsequenz daraus, dass es sich hier um ein
Spiel handelt, also um eine Art Geographiequiz, wo die Frage gestellt
wird, ob man den Küchentyp eines Restaurants kennt. Wenn dir das Video
zu lang ist, schau doch mal diese Webseiten an: [1][2].

Die Statistik hier [3] zeigt das aktuelle Verhältnis der Accounts -
wobei das v.a. Zahl der Anmeldungen anzeigt, nicht die "Aktiven". Es
zeigt, dass die Mehrheit sich mit dem OSM-Account angemeldet hat. Ich
denke es hat auch viele aktive GeoCacher darunter. Es ist hier ja auch
eine Lösung gesucht für Nicht-OSM-Accounts.

Eines der Ziele des Kort Games war, einerseits bestehende Mapper,
welche die Lust etwas verloren haben, zum Wieder-Mitmachen zu
animieren, wie auch neue Mapper zu gewinnen, in dem sie spielerisch zu
OSM beitragen können.

Der Unterschied zu Wheelmap ist, dass wir in Kort nur von
Verbesserungen sprechen, die mind. drei Mal(!) von anderen Spielern,
die nichts voneinander wissen, überprüft, bzw. bestätigt wurden.

LG, Stefan


[1] http://wiki.openstreetmap.org/wiki/KortGame
[2] http://www.kort.ch/
[3] http://www.kort.ch/statistics.php


Am 16. Juni 2013 14:19 schrieb Henning Scholland :
>
> Am 16.06.2013 09:13, schrieb Michael Kugelmann:
>
>> Am 16.06.2013 00:14, schrieb Henning Scholland:
>>>
>>> Ich kann mich als Mapper doch via Kort zu "Fehlern" führen lassen, vor
>>> Ort dann alles Überprüfen und das sowohl Kort melden als auch in OSM
>>> eintragen.
>>
>> KORT ist ein Spiel, sieh Dir die (bald veröffentlichte) Videoaufzeichnung
>> von der FOSSGIS 2013 an, auf der es einen Vortrag (inkl. Livedemo) dazu gab.
>> Daraus ergibt sich, dass die Spieler die Edits dort eher nicht in
>> JOSM/iD/... fixen werden sondern in KORT.
>
>
> Frederiks Aussage war: Die meisten KORT-Spieler sind Mapper, ergo ist es
> nicht so schlimm, wenn die Verbesserungen via Proxy zu OSM fließen. Wenn dem
> so ist, stelle ich die Frage, warum das dann überhaupt nötig ist und diese
> Mapper den Fehler nicht direkt beheben. Wenn dem nicht so ist, sehe ich hier
> keinen Grund, warum man KORT anders behandeln sollte als andere Projekte.
> Bei der Wheelmap und ihrem Editor gab es große Diskussionen mit dem
> Resultat, dass Edits, die über wheelchair=* hinaus gehen, nur noch via
> OSM-Account möglich sind.
>
> Henning
>
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Kort Game mit neuer Aktion/Kampagne dieses Wochenende!

[Stefan Keller]

Hallo Simeon

Vorab: Kort basiert auf Daten von keepright und neu auf mittels
osm2pgsql nach PostgreSQL aufbereitete Daten. "Sprache des Namens" ist
ein Fehlertyp von keepright.

Wie soll ein Auswertesystem "merken" in welcher Sprache ein Name
geschrieben ist?

"Sprache des Namens" finde ich sehr sinnvoll, denn es ist durchaus
nicht so, dass Ländergrenzen eine Sprachgrenze bilden würden,
geschweige denn dass innerhalb eines Landes oder Region nur eine
Sprache gesprochen wird (auch wenn das einige Landsmänner aus DE, FR,
IT oder den USA immer wieder meinen ;-)).

LG, Stefan

Am 18. Juni 2013 15:48 schrieb Simeon :
> Hallo Stefan und alle anderen,
>
> Ich wollte die Tage einige Vorschläge zurück zu OSM eintragen, da fiel mir
> auf, dass alle aufgeführten Proposals nur von der Art "Sprache des Namens
> unbekannt" sind. Nach Nachfrage im Forum (
> http://forum.openstreetmap.org/viewtopic.php?id=21557 ) bin ich davon
> abgekommen, die alle einzutragen, da sie meiner (und auch der anderen
> Poster) Meinung nach redundant und unnötig ist. Was hattet ihr euch überlegt
> als ihr die ins Spiel genommen habt? Gibt es Gründe, die alle doch
> einzutragen? Lohnt es sich, diese Art Fehler raus zunehmen sodass mehr
> sinnvollere Tasks anfallen?
>
> Grüße - Theodin
>
>
> Am 15.06.2013 17:13, schrieb Markus Semm:
>
>> Hallo Stefan,
>>
>> auf der Fossgis wurde diese Woche von den Kort-Entwicklern im Rahmen der
>> Projektpräsentation gesagt, dass die bislang fast 25.000 Änderungen, die
>> Nutzer von Kort bislang vorgenommen haben, noch gar nicht an OSM übertragen
>> wurden, wohl wegen grundsätzlicher Bedenken hinsichtlich einer automatischen
>> Änderung von Daten in OSM, die die schweizer Community vorgetragen hat.
>> Frederik hat zwar in der selben Session darauf hingewiesen, dass er das
>> Thema "automatisierte Updates" im Fall Kort entspannt sieht (und ich
>> schließe mich dem an), vom Kort-Team kam aber dann keine Aussage mehr, ob
>> und wann die mühsam von mir und vielen anderen recherchierten Daten
>> zurückfließen ins OSM.
>>
>> Kannst Du dazu etwas Konkretes sagen?
>>
>> Gruß
>> Markus
>>
>> -Ursprüngliche Nachricht-
>> Von: Stefan Keller [mailto:sfkel...@gmail.com]
>> Gesendet: Samstag, 15. Juni 2013 17:03
>> An: Openstreetmap allgemeines in Deutsch
>> Betreff: [Talk-de] Kort Game mit neuer Aktion/Kampagne dieses Wochenende!
>>
>> Liebe Mapper,
>>
>> Pünktlich zur FOSSGIS startete das Kort-Team eine neue Funktion: Die
>> Kort-Aktion!
>>
>> Wer in sich der Deutschschweiz aufhält, sollte Ausschau halten nach
>> Aufträgen und Überprüfungen mit einem Stern. Diese ergeben doppelte
>> Koins. Alle anderen aufgepasst: Bald gibt es weitere
>> Aktionen/Kampagnen.
>>
>> Die  Aktion/Kampagne  geht morgen Sonntag, 16. Juni 2013, zu Ende;
>> also nichts wie los! Weitersagen, v.a. auch an GeoCacher :-)
>>
>> Stefan & das Kort-Team
>> www.kort.ch bzw. http://play.kort.ch!
>>
>> [1] Link zum Vortrag vom 13.6.2013 an der FOSSGIS:
>> http://www.fossgis.de/konferenz/2013/programm/events/541.de.html
>>
>> ___
>> Talk-de mailing list
>> Talk-de@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-de
>>
>>
>> ___
>> Talk-de mailing list
>> Talk-de@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-de
>>
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Kort Game mit neuer Aktion/Kampagne dieses Wochenende!

[Stefan Keller]

Hallo Theodin (sorry meine Namensverwechslung)

Ich sehe gerade, dass es bei den Lösungen keine Möglichkeit mehr gibt,
weitere 10 Lösungen anzuzeigen. Damit könntest du nach "spannenderen"
Lösungen suchen und andere weglassen. Das hatten wir mal in einer
früheren Version drin. Ich schaue mal, ob wir wenigstens dieses
"Blättern" wieder hinkriegen.

LG, Stefan

P.S. Die Lösungen-Seite ist übrigens so langsam, weil es jeden der 10
Einträge mit einem Aufruf an OSM prüfen muss, ob das OSM-Objekt noch
vorhanden ist.


Am 18. Juni 2013 16:04 schrieb Stefan Keller :
> Hallo Simeon
>
> Vorab: Kort basiert auf Daten von keepright und neu auf mittels
> osm2pgsql nach PostgreSQL aufbereitete Daten. "Sprache des Namens" ist
> ein Fehlertyp von keepright.
>
> Wie soll ein Auswertesystem "merken" in welcher Sprache ein Name
> geschrieben ist?
>
> "Sprache des Namens" finde ich sehr sinnvoll, denn es ist durchaus
> nicht so, dass Ländergrenzen eine Sprachgrenze bilden würden,
> geschweige denn dass innerhalb eines Landes oder Region nur eine
> Sprache gesprochen wird (auch wenn das einige Landsmänner aus DE, FR,
> IT oder den USA immer wieder meinen ;-)).
>
> LG, Stefan
>
> Am 18. Juni 2013 15:48 schrieb Simeon :
>> Hallo Stefan und alle anderen,
>>
>> Ich wollte die Tage einige Vorschläge zurück zu OSM eintragen, da fiel mir
>> auf, dass alle aufgeführten Proposals nur von der Art "Sprache des Namens
>> unbekannt" sind. Nach Nachfrage im Forum (
>> http://forum.openstreetmap.org/viewtopic.php?id=21557 ) bin ich davon
>> abgekommen, die alle einzutragen, da sie meiner (und auch der anderen
>> Poster) Meinung nach redundant und unnötig ist. Was hattet ihr euch überlegt
>> als ihr die ins Spiel genommen habt? Gibt es Gründe, die alle doch
>> einzutragen? Lohnt es sich, diese Art Fehler raus zunehmen sodass mehr
>> sinnvollere Tasks anfallen?
>>
>> Grüße - Theodin
>>
>>
>> Am 15.06.2013 17:13, schrieb Markus Semm:
>>
>>> Hallo Stefan,
>>>
>>> auf der Fossgis wurde diese Woche von den Kort-Entwicklern im Rahmen der
>>> Projektpräsentation gesagt, dass die bislang fast 25.000 Änderungen, die
>>> Nutzer von Kort bislang vorgenommen haben, noch gar nicht an OSM übertragen
>>> wurden, wohl wegen grundsätzlicher Bedenken hinsichtlich einer automatischen
>>> Änderung von Daten in OSM, die die schweizer Community vorgetragen hat.
>>> Frederik hat zwar in der selben Session darauf hingewiesen, dass er das
>>> Thema "automatisierte Updates" im Fall Kort entspannt sieht (und ich
>>> schließe mich dem an), vom Kort-Team kam aber dann keine Aussage mehr, ob
>>> und wann die mühsam von mir und vielen anderen recherchierten Daten
>>> zurückfließen ins OSM.
>>>
>>> Kannst Du dazu etwas Konkretes sagen?
>>>
>>> Gruß
>>> Markus
>>>
>>> -Ursprüngliche Nachricht-
>>> Von: Stefan Keller [mailto:sfkel...@gmail.com]
>>> Gesendet: Samstag, 15. Juni 2013 17:03
>>> An: Openstreetmap allgemeines in Deutsch
>>> Betreff: [Talk-de] Kort Game mit neuer Aktion/Kampagne dieses Wochenende!
>>>
>>> Liebe Mapper,
>>>
>>> Pünktlich zur FOSSGIS startete das Kort-Team eine neue Funktion: Die
>>> Kort-Aktion!
>>>
>>> Wer in sich der Deutschschweiz aufhält, sollte Ausschau halten nach
>>> Aufträgen und Überprüfungen mit einem Stern. Diese ergeben doppelte
>>> Koins. Alle anderen aufgepasst: Bald gibt es weitere
>>> Aktionen/Kampagnen.
>>>
>>> Die  Aktion/Kampagne  geht morgen Sonntag, 16. Juni 2013, zu Ende;
>>> also nichts wie los! Weitersagen, v.a. auch an GeoCacher :-)
>>>
>>> Stefan & das Kort-Team
>>> www.kort.ch bzw. http://play.kort.ch!
>>>
>>> [1] Link zum Vortrag vom 13.6.2013 an der FOSSGIS:
>>> http://www.fossgis.de/konferenz/2013/programm/events/541.de.html
>>>
>>> ___
>>> Talk-de mailing list
>>> Talk-de@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-de
>>>
>>>
>>> ___
>>> Talk-de mailing list
>>> Talk-de@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-de
>>>
>>
>>
>> ___
>> Talk-de mailing list
>> Talk-de@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Kort Game mit neuer Aktion/Kampagne dieses Wochenende!

[Stefan Keller]

Ja; in Kort gibt es die Möglichkeit "unlösbar" anzuwählen.
Das sieht man auch in der Statistik der "normalen" Webseite:
http://www.kort.ch/statistics.php

LG, Stefan

Am 18. Juni 2013 17:21 schrieb René Kirchhoff :
> Hallo Stefan.
> Dabei sollte man nicht vergessen, dass man in keepright einen Fehler auch
> als "kein Fehler" kennzeichnen kann.
> Gibt es diese Möglichkeit auch bei Kort oder ist der Fehler nur Lösbar,
> indem ich den ggf. identischen Namen ein zweites mal angebe?
> (Kann es selber nicht prüfen, da FF und IE leider nicht unterstützt werden.)
> Gruß René
>
> Am 18. Juni 2013 16:04 schrieb Stefan Keller :
>
>> Hallo Simeon
>>
>> Vorab: Kort basiert auf Daten von keepright und neu auf mittels
>> osm2pgsql nach PostgreSQL aufbereitete Daten. "Sprache des Namens" ist
>> ein Fehlertyp von keepright.
>>
>> Wie soll ein Auswertesystem "merken" in welcher Sprache ein Name
>> geschrieben ist?
>>
>> "Sprache des Namens" finde ich sehr sinnvoll, denn es ist durchaus
>> nicht so, dass Ländergrenzen eine Sprachgrenze bilden würden,
>> geschweige denn dass innerhalb eines Landes oder Region nur eine
>> Sprache gesprochen wird (auch wenn das einige Landsmänner aus DE, FR,
>> IT oder den USA immer wieder meinen ;-)).
>>
>> LG, Stefan
>>
>> Am 18. Juni 2013 15:48 schrieb Simeon :
>> > Hallo Stefan und alle anderen,
>> >
>> > Ich wollte die Tage einige Vorschläge zurück zu OSM eintragen, da fiel
>> mir
>> > auf, dass alle aufgeführten Proposals nur von der Art "Sprache des Namens
>> > unbekannt" sind. Nach Nachfrage im Forum (
>> > http://forum.openstreetmap.org/viewtopic.php?id=21557 ) bin ich davon
>> > abgekommen, die alle einzutragen, da sie meiner (und auch der anderen
>> > Poster) Meinung nach redundant und unnötig ist. Was hattet ihr euch
>> überlegt
>> > als ihr die ins Spiel genommen habt? Gibt es Gründe, die alle doch
>> > einzutragen? Lohnt es sich, diese Art Fehler raus zunehmen sodass mehr
>> > sinnvollere Tasks anfallen?
>> >
>> > Grüße - Theodin
>>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Kort Game mit neuer Aktion/Kampagne dieses Wochenende!

[Stefan Keller]

Am 18. Juni 2013 21:48 schrieb Simeon :
> Checkt Kort auch die Änderungen oder woher "weiß" es ob jemand den Fehler in
> OSM eingetragen hat?

Kort prüft zuerst ob der Node überhaupt noch in der OSM DB vorhanden
ist und dann, ob der Keys (z.B. "cuisine") fehlt bzw. der Value leer
ist. Dann ist die Lösung von Kort noch aktuell.

LG, Stefan

Am 18. Juni 2013 21:48 schrieb Simeon :
> Guten Abend Stefan und wer sonst noch so zuhört,
>
> Wenn das mit dem Blättern ginge. wäre das klasse. Auch die Anmerkungen
> bezüglich der Sprache sehe ich jetzt nicht mehr so eng. Es kann sinnvoll
> sein, die Sprache anzugeben; aber in größeren sprachlich zusammenhängenden
> Gebieten ist und bleibt es unwahrscheinlich. Reicht dann eigentlich name:de
> als Untergruppe von name oder sollte beides dabei sein? Vermutlich beides,
> damit alle benannten Dinge ein "name=" haben.
>
> Checkt Kort auch die Änderungen oder woher "weiß" es ob jemand den Fehler in
> OSM eingetragen hat?
>
> Grüße - Simeon
>
> Am 18.06.2013 16:38, schrieb Stefan Keller:
>
>> Hallo Theodin (sorry meine Namensverwechslung)
>>
>> Ich sehe gerade, dass es bei den Lösungen keine Möglichkeit mehr gibt,
>> weitere 10 Lösungen anzuzeigen. Damit könntest du nach "spannenderen"
>> Lösungen suchen und andere weglassen. Das hatten wir mal in einer
>> früheren Version drin. Ich schaue mal, ob wir wenigstens dieses
>> "Blättern" wieder hinkriegen.
>>
>> LG, Stefan
>>
>> P.S. Die Lösungen-Seite ist übrigens so langsam, weil es jeden der 10
>> Einträge mit einem Aufruf an OSM prüfen muss, ob das OSM-Objekt noch
>> vorhanden ist.
>>
>>
>> Am 18. Juni 2013 16:04 schrieb Stefan Keller :
>>>
>>> Hallo Simeon
>>>
>>> Vorab: Kort basiert auf Daten von keepright und neu auf mittels
>>> osm2pgsql nach PostgreSQL aufbereitete Daten. "Sprache des Namens" ist
>>> ein Fehlertyp von keepright.
>>>
>>> Wie soll ein Auswertesystem "merken" in welcher Sprache ein Name
>>> geschrieben ist?
>>>
>>> "Sprache des Namens" finde ich sehr sinnvoll, denn es ist durchaus
>>> nicht so, dass Ländergrenzen eine Sprachgrenze bilden würden,
>>> geschweige denn dass innerhalb eines Landes oder Region nur eine
>>> Sprache gesprochen wird (auch wenn das einige Landsmänner aus DE, FR,
>>> IT oder den USA immer wieder meinen ;-)).
>>>
>>> LG, Stefan
>>>
>>> Am 18. Juni 2013 15:48 schrieb Simeon :
>>>>
>>>> Hallo Stefan und alle anderen,
>>>>
>>>> Ich wollte die Tage einige Vorschläge zurück zu OSM eintragen, da fiel
>>>> mir
>>>> auf, dass alle aufgeführten Proposals nur von der Art "Sprache des
>>>> Namens
>>>> unbekannt" sind. Nach Nachfrage im Forum (
>>>> http://forum.openstreetmap.org/viewtopic.php?id=21557 ) bin ich davon
>>>> abgekommen, die alle einzutragen, da sie meiner (und auch der anderen
>>>> Poster) Meinung nach redundant und unnötig ist. Was hattet ihr euch
>>>> überlegt
>>>> als ihr die ins Spiel genommen habt? Gibt es Gründe, die alle doch
>>>> einzutragen? Lohnt es sich, diese Art Fehler raus zunehmen sodass mehr
>>>> sinnvollere Tasks anfallen?
>>>>
>>>> Grüße - Theodin
>>>>
>>>>
>>>> Am 15.06.2013 17:13, schrieb Markus Semm:
>>>>
>>>>> Hallo Stefan,
>>>>>
>>>>> auf der Fossgis wurde diese Woche von den Kort-Entwicklern im Rahmen
>>>>> der
>>>>> Projektpräsentation gesagt, dass die bislang fast 25.000 Änderungen,
>>>>> die
>>>>> Nutzer von Kort bislang vorgenommen haben, noch gar nicht an OSM
>>>>> übertragen
>>>>> wurden, wohl wegen grundsätzlicher Bedenken hinsichtlich einer
>>>>> automatischen
>>>>> Änderung von Daten in OSM, die die schweizer Community vorgetragen hat.
>>>>> Frederik hat zwar in der selben Session darauf hingewiesen, dass er das
>>>>> Thema "automatisierte Updates" im Fall Kort entspannt sieht (und ich
>>>>> schließe mich dem an), vom Kort-Team kam aber dann keine Aussage mehr,
>>>>> ob
>>>>> und wann die mühsam von mir und vielen anderen recherchierten Daten
>>>>> zurückfließen ins OSM.
>>>>>
>>>>> Kannst Du dazu etwas Konkretes sagen?
>>>>>
>>>>> Gruß
>>>>

Re: [Talk-de] "Sprache des Namens" Fehler in Kort. War: Kort Game mit neuer Aktion/Kampagne dieses Wochenende!

[Stefan Keller]

Hallo Martin

Am 18. Juni 2013 16:44 schrieb Martin Raifer :
> Fakt ist, dass der für diesen Layer verwendete Fehlersuch-Algorithmus
> spätestens bei echt mehrsprachigen Regionen versagt und nur noch
> false-positives ausspuckt.

Die absolute Angabe "nur noch..." scheint mir etwas übertrieben.

> ...
> Das Feature in keepright mag zwar gut gemeint sein und könnte für
> nicht-mehrsprachige Regionen vielleicht auch sinvoll sein. Für mehrsprachige
> Namen bedarf es aber einer genaueren Auswertung um herauszufinden in welchen
> Sprachen der Name vorliegt.

Genau das ist Teil der Aufgabe beim Spielen.

Und sowohl bei keepright ("ignore") wie auch bei Kort ("nicht lösbar")
kann man false positives als solche angeben.

> Jedenfalls wird Kort durch das Einbinden dieser "Warnungen" in
> mehrsprachigen Regionen leider komplett unspielbar. :(

"Komplett unspielbar"?? Erstens ist es - wie du selber sagst - in
"einsprachigen Regionen" offenbar "spielbar", zweitens gibt es noch
sieben andere Fehlertypen (vgl. [1]). Warum also das Kind gleich mit
dem Bade ausschütten?

LG, Stefan

[1] 
https://kort.uservoice.com/knowledgebase/articles/206970-was-f%C3%BCr-auftr%C3%A4ge-und-%C3%9Cberpr%C3%BCfungen-gibt-es-




Am 18. Juni 2013 16:44 schrieb Martin Raifer :
> Zum "language unknown" Layer von keepright hatte ich bereits vor einiger
> Zeit eine kurze Diskussion mit dem Macher von keepright. Mein Fazit:
>
> Fakt ist, dass der für diesen Layer verwendete Fehlersuch-Algorithmus
> spätestens bei echt mehrsprachigen Regionen versagt und nur noch
> false-positives ausspuckt. Beispiel: Freiburg[1] (name=Fribourg - Freiburg,
> name:de=Freiburg, name:fr=Fribourg) wird in keepright [2] fälschlicherweise
> angezeigt. Oder noch extremer: fast Alles in Südtirol[3], Brüssel, …
>
> Unter anderem deshalb befindet sich dieser Layer in keepright auch in der
> Kategorie "Warnung" und nicht unter "Fehler".
>
> Das Feature in keepright mag zwar gut gemeint sein und könnte für
> nicht-mehrsprachige Regionen vielleicht auch sinvoll sein. Für mehrsprachige
> Namen bedarf es aber einer genaueren Auswertung um herauszufinden in welchen
> Sprachen der Name vorliegt.
>
> Jedenfalls wird Kort durch das Einbinden dieser "Warnungen" in
> mehrsprachigen Regionen leider komplett unspielbar. :(
>
> Liebe Grüße
> Martin
>
> [1] http://www.openstreetmap.org/browse/node/1685926271
> [2]
> http://keepright.ipax.at/report_map.php?zoom=18&lat=46.80319&lon=7.1523&layers=B0T&ch=0%2C360&show_ign=1&show_tmpign=1
> [3]
> http://keepright.ipax.at/report_map.php?zoom=16&lat=46.67399&lon=11.15604&layers=B0T&ch=0%2C360&show_ign=1&show_tmpign=1
>
>
> Am 18.06.2013, 16:04 Uhr, schrieb Stefan Keller :
>
>> Hallo Simeon
>>
>> Vorab: Kort basiert auf Daten von keepright und neu auf mittels
>> osm2pgsql nach PostgreSQL aufbereitete Daten. "Sprache des Namens" ist
>> ein Fehlertyp von keepright.
>>
>> Wie soll ein Auswertesystem "merken" in welcher Sprache ein Name
>> geschrieben ist?
>>
>> "Sprache des Namens" finde ich sehr sinnvoll, denn es ist durchaus
>> nicht so, dass Ländergrenzen eine Sprachgrenze bilden würden,
>> geschweige denn dass innerhalb eines Landes oder Region nur eine
>> Sprache gesprochen wird (auch wenn das einige Landsmänner aus DE, FR,
>> IT oder den USA immer wieder meinen ;-)).
>>
>> LG, Stefan
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] "Sprache des Namens" Fehler in Kort.

[Stefan Keller]

Lieber Martin

Am 19. Juni 2013 10:25 schrieb Martin Raifer :
> danke für deine Antwort. Vielleicht habe ich mich bei dem einen oder anderen
> Satz etwas zu stark ausgedrückt. Meine Gesamtaussage aber bleibt, dass Kort,
> wie es sich zur Zeit präsentiert, in mehrsprachigen Regionen unspielbar ist.
> Und das ist schade.

Danke für deine Ausführungen; jetzt verstehe ich's besser. Mir ist
bewusst, dass es Häufungen von einem "Fehler" geben kann. Mengenmässig
sind weltweit gesehen wohl nur wenige Gebiete betroffen. Trotzdem
braucht es Verbesserungen, wie du sie u.a. unten vorschlägst.

> Ich komme aus Südtirol, eines der wenigen Gebiete in Europa, die "echt
> mehrsprachig" sind.

Dass es "echte" mehrsprachige Gebiete gibt, ist mir als Schweizer
klar, wenn ich u.a. an Fribourg/Freiburg, Teile von Wallis und
Graubünden oder Biel/Bienne denke. Im Kanton Fribourg/Freiburg
entscheiden z.B. Gemeinden autonom, ob nun deutsch, franz. oder beides
gilt). Oft ist dann immer noch unklar, welche Sprache zuerst
geschrieben werden soll (und eine Regelung für Newline-Zeichen gibt es
bei OSM-Tags meines Wissens nicht)!

Wie Peter Wendorff schrieb, geht es hier nicht primär darum,
zusätzliche Übersetzungen anzugeben. Beim name-Tag geht es um mehrere
Aspekte, das letztlich in einem geografischen Namens-Schema
abgehandelt und dokumentiert werden müssten:

1. Im name-Tag steht das was gemäss on-the-ground-Regel draussen zu
sehen ist - und das was offizell und per Default auf der
(Landes-)Karte angezeigt werden soll. Das sollte sich mit der
offiziellen Schreibweise decken (sog. Endonyme, vgl. Wikipedia). Das
kann mitunter auch eine chinesische Schrift sein - oder aber eben eine
"echt" mehrsprachige Bezeichnung wie "Biel/Bienne". Für alle weiteren
Fälle wird der name:XX-Tag verwendet.

2) Mit Blick auf (Welt-)Karten, die z.B. für uns Europäer lesbar sind,
braucht es Exonyme, d.h. für uns lesbare geografische Namen, z.B. für
asiatische Gebiete.

3) Mit Blick auf mehrsprachige Karten sollte eine Software erkennen
können, in welcher Sprache der Name nun gilt.

4. Ausserdem gibt es eine Aussprache von Orten, wie sie inoffiziell,
mundartlich oder historisch von Einheimischen verwendet werden (z.B.
name:gsw=Rapperschwil für Rapperswil, vgl. nominatim).

Es macht daher für mich Sinn, für alle geogr. Namen einen name:XX-Tag
anzugeben auch bei mehrsprachigen name-Tags.

Der Keepright-Fehlertext heißt sinngemäss "Wenn der name-Tag
existiert, wäre es schön (nicht notwendig), wenn ein name:XX-Tag
existierte.". Bei mehrsprachigen Namen gibt es hier nun tatsächlich
ein Problem, dass Kort zurzeit fragt "In welcher Sprache ist der Name
"nnn* geschrieben? (de, fr, etc.)" und dann den Tag "name=nnn" nimmt
und ihn als "name:de=nnn" speichern will.

Für Kort scheint mit da ein "nicht lösbar" immer noch die beste
Antwort. Eine korrekte (Teil-)Lösung wären zwei (bzw. mehrere)
name:XX-Tags. Eine Lösung, wie man in OSM angeben könnte, wo das es
eine offizielle Ein- bzw. Mehrsprachenregelung gibt (wenn denn es eine
gibt), könnten Sprach-Multipolygone sein, doch gibt es meines Wissens
dazu noch keine Diskussion. Jochen Topf mit seiner  Multilingual Map
(http://mlm.jochentopf.com/ ) hat sich dazu ev. einige Überlegungen
gemacht.

Zu deinen Verbesserungsvorschlägen:

> 1. Eine Möglichkeit bestimmte Fehlerkategorien auszublenden und stattdessen
> andere Aufträge anzuzeigen.

Ausgezeichnete Idee. Das leite ich gleich an die Kort-Developpers weiter.

> 2. Immer einen ausgewogenen Mix an Aufträgen anzeigen, z.B. durch das
> bewusste Zurückhalten von Aufträgen einer Kategorie ab einer festgelegten
> maximalen Dichte.
>
> 3. Nie Aufträge stellen, von denen man weiß, dass diese nicht immer sinnvoll
> sind. Vor allem dann nicht, wenn man weiß, dass der "nicht lösbare" Teil
> lokal gehäuft vorkommt. Keine "Warnungen" als "Fehler" verkaufen!

Was nun als "Fehler" gilt und was eine Warnung oder gar irrelevant
sein soll, machmal eine Definitionsfrage.
 Solange es keine "(Mehr-)Sprachgebiete" gibt (wie oben
vorgeschlagen), "weiss man" nicht, was nun gilt.
Eine Dichte-Analyse scheint zwar spannend, ist aber für mich in keinem
Verhältnis von Aufwand und Ertrag, die es betrifft.
Dafür könnte das Fehlerkategorien-Ausblenden eine Abhilfe sein.

> 4. Zusammenarbeit mit dem Hersteller der verwendeten
> Qualitätsicherungssoftware (hier: keepright) zur Verbesserung der Qualität
> der zur Verfügung gestellten Daten.

Wir haben schon mehrmals mit Harald Kleiner kommuniziert. Ausserdem
haben wir dank der EOSMDBOne-DB neu die Möglichkeit, selber
Fehlerdaten zu extrahieren.

> Für diesen speziellen Fall: Ich habe
> bereits mit multilingualen Namen experimentiert und habe auch konkrete
> Ideen,

Das klingt interessant. Ich nehme an, die Diskussion wird hier auf
Talk-de stattfinden?

LG, Stefan



Am 19. Juni 2013 10:25 schrieb Martin Raifer :
> Lieber Stefan,
>
> danke für deine Antwort. Vielleicht habe ich mich bei dem einen oder anderen
> Satz etwas zu stark ausgedrückt. Meine Gesamtau

Re: [Talk-de] Kort Game mit neuer Aktion/Kampagne dieses Wochenende!

[Stefan Keller]

Kort hat als Zielpublikum nicht nur OSM-Kandidaten, sondern auch
solche, die "nur mal zwischendurch ein Geografiespiel spielen" wollen.
Es macht daher m.E. weder Sinn, allen ein OSM-Account zu "schenken"
noch Kort als Editor für OSM auszubauen.
Kort soll Spass machen und die Fleissigen (und Ehlichen!) belohnen.

LG, Stefan

Am 20. Juni 2013 06:56 schrieb Tobias Hobmeier :
> Hi hi,
>
> ich habe da eine etwas Naive Idee wäre es nicht möglich jedem Knot User
> auch einen OSM account zu verpassen
> und Knot praktisch dann als Editor für OSM arbeiten zu lassen? Bei
> Punkten die Validiert werden müssen könnte man dann den Punkt von 3.
> user in OSM übernehmen lassen und im falle eines fehlers von einem
> weiteren Validator (nr 4.) wieder entfernen ...
>
> oder Habe ich da was Wichtiges übersehen? (muss ja fast so sein Oo)
>
>
> On 06/15/13 21:17, Frederik Ramm wrote:
>> Hallo,
>>
>> On 15.06.2013 20:31, Stefan Keller wrote:
>>> Ja, die Bedenken des automatischen Zurückschreibens werden immer
>>> wieder hervorgebracht und wir nehmen sie ernst. Bei näherem Hinschauen
>>> verlieren sie sich meist. Es war übrigens nicht nur Frederik, der dies
>>> in diesem konkreten Fall entspannt sieht, sondern ein paar weitere
>>> gestandene Mapper im Saal.
>>
>> Ich habe mich zu der Frage nicht geaeussert; es war Jochen, der zum
>> Mikrofon griff und meinte, man sollte die Edits doch einfach
>> zurueckschreiben.
>>
>> Meine persoenliche Haltung zu der Frage ist ein bisschen zwiegespalten.
>>
>> *Fuer* ein automatisches Zurueckschreiben spricht, dass die Daten in
>> aller Regel vermutlich wirklich eine gute Qualitaet haben, da sie von
>> mehreren ueberprueft worden sind, und es sind ja auch nicht
>> irgendwelche Imports, sondern wirklich extra fuer OSM erfasste Daten.
>>
>> *Gegen* ein automatisches Zurueckschreiben spricht unter anderem ein
>> "principiis obsta"-Argument - wenn Kort das jetzt darf, wem muessen
>> wir das dann noch alles erlauben, und werden es in jedem Fall
>> gruendlich recherchierte, mehrfach ueberpruefte, relativ
>> vandalismus-sichere Daten sein, oder werden andere mit dem Argument
>> "Kort darf das doch auch" ploetzlich auch weitreichende Anderungen von
>> geringerer Qualitaet zu rechtfertigen versuchen? Das muss man im Auge
>> behalten.
>>
>> Im allgemeinen sind unsere Hauptargumente gegen "Eintragungen durch
>> Proxy" die folgenden:
>>
>> 1. Die Nutzer, die die Aenderungen vornehmen, sind/werden keine
>> OSM-Nutzer. Sie sind Nutzer einer anderen Plattform, wissen im
>> Extremfall nicht einmal was von OSM, fuehlen sich nicht als
>> OSM-Contributors. Salopp gesagt, wir haben ihre Daten, aber nicht ihr
>> Herz. Auch unsere Statistik kommt durcheinander - wir koennen dann
>> nicht mehr zuverlaessig ermitteln, wie viele Leute mit welcher
>> Intensitaet in einem bestimmten Bereich an OSM arbeiten.
>>
>> 2., und das folgt direkt aus 1., wir haben keine Moeglichkeit, die
>> Nutzer zu kontaktieren. Haette es Kort schon vor 5 Jahren gegeben, wie
>> haetten wir dann die Kort-Mitspieler erreichen koennen, um sie um
>> Zustimmung zum Lizenzwechsel zu bitten? Oder wenn irgendwo doch mal
>> etwas eingetragen wird, was andere Mapper falsch finden, wen koennen
>> sie dann anschreiben mit einer Rueckfrage?
>>
>> 3. Wenn wir feststellen, dass mit einem Nutzer-Acccount
>> urheberrechtlich geschueztes oder sonstwie problematisches Material
>> hochgeladen wird, so muessen wir im Extremfall alle Edits dieses
>> Nutzers revertieren. Es waere schade, wenn sowas mit einem
>> "Gateway"-Account passiert.
>>
>> Im konkreten Fall ist der Punkt 1 relativ wenig relevant, denn wir
>> haben gehoert, dass die allermeisten Kort-Spieler tatsaechlich
>> OSM-Beitragende sind. Die Punkte 2 und 3 lassen sich vielleicht im
>> konkreten Fall umschiffen oder zumindest abmildern.
>>
>> Ich glaube, es waere gut, wenn diese geplante naechste Projektphase
>> bei Kort mit automatischem Hochspielen der Anderungen in Abstimmung
>> mit der Data Working Group gestartet werden wuerde und wenn man das
>> allgemein als "Erprobungsphase" deklarieren koennte; so wird Dritten
>> klar, dass das Modell nicht ohne Ruecksprache nachgeahmt werden soll.
>> Eventuell kann die Community dann gemeinsam zu einem Konsens kommen,
>> welche Art von Edits auf welche Weise "durch Proxy" gemacht werden
>> duerfen und welche nicht.
>>
>> Bye
>> Frederik
>>
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] "Sprache des Namens" Fehler in Kort.

[Stefan Keller]

Am 23. Juni 2013 15:18 schrieb Peter Wendorff :
> Es gibt eigentlich noch eine dritte Kategorie, und das sind die
> fehlenden Daten. Nicht falsch, aber eben einfach nicht vorhanden.

Richtig! Die neue "Kort-Fehlerkategorie" "fehlende Küche" (= fehlender
Tag "cuisine") ist so ein Beispiel. Das ist einer der Neuerungen des
Kort Games. Die Daten kommen von meiner EOSMBOne (d.h. aus osm2pgsql).

LG, Stefan

Am 23. Juni 2013 15:18 schrieb Peter Wendorff :
> Hi.
> (Kürzungen in den Folgenden Zitaten nur abschnittsweise, deshalb nicht
> im Einzelnen kenntlich gemacht)
> Am 23.06.2013 14:04, schrieb Stefan Keller:
>> Zu deinen Verbesserungsvorschlägen:
>>
>> Am 19. Juni 2013 10:25 schrieb Martin Raifer :
>>> 3. Nie Aufträge stellen, von denen man weiß, dass diese nicht immer sinnvoll
>>> sind. Vor allem dann nicht, wenn man weiß, dass der "nicht lösbare" Teil
>>> lokal gehäuft vorkommt. Keine "Warnungen" als "Fehler" verkaufen!
>>
>> Was nun als "Fehler" gilt und was eine Warnung oder gar irrelevant
>> sein soll, machmal eine Definitionsfrage.
>>  Solange es keine "(Mehr-)Sprachgebiete" gibt (wie oben
>> vorgeschlagen), "weiss man" nicht, was nun gilt.
>> Eine Dichte-Analyse scheint zwar spannend, ist aber für mich in keinem
>> Verhältnis von Aufwand und Ertrag, die es betrifft.
>> Dafür könnte das Fehlerkategorien-Ausblenden eine Abhilfe sein.
> Klar ist das eine Definitionsfrage, was man als Fehler und was nur als
> Warnung betrachtet, aber ich denke, die einzig sinnvolle Definition
> hier, wenn es sich um das Bearbeiten von OSM-Daten handelt, ist die,
> dass ich, um etwas einen Fehler zu nennen, schon sicher sein sollte,
> dass es falsch ist. Ein Fehler sagt dem Empfänger der dazugehörigen
> Meldung: So ist das falsch, pfui!
> Eine Warnung ist dagegen eher: "sag mal: das, was du da grade gemacht
> hast, ist zwar möglich, aber zumindest ungewöhnlich. Hast du das
> wirklich so gemeint?"
>
> Es gibt eigentlich noch eine dritte Kategorie, und das sind die
> fehlenden Daten. Nicht falsch, aber eben einfach nicht vorhanden. Fehler
> werden daraus nur, wenn man in der Auswertung "Zufällig" andere
> Default-Annahmen trifft als man müsste ;)
>
> Zu dieser Kategorie gehören die lokalisierten name-Tags.
> ein nicht-lokalisierter name-Tag irgendwo mitten in Deutschland, der den
> Namen auf Deutsch enthält, ist doch erstmal nicht falsch, das ist der
> Name. Mitten in Deutschland wird auch jede Software, die das
> berücksichtigen will, selst mit groben Heuristiken diesen Namen als
> deutschsprachig interpretieren (als best-guess eben).
> Deshalb alle name-Tags ohne sprachvariante als "Fehler" zu bezeichnen,
> ist falsch, und auch eine "Warnung" ist zumindest regional zu hoch
> gegriffen.
>
> Wenn wir tatsächlich wollten, dass die OSM-Datenbank für jeden Namen
> mindestens einen name:xx-Tag enthält, dann wär das schonmal 'ne ganz
> schöne Hausnummer:
>
> laut Taginfo gibt es in osm:
> name: 35.535.456 mal
> der verbreitetste lokalisierte Tag dazu ist
> name:en: 831.929 mal - das sind 2,34%
> danach kommen:
> name:ru (314.898, 0,89%)
> name:ja (241.130, 0,68%)
> name:fr (203.957, 0,57%)
> name:de (182.59, 0,51%)
> und so weiter.
>
> Ganz grob überschlagen gibt es etwa zehnmal so viele name-Tags wie alle
> lokalisierten Name-Tags zusammengenommen.
> Wenn man das also als Warnung beanstanden würde, sollte man erstmal
> generell in osm propagieren, dass generell lokalisierte Namen angegeben
> werden sollten - und das ist, soweit ich bisherige Diskussionen dazu im
> Kopf habe, zwar nicht verpönt, aber bei weitem nicht Konsens.
>
> Eine Ausnahme allerdings sehe ich schon:
> WENN ein Objekt
> - ein name-Tag hat
> - und mindestens ein lokalisiertes name:** besitzt,
> - und keines der lokalisierten name:**-Tags im name-Tag enthalten ist
> (als Teil des Namens, damit auch die Kombinierten name-Tags wie
> Brüssel/Bruxxelex oder so nicht als fehler erkannt werden),
> DANN fehlt offensichtlich mindestens ein name, und der ist dann auch
> sinnvoll einzutragen, z.B., um bei textbasierten OSM-Diensten die
> Browser-Sprache bedienen zu können.
>
> Gruß
> Peter
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] "Sprache des Namens" Fehler in Kort.

[Stefan Keller]

Hallo Martin

Am 23. Juni 2013 17:48 schrieb Martin Raifer :
> Genau davon sprechen wir hier die ganze Zeit. ;)
>
> Der Standard-Use-Case für die redundante Eintragung des Namens ist
> beispielsweise in etwa folgender:
> Man möchte eine Karte erstellen, die Labels in folgender Sprach-Reihenfolge
> anzeigt: 1. Deutsch, 2. Englisch, 3. der lokale Name (siehe
> http://mlm.jochentopf.com/). Wenn nun bei München kein redundantes
> name:de=München angegeben ist (also nur name=München & name:en=Munich), wird
> es für den Renderer sehr schwierig die Karte wie gewünscht anzuzeigen;
> wahrscheinlicher würde dann der englische Name angezeigt werden.

Ich bin immer noch nicht ganz sicher, ob wir uns verstehen, denn die
Redundanz bei name=München und name:de=München scheint mir kaum
vermeidbar.
Der Tag name=München ist für mich der offizielle Name (Endonym).
Der Tag name:de=München zeigt einem Programm, wie der Name auf
*deutsch* heisst (ähnlich wie name:de=Peking); das ":de" ist hier
wichtig.
Lokalisierte Namen sind für mich ein Zusatz. Für München könnte es
"name:gsw=Minga" sein.

LG, Stefan

Am 23. Juni 2013 17:48 schrieb Martin Raifer :
> Am 23.06.2013, 15:18 Uhr, schrieb Peter Wendorff
> :
>>
>> [...]
>>
>> Wenn man das also als Warnung beanstanden würde, sollte man erstmal
>> generell in osm propagieren, dass generell lokalisierte Namen angegeben
>> werden sollten - und das ist, soweit ich bisherige Diskussionen dazu im
>> Kopf habe, zwar nicht verpönt, aber bei weitem nicht Konsens.
>
>
> Darum geht es in bei den hier angesprochenen Kort-Aufträgen bzw.
> KeepRight-Warnungen auch gar nicht.
>
>
>> Eine Ausnahme allerdings sehe ich schon:
>> WENN ein Objekt
>> - ein name-Tag hat
>> - und mindestens ein lokalisiertes name:** besitzt,
>> - und keines der lokalisierten name:**-Tags im name-Tag enthalten ist
>> (als Teil des Namens, damit auch die Kombinierten name-Tags wie
>> Brüssel/Bruxxelex oder so nicht als fehler erkannt werden),
>> DANN fehlt offensichtlich mindestens ein name, und der ist dann auch
>> sinnvoll einzutragen, z.B., um bei textbasierten OSM-Diensten die
>> Browser-Sprache bedienen zu können.
>
>
> Genau davon sprechen wir hier die ganze Zeit. ;)
>
> Der Standard-Use-Case für die redundante Eintragung des Namens ist
> beispielsweise in etwa folgender:
> Man möchte eine Karte erstellen, die Labels in folgender Sprach-Reihenfolge
> anzeigt: 1. Deutsch, 2. Englisch, 3. der lokale Name (siehe
> http://mlm.jochentopf.com/). Wenn nun bei München kein redundantes
> name:de=München angegeben ist (also nur name=München & name:en=Munich), wird
> es für den Renderer sehr schwierig die Karte wie gewünscht anzuzeigen;
> wahrscheinlicher würde dann der englische Name angezeigt werden.
>
> Allerdings ist dein Kritierium "keines der lokalisierten name:**-Tags [ist]
> im name-Tag enthalten" auch nicht hinreichend. Das wieso werde ich in einem
> weiteren Posting gleich ausführen.
>
> Grüße
> Martin
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] "Sprache des Namens" Fehler in Kort.

[Stefan Keller]

Eine bewusst gewählte Eigenheit von Kort ist, dass nur ein Tag aufs
Mal korrigiert bzw. ergänzt werden kann (d.h. es wird z.B. zu bei
name=Biel/Bienne der Tag name:de=Biel ergänzt).

Bei der nächsten Aktualisierung sollte es dann immer noch als Fehler
taxiert werden, weil da ein weiterer name:XX fehlt (nämlich
name:fr=Bienne). Bin nun nicht unsicher, ob das keepright so handhabt.
Falls ja, wird es auch in Kort nochmals fragen und man kann
name:fr=Bienne eintgragen.

Dann haben also Keepright und Kort doch nicht so unrecht, dass ein
name:XX fehlt!? Man könnte höchstens ergänzen "dass ein oder mehrere
name:XX fehlen".

LG, Stefan

Am 23. Juni 2013 18:47 schrieb Martin Raifer :
> Am 23.06.2013, 18:36 Uhr, schrieb Stefan Keller :
>
>
>> Ich bin immer noch nicht ganz sicher, ob wir uns verstehen, denn die
>> Redundanz bei name=München und name:de=München scheint mir kaum
>> vermeidbar.
>> Der Tag name=München ist für mich der offizielle Name (Endonym).
>> Der Tag name:de=München zeigt einem Programm, wie der Name auf
>> *deutsch* heisst (ähnlich wie name:de=Peking); das ":de" ist hier
>> wichtig.
>> Lokalisierte Namen sind für mich ein Zusatz. Für München könnte es
>> "name:gsw=Minga" sein.
>
>
> Ich glaube dass wir uns schon verstehen, denn genau das wollte ich durch
> mein Beispiel unterstreichen.
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] "Sprache des Namens" Fehler in Kort.

[Stefan Keller]

Am 23. Juni 2013 21:18 schrieb Hans Schmidt :
>  2. Alle name-Tags müssen verschoben werden

Die name-Tags sind dazu da, das zu erfassen, was Mapper sehen und
Renderer ohne weitere Angaben darstellen können.
Deren Values sollten daher nicht verschoben sondern ggf. kopiert
werden (z.B. nach name:de=München).
Vgl. auch meine Ausführungen zu Endonyme und Exonymen oben.

LG, Stefan

Am 24. Juni 2013 01:57 schrieb Dirk Sohler :
> Hans Schmidt schrieb:
>> Also, was gemacht werden muss:
>>
>> [1-5]
>
> Perfekt zusammengefasst!
>
> Grüße,
> Dirk
>
> --
> Local time :: Ortszeit :: DE-HH
> 2013-06-24T01:57:10+0200
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>

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

Re: [Talk-de] "Sprache des Namens" Fehler in Kort.

[Stefan Keller]

Am 24. Juni 2013 04:40 schrieb Dirk Sohler :
> Wenn langfristig name rausfliegen soll, und durch name:de ersetzt
> werden soll (was nur sinnvoll wäre), muss es irgendwann verschoben
> werden (...)

Nein; es gibt keinen Grund, den name-Tag rausfliegen zu lassen.
Dies wegen den mehrsprachigen Ortsnamen und Strassen, wie Biel/Bienne
oder Martins Beispiel:
 name=Bolzano - Bozen
 name:it=Bolzano
 name:de=Bozen

Solche Beispiele gibt es ziemlich sicher auch in Deutschland, nicht
nur in Österreichm, Italien, der Schweiz und Spanien. Vgl. oben.

LG, Stefan

Am 24. Juni 2013 04:40 schrieb Dirk Sohler :
> Stefan Keller schrieb:
>> Die name-Tags sind dazu da, das zu erfassen, was Mapper sehen und
>> Renderer ohne weitere Angaben darstellen können.
>> Deren Values sollten daher nicht verschoben sondern ggf. kopiert
>> werden (z.B. nach name:de=München).
>
> Wenn langfristig name rausfliegen soll, und durch name:de ersetzt
> werden soll (was nur sinnvoll wäre), muss es irgendwann verschoben
> werden, spätestens mit Version N+1, wenn name nicht mehr unterstützt
> wird, muss bis Version N jegliches vorkommen von name durch name:de
> ersetzt werden (name:de, oder name:en, oder name:ru, etc.).
>
> Je eher das gemacht wird, desto besser.
>
> Grüße,
> Dirk
>
> --
> Local time :: Ortszeit :: DE-HH
> 2013-06-24T04:37:59+0200
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>

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

Re: [Talk-de] "Sprache des Namens" Fehler in Kort.

[Stefan Keller]

Hallo Hans,

Ich kann nur nochmals ganz kurz wiederholen, auf Simon Beitrag oben
verweisen, und mit den Worten von Peter W. sagen:
> Den name-Tag rausfliegen zu lassen halte ich für eine ganz
> ganz blöde Idee.

LG, Stefan


Am 25. Juni 2013 23:21 schrieb fly :
> On 25.06.2013 22:46, Hans Schmidt wrote:
>> Am 24.06.2013 22:53, schrieb Peter Wendorff:
>
>> Ich habe jetzt mal eine E-Mail zur JOSM-developer-Liste geschrieben,
>> zusammen mit einem Mockup, den ich in Excel gestellt habe.
>
> Für sowas ist https://josm.openstreetmap.de die besser Adresse, aber das
> wird schon klappen.
>
> Auch hättest Du Dich nicht erst auf der Mailingliste anmelden müssen
> sonder hättest sogar anonyme bleiben können !
>
>> Ich mecker nicht nur, sondern entwerfe das auch :)
>
> Super.
>
>> Mal sehen, was daraus wird und wie die Reaktionen sind.
>
> Erwarte nicht zu viel. JOSM wird gerade von 1-4 Entwicklern aktiv
> entwickelt.
>
> Grüße
> fly
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

[Talk-de] FOSSGIS 2013: Nachlese in Bildern...!

[Stefan Keller]

Hier nebst einer News (http://bit.ly/18fPeeW ) und einem Artikel
http://www.geowebforum.ch/thread.php?threadID=1110 eine erste FOSSGIS
2013-Nachlese in Bildern…

Allen voran eine Panoramasicht der Ausstellung:
https://twitter.com/sfkeller/status/349862446208516097  . Da waren die
Konferenzvorträge in vollem Gange; daher die "wenigen" Leute. Man
sieht aber, wie alle Projektstände gut besetzt waren :-)

Dann:
* http://eventifier.co/event/fossgis2013/
* https://twitter.com/sfkeller/media/grid
* http://fotodrachen-de.tumblr.com/tagged/fossgis2013

Weitere Bilder folgen ev. noch (immer mit #fossgis2013 taggen!). An
dieser Stelle möchte ich nochmals meinen Dank aussprechen, v.a. auch
an die fleissigen Helfer an den Ständen!

LG, Stefan

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

[Talk-de] Overpass API: Gegeben id/name gesucht Area: Wie?

[Stefan Keller]

Hallo!

Folgende Frage zum Overpass API:

* Gegeben die OSM-id (oder der name) einer Relation, genauer: ein Multipolygon
  (z.B. http://www.openstreetmap.org/browse/relation/2135966 ).
* Gesucht: Irgend ein Output mit (Area-)Geometrie zur
Weiterverarbeitung (XML, GeoJSON, etc.), d.h. nicht nur die Relation
mit Verweisen auf Ways, sondern ein Multipolygon mit Koordinaten.

Hab's mit Overpass-Turbo und verschiedenen API-Tricks probiert, ohne Erfolg.

Kann man das mit dem Overpass API und wenn ja, wie?

LG, Stefan

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

[Talk-de] Koins sammeln waehrend AGIT 25 im Land von Red Bull (Kort Game-Aktion)

[Stefan Keller]

Liebe Mapper!

Anlässlich der AGIT 25 in Salzburg wollen wir zeigen, dass nicht nur
Red Bull Kampagnen machen kann. Es gibt nämlich eine Kort-Aktion für
unbekannte Wegtypen (Asphalt, Schotter...)! Die Aktion dauert noch bis
Sonntag und gilt für alle Strassen und Wege in der Stadt Salzburg.
Nutzt die Gelegenheit, um doppelte Koins zu sammeln. Und vergesst
nicht, im OpenStreetMap-Spezialforum vorbeizuschauen (3. Juli, ab 15
Uhr, Blauer Hörsaal).

LG, Stefan
Kort Headquarters

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

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

[Stefan Keller]

Hallo Tracy

Mit grossem Interesse verfolge ich diese Diskussion, denn ich
beschäftige mich seit einiger Zeit mit dem Thema, wie man externe
Datenbanken mit OSM verknüpfen kann.

Am 11. Juli 2013 12:21 schrieb Tracy Kasperczyk :
> ...
> Hiermit unsere vorläufige Stellungnahme zu diesem Thema:
>
> ** **Zunächst eine Ergänzung unserer Beschreibung:
>
>  Wir nehmen die Anregung von Stephan Wolff auf und ändern den Namen in
> ref_ifopt
>
> Die IFOPT Nummer (globale ID)  gibt es für alle Haltestellenobjekte,
> speziell auch für alle Haltepunkte der Busse und Straßenbahnen. Das ist
> dann so was wie ein eindeutiges Nummernschild in den Ländern, die mitmachen.
> 

Das was ihr mit dem IFOPT in OSM vorhabt, ist analog TCM und
entspricht der Variante 2, die ich hier zunächst für mich dokumentiert
habe: [1].

Ich meine, wenn schon eine solche "Projekt-Spezial-ID", dann würde ich
einen sinnigen Tag-Namen verwenden, wie ihn Jochen
("public_transport:ifopt:stop_id") vorschlug.

Und in jedem Falle würde ich es bei diesem Projekt-Spezial-Tag
belassen und keine weiteren Tags vorsehen (die sind ja über die ID mit
der externen DB verknüpft).

Konsequenter wäre aber m.E. ganz ohne Projekt-Spezial-ID auszukommen,
in dem die OSM-ID oder eine noch zu findende
"permanente/stabile/globale OSM IDs" verwendet wird, auf die sich die
externe Datenbank bezieht (=> vgl. Variante 4 [1]). Am 22.07.12 gab es
eine Diskussion über solche "Permanente/stabile OSM IDs!". Ich schlug
dort eine einzige zusätzliche ID-Tag pro OSM-Objekt vor. Dort war
eines der (berechtigten) Einwände, dass die "interne" OSM-ID instabil
sei und sowohl bei dieser als auch bei Projekt-Spezial-IDs die
OSM-Daten "aufgebläht" würden.

Was mir an IFOPT jedenfalls nicht gefällt, ist die Codierung durch
"sprechende" Schlüssel (die ändern können!).

Ich frage mich daher, ob nicht der Vorschlag von Wolfgang Hinsch vom
10. Juli 2013 17:04 am besten wäre  ("public_transport:stop_position")
- vgl. unten. So ein Tag könnte auch ausserhalb den an IFOPT
angeschlossenen Bahnhöfen (d.h. weltweit) verwendet werden.

LG, Stefan

[1] http://giswiki.hsr.ch/OpenStreetMap_und_externe_Datenbanken#Variante_2

LG, Stefan


Am 10. Juli 2013 17:04 schrieb Wolfgang Hinsch :
> ...
> Also, wenn ich das richtig verstanden habe, werden damit Positionen auf
> dem Gleis und auf dem Bahnsteig am Gleis markiert. Wie das in
> irgendeiner Spezial-DB heißt, kann uns doch völlig schnuppe sein. Besser
> wäre ein Klartext wie:
>
> public_transport:stop_position="Gleis3_Nord';
> public_transport:stop_position="Gleis3_Mitte';
> public_transport:stop_position="Gleis3_Sued';
>
> oder ost/west, wenn der Bahnhof anders rum liegt.
>
> Falls eine Position reicht (an vielen Bahnsteigen werden mehrere Züge
> hintereinander bereitgestellt), einfach nur 'Gleis3'.
>
> Dann wird im Wiki erklärt, was das heißen soll, eine Vorlage dazu, damit
> die Rechtschreibung stimmt, ein Style für josm, damit es angezeigt wird
> und gut ist. Dann weiß jeder, was gemeint ist und kann das auch
> reparieren.
>
> Das Bundesland und der Bahnhofsname sollte sich eindeutig aus der Lage
> ergeben.
>
> Die Bahnsteigpositionen analog. Eingänge auch (Eingang_Nord,
> Eingang_Nord-Ost oder so). Aus einer separaten Tabelle geht dann hervor,
> welche ID damit gemeint ist, das muss nicht in OSM stehen.
>
> Zusätzlich hat man damit den Vorteil, dass sofort auffällt, wenn in den
> Daten etwas fehlt, weil dann für IDs die OSM-Position nicht gefunden
> wird.
>
> Vielleicht übersehe ich etwas, aber eigentlich könnte das so einfach
> sein.
>
> Gruß, Wolfgang


Am 11. Juli 2013 12:21 schrieb Tracy Kasperczyk :
> Hallo liebe OSM-Gemeinde,
>
> mit dieser Mail wollen wir uns bei Ihnen allen melden. Wir müssen intern
> erst ein paar Sachen klären, bevor wir eine Stellungnahme zu Ihren vielen
> E-Mail nehmen können. Wir bedanken uns aber schon einmal sehr dafür, daß
> Sie uns so zahlreich geantwortet haben.
>
> Hiermit unsere vorläufige Stellungnahme zu diesem Thema:
>
> ** **Zunächst eine Ergänzung unserer Beschreibung:
>
>  Wir nehmen die Anregung von Stephan Wolff auf und ändern den Namen in
> ref_ifopt
>
> Die IFOPT Nummer (globale ID)  gibt es für alle Haltestellenobjekte,
> speziell auch für alle Haltepunkte der Busse und Straßenbahnen. Das ist
> dann so was wie ein eindeutiges Nummernschild in den Ländern, die mitmachen.
> 
>
>  Wir bemühen uns um eine Veröffentlichung aller Nummern in den Portalen der
> verantwortlichen Ländern. Allerdings sind noch nicht alle Nummern
> endgültig. Vor allem in den Überschneidungsbereichen der Verbünde, z.B. VRR
> und VRS fällt noch Arbeit an. Es gibt europaweit eine Open Data Initiative
> die diese Daten öffentlich zugänglich machen will.
>
>
> Einige  Verkehrsverbünde bieten kostenfreie öffentliche Schnittstellen zum
> Abruf von Fahrplaninformationen an. Die IFOPT Nummer kann in diesem
> Zusammenhang als eindeutiges Anfragekriterium genutzt werden, um
> beispielsweise alle Abfahrten

Re: [Talk-de] Project of the Week und Gamification

[Stefan Keller]

Hallo,

Ich denke wir sollten unterscheiden zwischen verschiedenen
Zielgruppen, die motiviert werden sollen:
1. Aktive (erfahrene) Mapper
2. Gelegenheits-Mapper bzw. solche, die nach dem ersten Mal aufgegeben haben
3. Mapper-Kandidaten (wie z.B. Geochacher).

Erste Erfahrungen mit Gamification konnten wir schon mit dem Kort Game
sammeln [1]. Sie waren recht positiv. Das Spiel sprach v.a. die
Zielgruppen 2 und 3 an.

LG, Stefan

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


Am 12. Juli 2013 23:10 schrieb Peter Barth :
> Hallo Thorsten,
>
> Thorsten Alge schrieb:
>> Weiter wäre ein bereits angesprochenes Belohnungssystem mit Badges,
>> wie vielleicht von Foursquare, Diablo III oder WoW bekannt, eine coole
>> Sache die sicher den einen oder anderen Mapper bei Laune hält.
>
> wir haben das bei uns am Stammtisch auch schon mehrfach angesprochen und
> diskutiert. Ich hab mir das auch schon lange vorgenommen mal zu testen,
> wenn ich nur mehr Freizeit hätte ^^ Ich habe ja auch immer boinc und
> seti@home angeführt: Da gibt es dann soviele Arten von Statistiken und
> Auszeichnungen, dass man einfach immer mal irgenwann irgendwo auch
> erster ist. Hab da zwar persönlich nie mitgemacht aber von vielen
> gehört, dass das ihr Anreiz zur Beteiligung war. Ich fände so ein System
> auf jeden Fall super!
>
>> Hier
>> könnten Badges in drei Stufen (B/S/G)
>
> und Platin und die aus den Bundesjugendspielen allseits bekannten und
> beliebten "Teilnahmeurkunden" ;D
>
>> in bestimmten Kategorien  (z.B.
>> Hausnummern, Laternen, Straßenname, ...) für den Mapper vergeben
>> werden
>
> Top! Und mit Hausnummern gleich mal anfangen, da bin ich nämlich
> recht gut ;) Und Meta-Badges: "Hat schon 10 Gold-Badges" und so :)
>
>> vielleicht etwas vergleichbar mit der Seite von Pascal Neis
>> (http://hdyc.neis-one.org/).
>> [...]
>> Wenn sich die Badges vielleicht noch in der Nutzerseite auf OSM oder
>> dem OSM Wiki einbinden lassen, wäre das sicher auch nicht so verkehrt.
>
> Muss nicht sein. Seiten wie hdyc und OSMFight sind schließlich auch so
> cool, dass man sie einfach kennt. Wie sonst würden wir ohne OSMFight
> bei Tagging-Meinungsverschiedenheiten auf dem Stammtisch entscheiden
> können, wer nun Recht hat (kleiner Spass ;)). So wär das auch mit dem
> Badges, die kennt dann einfach jeder! :)
>
>> Für ganz fleißige Mapper könnte natürlich auch der Vorstand eine
>> Dankespostkarte, mit dem Kartenausschnitt der Region in dem der Mapper
>> aktiv ist, verschicken.
>
> Ich würde *dir* für so einen Dienst auf jeden Fall einen Abend Getränke
> auf einem Stammtisch, Hackertreffen oder ähnlichem spendieren ;)
>
>> Würde einfach mal gern hören was Ihr so davon haltet und ob Ihr glaubt
>> ob es sinnvoll und realisierbar ist.
>
> Absolut! Und Ja.
>
> Übrigens, da ja Pascal in seiner Antwort auch die Verknüpfung mit
> Help, Wiki oder ähnlichem angedeutet hatte: Finde ich auch eine nette
> Idee und wollte noch darauf hinweisen, dass OSM help ja auch massiv
> von diesem "Belohnungssystem" profitiert.
>
> Liebe Grüße
> vom baldigen Gold-Badge-Besitzer für Gebäude-in-Niederbayern mappen ;)
>
> Peda
>
> --
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Project of the Week und Gamification

[Stefan Keller]

Am 15. Juli 2013 14:53 schrieb Hartmut Holzgraefe
:
> On 07/15/2013 01:59 PM, Peter Barth wrote:
>
>> bitte überdenke das nochmal. Deine Dienste sind großartig, nützlich und
>> auch immer top gemacht! Ich will nichts davon missen, ich will lieber
>> noch mehr davon ;)

+1 auch von mir.

LG, Stefan

P.S. An alle: Lasst mich die Gelegenheit wahrnehmen, um inne zu halten
und - im Sinne der Netiquette - daran zu denken, dass erstens ein
neuer Thread eröffnet wird, wenn man das Thema verlässt und zweitens
bitte möglichst überlegte, nicht-ausufernde Statements gewählt werden.



Am 15. Juli 2013 14:53 schrieb Hartmut Holzgraefe
:
> On 07/15/2013 01:59 PM, Peter Barth wrote:
>
>> bitte überdenke das nochmal. Deine Dienste sind großartig, nützlich und
>> auch immer top gemacht! Ich will nichts davon missen, ich will lieber
>> noch mehr davon ;)
>>
>> Dass hier einige nach jahrelangem anstandslosen Betrieb plötzlich
>> allerlei Probleme sehen, illegales Datenabschnorcheln mit dem
>> Auswerten einer offenen Datenbank in einen Topf werfen und ähnlich
>> abstruse Zusammenhänge herstellen, sollte man sich nicht zu sehr zu
>> Herzen nehmen. [...]
>
>
> +1
>
> Als nächstes kommen noch zB. große Energieversorger und beschweren sich
> das es ja garnicht geht das man aus OSM Daten ihre kompleten
> Hochspannungsnetze erkennen kann ... oh, moment, been there, done that
> ...
>
> Die Daten sind da, die Daten sind nutzbar, die Tatsache das Benutzername
> und Uhrzeit in den veröffentlichten Rohdaten enthalten sind (letzter
> Edit je Objekt, und bei history dumps auch die gesamte Vergangenheit)
> sollte bekannt sein ...
>
> Der Unterschied ob eine bestimmte auf diesen Daten mögliche Auswertung
> direkt mundgekaut online angeboten wird, mit frei verfügbaren
> Werkzeugen möglich ist (grep auf history dump, OverPass?), oder die
> Möglichkeit auch nur theoretisch existiert ist damit irrelevant ...
>
> Entweder ist die Veröffentlichung von ID plus Timestamp generell
> rechtlich fragwürdig, oder die darauf aufbauenden Auswertungen sind
> es genau so wenig wie die Rohdaten selbst.
>
> Die gleichen Auswertungen wären auch auf dem Wikipedia-Datenbestand
> möglich, oder auf jedem beliebigen öffentlichen SVN/GIT/... Source
> Code Repository, auf dem Archiv jeder öffentlichen Mailingliste
> oder jedem öffentlichen Chat ... und in vielen dieser Fälle kenne
> ich auch entsprechende öffentlich verfügbare Auswertungen.
>
> PS: Rechtlich "interessant" wird es eher beim Einsatz entsprechender
> Systeme im Arbeitsumfeld da die entsprechenden Rohdaten und
> Auswertungen sich schnell mit dem Thema "Arbeitsüberwachung"
> überschneiden ... aber auch da erst wenn die Pseudonymisierung
> einfach rückgängig gemacht werden kann (AFAIK; IANAL; etc.)
>
> --
> hartmut
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten

[Stefan Keller]

Liebe alle

Das Thema "temporäre Verkehrshindernisse (Fahrverbote, gesperrte
Strassen) v.a. wegen Bauarbeiten oder Veranstaltungen" interessiert
mich auch. Ich habe es gerade diese Tage auf Talk-ch angeschnitten
("Temporär gesperrte Strassen").

Das Argument, dass veraltete Daten in "offline" Applikationen (Navis)
landen können, ist oft zu hören. Doch ist das wirklich das einzige
Argument gegen entsprechende Tags in OSM? Mir scheint das Argument
etwas "zu fürsorglich", denn einerseits könnten Importprogramme
Baustellen herausfiltern und zweitens könnten
Qualitätssicherungsprogramme veraltete Daten durchaus aufspüren.

Ich hake hier bewusst nach, um die Möglichkeiten und Grenzen eines
eigenen Projekts abzustecken. Die Idee diese Projekts ist, solche
Informationen über eine Karte und ein Webservice/API zur Verfügung zu
stellen. Zudem können "Profis" (= Bewilligungs-Behörden) wie auch
Freiwillige (= Mapper) solche Daten erfassen.

LG, Stefan


Am 22. Juli 2013 08:57 schrieb Joachim Kast :
> Hallo Alexander,
>
>> Aus gegebenem Anlass - 'historisches Stadtfest' alle 4 Jahre mit
>> hunderttausendend von Gaesten, gesperrte Parkplaetze und Strassen,
>> Umleitungen, zusaetzliche amenities etc..
>
> OSM kann wirklich sehr aktuell sein, aber bis die Informationen eines
> Wochenend-Ereignisses beim "normalen Endanwender" ankommen, ist es
> vermutlich schon längst wieder vorbei. Im schlimmsten Fall holt sich
> z.B. ein Navigationsprojekt genau an diesem Wochenende die Daten und
> berücksichtigt in den nächsten 3 Monaten die Straßensperrungen.
>
> Ein Festival-Gelände auf der grünen Wiese ist problemlos, aber innerhalb
> eines dicht gemappten Gebietes für ein Wochenende alles umzuschmeißen
> richtet bestimmt mehr Verwirrung an als dass es Nutzen bringt.
>
> Sowas sollte auf einem getrennten Datenbestand eingetragen und eine
> temporäre Veranstaltungskarte erstellt werden, die man sich auch schon
> einige Zeit im Voraus anschauen kann.
>
> Grüße
> Joachim
>
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten

[Stefan Keller]

Hallo Frank und Thorsten

Vielleicht hast du beim Schreiben Thorsts Vorschlag noch nicht gesehen:

Thorsten Kurz schrieb am 22. Juli 2013 19:25:
> Wäre es vielleicht möglich, das ganze in ein Tagging-Schema zu packen,
> das man im Zweifelsfall auch komplett ignorieren kann und immer noch
> etwas einigermassen sinnvolles erhält? Wie wäre es z.B., statt
>
> highway = construction
> construction = primary
>
> vielmehr
>
> highway = primary
> construction = yes
>
> zu verwenden?

Mittlerweile ist mir klar geworden, dass z.B. der highway-Tag nur dem
eigentlichen Attributieren der
Strassenklasse vorbehalten sein soll. Ein Hin- und Zurückändern wäre falsch.

Hingegen sind zusätzliche ("optionale") Tags (construction=yes etc.) -
wie von Thorsten vorgeschlagen - für mich eine durchaus gangbare
Lösung.

construction=yes deckt aber noch nicht alle Fälle ab - insbesondere
nicht Veranstaltungen wie Alexanders Stadtfest! Wie wär's in diesem
Falle mit:

* traffic_obstruction=yes/no

Am 22. Juli 2013 20:25 schrieb Frank :
> Das hin- und herändern (alle 4 Jahre) wäre auf ewig in der Historie.

Der "originale" highway-Tag nicht; ein construction=yes schon.

> Wer sich gerade während des Stadtfestes eine Garmin-Karte zieht, fährt dann
> wochenlang mit diesen "Sonder-Anpassungen" herum. Auch andere Auszüge werden
> nicht täglich aktualisiert.

Solche zeitlich "hinterherhinkenden" Projekte sollten sich nicht
beirren lassen von zusätzlichen Tags, die den letzten "Sperrzustand"
kennzeichnen.

Bei der Anwendung, die ich im Kopf habe - und die auch Alexander
anspricht - ist die Information ja Tage, wenn nicht Wochen im Voraus
bekannt mit offiziellem Start- und Enddatum. Dazu habe ich
ursprünglich start_date / end_date vorgeschlagen. Ob die wirklich
passend sind, bin ich mir auch nicht mehr sicher, denn diese Angaben
beziehen sich auf die Existenz des Objekts und nicht auf
Zusatzeigenschaften, auf die ich hinaus will. Besser so?

* traffic_obstruction_start=<>
* traffic_obstruction_end=<>

> Ich denke, die OSM-Datenbank sollte nur den "Normalzustand" wiedergeben und
> nicht den temporären Ausnahmezustand.

Ich glaube mittlerweile, dass sich beide Zustände nicht stören müssen.
Ich fasse zusammen:

* Strassen-Tags (highway) bleiben unberührt
* traffic_obstruction=yes/no -- Kennzeichnet eine
Verkehrsbehinderung
* traffic_obstruction_start=<>-- Beginn Verkehrsbehinderung
(falls bekannt)
* traffic_obstruction_end=<>  -- Ende Verkehrsbehinderung
(falls bekannt)
* emergency=yes/no   -- Blaulich-KFz. können
trotzdem durchfahren

> Dies kann evtl. auf einer Webseite oder in Flyern durch "Overlays"
> dargestellt werden.

Damit kann ich auch leben. Wie gesagt, möchte ich die Möglichkeiten ausloten.

LG, Stefan


Am 22. Juli 2013 20:25 schrieb Frank :
> Am 22.07.2013 08:07, schrieb Eckhart Wörner:
>
>> Hallo Alexander,
>>
>> Am Montag, 22. Juli 2013, 00:45:04 schrieb Alexander Lehner:
>>>
>>> Aus gegebenem Anlass - 'historisches Stadtfest' alle 4 Jahre mit
>>> hunderttausendend von Gaesten, gesperrte Parkplaetze und Strassen,
>>> Umleitungen, zusaetzliche amenities etc..
>>>
>>> Das Thema wurde schon ein paar Mal angeschnitten. Gibt's da irgendwelche
>>> neuen Erkenntnisse?
>>
>>
>> • gesperrte Straßen:
>> http://wiki.openstreetmap.org/wiki/Conditional_restrictions
>> • Umleitungen: ergeben sich normalerweise aus den gesperrten Straßen
>> • zusätzliche amenities: opening_hours?
>>
>> Eckhart
>>
>
> Ich denke, es ging Alexander eher um die Frage, ob man die temporären
> Zustände in die Datenbank eintragen und anschließend wieder heraus nehmen
> sollte.
>
> Es wäre zwar nett, wenn die Karte auch während des "Ausnahmezustandes
> Stadtfest" aktuell wäre, aber das erwartet der Besucher wohl nicht wirklich.
> Er weiß ja, dass die Sperrungen nur aus gegebenem Anlass vorübergehend
> eingerichtet wurden.
>
> Das hin- und herändern (alle 4 Jahre) wäre auf ewig in der Historie.
>
> Wer sich gerade während des Stadtfestes eine Garmin-Karte zieht, fährt dann
> wochenlang mit diesen "Sonder-Anpassungen" herum. Auch andere Auszüge werden
> nicht täglich aktualisiert.
>
> Ich denke, die OSM-Datenbank sollte nur den "Normalzustand" wiedergeben und
> nicht den temporären Ausnahmezustand.
>
> Dies kann evtl. auf einer Webseite oder in Flyern durch "Overlays"
> dargestellt werden.
>
> --
>
> Frank
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten

[Stefan Keller]

Hallo Malte und Henning

Falls ihr euch auf die Lösung mit dem Abändern bestender Tags bezieht,
muss ich euch vollkommen Recht geben:
highway=primary vorübergehend auf highway=construction zu wechseln
macht keinen Sinn.
Hingegen zeichnet sich eine bessere Lösung mit zusätlichen Tags ab,
welche "die Wirklichkeit" besser abbilden: Vgl. die anderen Mails.

LG, Stefan


Am 22. Juli 2013 20:44 schrieb Malte Blättermann :
> Am 22. Juli 2013 18:30 schrieb Henning Scholland :
>> Hallo,
>> evtl. ist es nicht das einzige Argument, aber ein sehr wichtiges. Die
>> Mapnikkarte ist die einzige Anwendung, die nahezu in Echtzeit die Daten
>> anzeigt. Allerdings hat man von der Karte nicht viel. Einzig das access
>> einiger Straßen dürfte ein paar rote Punkte auf die Karte zaubern.
>> Alle anderen Anwendungen hinken der Echtzeit um einiges hinterher. So
>> kann es dann sein, dass das Festival eine Woche später dargestellt wird
>> oder einen Monat lang. Einen wirklichen Vorteil des Eintragens
>> kurzfristiger Dinge sehe ich hier nicht. Tendenziell eher einen Nachteil.
>
>
> Sehr gut zusammengefasst! Danke!
>
>
> Gruß Malte
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten

[Stefan Keller]

Hallo Henning,

Es geht nicht darum "ein Objekt als X zu taggen, um dann im nächsten
Tag zu sagen, es ist Y". Und es geht niemandem um den Renderer.

Der aktuelle Vorschlag lautet:
Ein highway=primary bleibt ein highway=primary.
Es kann nun unbestrittenermassen vorkommen, dass eine Strasse zeitlich
angekündigt und befristet für den Verkehr gesperrt ist.
Das wird dann mit *zusätzlichen* Tags gekennzeichnet.
Navi- und andere Projekte müssen (bzw. können und sollen) diese
*zusätzlichen* Tags nicht auswerten.

LG, Stefan

Am 22. Juli 2013 22:01 schrieb Henning Scholland :
> Am 22.07.2013 21:41, schrieb Stefan Keller:
>
>> Hallo Malte und Henning
>>
>> Falls ihr euch auf die Lösung mit dem Abändern bestender Tags bezieht,
>> muss ich euch vollkommen Recht geben:
>> highway=primary vorübergehend auf highway=construction zu wechseln
>> macht keinen Sinn.
>> Hingegen zeichnet sich eine bessere Lösung mit zusätlichen Tags ab,
>> welche "die Wirklichkeit" besser abbilden: Vgl. die anderen Mails.
>
> Hallo,
> ich antworte dir mal auf diese Mail. Ich halte es für vollkommen verkehrt,
> ein Objekt als X zu taggen, um dann im nächsten Tag zu sagen, es ist Y.
> Konkret meint das: highway=primary hat eine gewisse Bedeutung. Wenn das
> Objekt, was ich eintragen möchte aber gar nicht diese Eigenschaften hat,
> dann ist es auch falsch, dieses Tag zu verwenden.
>
> Es ist für jeden Auswerter ein leichtes, highway= construction und
> construction=primary genauso zu behandeln wie highway=primary.
>
> Bei der Sache der kurzfristigen Änderungen geht es nicht darum, wie man
> einen Renderer überlisten kann, sondern dass es aktuell (meiner Meinung
> nach) nicht sinnvoll ist, das zu erfassen, weil die meisten Auswertungen
> ohnehin nicht rechtzeitig die Darstellung ändern und wie bereits gesagt
> egtl. die Daten für die kurzfristige Änderung schon nutzbar sein müssen,
> bevor man sie in OSM live schalten kann.
>
> Henning
>
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten

[Stefan Keller]

Lieber Wolfgang

Am 22. Juli 2013 23:59 schrieb Wolfgang Hinsch :
> Für diese temporären Umleitungen hat man doch die tmc-tags erfunden.
> Lasst die doch endlich mal funktionieren und lasst das Gebastel an den
> highways.
>
> Alles < 1 Jahr -> tmc

TMC scheint mind. innerhalb OSM "tot" zu sein. Vgl. [1].
Und so oder so, scheint mir TMC doch reichlich kompliziert,
unzugänglich und daher ungeeignet für diese Zwecke hier.
Oder kannst du mir ein Beispiel geben, wie man die Neustadtstrasse,
Landshut, mittels TMC für nächstes Wochenende sperren würde?

LG, Stefan

P.S. Bitte unterlasse herablassende Ausdrücke wie "Gebastel".

[1] http://wiki.openstreetmap.org/wiki/DE:TMC


Am 22. Juli 2013 23:59 schrieb Wolfgang Hinsch :
> Hallo,
>
> Am Montag, den 22.07.2013, 22:36 +0200 schrieb Stefan Keller:
>> Hallo Henning,
>>
>> Es geht nicht darum "ein Objekt als X zu taggen, um dann im nächsten
>> Tag zu sagen, es ist Y". Und es geht niemandem um den Renderer.
>>
>> Der aktuelle Vorschlag lautet:
>> Ein highway=primary bleibt ein highway=primary.
>> Es kann nun unbestrittenermassen vorkommen, dass eine Strasse zeitlich
>> angekündigt und befristet für den Verkehr gesperrt ist.
>> Das wird dann mit *zusätzlichen* Tags gekennzeichnet.
>> Navi- und andere Projekte müssen (bzw. können und sollen) diese
>> *zusätzlichen* Tags nicht auswerten.
>>
> Für diese temporären Umleitungen hat man doch die tmc-tags erfunden.
> Lasst die doch endlich mal funktionieren und lasst das Gebastel an den
> highways.
>
> Alles < 1 Jahr -> tmc
>
>
> Gruß, Wolfgang
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten

[Stefan Keller]

Hallo Joachim

Vielen Dank für den Hinweis auf TPEG. Das kannte ich noch nicht.

Ich befürchte aber, dass TPEG auch nicht viel einfacher ist als TMC.
Die v.a. weil es sich - wie TMC - auf effiziente Übermittlung über
Übertragungskanäle konzentriert. Hingegen gibt der Abschnitt "Aufbau
einer RTM Nachricht" undder nachfolgende (aus deinem Link [1])
interessante Hinweise, um die Vollständigkeit der hier besprochenen
Schemata zu prüfen.

In die richtige Richtung geht hingegen: Eckhart's Hinweis
Am 22. Juli 2013 08:07 schrieb Eckhart Wörner :
> ...
> • gesperrte Straßen: 
> http://wiki.openstreetmap.org/wiki/Conditional_restrictions

Ich kläre nun ab, inwiefern das meinen Vorschlag vom 22.07.2013, 22:36
+0200 ersetzt.

LG, Stefan

Am 23. Juli 2013 09:30 schrieb Joachim Kast :
>
>> TMC scheint mind. innerhalb OSM "tot" zu sein. Vgl. [1].
>> Und so oder so, scheint mir TMC doch reichlich kompliziert,
>> unzugänglich und daher ungeeignet für diese Zwecke hier.
>> Oder kannst du mir ein Beispiel geben, wie man die Neustadtstrasse,
>> Landshut, mittels TMC für nächstes Wochenende sperren würde?
>>
>> LG, Stefan
>
> Hallo Stefan,
>
> TMC ist innerhalb OSM "tot", weil es für den Normalmapper zu kompliziert
> und schwer nachvollziehbar ist. Solche komplexen Sachen, die nur von
> wenigen Experten so richtig verstanden werden, gehören von außerhalb
> integriert, ohne allzugroße Eingriffe in den OSM-Datenbestand.
>
> Blicken wir lieber in Richtung TPEG [1], dem TMC-Nachfolger für das
> Digitalradio. Dises System ist unabhängig vom Kartenmaterial und auch
> vom Übertragungskanal. Die ARD-Rundfunkanstalten stehen kurz vor dem
> Beta-Test und stellen dann auch die Meldungen z.B. als RSS-Feed zur
> Verfügung.
>
> Mit TPEG-Technologie dürfte es kein Problem sein, einzelne Straßen oder
> Parkplätze kurzfristig zu sperren, besetzte Parkhäuser oder auch die
> Preise an Tankstellen anzuzeigen.
>
>
> Grüße
> Joachim
>
>
> [1] http://de.wikipedia.org/wiki/TPEG
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten

[Stefan Keller]

Hallo Masi

Finde deine Überlegungen interessant, v.a. der Teil
Am 23. Juli 2013 00:13 schrieb Masi Master :
...
> Wenn der Zeitrahmen der Baustellenrelation abgelaufen ist, kann diese von
> Routern nicht mehr berücksichtigt werden und aufgrund des Datums können
> alle "überfälligen" Baustellen aus der Datenbank gelöscht werden.

Ok. Aber warum zwingend mit Relationen?

> Das Gleiche geht natürlich auch über einen Zusatztags eines Namenraums wie
> sperrung:von=*, sperrung:bis=*, sperrung:access=* usw. (in Englisch,
> versteht sich)
> Vorteil bei Zusatztags ist, dass man Straßenabschnitte unterschiedlich
> taggen kann. Nachteil sind die Kryptischen und sehr lang werdenden Tags.

Stimmt. Die langen Tags sind problematisch. Aber immer noch das
kleinere Übel als Tags, die voneinander abhängig sind.

Könnte man z.B. eine temporäre Sperrrung nicht so erfassen - gemäss
Eckharts Hinweis auf das bereits existierende [1]?

  motor_vehicle:conditional=no @ (2014-07-27..2014-07-28)

LG, Stefan

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


Am 23. Juli 2013 00:13 schrieb Masi Master :
> Am 22.07.2013, 20:25 Uhr, schrieb Frank :
>
>
>> Am 22.07.2013 08:07, schrieb Eckhart Wörner:
>>>
>>> Hallo Alexander,
>>>
>>> Am Montag, 22. Juli 2013, 00:45:04 schrieb Alexander Lehner:

 Aus gegebenem Anlass - 'historisches Stadtfest' alle 4 Jahre mit
 hunderttausendend von Gaesten, gesperrte Parkplaetze und Strassen,
 Umleitungen, zusaetzliche amenities etc..

 Das Thema wurde schon ein paar Mal angeschnitten. Gibt's da irgendwelche
 neuen Erkenntnisse?
>>>
>>>
>>> • gesperrte Straßen:
>>> http://wiki.openstreetmap.org/wiki/Conditional_restrictions
>>> • Umleitungen: ergeben sich normalerweise aus den gesperrten Straßen
>>> • zusätzliche amenities: opening_hours?
>>>
>>> Eckhart
>>>
>>
>> Ich denke, es ging Alexander eher um die Frage, ob man die temporären
>> Zustände in die Datenbank eintragen und anschließend wieder heraus nehmen
>> sollte.
>>
>> Es wäre zwar nett, wenn die Karte auch während des "Ausnahmezustandes
>> Stadtfest" aktuell wäre, aber das erwartet der Besucher wohl nicht wirklich.
>> Er weiß ja, dass die Sperrungen nur aus gegebenem Anlass vorübergehend
>> eingerichtet wurden.
>>
>> Das hin- und herändern (alle 4 Jahre) wäre auf ewig in der Historie.
>>
>> Wer sich gerade während des Stadtfestes eine Garmin-Karte zieht, fährt
>> dann wochenlang mit diesen "Sonder-Anpassungen" herum. Auch andere Auszüge
>> werden nicht täglich aktualisiert.
>>
>> Ich denke, die OSM-Datenbank sollte nur den "Normalzustand" wiedergeben
>> und nicht den temporären Ausnahmezustand.
>>
>> Dies kann evtl. auf einer Webseite oder in Flyern durch "Overlays"
>> dargestellt werden.
>
>
>
> Das Problem ist doch, dass das zeitliche Sperren nicht funktioniert und zu
> lange in der Datenbank bestehen bleibt (oft wird die Sperrung vergessen
> aus OSM herauszunehmen)
> Angenommen eine Straße hat das Tagging motorcycle=no + mofa=yes.
> Nun kommt einer und will die Straße mit access=no sperren. Funktioniert
> natürlich nicht für Mofas und alle anderen (vorher überflüssigen) *=yes
> Tags werden zum Verhängnis.
> date_on & date_off geht genausowenig, da nicht klar ist, auf welche Tags
> es sich bezieht.
>
> Eine mögliche Lösung ist eine Baustellen- oder Sperrungs-Relation, die
> alle access tags der Wege nicht beachtet und mit access=no überschreibt.
> Gleichzeitig kann die Relation weitere access tags aufnehmen, zB Freigabe
> für Fußgänger und Radfahrer, oder Freigabe für Anwohner. Bei der Relation
> MUSS aber mit angegeben werden, von wann - und noch wichtiger - BIS wann
> gesperrt ist.
> Wenn der Zeitrahmen der Baustellenrelation abgelaufen ist, kann diese von
> Routern nicht mehr berücksichtigt werden und aufgrund des Datums können
> alle "überfälligen" Baustellen aus der Datenbank gelöscht werden.
>
> Das Gleiche geht natürlich auch über einen Zusatztags eines Namenraums wie
> sperrung:von=*, sperrung:bis=*, sperrung:access=* usw. (in Englisch,
> versteht sich)
> Vorteil bei Zusatztags ist, dass man Straßenabschnitte unterschiedlich
> taggen kann. Nachteil sind die Kryptischen und sehr lang werdenden Tags.
>
> Falls das Enddatum unbekannt ist, sollte/muss eine Schätzung angegeben
> werden, damit die Mapper nach der Frist die Baustelle nochmal
> überprüfen/aktualisieren können.
>
> So, das war meine bisherige Überlegung.
> Aber vielleicht hat jemand noch einen besseren Vorschlag?
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Datenschutz Warnung im englischen OSM Wiki

[Stefan Keller]

Am 27. Juli 2013 23:03 schrieb Dirk Sohler :
> Das fängt ja schon damit an, dass weder auf openstreetmap.de noch auf
> openstreetmap.org von der „Landingpage“ aus ein auch so bezeichneter
> Link ins Wiki zu finden ist, noch dass die Lizenzbestimmungen für Laien
> ohne weiteres zu finden sind.

Im Web üblich ist ein Link zur Policy. Und auf besagten „Landingpages“
- wie auf praktisch allen *.osm.* Seiten hat es das.

Ich finde es gut, wenn Leute wie u.a. du und Tirkon sich für
"Transparenz" einsetzen. Das Problem ist, dass man die Leute auch
"zutexten" kann (auf Webseiten und allgemein), was unnötig ist und
abschreckend wirkt.

Gerade im Web klickt man (und damit meine ich praktisch
jedermann/frau) weiter, wenn da mehr als drei Zeilen stehen. Und der
Vorschlag, der hier zur Debatte steht ist mehr als drei Zeilen lang -
und immer unvollständig wenn nicht seinerseits irreführend.

Ich unterstütze daher ein besonnenes Vorgehen wo der Text an einer
Stelle steht und darauf verlinkt wird, wie dies u.a. Simon und
Frederik geschrieben haben.

LG, Stefan


Am 27. Juli 2013 23:03 schrieb Dirk Sohler :
> Frederik Ramm schrieb:
>> Und so weiter. Ich finde es daher nicht fair, davon zu sprechen, dass
>> die Hauptseite ein "schiefes Bild" vermittelt. Sie geht auf viele
>> Details des Projekts nicht ein, […]
>
> Vor allem nicht auf die negativen Details – Und dies auch anderswo
> nicht deutlich. Es sollte in verständlicher Sprache (und damit meine
> ich nicht verklausulierte Lizenssprache) deutlich darauf hingewiesen
> werden, was (um beim Thema zu bleiben, aber das gilt natürlich auch für
> alle anderen Details) mit den Daten passiert, und welche Daten das im
> einzelnen sind, und was die Konsequenzen sind.
>
> Das fängt ja schon damit an, dass weder auf openstreetmap.de noch auf
> openstreetmap.org von der „Landingpage“ aus ein auch so bezeichneter
> Link ins Wiki zu finden ist, noch dass die Lizenzbestimmungen für Laien
> ohne weiteres zu finden sind.
>
> Den Beginners Guide muss man auch erst mal suchen. Für jemanden, der
> vielleicht nur ein paar Hausnummern in seiner Umgebung mappen möchte,
> oder dem aufgefallen ist, dass seine Straße falsch erfasst wurde, ist
> das schlicht nicht gangbar.
>
> Klar, es ist nicht so, das verheimlicht wird, was mit den Daten
> passiert, aber es ist eben auch nicht so, dass es den Usern leicht
> gemacht wird, an die Informationen zu kommen.
>
> Grüße,
> Dirk
>
> --
> Local time :: Ortszeit :: DE-HH
> 2013-07-27T22:54:16+0200
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>

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

Re: [Talk-de] Datenschutz Warnung im englischen OSM Wiki

[Stefan Keller]

Hallo Mark

Ich finde deine Bemerkungen gut. Nachdem auch Frederik - als Mitglied
der DWG - sich eine Verbesserung vorstellen kann, glaube ich, dass wir
uns damit einer Lösung nähern. Diese sollte nun aber vom DWG
vorgeschlagen werden (wohl auf englisch) und die Diskussion hier
könnte damit etwas abgekürzt werden.

Ich persönlich war auch ganz kurz erstaunt, realisierte dann schnell,
was es heissen würde, wenn die History ohne Usernamen angegeben würde
und erinnerte ich mich an meine Wikipedia-Zeiten, wo es
selbstverständlich ist, dass man den Usernamen angibt.

Da OSM auch vorbildlich sein soll in Sachen Datenschutz, habe ich mir
kurz auch in wissenschaftlicher Literatur umgesehen und folgendes
gefunden [1] S.11-12 "Auf europäischer Ebene sind derzeit Bestrebungen
für einen stärkeren Datenschutz im Gang. So bemängelt die
EU-Kommission insbesondere die in Onlineumgebungen oft unklaren,
schwierig zu findenden und intransparenten Datenschutzhinweise. Ferner
fordert sie bessere Kontrollrechte für Personen, die von der
Datenbearbeitung betroffen sind. Im Hinblick auf geographische
Positionsangaben empfiehlt ein beratendes Gremium der EU-Kommission,
dass Ortungsdienste standardmässig – d.h. in der Voreinstellung –
abgeschaltet sein müssen. Zudem sollten Personen, die der Verwendung
«ihrer» Ortungsdaten zugestimmt haben, ihre Einwilligung jährlich
wiederholen müssen und diese sehr einfach widerrufen können. Für
Ortungsfunktionalitäten, die dem Nutzer nicht bewusst sind, müssten
die Anbieter verpflichtet werden, ein ständiges Warnzeichen
aufzuschalten."

Eins-zu-eins auf OSM umgelegt hiesse das, dass es
1. gute Datenschutzhinweise geben soll (wie bereits vorgeschlagen),
2. dass man seine Einwilligung jährlich wiederholen muss,
3. diese einfach widerrufen können muss und
4. ein "ständiges Warnzeichen aufzuschalten" ist (in OSM: beim Editieren).

Eigentlich reichen mir als erster Schritt etwas verbesserte Datenschutzhinweise!

LG, Stefan

[1] "Geographische Wegmarken in der Cyberwelt" (2010)
http://www.empa.ch/plugin/template/empa/*/121836/---/wegmarken.pdf


Am 30. Juli 2013 00:39 schrieb Mark Obrembalski :
> On 29.07.2013 22:11, Tirkon wrote:
>
>> Ich weiß vermutlich seit der ersten Woche bei OSM, dass der Username
>> an jeder Änderung hängt. Das merkt man spätestens dann, wenn man die
>> Chronik aufruft. Mir war aber nicht bewusst, dass dieser mit
>> herausgegeben wird.
>
>
> An diesem Punkt war mir das auch nicht so direkt bewusst in dem Sinn, dass
> das zu den ersten Dingen gehört hätte, über die ich mir groß Gedanken
> gemacht hätte. Da ich aber etwa die Wikipedia schon kannte, wo man fremde
> Usernamen sieht sobald man in eine Versionsgeschichte oder auf eine
> Diskussionsseite schaut, war es aber sicher etwas, was ich jederzeit als
> naheliegend angesehen hätte, wenn ich denn einen Grund gehabt hätte, darüber
> nachzudenken. Außerdem hielt und halte ich es für normal, dass Leute, die
> einen wertvollen Beitrag zu einem Publikationsprojekt leisten, in
> irgendeiner Weise durch Nennung mit Namen (wenn sie sebst unter Pseudonym
> auftreten, mit dem von ihnen gewählten Pseudonym) gewürdigt werden. Unter
> Umständen ist das ja sogar rechtlich geboten. In OSM waren ja alle ganz
> fürchterlich vorsichtig mit den Urheberrechten und ähnlichem (das ist auch
> heute noch ungefähr so) - auch von daher lag es also nahe, dass die Benutzer
> entsprechend als Quelle genannt werden.
>
> Ziemlich schnell habe ich aber auch fremde Benutzernamen gesehen, einfach
> indem ich mir zu einem Objekt mal eine Versionsgeschichte angeschaut habe.
> Auch auf der Mailingliste tauchte recht bald ein Hinweis der Art "Die
> Bearbeitungen von xyz schauen komisch aus, kann da mal jemand nachschauen?"
> auf. Spätestens an dem Punkt war es also sonnenklar, dass zumindest jeder
> OSM-Benutzer nachschauen kann, welche Bearbeitung von wem stammt. Und
> OSM-Benutzer kann ja jeder leicht werden.
>
>
>> Zudem habe ich freie
>> Projekte eigentlich immer als die Datenschutz-freundliche Bastion im
>> Internet angesehen.
>
>
> Das sind sie ja auch einigermaßen, einschließlich OSM im gegenwärtigen
> Zustand. OSM verlangt von niemandem, dass er bei der Anmeldung seinen Namen,
> seine Adresse oder sonst was (außer einer Mailadresse - kann man ja auch ne
> Wegwerfadresse nehmen) angibt. OSM drängt seine Benutzer nirgends, doch ganz
> viel über sich einzugeben, man wolle doch so richtig dabeisein. OSM hat auf
> seinen Seiten keine Like-Buttons, kein Google Analytics, keine
> Reichweiten-Zählpixel, keine Werbenetzwerke. OSM versucht auch nicht, fremde
> Seiten mit Like-Buttons oder Zählpixeln zu pflastern. OSM betreibt keine
> Paralleldienste, mit denen es möglich wäre, bei den Benutzern Daten aus ganz
> anderem Kontext abzugreifen und zusammenzuführen (schau dir mal an, was an
> einem Google-Account alles für Lebensbereiche hängen können). OSM verkauft
> keinerlei Daten - alle Daten, die OSM abgibt, kann sich jeder ohne weiteres
> anschauen. Bill Gates kriegt

Re: [Talk-de] Gibt OSM auch Daten über die Beitragenden heraus?

[Stefan Keller]

Hallo,

Es gibt zurzeit etwa drei bis vier Threads zu diesem Thema. Da blickt
keiner mehr durch... Ich schlage daher vor, die Diskussion hier zu
einem vorläufigen Ende zu bringen.

Ich glaube, dass es einen guten Vorschlag und es eine Konvergenz der
Meinungen gibt, dass es einen verbesserten Datenschutzhinweis beim
Anmelden braucht.

Weitere (theoretische) Möglichkeiten habe ich im Thread "Datenschutz
Warnung im englischen OSM Wiki" zusammengestellt. Und ich teile auch
Marc Gehling's Hinweis, dass Frederik und Simon sich schon geäussert
haben. Und nur auf talk-de zu posten oder mal einfach etwas (auf
deutsch) ins Wiki zu schreiben, bringt wenig!

LG, Stefan


Am 29. Juli 2013 22:58 schrieb Michael Paulmann :
> Am 28.07.2013 21:59, schrieb Frederik Ramm:
>>
>> Hallo,
>>
>> On 28.07.2013 17:00, Kai Krueger wrote:
>>>
>>> Natuerlich jeder Schutz ist mit genuegend Aufwand zu ueberwinden. Die
>>> Frage
>>> ist wieviel Aufwand ist es dem "Angreifer" wert, und wieviel ist der
>>> Schutz
>>> dem Nutzer Wert in form von Einschraenkungen. Das Problem ist, das dank
>>> "Big
>>> Data" und der Freizugigkeit der Daten, diese Balance stark in Richtung
>>> Auswertung verschoben wurde. Nun ist die Frage, kann man durch technische
>>> und politische Massnahmen diese Balance wieder zum Wohle des Nutzers
>>> veraendern.
>>
>>
>> Ich denke mal, die Terminologie "Angreifer" wird der Sache nicht gerecht.
>> Die meisten Leute, die irgendeine Auswertung basteln, wollen damit ja einen
>> Nutzen fuer das Projekt stiften. Wenn wir denen sagen wuerden, dass sie die
>> Daten nicht zu diesem und jenen Zweck nutzen sollen, dann wuerden die sich
>> vermutlich auch dran halten und nicht nach Luecken suchen.
>>
>> Allerdings haben wir bislang darauf gebaut, dass Dritte aus eigenem
>> Antrieb mit unseren Daten coole und nuetzliche Anwendungen bauen, die das
>> Projekt voranbringen, ohne uns vorher um Erlaubnis fragen zu muessen.
>>
>> Ich kann mit ziemlicher Sicherheit sagen, dass die OSM Foundation nicht
>> die Ressourcen haette, irgendeine Einzelfallpruefung vorzunehmen, um so
>> einzelnen Leuten mit lauteren Absichten mehr Daten zuzubilligen als anderen.
>>
>> Auf Anhieb fallen mir die Untersuchungen zur Datenqualitaet den englischen
>> Professors Muki Haklay ein; er hat u.a. festgestellt, dass die
>> Datenqualitaet in Grossbritannien in einem betrachteten Planquadrat ab einer
>> gewissen Mindest-Anzahl aktiver Mapper in aller Regel eine geforderte
>> Mindestgrenze ueberschreitet - die genauen Zahlen kenn ich nicht mehr, aber
>> seine Betrachtungen waren durchaus interessant und haetten ohne Zuordnung
>> von Edits zu Accounts nicht gemacht werden koennen.
>>
>> Auch beim Analysieren groesserer Importe oder Massen-Edits kommt man oft
>> schnell an den Punkt, wo man mehr braucht als das Ergebnis einer
>> API-Abfrage. Ich wuerde mich sehr unwohl dabei fuehlen, wenn das Projekt
>> sich in diesen Dingen kuenftig nicht mehr "selber helfen" koennte, sondern
>> zwangsweise auf die Exekutive der OSMF angewiesen waere.
>>
>>
>> Also wenn ich vor die Wahl gestellt werde, entweder die Daten aller ein
>> bisschen weniger zu schuetzen oder alternativ dazu eine Machtverschiebung
>> von "dem Projekt insgesamt" zur OSMF vorzunehmen, dann wuerde ich lieber den
>> reduzierten Datenschutz waehlen.
>>
>> Bye
>> Frederik
>>
> +100
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Overpass API 0.7.4: Differenz-Operator

[Stefan Keller]

Lieber Roland

Hut ab wie du es schaffst, ein recht performantes und verlässliches
OSM API für die weltweite OSM-DB zu implementieren - und es erst noch
immer weiter auszubauen! Ich weiß, wovon ich spreche, wenn ich an den
Betrieb des Kort Games denke.

Der Differenz-Operator ist eine sinnvolle Erweiterung. Nur bin ich mit
der Benennung nicht so glücklich - wie mit anderen Syntax-Elementen ja
auch/nicht (wie namentlich print und recurse).

Diese Differenz gehört zu den "Set Operationen" und gemäss SQL
Standard heissen die UNION, INTERSECT und EXCEPT - und sie werden
unterstützt u.a. von PostgreSQL, MySQL/MariaDB, SQLPlus sowie von MS
SQL Server und DB2. Nur Oracle weicht davon ab und kennt statt EXCEPT
=> MINUS.

"Difference" ist mir zu nahe an "Intersect". Natürlich muss die
Overpass API nicht SQL übernehmen, doch gibt SQL eine schöne
theoretische Basis her (z.B. dass ein weiterer Operator "INTERSECT"
heissen könnte :-).

Ich schlage daher vor, lieber vom EXCEPT Operator/Statement zu
sprechen. Was meinst du dazu?

LG, Stefan


Am 2. August 2013 17:54 schrieb Roland Olbricht :
> Liebe Mitmapper,
>
> eine neue Version der Overpass API, Version 0.7.4 steht auf
> http://overpass-api.de
> zur Verfügung. Auf der Rambler-Instanz folgt das Update in den nächsten Tagen.
> Neben zahlreichen behobenen Bugs ist vor allem die Abfrage nach Ways und damit
> auch Relationen in kleinen Bounding-Boxen effizienter geworden. Damit sollte
> sich mit dem POI-Overlay-Prototyp
> http://overpass.apis.dev.openstreetmap.org/
> jetzt zügig arbeiten lassen.
>
> An Erweiterungen der Syntax gibt es zwei: Zum einen "global deklarierte
> Bounding-Boxen"; diese werde ich morgen genauer erläutern, wenn das
> korrespondierende JOSM-Plugin mirrored_download sich aktualisiert hat.
>
> Zum anderen der Differenz-Operator. Er dient dazu, Suchen der Art "alle
> Objekte die X haben/sind, aber nicht Y haben/sind" zu finden. Zum Beispiel
> hier alle Nodes, die einen Wert für "maxheight" gesetzt haben, aber nicht Teil
> einer Straße (d.h. eines ways mit Tag "highway") sind:
>
> http://overpass-turbo.eu/s/I6
>
> // Neu in Overpass 0.7.4: Der Differenz-Operator
>
> [bbox:50.6,7.0,50.8,7.3];
> (
>   node[maxheight]; // Alle Nodes mit irgendeinem Wert für "maxheight"
>   -
>   (way[highway];>;);   // die nicht auf irgendeiner Form von Straße liegen
> );
> out;
>
> Für den besonders häufigen Fall, dass es um "hat Tag X, aber nicht Tag Y"
> geht, empfehle ich weiterhin die bekannte Syntax mit "[...!~...]". Diese
> arbeitet effizienter als der Differenzoperator es kann.
>
> http://overpass-turbo.eu/s/I8
>
> // Neu in Overpass 0.7.4: Der Differenz-Operator
> //
> // Wenn es bloß um nicht gesetzte Tags geht, sollten diese lieber
> // als Bedingung aufgelistet werden und nicht als Differenz-Operator.
> // Das funktioniert schneller
>
> [bbox:50.7,7.0,50.75,7.1];
> ( way[highway=residential][name!~'.'];  // Ways mit Tag "highway", aber ohne
> Tag "name".
>   >;
> );
> out;
>
> Alle Details zur neuen Version gibt es im Wiki:
> http://wiki.openstreetmap.org/wiki/Overpass_API/versions
>
> Viele Grüße,
>
> Roland
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Info zu einer Arbeit über metrische Distanzmessung

[Stefan Keller]

Hallo Peter

Interessant. Scheint so etwas ähnliches wie der proprietäre" aber bewährte
PhotoModeler zu sein [1].

Nur damit ich es richtig verstehe:

1. Der geplante Ablauf - z.B. für die Bestimmung der Höhe einer
Kirchturmspitze - geht so:
* Der Benutzer macht mit dem Smartphone mind. zwei Bilder im seitlichen
Abstand von einigen Metern
* (wie der exakte Abstand gemessen wird ist noch offen).
* Der Benutzer bezeichnet (oder bestätigt) eine in den Bildern gemeinsame
horizontale Kante (z.B. seitliche Turmmauer)
* Wenn die SW fertig gerechnet hat, zeigt der Benutzer auf die
Kirchturmspitze und erhält dessen Höhe
?

2. Und deine Idee besteht darin, die in der Studentischen Arbeit
erarbeitete Desktopkomponente, welche die eigentliche 3D Rekonstruktion
macht, in ein App zu packen (obschon die SW schon auf dem Desktop einige
Zeit braucht und an Ressourcengrenzen stösst)?

LG, Stefan


[1] http://www.photomodeler.com/products/how-it-works.html


Am 22. August 2013 14:46 schrieb Peter Barth :

> Hallo Stephan,
>
> Stephan Knauss schrieb:
> > > [1] http://www.forwiss.uni-passau.de/extern/doc/BA_Stier_Reimar.pdf
> >
> > nette Arbeit. Erinnert mich etwas an das was Marek gemacht hat.
>
> das muss ich jetzt aber glaub ich doch kurz nochmal klarstellen, dass
> das etwas grundlegend anderes ist. Marek beschreibt da im Prinzip
> Fotogrammetrie, die erhebliche Nachteile gegenüber einer richtigen 3D-
> Rekonstruktion hat:
>
> * "schlechte" Abbildungseigenschaften der Kamera die nicht ausgeglichen
>   werden (Stichwort: Verzeichnung, Folge: Ungenauigkeit)
> * geringe und ungenaue Grundlage für die Metrik (Höhe der Kamera, Ebene
>   vor Gebäude, Ausrichtung der Kamera)
> * nur Höhen an Ebenen messbar (die Höhe eines Kirchturms kannst du damit
>   z.B. nicht bestimmen)
>
> Die Arbeit beschreibt bzw. vergleicht sich übrigens auch gegen andere
> Methoden und stellt vor allem auch die von mir kurz angesprochenen
> Vorteile heraus. Hauptnachteil ist "nur", dass es keine fertige App
> gibt. Dann wäre dass nämlich erheblich einfacher als mit Fotogrammetrie.
>
> Gruß,
> Peda
>
> --
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

[Stefan Keller]

Hoi Tobias

Interessante Diskussion und gut dass du gefragt hast :-)

Du hast geschrieben:
> - Ein Voronoi-Diagramm mit Postleitzahlen.

Voronoi ist m.E. bereits lösungsbezogen. Da gibt es ev. treffendere
Begriffe und vielleicht gibt es ja bessere Ansätze:
Bei Voronoi wird jede Region wird durch genau ein Zentrum bestimmt.
Was hier doch gesucht ist, das ist die Abgrenzung zwischen "Punktwolken",
bzw. Gebäudegruppen, wobei es auch Ausreisser haben kann, seien es korrekte
(weil der Pöstler mal schnell den anderen Briefkasten bedient, daher ja de
Name Post-Leit-Zahl) oder sei es weil es ein Fehler in den Daten ist.
Ich würde von Flächen-Segmentations-Algorithmus sprechen und als
Lösungsansatz z.B. Clustering-Algorithmen anschauen, z.B. [1]

LG, Stefan

[1] http://pointclouds.org/documentation/tutorials/cluster_extraction.php



Am 2. Oktober 2013 07:43 schrieb Toggenburger Lukas <
lukas.toggenbur...@htwchur.ch>:

> Ich versuche mal eine Zusammenfassung vom bisher gesagten zu machen.
> Folgende neue Wünsche habe ich herausgelesen:
>
> - Häuser als adressiert anerkennen, wenn ein oder mehrere Hausnummern auf
> den Eingängen (bzw. auf dem Gebäude) getaggt sind.
>
> - Glaubwürdigkeitsklassen: Anzahl anderer Strassen zählen, die eine
> Verbindungslinie Haus<->Zugehörige Strasse kreuzt (bzw. Anzahl Strassen
> zählen, die näher liegen, als die in der Adresse eingetragene Strasse)
>
> - Ausgabe von nicht-getaggten Häusern als GPX, damit man diese unterwegs
> anvisieren kann. Und/oder: Link generieren, der mittels Overpass das
> ausgibt, was auch im OSMI sichtbar ist.
>
> - GUI: Shortcut um alle Fehler-Arten anzuzeigen (in der bisherigen
> Version: no addr:street tag, street not found, interpolation lines with
> errors) und evtl. andere Angaben gleichzeitig ausblenden
>
> - Fehlende Postleitzahlen (evtl. auch fehlendes addr:city=, fehlendes
> addr:country=) markieren (evtl. nur dort, wo schon Adressangaben vorhanden
> sind)
>
> - Ein Voronoi-Diagramm mit Postleitzahlen. Ich nehme an, das gibt/gab es
> jedoch schon unter http://osm.wno-edv-service.de/plz .
>
> - Konfliktierende Adress-Angaben finden: Z.B. Postleitzahl aus
> addr:postcode <-> PLZ aus PLZ-Polygon
>
> Habe ich etwas übersehen?
>
> Bezüglich den Tagging-Schemata, ob und wie z.B. PLZ erfasst werden sollen,
> möchte ich niemandem Vorschriften machen. Es sollte jedoch erkannt werden,
> wenn es widersprüchliche Angaben hat, damit das jemand reparieren kann.
>
> Grüsse
>
> Lukas
> ___
> 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] tourism = viewpoint?

[Stefan Keller]

Nicht jeder Berg ist ein Berg :-) siehe die Kriterien hier [1]. Von daher
macht "tourism = viewpoint" von mir aus schon Sinn.

Ein ähnlicher Fall ist "tourism = yes". Das wird ja benutzt um die
touristische Bedeutung eines, durch andere Tags beschriebenen, Objektes
anzugeben.

LG, Stefan

[1] http://de.wikipedia.org/wiki/Berg


Am 11. Juli 2013 17:09 schrieb Tirkon :

> Sven Geggus  wrote:
>
> >Also Leute ehrlich. Wie kann man nur auf die völlig bescheuerte Idee
> >kommen 8000er Gipfel als "tourism = viewpoint" zu taggen?
>
> Und es wird noch verrückter: Wir dürfen auch all die Kioske mappen,
> die dort eröffnet werden - ideal, um dort insbesondere die Bücher von
> Reinhold Messner zu verkaufen. ;-)
>
> https://www.youtube.com/watch?v=D_pwYa58PRY
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] KeepRight seeks volunteers to help maintaining the website

[Stefan Keller]

Hi,

The founder of KeepRight [1] seeks volunteers who are willing to take over
maintaining the website!

KeepRight is a well-known and important quality assurance tool for OSM [2].
Many projects rely on it, like the "Quality Assurance Tools script" for
JOSM [3] or the Kort Game [4].

Please contact Harald at keepright at gmx dot at if you are interested or
have questions.

Yours, S.
(found via german OSM forum [5])

[1] http://keepright.at/
[2] http://wiki.openstreetmap.org/wiki/Keep_Right
[3] http://wiki.openstreetmap.org/wiki/Quality_Assurance_Tools_script
[4] http://wiki.openstreetmap.org/wiki/Kort_Game
[5] http://forum.openstreetmap.org/viewtopic.php?id=22784
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] KeepRight seeks volunteers to help maintaining the website

[Stefan Keller]

Addendum: Just in case Harald is not reachable: I'm available to answer
questions and coordinate communicatins around KeepRight for a while until
the new "project leaders" have been found.

Yours, S.


2013/10/13 Stefan Keller 

> Hi,
>
> The founder of KeepRight [1] seeks volunteers who are willing to take over
> maintaining the website!
>
> KeepRight is a well-known and important quality assurance tool for OSM
> [2]. Many projects rely on it, like the "Quality Assurance Tools script"
> for JOSM [3] or the Kort Game [4].
>
> Please contact Harald at keepright at gmx dot at if you are interested or
> have questions.
>
> Yours, S.
> (found via german OSM forum [5])
>
> [1] http://keepright.at/
> [2] http://wiki.openstreetmap.org/wiki/Keep_Right
> [3] http://wiki.openstreetmap.org/wiki/Quality_Assurance_Tools_script
> [4] http://wiki.openstreetmap.org/wiki/Kort_Game
> [5] http://forum.openstreetmap.org/viewtopic.php?id=22784
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] KeepRight seeks volunteers to help maintaining the website

[Stefan Keller]

Another addendum:
There is a SVN mirror on github:
https://github.com/CloCkWeRX/keepright-mirror
We found one person who is willing to take over.
Now we need at least another one...

-S.


2013/10/13 Stefan Keller 

> Addendum: Just in case Harald is not reachable: I'm available to answer
> questions and coordinate communicatins around KeepRight for a while until
> the new "project leaders" have been found.
>
> Yours, S.
>
>
> 2013/10/13 Stefan Keller 
>
>> Hi,
>>
>> The founder of KeepRight [1] seeks volunteers who are willing to take
>> over maintaining the website!
>>
>> KeepRight is a well-known and important quality assurance tool for OSM
>> [2]. Many projects rely on it, like the "Quality Assurance Tools script"
>> for JOSM [3] or the Kort Game [4].
>>
>> Please contact Harald at keepright at gmx dot at if you are interested
>> or have questions.
>>
>> Yours, S.
>> (found via german OSM forum [5])
>>
>> [1] http://keepright.at/
>> [2] http://wiki.openstreetmap.org/wiki/Keep_Right
>> [3] http://wiki.openstreetmap.org/wiki/Quality_Assurance_Tools_script
>> [4] http://wiki.openstreetmap.org/wiki/Kort_Game
>> [5] http://forum.openstreetmap.org/viewtopic.php?id=22784
>>
>
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] WG: Vorträge für FOSSGIS/OSM Konferenz 2014 gesucht

[Stefan Keller]

Am 2013-11-15 19:51:40 schrieb !i! im Forum:

Hallo,

für die FOSSGIS Konferenz im kommenden März in Berlin, sucht unbedingt noch
Vorträge. Bisher sind erst etwa 20 eingegangen und das ist ja ein bissel
mau, nech wink
Da es AFAIK DAS zentrale Zusammentreffen der deutschsprachigen Community
ist, wäre es super, wenn auch die OSM Community zeigt, was 2013/2014 so
entstanden ist, oder gerade heranreift:
http://www.fossgis.de/konferenz/2014/callforpapers/
(Einsendeschluss 30.11.)

Ich selbst finde es schade, dass man sich keine Themen "wünschen" kann,
hört man hier doch von so vielen spannenden Sachen. Für Themen mit mehr
Interessenten kann man dann ja auch mal gezielt Leute anschreiben, die sich
mit der Materie befassen.
Ich hab deshalb einfach mal angefangen was aufzuschreiben und bin gespannt,
was euch noch so auf den Nägeln brennt:
https://etherpad.mozilla.org/mx92b22SRg
(auch wenn ihr nur an Videos interessiert seid, bereichert bitte unser
Meinungsbild!)

P.S: Leute die Interesse haben da was einzureichen, aber sich aus
verschiedenen Gründen nicht trauen, die kann ich beruhigen. Die Konferenz
ist von sehr angenehmer Größe und mit sehr gutem Publikum (Mapper 
Free-GIS ExpertenVerwaltung). Auch wer finanziell nicht so gut
darstellt, kann über Fahrgemeinschaften und den FOSSGIS auf Nachfrage noch
Geld sparen.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Projekt Ahaus-Heek-Legden und Map-Wizard

[Stefan Keller]

Hallo

Kann jemand mehr berichten über den "Map-Wizard"
(http://www.map-wizard.com/) und das
Touristik-/Kulturlandschafts-Kartierungs-Projekt
Ahaus-Heek-Legden:
http://www.ahaus.de/2328.0.html?&print=1&no_cache=1(gefunden via
Wochennotiz Nr. 178 vom Dezember 2013!)?

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

Re: [Talk-de] Telenav übernimmt Skobbler

[Stefan Keller]

Hallo "wn reader", liebe alle

Interessante Nachrichten. Ich bin ja generell sehr für eine vermehrte
kommerziellen Nutzung von OSM-Daten - dies aber immer in der Annahme,
dass auch etwas in irgendeiner Form zurückgegeben wird.

1. Wenn ich mich nicht täusche, gibt gibt es beim Skobbler Navi-App
ein Fehler-Rückmelde-Formular und MapDust [2] soll laut ihnen "eines
der besten Verbesserungsportale für OpenStreetMap im Web" sein. Ich
hoffe, das wird noch ausgebaut.
=> Weiss da jemand mehr?

2. Die Meldung oben wurden offenbar von Wall Street und u.a. von
geoawesomeness übernommen. Da steht dann u.a. im Leadtext [2] "Telenav
acquires OpenStreetMap leader Skobbler, (...). Telenav had acquired
OpenStreetMap in 2013. Evidently Telenav is seeking to consolidate its
position in the OSM domain." (!?!)
=> Dies sollte ev. berichtigt werden.

LG, Stefan

[1] http://www.skobbler.de/mapdust
[2] http://geoawesomeness.com/telenav-acquires-openstreetmap-leader-skobbler/


2014/1/31 wn reader :
> Hallo,
>
> Telenav übernimmt Skobbler - http://www.skobbler.de 
> http://www.telenav.com/about/pr/pr-20140130.html
>
> Der Wert beläuft sich auf ca. 19,2 Mio. Dollar in Barmitteln plus 4,6 Mio. 
> Dollar in Stammaktien des Unternehmens. ( via 
> http://www.live-pr.com/telenav-bernimmt-mit-skobbler-das-f-hrende-r1050246598.htm
>  )
>
> Steve hat dazu gebloggt - 
> http://stevecoast.com/2014/01/30/its-time-to-make-openstreetmap-your-only-street-map/
>
>
> ___
> 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] Parkplatz einzeln als Punkt (nicht Flaeche): Wie?

[Stefan Keller]

Vielen Dank für die Diskussion. Also ich fasse mal zusammen:

Ausgangslage ist, dass einzelne Behinderten-Parkplätze erfasst werden
sollen, um sie später darzustellen (möglichst ohne mehrfache "P"s am
selben Ort) und v.a. auszuwerten (z.B. für Routing).

Stand:
Zurzeit gibt es für (v.a. grosse?) Parkplatz-Areale die Tags
"amenity=parking" sowie "amenity=bicycle_parking". Beide als Area aber
auch als Node (vgl. http://wiki.openstreetmap.org/wiki/Amenity ).
Zusätzlich kann "capacity:disabled=yes/" angegeben werden
(vgl. http://wiki.openstreetmap.org/wiki/Key:capacity:disabled ).

Diskussion: Es stellten sich die Fragen, 1. ob gleichzeitig flächige
Parkplatzareale und Einzelparkplätze (Punkt) erfasst werden sollen und
2. ob Einzelparkplätze gar selber als Fläche modelliert werden sollen.

Kommentar dazu:
* Ein weiteres Bedürfnis sind nicht nur Behinderten-Parkplatz sondern
auch Frauen-Parkplätze (bei amenity=parking zusätzlich
"capacity:women=yes/") sowie Familien-Parkplätze (zusätzlich
"capacity:parent=yes/").
* Es sollen gleichzeitig (d.h. am gleichen Ort) flächige
Parkplatzareale *und* Einzelparkplätze (Punkte/Symbole) erfasst werden
können. Vorschlag von aighes: Verschieden taggen und mit Relation
verknüpfen.
* Einzelparkplätzen sollen also nicht mit "amenity=parking" sondern
mit etwas anderem getaggt werden (wobei hier die Meinungen noch
auseinander gehen: Vgl.
http://lists.openstreetmap.org/pipermail/talk-de/2010-July/072184.html
). Vorschlag von mir: Bekanntlich ist es ja unter Androhung von Busse
verboten, als Normal-Autofahrer auf einem Behinderten-Parkplatz zu
parkieren.

=> Für grosse Parkplatz-Areale die Tags "amenity=parking" bzw.
"amenity=bicycle_parking" und zwar nur als Area mit dem
capacity-Zusatz-Tag.
=> Von der Erfassung von Einzelparkpklätzen (welcher Art auch immer)
mit "amenity=parking" soll abgeraten werden.
=> Einzelparkpklätze sollen mit
"parking_space=normal|woman|disabled|yes" getaggt werden (gem.
Vorschlag von aighes) (Frage: Warum "yes").

Wenn die Zeit (und Kollege t-i) soweit ist, machen wir ein Proposal
(t-i ist noch einige Tage abwesend).

LG, S.

Am 27. September 2010 22:38 schrieb aighes :
>
> Hallo,
> kannst du gerne machen. Allerdings sollte weiterhin eine Fläche mit den
> üblichen Tags vorhanden sein. Die einzelnen Stellplätze dann mit einem
> anderen Tag eintragen und dafür nicht amenity=parking nutzen. Spontan fällt
> mir parking_space=normal|woman|disabled|yes ein. Die Grundfläche und die
> einzelnen Nodes dann in eine Relation und gut ist.
>
> Viele Grüße,
> aighes
> --
> View this message in context: 
> http://gis.638310.n2.nabble.com/Parkplatz-einzeln-als-Punkt-nicht-Flaeche-Wie-tp5574328p5576827.html
> Sent from the Germany mailing list archive at Nabble.com.
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>

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

Re: [Talk-de] Wie Indoor-Wege mit 'normalen' Wegen verbinden (level)? Neues zu indoor=yes?

[Stefan Keller]

> dazwischen mit ensprechenden Kommaleveln.
Was sind Kommalevel?

LG, S.

Am 30. September 2010 10:35 schrieb Andreas Hubel :
> Am 29.09.2010 um 22:55 schrieb Steffen Wolf:
>> Hmm, wie werden denn eigentlich aussergebaeudliche Fusswege eingetragen,
>> die unter einem Gebaeue entlangfuehren, das an der Stelle eben erst in
>> der zweiten Etage beginnt? Und kann man die dann von einer Passage
>> unterscheiden? Sind ja beide eigentlich nicht so richtig indoor.
> Ich würde diese vereinzelten Sonderfälle mit outdoor=yes taggen.
>
>> Und wie spielt jetzt noch so ein Gebaeudeverbindungsweg in hoeheren Etagen in
>> dieses Konzept?
> Bei diesen Fußgänger Brücken tagge ich den Node im einen Gebäude mit dem 
> entsprechenden Level und den im Endnode im
> anderen Gebäude wieder mit dem entsprechenden level. Ggf. halt noch bridge=yes
> Falls die Verbindung irgendwelche Knicks in der Höhe macht (Treppen etc) dann 
> eben auch noch einen oder mehrere Nodes
> dazwischen mit ensprechenden Kommaleveln.
>
> Wenn mans so übertreiben möchte:
> Irgendwo (z.B. im Building oder wenns sein muss auch in ner Relation) muss 
> man halt noch sagen auf welcher Höhe die einzelnen Stockwerke des Gebäudes 
> liegen. Grade bei solchen Verbindungswegen merkt man die Höhenunterschiede 
> doch recht stark...
>
> MfG Andi
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>

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

[Talk-de] 11. Zürcher OSM-Stammtisch am 11. Ok tober 2010 zum Thema "Schöne Karten erzeugen mit OSM-Daten"

[Stefan Keller]

Erlaubt mir ein Cross-Posting (aus Talk-ch) in der Annahme, das Thema
könnte eine breitere Leserschaft interessieren:

Der 11. Zürcher OSM-Stammtisch vom 11. Oktober 2010 beschäftigt sich
u.a. mit dem Thema

  "Wie kann man aus OSM-Daten 'schöne' (druckbare) Karten erzeugen?"

Ich habe die Fa. OCAD AG (Baar/Schweiz) angefragt, ob jemand ihre
Software vorführen könnte.
OCAD ist Marktführerin für Orientierungslauf-Karten und die
französischen 25'000er-Landeskarten (TOP 25 série bleue) werden damit
hergestellt.

Weitere Infos: 
http://wiki.openstreetmap.org/wiki/DE:Switzerland:Zürich/OSM-Treffen

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

Re: [Talk-de] rolli-parking mit nummer

[Stefan Keller]

Hallo

Bitte beachtet, dass das aktuelle Konzept von 'Parkplatz' ein
Parkplatz-Areal meint. Daher auch der optionale Zusatz-Tag
capacity=number für die Anzahl der verfügbaren Parkplätze eines Areals
(vgl. http://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dparking).

Ich meine, dass persönliche Parkplätze (ob Areal oder Einzel) nicht
interessant sind für OSM, ähnlich wie private. Auf jeden Fall kann
m.E. eine solche Nummer nur an Einzelparkplätze hinzugefügt werden
(auch wenn das amenity=parking als Node zulassen würde).

Einzelparkplätze sollten *nicht* mit "amenity=parking" getaggt werden.
Der aktuelle Vorschlag ist "parking_space=normal|woman|disabled|yes"
(vgl. die Diskussion hier:
http://www.mail-archive.com/talk-de@openstreetmap.org/msg75425.html
!).

LG, S.


Am 13. Oktober 2010 22:11 schrieb Walter Nordmann :
>
>
> M∡rtin Koppenhoefer wrote:
>>
>> Die Frage war hier nach Parkplätzen für eingeschränkt Mobile, nicht
>> nach Autonummern, erstere haben gelegentlich ein Zusatzschild der Art
>> "nur für den Träger des Ausweises Nr. 543543543" (Wortlaut habe ich
>> gerade nicht parat). Das sind nur dann personenbezogene Daten, wenn
>> man sie auf eine Person bezieht.
>>
> ich frage mich, warum sollte die nummer in osm rein? ich sehe absolut keinen
> grund dafür.
> ok, die info, dass es sich um einen RESERVIERTEN platz handelt "hier
> parkplatz aber nicht für dich !!! " ist ok, aber wofür die kennzeichnung?
>
> gruss
> walter
>
>
> -
> Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll
> hinein. - Ingo Insterburg
> --
> View this message in context: 
> http://gis.638310.n2.nabble.com/rolli-parking-mit-nummer-tp5628601p5632515.html
> Sent from the Germany mailing list archive at Nabble.com.
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>

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

Re: [Talk-de] Parkplatz einzeln als Punkt (nicht Flaeche): Wie?

[Stefan Keller]

Habe meinen Vorschlag für die Erfassung von Einzelparkplätzen (engl.
''individual parking spaces'') innerhalb von Parkplatz-Arealen
nochmals überarbeitet und hier festgehalten:

http://wiki.openstreetmap.org/wiki/User:Geonick/Parking

Grüsse, S.

Am 30. September 2010 19:39 schrieb M∡rtin Koppenhoefer
:
> Am 29. September 2010 13:40 schrieb Stefan Keller :
>> Ausgangslage ist, dass einzelne Behinderten-Parkplätze erfasst werden
>
>
> im Prinzip geht es allgemeiner darum, nicht nur Parkplätze (als
> Gesamtheit inkl. Wegen etc.) zu taggen, sondern auch einzelne
> Parkflächen (Netto-Stellplätze) eintragen zu können.
>
>
>> Stand:
> +1
>
>
>> Kommentar dazu:
>> * Ein weiteres Bedürfnis sind nicht nur Behinderten-Parkplatz sondern
>> auch Frauen-Parkplätze (bei amenity=parking zusätzlich
>
>
> ja klar, und auch sonstige Sonderparkplätze, und warum eigentlich
> nicht auch allgemeine Parkplätze? Z.b. sind mancherorts die
> Parkflächen entlang der Straße als amenity=parking getaggt. Die könnte
> man dann auch umstellen.
>
>
>> * Es sollen gleichzeitig (d.h. am gleichen Ort) flächige
>> Parkplatzareale *und* Einzelparkplätze (Punkte/Symbole) erfasst werden
>> können. Vorschlag von aighes: Verschieden taggen und mit Relation
>> verknüpfen.
>
>
> wer will, kann sich ne Relation dazu ausdenken, brauchen tut man die
> nicht notwendigerweise, ist ja geometrisch schon definiert (wenn auch
> aufwendig in der Auswertung).
>
>
>> * Einzelparkplätzen sollen also nicht mit "amenity=parking" sondern
>> mit etwas anderem getaggt werden
>
>
> +1
>
>
>> => Für grosse Parkplatz-Areale die Tags "amenity=parking" bzw.
>> "amenity=bicycle_parking" und zwar nur als Area mit dem
>> capacity-Zusatz-Tag.
>
>
> warum "nur" als Area, node als Interimslösung ist in dünnen Gebieten
> besser als nichts
> was sind "große" Areale? Kommt dann demnächst ein Bot daher und löscht
> mir die amenity=parking mit dem Verweis, 20 Stellplätze (oder wieviel
> auch immer) sind nicht ausreichend für einen Parkplatz? Ich würde
> "gesamten" Parkplatz schreiben.
>
>
>> => Von der Erfassung von Einzelparkpklätzen (welcher Art auch immer)
>> mit "amenity=parking" soll abgeraten werden.
>
>
> klar
>
>
>> => Einzelparkpklätze sollen mit
>> "parking_space=normal|woman|disabled|yes" getaggt werden (gem.
>> Vorschlag von aighes) (Frage: Warum "yes").
>
>
> vermutlich yes, wenn man es nicht weiss, ob es ein Sonderparkplatz ist.
>
> Gruß Martin
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>

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

Re: [Talk-de] Amenity Editor mit OAuth

[Stefan Keller]

Keine Suche?
Kein Problem für gut gemachte Webkarten mit Permalink!
Einfach "osm heidelberg" in http://directory.geometa.info/ eingeben.

-LG, S.

Am 18. Oktober 2010 10:46 schrieb Peter Körner :
> Am 17.10.2010 14:34, schrieb Adrian Stabiszewski:
>>
>> Das Tools ist wie bisher unter http://ae.osmsurround.org erreichbar.
>
> Bitte, bitte: eine Suche!
> Wie soll ich sonst ohne Permalink oder Ewiges Rumklicken meinen Wohnort
> finden?
>
> Lg
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>

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

Re: [Talk-de] OSM quo vadis

[Stefan Keller]

Ich bin mit der Einschätzung von Frederik grundsätzlich einverstanden,
nämlich dass der Kern unseres OSM-Projektes die Sammlung freier Daten
ist. Wenn wir etwas "auf die einsame Insel" mitnehmen müssten, dann
ist es die Datenbank, nicht abgeleitete Produkte und schon gar nicht
die Karten-Tiles.

Aus meiner Erfahrung weiss ich aber, dass die Leute etwas Sichtbares,
"Greifbares", etwas "direkt Nützliches" brauchen. Dazu ist die
aktuelle Startseite mit einer Webkarte goldrichtig - sozusagen das
Schaufenster zu den Daten und zum Projekt (ähnlich wie übrigens auch
http://geonames.org). OSM als Webservice (Tiles) scheint mir ein
zweiter wichtiger "Showcase".

Und aufgeräumt soll die Startseite sein, bzw. bleiben.

Kartengrafik ist anspruchsvoll. Und mit dem Haupt-Renderer Mapnik m.E.
nicht schlecht. Wenn sich dazu jemand die Mühe macht, konstruktive
Kritik zu üben (was ja teilweise der Auslöser dieser Diskussion ist) ,
dann könnte man die Verbesserungsvorschläge durchaus prüfen.

Neben der nochmals verbesserten Kartengrafik (Mapnik) könnte man m.E.
höchstens - wie bereits vorgeschlagen - links noch einen Hauptlink
"Anwendungen" dazutun. Zu den Anwendungen zähle ich:
OSM-"Kern-Software" sowie weitere (Open Source) Software, Webdienste,
Webkarten und abgeleitete Daten "Dritter".

Bei den Hauptlinks würde ich die "Legende" rausnehmen und woanders
hintun (die gehört nicht dahin) und die Links gemäss
Usability-Prinzipien ordnen. D.h

Anstelle:
* Hilfe + Wiki
* Urheberrecht + Lizenz
* Neuigkeiten-Blog
* Shop
* Legende

Neu:
* Aktuelles
* Hilfe + Wiki
* Anwendungen
* Lizenz
* Shop

Das wäre mit kleinem Aufwand grosse Wirkung.

Gruss, S.


Am 20. Oktober 2010 03:23 schrieb Florian Gross :
> Am Dienstag 19 Oktober 2010, 17:06:54 glaubte Peter Körner zu wissen:
>
>> Wenn die Maus nicht innerhalb eines Blockes ist, wechseln diese alle 5
>> Sekunden den Inhalt.
>
> WUAAHHH!!1
>
> Bitte bitte nichts sich dauernd veränderndes. Mit sowas verscheucht
> man sich eine einige Besucher. Sowas nervt nur.
>
> Wenn du auf sowas in extrem stehst kann ich dir
> http://www.klickibunti.org/buntibunti.php wärmestens ans Herz
> legen.
> ACHTUNG! Die Seite ist nur mit äußerster Vorsicht zu genießen!
>
> flo
> --
>>Aber Windows 2000 kommt... Ich hoffe nicht, dass wir damit die Schnauze 
>>fallen.
> "Aber der Smart kommt...  Ich hoffe nicht, daß wir damit auf der Autobahn
> überholt werden..." Hoffst du auf das generelle Tempolimit? :-)
>                                     [Ralph Mothes und Thomas Koehler in dasr]
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>

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

Re: [Talk-de] OSM quo vadis

[Stefan Keller]

> Ich denke, wir brauchen den Mittelweg: Karte UND Infos, und beides auf einem 
> gemeinsamen Portal.

Zu diesem Schluss bin ich auch gekommen. Dazu folgendes: Nicht umsonst
heisst es allenthalben, OSM sei das "Wikipedia der Landkarten". Und:
Seit 30 Jahren versuchen die GIS-Leute (inkl. mir) zu erklären, was
sie unter anderem machen (nämlich: Eingabe, Verarbeitung, Ausgabe und
Präsentation von Geodaten) - seit G*** Maps, Earth & Co. geht das
alles plötzlich viel einfacher...

Daher mein Votum für eine leicht überarbeitete Startseite mit einer
"OSM-Standard-Landkarten-Darstellung" sowie ein von dort verlinktes
"Portal", wie manche es nennen.

LG, S.

Am 20. Oktober 2010 14:43 schrieb Peter Wendorff :
>  Nun ja (Teilkommentare zwischen dem Text)
>
> On 20.10.2010 13:19, Frederik Ramm wrote:
>>
>> On 10/20/10 13:00, Markus wrote:
>>>
>>> _Startseite_
>>> Weltkarte (mit Link zum Portal)
>>> _Portal_
>>> Ansprechende übersichtliche informative Seite mit Zugang zu all den
>>> vielfältigen Inhalten, die hier im Thread bisher angeregt wurden.
>>
>> Umgekehrt - Startseite unseres Projektes sollte nicht die Karte sein,
>> sondern das, was Du "Portal" nennst. "Die Karte" ist ja nur ein Beispiel
>> dafuer, was man mit unseren Daten machen kann, und nicht unser Ziel oder
>> Ergebnis. Langfristig, wenn es viele andere Seiten wie opencyclemap.org usw.
>> gibt, die schoene Karten aus unseren Daten machen, kann die Karte von
>> openstreetmap.org auch ganz weg.
>
> Jein.
> Ich bin auch dafür, dass die Startseite nicht die Karte sein sollte.
> Ich gebe Dir recht, dass die Karte nur ein Beispiel dafür ist, was man aus
> osm machen kann.
> Ich gebe dir aber nicht recht, dass die Karte völlig verschwinden kann.
>>>
>>> Aber wir dürfen sie nicht als Konkurrenz zur Karte aufbauen.
>>> Denn der Besucher sieht in OSM die freie Weltkarte:
>>> die Visualisierung der von uns gesammelten Geo-Daten,
>>
>> Dann muessen wir den Besucher umerziehen. Eine kostenlose Weltkarte
>> bekommt er bei Google. Der Unterschied zwischen der freien und kostenlosen
>> Karte laesst sich nicht anhand eines Kartenbilds erklaeren.
>
> Wie aber willst Du einen Besucher umerziehen, wenn er zu Google geht, weil
> er keine Karte sieht, die er eigentlich sucht?
> "Erziehung" von Besuchern und Nutzern ist gut und richtig - aber nicht im
> Fahrstuhlpitch Frontpage zu erreichen, wenn diese überhaupt nicht die
> Erwartungen trifft.
> Die Karte ist ein Eyecatcher, und als solche wirkt sie vermutlich ganz gut.
> Momentan mit der Problematik, dass die zusätzlichen Infos fehlen: Warum
> eigentlich? was ist hier besser als bei Google und Co? Was hab ich davon?
> Was kann ich hier? nichts? ich geh zu google.
>
> Wenn die Karte aber fehlt, die ich eigentlich suche, dann "bin ich hier
> falsch", dann "erzählen die mir irgendeine Utopie von Freiheit, die mir aber
> Arbeit macht, um etwas davon zu haben".
>
> Ich denke, wir brauchen den Mittelweg: Karte UND Infos, und beides auf einem
> gemeinsamen Portal.
>>
>> Es ist in meinen Augen nicht akzeptabel, die Richtung des Projekts durch
>> das zu definieren, was ein uninformierter Besucher sich eventuell unter dem
>> Projekt vorstellt. Wenn das stimmt, was Du sagst ("der Besucher sieht in OSM
>> ... die Visualisierung der Geodaten"), dann liegt der Besucher falsch, und
>> wir muessen uns bemuehen, ihn aufzuklaeren, anstatt einfach aufzugeben und
>> den Versuch zu unternehmen, ihm das zu liefern, was er sich vorgestellt hat.
>
> Ich will nicht die Karte dem "OttonormalGoogle-Nutzer" anpassen; ich will
> nicht den Kartenstil deshalb ändern, weil Mapper das falsche Publikum wären
> oder so - sicher nicht.
> Ich will die Karte auch nicht Infos vorziehen.
> Um aber Menschen zur OSM zu bringen, zieht erstmal die Karte. Da zieht das
> Argument, die Karte ändern zu können und fehlende Daten einzupflegen, die
> Karte zu verbessern. Danach, nach den ersten Sekunden und Minuten, zieht das
> Argument der FREIEN Daten, und nur beim technisch versierten,
> anspruchsvollen Teil derer, mit denen man spricht, zieht ganz zum Schluss
> die Möglichkeit, eigene Karten und Anwendungen zu machen.
>
> Dem sollten wir Rechnung tragen, indem wir in der Präsentation beides
> bedienen: Die Karte, die greifbares veranschaulicht, und den ganzen Rest,
> der die Freie Nutzbarkeit der Daten in allen Facetten skizziert.
>
> Gruß
> Peter
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>

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

Re: [Talk-de] Referenz-Tag mit Prefix

[Stefan Keller]

Ich begreife den ref-Tag immer noch nicht...

* Soll das eine Beziehung sein, um mehrere Ways (z.B. einer Autobahn)
mit gleichem Strassennamen zusammenzufassen?
* Gibt es Tools, die nutzen?
* Gibt es dafür nicht die Relation?

"Key:ref" erscheint auch im Wiki in 9(!) Untervarianten
(http://wiki.openstreetmap.org/wiki/Map_Features#References bzw.
http://wiki.openstreetmap.org/wiki/Key:reference) jedoch ohne
wirkliche Erklärung.

Hier zwei verwirrende Beispiele:

1. Es gibt Feldbachstrasse(n), mit ref=339; dazu gibt es aber auch
eine damit verbundene Strasse namens Oetwilerstrasse.

2. Da gibt es im (Schweizer) Bündnerland eine ref="Google Maps"!!!
siehe http://nominatim.openstreetmap.org/details.php?place_id=45040304

-S.

Am 29. September 2010 03:05 schrieb Stephan Wolff :
> Am 24.09.2010 10:27, schrieb Jochen Topf:
>>
>> On Fri, Sep 24, 2010 at 09:09:44AM +0200, Andre Joost wrote:
>
>>> Vorschlag:
>>> ref:kvv=R8
>>> ref:vrn=R51
>
>> Was genau soll eigentlich der "ref"-Bestandteil aussagen? Brauchen wir
>> den?
>
> "ref:" ist nicht zwingend, aber hilfreich. Ähnlich wie "name:de=TEXT"
> Vorteile hat gegenüber "deutsche_bezeichnung=TEXT".
>
>> Warum nicht etwas wie:
>> karlsruher_verkehrs_verbund_haltestellennummer=ABC
>> oder
>> freiburger_verkehrs_ag_linie=17
>
> Ein Programm, das ref-Tags auswertet und als Kartenbeschriftung einträgt,
> könnte aus Andres Beispiel einen sinnvollen Text generieren (etwa "R8(kvv) /
> R51(vrn)"). Jochens Alternative wäre nicht auswertbar.
>
> Ein OSM-User, der nicht deutsch versteht, kann Andres Beispiel zumindest
> teilweise interpretieren, Jochens Tagnamen nicht.
>
>> Und sowas wie ref:de:foo=18 täuscht nur eine Systematik vor, die nicht
>> existiert.
>
> Da stimme ich Jochen zu.
>
> Viele Grüße, Stephan
>
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>

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

Re: [Talk-de] Neu: Karte für Android und iPhone Brow ser

[Stefan Keller]

Servus Bernhard

Sehr schöne Website - auch auf Android! Witzig gemacht der OSM-Hinweis
links unten. Interessant die schlanke khtml lib.
Hab's mit Firefox 3.6.11 und Nexus One (Google/HTC) getestet.
Folgende Fragen und Hinweise dazu:

1. Du schreibst oben "Ich hab eine neue simple Karte mit GPS und
Nominatim für iPhone und Android gemacht".
* In der Doku. findet man dann aber kaum Hinweise zu Unterschieden
zwischen PC-Browser und Mobile. => Doku. ergänzen?
* Tatsächlich habe ich nach oberflächlichem Code-Browsen nichts
gefunden, wo geprüft wird, welcher Browser (user-agent) da die
html-Seite aufruft (auch kein type="text/css" media="handheld").
* Android fehlt mind. in der Doku. praktisch ganz (Multitouch?).

2. Zu http://www.khtml.org/osm/v0.78/index.php generell:
* Window Title "World Map with Route planning" würde ich "khtml World
Map" nennen, um sich sichtbar abzugrenzen. Dann "World Map with Route
planning"  nochmals erwähnen. Route planning, ticker etc. dann
im Text.

3. Zu http://www.khtml.org/osm/v0.78/index.php mit dem Nexus One-Browser
* Da sieht man einen rosa Schleier während Zoom/Pan/(Re-)Load-Operationen.
* Nach "More..." gibt es Permalink: Erhalte da eine weisse Seite (wenn
ich dann im Browser "Aktualisieren" klicke, siehr man wieder etwas).
* Die "+" / "-" Icons würde ich noch schlichter halten und den "Griff"
der Lupe weglassen.

Beste Grüsse - und vielleicht sehen wir uns ja an der nächsten AGIT
(www.agit.at)?
Stefan (alias Geonick)

P.S. "Live Changes":
http://www.khtml.org/osm/v0.63/examples/changes.html New beta: Lädt
bei mir auf Firefox ewig - obschon ich 'reingezoomt bin.

P.P.S. "See the last changes in your area" => Deaktiviert. Was war der
Grund? Gibt's da Ersatz/Alternativen (neben OSM Aware und
LiveMapViewer)?



Prof. Stefan Keller, Dozent für Informationssysteme,
Abt. Informatik HSR Institut für Software und GISpunkt,
www.ifs.hsr.ch und www.gis.hsr.ch
Oberseestr. 10 Pf.1475, CH-8640 Rapperswil, HSR Hochschule für Technik

Am 19. Oktober 2010 10:53 schrieb Bernhard Zwischenbrugger 
:
> Hallo ihr lieben
>
> Ich hab eine neue simple Karte mit GPS und Nominatim für iPhone und Android
> gemacht.
>
> Beim iPhone hat man das beste Ergebnis, wenn man auf "+" und "Zum
> Home-Bildschirm" verwendet.
>
> Die Karte ist eine Browser Applikation und muss nicht installiert werden.
>
> URL:
> http://khtml.org
>
> lg, Bernhard
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>

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

Re: [Talk-de] Neu: Karte für Android und iPhone Brow ser

[Stefan Keller]

 nochmals erwähnen. Route planning, ticker etc. dann
>> im Text.
>>
>
> An der Page könnte man noch einiges feilen.
>>
>> 3. Zu http://www.khtml.org/osm/v0.78/index.php mit dem Nexus One-Browser
>> * Da sieht man einen rosa Schleier während Zoom/Pan/(Re-)Load-Operationen.
>>
>
> Am Milestone ist das Gelb. Ich bin aber leider noch nicht draufgekommen
> woher das kommt.
> Bei den Events hab ich ein perventDefault drinnen und das Selektieren von
> Text ist dekativiert.
> Ich probiere aber den Fehler zu finden.
>>
>> * Nach "More..." gibt es Permalink: Erhalte da eine weisse Seite (wenn
>> ich dann im Browser "Aktualisieren" klicke, siehr man wieder etwas).
>>
>
> Ist in der neuesten Version repariert.
> http://www.khtml.org/osm/v0.83/examples/mobile/
> <http://www.khtml.org/osm/v0.79/examples/mobile/>
> Der Permalink wird mit eiem Hash gemacht.
> Wien:
> http://www.khtml.org/osm/v0.83/examples/mobile/index.html#48.2:16.5:12
> Da die URL Zeile in den Mobilen Browsern sehr kurz ist, sieht man den
> Hashwert aber nicht.
> Es kapiert also niemand wie das geht.
> Auch QR Codes haben mit langen URLs Probleme.
>>
>> * Die "+" / "-" Icons würde ich noch schlichter halten und den "Griff"
>> der Lupe weglassen.
>>
>>
>
> Wenn ich besser Icons finde, dann bau ich diese ein.
>>
>> Beste Grüsse - und vielleicht sehen wir uns ja an der nächsten AGIT
>> (www.agit.at)?
>>
>
> Ich würde mein library gerne auf der AGIT vorstellen - bis Dezember bin ich
> aber
> ausgelastet und werde mich da wohl eher nicht bewerben.
>>
>> Stefan (alias Geonick)
>>
>> P.S. "Live Changes":Enduser-Tauglich
>> http://www.khtml.org/osm/v0.63/examples/changes.html New beta: Lädt
>> bei mir auf Firefox ewig - obschon ich 'reingezoomt bin.
>>
>
> Das gibt es auch in einer neueren Version:
> http://www.khtml.org/osm/v0.83/examples/changes.html
>
> Die Changes Page ist nicht wirklich für die Allgemeinheit bestimmt.
> Das UI ist recht kompliziert und nicht erklärt.
>
> Die changesets API wurde umgebaut und reinzoomen ist nicht mehr nötig.
> Zumindest funktioniert das bei sehr grossen und sehr kleinen Bereichen
> sehr gut. Bei mittelgrossen Bereichen ist die DB aber leider noch sehr
> beschäftigt.
> (Kombination timestamp und geoindex)
>
> Das Laden der einzelnen Changesets dauert recht lange, da die Changesets
> nicht alle Informationen enthalten die gebraucht werden.
> (Mehrere AJAX Requests)
>
> Sobald ich einen Weg finde die nötigen Informationen in einer vernünftigen
> Zeit
> aus der API auszulesen, bau ich da ein besseres UI.
>
>> P.P.S. "See the last changes in your area" =>  Deaktiviert. Was war der
>> Grund?
>
> Das wurde im Forum diskutiert. Die API Requests können die DB sehr belasten
> und das hat jemanden furchtbar aufgeregt. Die Konsequenz war, dass ich den
> Link deaktiviert
> habe.
>>
>> Gibt's da Ersatz/Alternativen (neben OSM Aware und
>> LiveMapViewer)?
>>
>
> Keine Ahnung.
>
>
> lg, Bernhard Zwischenbrugger
>
>
>
>> 
>>
>> Prof. Stefan Keller, Dozent für Informationssysteme,
>> Abt. Informatik HSR Institut für Software und GISpunkt,
>> www.ifs.hsr.ch und www.gis.hsr.ch
>> Oberseestr. 10 Pf.1475, CH-8640 Rapperswil, HSR Hochschule für Technik
>>
>> Am 19. Oktober 2010 10:53 schrieb Bernhard
>> Zwischenbrugger:
>>
>>>
>>> Hallo ihr lieben
>>>
>>> Ich hab eine neue simple Karte mit GPS und Nominatim für iPhone und
>>> Android
>>> gemacht.
>>>
>>> Beim iPhone hat man das beste Ergebnis, wenn man auf "+" und "Zum
>>> Home-Bildschirm" verwendet.
>>>
>>> Die Karte ist eine Browser Applikation und muss nicht installiert werden.
>>>
>>> URL:
>>> http://khtml.org
>>>
>>> lg, Bernhard
>>>
>>> ___
>>> Talk-de mailing list
>>> Talk-de@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-de
>>>
>>>
>>
>> ___
>> Talk-de mailing list
>> Talk-de@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-de
>>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Portal Vorschlag (Was: Re: OSM quo vadis)

[Stefan Keller]

Gute Arbeit.

Ich finde eine - auf dem Portal einzige - topografische Onlinekarte
(wie es jetzt mit Mapnik ist) nützlich: Erstens
weil diese "Weltkarte" "nach aussen" m.E. ein greifbares
Aushängeschild ist und zweitens weil sie "nach innen" identifizierend
und koordinierend wirkt.

Hier noch Kleinigkeiten zum mittleren Kasten: Da steht "Alle unsere
Geodaten sind als Geometrie-Objekte gespeichert — Punkte, Linien,
Flächen — daher sind sie vielfältig einsetzbar. So lassen sich
beispielsweise nicht nur Rasterkarten erstellen, sondern auch
Routinganwendungen oder Geokodierung."

* Statt gespeichert => verwaltet.
* Statt Geokodierung => Adress-Geokodierung.
* Irgendwo das Kürzel OSM einflechten.

Interessant, dass du da "Flächen" erwähnst; das ist konzeptionell
richtig und wünschbar. In Wahrheit gibt es aber in OSM eben leider
noch gar keine solche! Ehrlicherweise müsste man da "Punkte, Linien,
Beziehungen" schreiben...

LG, S.

Am 25. Oktober 2010 17:19 schrieb Sebastian Hohmann :
> Am 25.10.2010 16:41, schrieb Peter Körner:
>>
>> Am 25.10.2010 15:27, schrieb Sebastian Hohmann:
>>>
>>> Um eine Auswahl an anderen Karten zu sehen, braucht man einen Klick auf
>>> "Andere empfohlene Karten". Wenn man sich in einer Box Karte für Karte
>>> durchklicken muss, hat man viel weniger Platz und Übersicht.
>>
>> Aber warum fokusierst du dich so auf Karten? Es war doch einer der
>> Ausgangspunkte dieser Diskussion, dass wir viel mehr als Karten
>> ermöglichen: Routing, Smartphone-Anwendungen, Suchen, Statistiken, und
>> vieles mehr.
>>
>
> Auf der Seite sind doch schon Routing und mobile Anwendungen zu finden. Ich
> verstehe einfach nicht, warum ein Durchklicken "Sache für Sache" besser sein
> soll, als eine Übersichtsseite, wo man einfach schnell durchscrollen kann.
>
> Erinnert man sich z.B. daran eine bestimmte Anwendung da mal gesehen zu
> haben, müsste man sich eventuell zig mal durchklicken, anstatt direkt
> gezielt in ein paar Sekunden auf den Link zu kommen.
>
> Vielleicht kann man ja "Andere empfohlene Karten" durch "Andere empfohlene
> Anwendungen" ersetzen, aber ansonsten sehe ich da kein Problem.
>
> Gruß
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>

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

Re: [Talk-de] Schlechtest Wertung für OSM im Kartenver gleich

[Stefan Keller]

Der Vergleich mit Apfel und Birne gefällt mir - möchte ihn aber etwas anpassen:

Ich sehe die OSM-Daten wie Obstkerne.
Leider sieht man die durch die Äpfel und Birnen nicht!
Also brauchen wir nebst dem Portal ein Obst - ob Apfel oder Birne -
damit man OSM sieht.
Mit Mapnik als Onlinekarte haben wir so einen Apfel sozusagen als
"Spatz, in der Hand".
Lasst uns zuerst die Daten (u.a. mit Städte-Klassierung) und dann auch
das Mapnik-Styling verbessern.

S.

Am 24. Oktober 2010 19:46 schrieb Frederik Ramm :
> Hallo,
>
> Stefan Sandrock wrote:
>>
>> So - und nun kommt die Wirklichkeit und hält uns vom Projekt vor, wie es
>> wahrgenommen wird.
>
> Eben. Und da ist der Knackpunkt. Wir sind eine Birne, und jetzt kommt die
> Oeffentlichkeit und haelt uns vor, dass wir im Apfelwettbewerb leider wegen
> eines Abzugs in der Form-Note den letzten Platz gemacht haben. Nun koennen
> wir entweder (a) beschliessen, doch lieber ein Apfel sein zu wollen, weil
> das diejenigen, die uns nicht kennen, von uns erwarten, oder (b) versuchen,
> denen, die uns nicht kennen, zu erklaeren, was eine Birne ist und dass es da
> naturgemaess Unterschiede zum Apfel gibt.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>

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

Re: [Talk-de] OSM auf Deutsch

[Stefan Keller]

Hier etliche Ausführungen und Verweise zum Thema:
http://gis.hsr.ch/wiki/Geografische_Namen .
Ist zwar etwas schweizlastig, aber trotzdem für alle Deutschsprachigen
interessant.

LG, S.

Am 18. September 2009 19:10 schrieb Martin Koppenhoefer
:
> Am 18. September 2009 15:58 schrieb Dennis Egbers :
>> bessere Alternative. Offiziell heißt (falls die sich inzwischen nicht
>> doch anderweitig geeinigt haben) Sterzing Vipiteno oder Brixen
>> Bressanone. Trotzdem benutzt in dem Fall doch fast niemand - weder vor
>> Ort noch in Deutschland - die italienischen Namen (zudem die ja nun
>> auch alles andere als politisch korrekt zustande gekommen sind).
>
> naja, die (italienischsprachigen) Italiener benutzen "alle" die
> italienischen Namen, und vor Ort gelten beide Namen gleichberechtigt
> (Südtirol ist eine autonome Region mit Sonderstatus), so dass die
> Deutschsprachigen "natürlich" die deutschen Namen weiterhin benutzen
> (als Minderheit reagiert man da ja immer besonders empfindlich).
>
> Grundsätzlich halte ich ein name:de für die Orte, wo ein deutscher
> Name "besteht", für angebracht. Das gilt m.E. für Rom wie Breslau oder
> Auschwitz gleichermaßen.
>
> Gruß Martin
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>

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

Re: [Talk-de] Beschriftung von Orten

[Stefan Keller]

@Tobias: Was hast du wohin im Wiki verschoben?

@Markus: Bin auch an einer Ortsgrößenklassen interessiert, damit die
Renderer eine Chance haben, Populations-mässig kleiner - aber
wichtigere - Orte früher und über andere zu zeichnen. Habe nun in
osm.xml noch nichts Ähnliches zu Frederiks Vorschlag gesehen (Ändern
Layer "placenames" ab Zeile 7017).

Was ist der Stand?

Liebe Grüsse, S.

Am 29. Juni 2009 16:56 schrieb Tobias Wendorff
:
> Markus schrieb:
>> http://wiki.openstreetmap.org/wiki/DE:Anzeige_von_Städten
>> http://wiki.openstreetmap.org/wiki/Ortsgrößenklassen
>
> Bin ich denn der einzige, der Ordnung im Wiki haben möchte?
>
> wiki/maps/DE:...
> oder
> wiki/cartographie/DE:...
>
> aber nicht alles irgendwieherum klatschen.
>
> Ich werde ins neue Wiki eindeutig Verschiebe- und
> Umbenennungsfuktionen einbauen. Momentan gibt es ja nur
> wenige Leute, die diese Rechte haben :-/
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>

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

Re: [Talk-de] Wiki: Haltestellen-Chaos

[Stefan Keller]

Claudius, du verwirrst mich. Es ist hier doch eine eine Tendenz
erkennbar, nämlich highway=bus_stop als Mast beim Haltepunkt neben der
Straße (nicht auf dem Way) plus allfällige weitere Tags.

Oben schriebst du:
> Da es da aber immer noch keinen Konsens gibt (und sich nicht einmal einer 
> abzeichnet,
> da die transit-Liste nicht zu Potte kommt) werde ich das Wiki zu bus_stop 
> nicht verändern.
und
> Bei Haltestellen die ich neu erfasse packe ich gar kein bus_stop mehr dran, 
> sondern ausschliesslich public_transport-Tags.

Der Fall hier scheint mir klar: "Aus Kompatibilitätsgründen wird
highway=bus_stop aber üblicherweise zusätzlich bei einem Node mit
public_transport=stop_position verwendet und mit denselben Attributen
versehen wie bei unified_stoparea."

Hat nun niemand (anders) den Mut, im Wiki mindestens die
"Meistgenutzte Verwendung" (mit highway=bus_stop) noch mehr
hervorzuheben und die anderen Schemas noch besser abzusetzen?

-S.


Am 3. November 2010 19:57 schrieb Claudius :
> Am 03.11.2010 18:16, M∡rtin Koppenhoefer:
>>
>> Am 3. November 2010 12:50 schrieb Claudius:

 kann Dir das nicht völlig egal sein, wo Du die stop_position sowieso
 nochmal extra einträgst?
>>>
>>> Könnte mir, aber da ich mich selber auch schon mit der Auswertung
>>> beschäftigt habe, konnte ich den Vorteil der Platzierung auf dem Weg
>>> erkennen. Die Information zum Haltestellenstandort steckt ja im
>>> platform-Tag.
>>
>>
>> Klar, man kann diese Argumentation auch umdrehen, was bleibt ist dass
>> Du ein tag (highway=bus_stop) absichtlich entgegen dem allgemeinen
>> (AFAIK lang und breit ausdiskuttierten) Konsens verwendest, obwohl Du
>> sowieso Redundanzen anlegst. Ist in meinen Augen respektlos gegenüber
>> der Community.
>
> Nein, da habe ich mich missverständlich ausgedrückt. Ich setze kein
> gesondertes highway=bus_stop, ich belasse aber vorhandene auf dem Weg und
> tagge die nicht an den Knoten auf der Warteposition um. Könnte ich wohl
> machen, wenn das einigen hier so wichtig ist.
> Bei Haltestellen die ich neu erfasse packe ich gar kein bus_stop mehr dran,
> sondern ausschliesslich public_transport-Tags
>
> Claudius
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>

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

Re: [Talk-de] OLM 5 ist da

[Stefan Keller]

Schöne Webapp.! Leider muss ich aber zugeben, dass ich etwas verwirrt
bin, welche Links nun verarbeitet werden.

Eine Suche nach Rapperswil ergibt z.B. nur drei Treffer, einer davon
z.B. der Bahnhof:
http://olm.openstreetmap.de/?zoom=18&lat=47.224718&lon=8.817574&id=35120580&objecttype=node
Wenn man sich die Details dazu ansieht
(http://www.openstreetmap.org/browse/node/35120580 ), dann sehe ich
keine Tags, die nach Links aussehen.

Auf der anderen Seite gibt es Nodes, in die sehr wohl Weblinks
enthalten, die aber nicht gefunden (bzw. geparsed) werden...? Z.B.
Hochschule Rapperswil
http://www.openstreetmap.org/browse/node/266045142 (siehe
website-Tag).

-S.


Am 28. November 2010 18:36 schrieb Alexander Matheisen
:
>> Für diese Kneipe (http://www.openstreetmap.org/browse/way/38072458)
>> wird mir momentan "geschlossen" angezeigt. Dabei müsste die Syntax von
>> opening_hours den Konventionen entsprechen.
>
> Ist gefixt. Problem war, dass mir die Datumsfunktion eine falsche Zahl
> für den aktuellen Wochentag geliefert hat.
>
>
> Alex
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>

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

Re: [Talk-de] neue Karte http://openptmap.de

[Stefan Keller]

Schön!
Hab's gleich hier im geometa directory verlinkt:
http://directory.geometa.info/search.php/all/traffic?sort=date_desc

-S.

P.S. Ein "Über / About" wäre noch nicht schlecht.

Am 28. November 2010 18:33 schrieb Mike  Dupont
:
> Klasse!
>
> 2010/11/28 Carsten Schönert :
>> Nabend,
>>
>> zu nächst einmal Danke für das Schaffen einer neuen Karte mit dem Thema ÖPNV
>> Deutschland.
>>
>> Was mir aber auffällt das ab der Zoomstufe 13 keine Tiles mehr angezeigt
>> werden. Fehlen die noch oder ist das nur in dem Bereich den ich jetzt
>> ausgewählt habe so?
>> http://openptmap.de/?zoom=13&lat=50.89791&lon=11.8797&layers=BT
>>
>> Des weiteren würde ich das Einblenden der Stadt- und Ortsnamen im
>> Hintergrund sehr hilfreich finden. Ich musste jetzt erst ne ganze Weile
>> suchen bis in dem Bereich war der mich interessiert. :-)
>>
>> Und ist noch eine Erweiterung der Karte bei einer möglichen Interaktion beim
>> Überfahren der Haltestellen geplant?
>> z.B. Haltestellennamen,
>> Operatornamen,
>> Liniennummern
>>
>> Danke und Gruß
>> Carsten
>>
>> ___
>> Talk-de mailing list
>> Talk-de@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-de
>>
>
>
>
> --
> James Michael DuPont
> Member of Free Libre Open Source Software Kosova and Albania
> flossk.org flossal.org
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>

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

Re: [Talk-de] OLM 5 ist da

[Stefan Keller]

Ok, stimmt: "Hochschule Rapperswil" wird gefunden, wenn man 2x
"Weitere Treffer..." anzeigt.

D.h. also folgendes: Die OLM-Marker werden von der
OpenStreetMap-Datenbank direkt geholt und die Suche bedient sich
Nominatim. => Steht das irgendwo explizit?

Damit können vier verschiedene Probleme auftauchen:
1. Nominatim findet Objekte, die gar keine OSM-POIs sind (falsche Positive).
2. Nominatim verfehlt OLM-POIs, obschon in OLM welche vorhanden sind
(falsche Negative).
3. OLM zeigt Objekte an, obschon sie nicht erscheinen dürften (falsche Positive)
4. OLM verfehlt Objekte, obschon sie "angezeigt" werden müssten
(falsche Positive)

Die Verwirrung um falsche Positive könnte man entschärfen, in dem mit
"id=35120580&objecttype=node" andere Popups generiert werden - oder
zumindest solche, bei denen klar ist, dass keine Weblinks enthalten
sind.

Die Verwirrung sowohl um falsche Positive wie auch falsche Negative
könnten entschärft werden, indem an geeigneter Stelle deutlich darauf
hingewiesen wird, dass sich die Suche Nominatim bedient (die keine
OLM-Filter-Kriterien anwendet).

LG, S.

Am 28. November 2010 20:20 schrieb Alexander Matheisen
:
> Am Sonntag, den 28.11.2010, 18:44 +0100 schrieb Stefan Keller:
>> Schöne Webapp.! Leider muss ich aber zugeben, dass ich etwas verwirrt
>> bin, welche Links nun verarbeitet werden.
>>
>> Eine Suche nach Rapperswil ergibt z.B. nur drei Treffer, einer davon
>> z.B. der Bahnhof:
>> http://olm.openstreetmap.de/?zoom=18&lat=47.224718&lon=8.817574&id=35120580&objecttype=node
>> Wenn man sich die Details dazu ansieht
>> (http://www.openstreetmap.org/browse/node/35120580 ), dann sehe ich
>> keine Tags, die nach Links aussehen.
>
> Um als Marker auf der Karte zu erscheinen, müssen Objekte bestimmte Tags
> haben (siehe unten). Die Informationen in den Popups sind davon
> unabhängig.
>
>> Auf der anderen Seite gibt es Nodes, in die sehr wohl Weblinks
>> enthalten, die aber nicht gefunden (bzw. geparsed) werden...? Z.B.
>> Hochschule Rapperswil
>> http://www.openstreetmap.org/browse/node/266045142 (siehe
>> website-Tag).
>
> Falls sie mit der Suche nicht gefunden werden, hat das nichts mit OLM zu
> tun. Die Suche nutzt Nominatim wie auch auf der Hauptseite.
> Wann Objekte erscheinen, steht hier:
> http://olm.openstreetmap.de/info/index.html
>
> Zumindest bei mir erscheinen an der Hochschule Marker, manchmal hilft es
> auch, mal die Punkte mit dem Link unten neu zu laden.
>
>
> Alex
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>

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

Re: [Talk-de] Impliziert bicycle=yes, dass die Stra ße nicht durch Autos befahren werden darf?

[Stefan Keller]

Moment mal: Dafür gibt es doch "highway=cycleway"?
(siehe http://wiki.openstreetmap.org/wiki/DE:Tag:highway%3Dcycleway )

> Der Vollständigkeit halber noch das Tagging für einen Weg, der nur für 
> Fahrräder zu benutzen ist:
>  access=no
>  bicycle=yes/official
>
> Allgemeine Regel: Mit access=destination/no/* schließt man alles aus, um dann 
> mit bicycle/motorbike/psv/hgv/*=yes die Ausnahmen zu erlauben.

Zu so einer Default-Regelung mit "access=no" finde ich im Wiki nichts!
http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions

Fände ich auch unsinnig. Das wäre wie wenn ich zu einer Tankstelle
(amenity=fuel) mit ausschliesslich Bleifreibenzin sagen würde "Dies
ist ist keine Tankstelle, aber wenn euch Bleifreibenzin genügt..."
oder: "Dies ist kein Wald, aber wenn es Nadelwald sein muss, dann
bitte."!

LG, S.

Am 4. Dezember 2010 10:38 schrieb Claudius :
> Am 03.12.2010 18:47, Chris66:
>>
>> Am 03.12.2010 18:24, schrieb Tom Müller:
>>
>>> ich bin etwas verwirrt, ob der verschiedenen access-Tags.
>>> Impliziert ein bicycle=yes, dass der Weg nicht durch Autos befahren
>>> werden darf?
>>
>> Nein, das wäre höchstens bei bicycle=official der Fall, aber da herrscht
>> wie üblich bei OSM in der Community keine Einigkeit. ;)
>
> Der Vollständigkeit halber noch das Tagging für einen Weg, der nur für
> Fahrräder zu benutzen ist:
> access=no
> bicycle=yes/official
>
> Allgemeine Regel: Mit access=destination/no/* schließt man alles aus, um
> dann mit bicycle/motorbike/psv/hgv/*=yes die Ausnahmen zu erlauben.
>
> Claudius
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>

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

Re: [Talk-de] Impliziert bicycle=yes, dass die Stra ße nicht durch Autos befahren werden darf?

[Stefan Keller]

Danke für den Hinweis. Also ist hier mit bicycle=yes implizit ein
Ausbauzustand gemeint als Zusatztag zu highway=path?

Im Wiki (http://wiki.openstreetmap.org/wiki/DE:Howto_Map_A#F ) finde
ich zu Fahrradweg:
"highway=cycleway" oder alternativ "highway=path" mit "bicycle=designated".

Daraus schliesse ich, dass genau diese beiden Tagging-Varianten die
aktuelle Antwort auf die ursprüngliche Frage ist.

-S.

P.S. Leider finde ich auch zur Inkonsitenz nichts im OSM Wiki
(beachtet das überhaupt jemand :->?).

Am 4. Dezember 2010 14:24 schrieb Falk Zscheile :
> Am 4. Dezember 2010 13:15 schrieb Stefan Keller :
>> Moment mal: Dafür gibt es doch "highway=cycleway"?
>> (siehe http://wiki.openstreetmap.org/wiki/DE:Tag:highway%3Dcycleway )
>>
>>> Der Vollständigkeit halber noch das Tagging für einen Weg, der nur für 
>>> Fahrräder zu benutzen ist:
>>>  access=no
>>>  bicycle=yes/official
>>>
>>> Allgemeine Regel: Mit access=destination/no/* schließt man alles aus, um 
>>> dann mit bicycle/motorbike/psv/hgv/*=yes die Ausnahmen zu erlauben.
>>
>> Zu so einer Default-Regelung mit "access=no" finde ich im Wiki nichts!
>> http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions
>>
>> Fände ich auch unsinnig. [...]
>
> Vorsicht, ihr begebt euch bei dieser Disskussion auf unsicheren Boden,
> da ihr auf Basis einer bei OSM existierenden Inkonsistenz
> argumentieren wollt.
>
> Bei OSM haben wir keine klare Trennung zwischen Ausbauzustand einer
> Straße und straßenverkehrsrechtlichen Regelungen, die eine Eigenschaft
> eines Weges bestimmen. Es wird also immer einen Graubereich geben ob
> man etwas über die access-Tags ausdrückt oder über den Straßentyp.
>
> Gruß, Falk
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>

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

Re: [Talk-de] Impliziert bicycle=yes, dass die Stra ße nicht durch Autos befahren werden darf?

[Stefan Keller]

Also zunächst steht da klipp und klar auf Zeile zwölf
> access=no Access by this transport mode is not permitted, public does not 
> have a right of way.

Deine Interpretation aus dem Satz, den du zitierst, scheint mir etwas
an den Bremsdrähten herbeigezogen :->.

Es ist wie gesagt wider jede Logik - menschlich wie maschinell. Es
gibt z.B. hier keinen Hinweis dazu
http://wiki.openstreetmap.org/wiki/Tag:access=no - ausser dass
Routingprogramm solche Wege meiden sollen! Willst du das?

Und die Statistik zeigt, dass bisher bicycle=* nur ca. 7% mal mit
access=* kombiniert worden ist - gleichwenig wie
Einbahn-Fahrradwege(http://taginfo.openstreetmap.de/keys/bicycle?filter=ways#keys
)

S.

Am 4. Dezember 2010 17:09 schrieb Bartosz Fabianowski :
>>> Zu so einer Default-Regelung mit "access=no" finde ich im Wiki nichts!
>
>> Ich meine das irgendwann mal irgendwo (wahrscheinlich wiki) gelesen zu
>> haben, finde jetzt aber auch nichts mehr.
>
> Das steht hier:
>
> http://wiki.openstreetmap.org/wiki/Key:access
>
> "Use the access=* key to describe a general access restriction (all
> transport modes). This may be tightened or relaxed by adding keys which
> describe access for more specific modes of transport. These keys each have a
> place in an implied tree structure in which keys become narrower in scope as
> they branch out from the root."
>
> Es gibt also eine Schlüsselhierarchie. Mit "access=no" kann man erstmal
> absolut alles ausschließen um dann einzelne Verkehrstypen zu erlauben.
>
> Gruß,
> - Bartosz
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>

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

[Talk-de] Administrative Grenzen (insbes. Schweiz via osm2pgsql-Import)

[Stefan Keller]

Hallo

Hat jemand einen Überblick über den "Stand" der Erfassung der
administrativen Grenzen (insbesondere Deutschland und Schweiz)?

Dass das mit Ländergrenzen in OSM noch nicht so gut klappt ist mir
bewusst. Ich weiss auch, dass ein Import von genaueren Schweizer
Gemeindegrenzen geplant ist. Mir geht es aber um die topologische
Korrektheit in Hinblick auf Analysen (POI-in-Polygon, Nachbarschaft
etc.). Der erste Knackpunkt ist, ob man damit Flächen bilden kann!

Ich habe gerade mit einem osm2pgsql-Import gesehen, dass man für
Zürcher Gemeinden brauchbare Flächen (Polygone) mit admin_level (z.B.
8) erhält - nicht jedoch für St. Galler Gemeinden. Der Grund liegt wie
ich vermute darin, dass St. Galler Gemeindegrenzen keine Flächen
bilden (wohl auch die Kantonsgrenze nicht, siehe z.B. das
Kantons-Grenzgebiet zwischen Rüti (ZH) und Rapperswil-Jona (SG) hier
http://www.openstreetmap.org/?lat=47.2436&lon=8.8201&zoom=14&layers=M
).

Hat da jemand eine bessere Erklärung bzw. Lösung?

LG, S.

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

Re: [Talk-de] Administrative Grenzen (insbes. Schweiz via osm2pgsql-Import)

[Stefan Keller]

Vielen Dank an Walter und Flo für die schnellen Antworten!
Bin nun gespannt, was meine Kollegen aus Schweiz dazu meinen (die
Eidgenossen sind halt etwas langsamer - dafür hoffentlich gründlicher
:-).

Der (implizite) Hinweis, dass administrative Grenzen ja mit Relationen
gehandhabt werden, nützte mir schon.

Folgende Gedanken inzwischen:

1. Das erinnert mich schmerzlich daran, dass OSM keine "echten"
Flächen/Polygone" hat... (wenn es also darum geht, über die nächste
OSM-API abzustimmen, dann denkt bitte daran und helft den Basistyp
polygon einzuführen! Echte Polygone im Sinne der internationalen
OGC-Norm "Simple Features" würden einiges entschlacken: die Relationen
würden entlastet, die Tools inkl. Editoren könntens prüfen, etc)

2. Man könnte solche Flächen in einem Info- oder gar "Quality
Assurance"-Tool visualisieren! Dann würde schnell ins Auge springen,
dass da etwas nicht simmt (wo keine Fläche ist bleibts weiss).

3 .Zurzeit sind gegenteilige Anreize da: Mapnik zeigt nebst
Ortschaften (Node mit place=village) zurzeit offenbar auch der Name im
Zentrum vom geschlossenen Way mit "landuse=residential", so dass oft
zwei "Ortsnamen" dargestellt werden (vgl. z.B. Wolfhausen
http://www.openstreetmap.org/?lat=47.25717&lon=8.79939&zoom=15&layers=M
). Dieses Mapnik-Styling müsste geändert werden - aber das ist eine
andere Geschichte.

LG, S.

Am 23. Dezember 2010 12:31 schrieb Walter Nordmann :
>
> hi flo,
>
> deckt sich in etwa mit meinen daten: manche sind ok und manche immer noch
> put.
> da man ja immer "hinterher rennt" hab ich mich dazu durchgerungen, defekte
> grenzen zu ignorieren bzw einfach die letzte "gute" version zu verwenden.
> aber das machst du ja auch.
> gruss
> walter
>
> -
> Wir haben die Lösungen für die Probleme, die Sie nicht hätten, wenn Sie nicht
> unsere Produkte einsetzen würden.
> --
> View this message in context: 
> http://gis.638310.n2.nabble.com/Administrative-Grenzen-insbes-Schweiz-via-osm2pgsql-Import-tp5861945p5862060.html
> Sent from the Germany mailing list archive at Nabble.com.
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>

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

Re: [Talk-de] 3000 sprachspezifische name Tags automatisch einfügen, wie?

[Stefan Keller]

Die Daten scheinst du ja zu haben, z.B. als CSV-Datei.
So wie ich dich verstehe, geht es nun darum, einen "Bot" zu schreiben.
Da bin ich selber interessiert, wer das schon gemacht hat. Eine erste
Info gibt das Wiki: http://wiki.openstreetmap.org/wiki/Bot
Meine Frage wäre, wo man solche Bots am besten diskutiert (d.h. wo
sich die Bot-Schreiber "virtuell treffen").

LG, S.


Am 24. Dezember 2010 21:04 schrieb Tirkon :
> Moin,
>
> gibt es eine Methode, eine Übersetzungsliste mit einigen tausend
> niederdeutschen Ortsnamen als Gesamtjob in OSM einzuverleiben, indem
> man diese in einer Tabelle name->name:nds gegenüberstellt?
>
> Grüße
> Tirkon
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>

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