date:20100314

Am 10. März 2010 11:31 schrieb Torsten Breda :
> Innenstadt in JOSM anschaut, weiß was ich meine. Da gibt es neben den
> Straßen und POIs viele andere Dinge, die in der Karte zu sehen sind.
> Landflächen, Plätze, Buslinien, Grenzen, Brücken, Stromleitungen,
> Tunnel und und und...


> Wer in so einem Gebiet wirklich nur eine Kleinigkeit ändern möchte,
> muss höllich aufpassen, das er keine Relationen beschädigt, Straßen
> mit Flächen verbindet, Maxspeed löscht oder auf eine falsche Straße
> ausweitet, "Löcher" in Wanderrouten erzeugt und so weiter.


Das ist eine Frage vom Arbeitsstil. Wenn der darin besteht,
vorhandenes zu löschen und dann neu einzutragen: ja. Ansonsten sehe
ich nicht, wie man durch das Ergänzen einer fehlenden Straße z.B.
einen Maxspeed löscht oder eine Relation beschädigt. Auch durch das
Hinzufügen von POIs, anderen Nodes und Tags passiert sowas nicht.


> Man muss
> sich immer mit der sonstigen Verwendung der Elemente vertraut machen,
> um nicht die Arbeit der Anderen zu stören oder zu beschädigen.


ja, das muss man wohl, insbesondere, wenn man ein Gebiet "umkrempeln"
will - danach hört sich das m.E. an, weil beim behutsamen Ergänzen
sehe ich diese ganzen Probleme nicht - auch nicht in der dichten
Stadt.

> 2. Immer mehr Energie wird in die Pflege/Reparatur der Daten aufgewendet.


zwangsläufig, je mehr Abdeckung da ist.


> 3. Ein sinnvolles Bearbeiten ist nur noch durch wenige Experten möglich.
wieso?


> 4. Importe werden sehr kompliziert. - Gespendete Daten müssen mit
> größter Vorsicht oder händich eingefügt werden.

ja, aber kein Problem: Importe waren noch nie prioritär und werden mit
steigender Abdeckung auch immer unwichtiger.


> Wie kann man das Lösen?


was?

> Was ist das Grundproblem?
> OSM ist monolithisch! - Alles ist miteinander verknüpft und verwoben.
> Eine kleine Änderung kann große Wirkung haben und Bereiche oder
> Sachverhalte ändern, die man gar nicht verändern wollte.
> Was fehlt, ist die Modularität!


damit führt man m.E. erst Recht Probleme ein. Die Dinge sind ja nicht
ohne Grund aufeinander bezogen: diese Bezüge bestehen auch in der
Realität. Wenn man nun bestimmte "Ebenen" ausblendet gehen diese
Bezüge verloren.

> JOSM würde fragen: "Was möchten sie Bearbeiten und sehen?" Man bekäme
> -
> |   Modul     |   editierbar   |  sichtbar  |
> -
> | Straßen     |        o       |     x      |
> -
> | Landnutzung |        o       |     x      |
> -
> | Gebäude     |        o       |     o      |
> -
> | Routen      |        o       |     o      |
> -
> | Grenzen     |        x       |     x      |
> -
> | ÖPNV        |        o       |     o      |
> -

so was ähnliches wäre schon nicht schlecht: Unterlayer, die dynamisch
automatisch (oder bei Bedarf auch manuell z.B. über Suchanfragen)
generiert (gefiltert) werden, und für die man die Sichtbarkeit und
Bearbeitbarkeit (sowie ggf. die Anzeigereihenfolge) im Layermenü
jeweils individuell steuern kann. Probleme sehe ich allerdings noch
genug, vor allem, wenn z.B. verschiedene Ebenen dieselben Nodes
verwenden. Darf man die Nodes dann z.B. verschieben wenn ein Teil der
Ebenen gesperrt ist und ein Teil nicht?

Ein Großteil der von Dir angesprochenen Probleme resultiert m.E. aus
ungünstiger Modellierung beim Mappen: wenn z.B. Landuses bis zur
Straßenmitte gezogen werden. Das "löst" beim Rendern zwar ggf. ein
paar Probleme, beim Ändern der entspr. Straße ist es aber u.U. extrem
lästig. Wie bearbeitbar unsere Daten bleiben haben wir sozusagen
selbst in der Hand ;-)

Gruß Martin

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

Re: [Talk-de] Onkel Didi baut Autobahnen

2010-03-14 Diskussionsfäden Walter Nordmann


hätte zu etwas ganz anderem lust ;-)

was ist denn in den typ gefahren? hast du ihn mal angemailt?

gruss

tante emma

-
Ich geh zugrunde.  wer kommt mit?
-- 
View this message in context: 
http://n2.nabble.com/Onkel-Didi-baut-Autobahnen-tp4734240p4734320.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] Onkel Didi baut Autobahnen

2010-03-14 Diskussionsfäden Chris-Hein Lunkhusen

Hi,
wer hat Lust auf Reparatur?



Chris


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

Re: [Talk-de] Baumkataster

Mirko Küster  wrote:

>Ich hatte das mal bei mir mit einzelnen Bäumen durchgespielt. Da kommt dann 
>sowas bei raus (grüne Punkte).
>
>http://www.openstreetmap.org/?lat=51.29571&lon=11.43631&zoom=17&layers=B000FTF

Marcel Reich-Ranicki hätte sicher seine helle Freude, dieses weiter
auszuschmücken: Denn wer hätte je gedacht, dass selbst ein trockenes
Stück Software vom Type Renderer aich in eine Auseinandersetung mit
der Linguistik begeben und ach so alten Lebensweisheiten geschlagen
geben müsse, denn "Sie sähe den Wald vor lauter Bäumen nicht." ;-)


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

Re: [Talk-de] Bot Vorschlag: St. NAME --> Sankt NAME

2010-03-14 Diskussionsfäden Martin Czarkowski



Am 14.03.2010 21:02, schrieb Jonas Stein:
> Abkuerzungen, die man automatisiert anpassen koennte:
>
> St. -->  Sankt
> Pfr. -->  Pfarrer
> Pl. -->  Platz
> Dr. -->  Doktor
> Prof. -->  Professor
>
strikt dagegen, die Gründe wurden schon mehrfach genannt

--
Martin

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

Re: [Talk-de] Fahrradparken

moin

On 13.03.2010, at 14:10, Guenther Meyer wrote:

> Am Samstag 13 März 2010 13:33:49 schrieb Falk Zscheile:
>>> was ich mich frage:
>>> warum gibt's da eigentlich wieder mal ein separates tag?
>>> fuer mich gehoert das eindeutig unter amenity=parking.
>> 
>> Weil sich die Tags bei OSM meist am Einzelfall entwickelt und da war
>> das Auto mit amenity=parking zuerst da und hat das Tag besetzt. Jetzt
>> kann man nicht mehr ein amenity=parking, parking=bicycle einführen,
>> weil amenity=parking aufgrund seiner Entwicklung schon als
>> amenity=parking, parking=car verstanden wird.
> ich seh da kein problem:
> wenn es keine zusatztags gibt, die die art des parkplatzes genauer 
> spezifizieren, wird einfach ein autoparkplatz angenommen.
> die zeiten, wo eine software nur das "haupttag" auswerten, und alles andere 
> ignorieren kann, sind vorbei.

na die idee könnte doch nen Bot programmierer mal aufgreifen und erstmal alle 
auto parkplätze mit einem tag parking=car ergänzen.
in 1 jahr oder so kann man dann alle amenity=parking per bot löschen, wenn bis 
dahin bekannt genug geworden ist das dieses tag obsolet ist. oder halt mit 
entsprechender längerer frist. müsste man dann halt nur im wiki auch explizit 
bekannt geben.

cu assetburned

smime.p7s
Description: S/MIME cryptographic signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Rendern von Seezeichen und Editor

2010-03-14 Diskussionsfäden Jan Jesse

 
Hallo Olaf, hallo Frederik,

> 
> Nein, es war immer eine Benutzer-Interaktion nötig.
> 

Das stimmt absolut.

> Dann schaue dir doch bitte einmal die Knoten-Chronik von:
> - http://www.openstreetmap.org/browse/node/431046138/history
> - http://www.openstreetmap.org/browse/node/431046061/history
> an!
> 

Und hier wird es für mich heikel und gleichzeitig interessant. Zunächst Olaf, 
hast Du recht. Die Lichter gehören zu den ursprünglichen Aufzeichnungen aus der 
FT und wurden nie entfernt. Insofern ist die von mir ausgelöste Aufregung 
unberechtigt. Ich entschuldige mich. Tut mir an der Stelle wirklich leid.

Wie kommt es nun zu dieser Fehlinterpretation meinerseits?

Die betreffenden Tonnen wurden zu einem Zeitpunkt erfaßßt, als wir ganz am 
Anfang standen. Damals offenbar mit Licht. Ich weiß nicht, ob das damals 
richtig oder falsch war, ist jetzt erst einmal egal.

Inzwischen haben die Tonnen alle eine ellenlange History, und genau das war 
eigentlich mein Thema. Es wurde mehrfach umgetaggt, in dem damals "neuen" 
Taggingschema, also in der FT sind die Lichter nicht verzeichnet, bzw. gelöscht 
worden. Die Tonne wurde durch die FT editiert, die Daten des jeweils anderen 
Schemas durften nach gültigem Konsenz nicht angetastet werden, durften also 
auch nicht gelöscht werden. 

Später haben wir (FT) entschieden, beide Schemata zu lesen. Das war in der 
Logik der Abläufe dann offenbar auch falsch. Der letzte Edit hat entsprechend  
dazu geführt, daß die Lichter von uns wieder (neu) interpretiert wurden, weil 
wir sie ja zwischenzeitlich nicht angetastet, d.h. nicht gelöscht hatten.

Hat das jetzt jemand verstanden? 

Ich sehe genau hier das Problem. Wenn ein Editor nur ein Schema schreibt, aber 
alle Möglichkeiten lesen will, ist  eine Abgrenzung verdammt schwer bis 
unmöglich. Die Daten müssen von Hand bearbeitet werden, damit verlieren die 
Editoren ihren Zweck. Wenn der Editor die jeweils anderen Daten nicht anfassen 
darf, darf er sie auch nicht interpretieren, sonst entsteht genau der 
vorliegende Fehler.

Wenn wir ein Konstrukt geschaffen haben, bei dem ein Edit eines Nodes solche 
"Seiteneffekte" hat, sind wir auf dem falschen Weg!

Was wollen wir tun?

Ich denke, wir müssen wenigstens den Konsenz modifizieren, der da sagt, keiner 
rührt die tags der anderen an.

Wir sollten zumindest zukünftig dafür sorgen, daß inhaltliche Widersprüche 
(colour=green und seamark:colour=red ist derzeit im gleichen node möglich) 
ausgeschlossen und veraltete Informationen korrigiert werden. In diesem Sinne 
müßte das Löschen der jeweils anderen Tags eigentlich verpflichtend werden.

Außerdem sollten zukünftig unnötige Edits unterbleiben. Damit meine ich sowohl 
die diversen Bots, die in der Vergangenheit über die Daten geschickt wurden 
(Stichwort color und colour), als auch wohlmeinende händische Korrekturen. 

Wie das zukünftig praktiziert werden soll weiß ich nicht, und bin da auch 
ziemlich beliebig. Aber das wir schon jetzt einen Datenbestand haben, der nur 
noch mit der entsprechenden History richtig interpretiert werden kann, zeigt 
mir eine Notwendigkeit, die Dinge endlich auf einen ordentlichen Weg zu bringen.

Beste Grüße aus Berlin

JJ


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

Re: [Talk-de] Fahrradparken

Am Sonntag 14 März 2010 23:13:43 schrieb Martin Koppenhoefer:
> Am 13. März 2010 13:23 schrieb Chris-Hein Lunkhusen :
> > Schon mal versucht mit einem Auto auf einem Fahrradparkplatz
> > zu parken? ;-)
> > Unter "Parkplatz" versteht man in der autofixierten Welt nunmal
> > in erster Linie einen Autoparkplatz.
> 
> ja, mit dem Fahrrad braucht man i.d.R. auch gar keinen Parkplatz, weil
> der effektive Platzbedarf verglichen mit dem Auto so verschwindend
> gering ist, dass man es praktisch überall abstellen kann. In
> Einzelfällen sieht das natürlich anders aus (vor der Uni, am Bahnhof,
> ...).
> 
grade an solchen orten hast du ueberall, wo man ein fahrrad abstellen koennte, 
entsprechende verbotsschilder. da ist es schon gut zu wissen, wo das parken 
explizit erlaubt bzw. gewuenscht ist...

> Gibt's eigentlich auch ein allgemeines Zweiradparken-tag und eins für
> motorisierte Zweiräder?
> 

es gibt tatsaechlich ein proposal - zumindest fuer letzteres:

amenity=parking
capacity:motorcycle=yes/no/number 

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

Re: [Talk-de] Fahrschule

Am Sonntag 14 März 2010 23:18:30 schrieb Martin Koppenhoefer:
> Am 14. März 2010 22:57 schrieb Florian Gross
> 
> :
> > Und nachher ist jede Schule unter was anderem eingeordnet?
> >
> > Hauptschule unter school[1], Fahrschule[2] unter business,
> > Tanzschule[3] unter amenity?
> 
> ja, bei den 3 genannten ist es m.E. überhaupt nicht sinnvoll, die
> unter einem Haupttag zu subsummieren. Die haben überhaupt nichts
> miteinander zu tun.
ueberhaupt nichts?!?
in allen lernt man was...

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

Re: [Talk-de] Korrektur von durch OSM Inspector gefundenen Fehlern

2010-03-14 Diskussionsfäden Pascal Neis

Hi,

Torsten Breda schrieb:
>
> Wollt ihr, dass diese Fehler schnell beseitigt werden?
> Dann macht einen Bundesländervergleich! Eine kleine Auswertung und
> Grafik motiviert ungemein. Und Wettbewerb schadet auch nicht. Ein
> kleines Diagramm oder ein Trend auf dem man sehen kann, welchen Anteil
> die Fehler am Gesamten haben.

habe mal einen aktuellen Vergleich für heute erstellen lassen.
Sortiert ist sie absteigend anhand der Fehler bei nicht verbundenen
Straßen mit einem Abstand bis zu einem Meter im jeweiligen Bundesland.
Was hier noch fehlt, ist der NoExit- und der redundante Straßenfehler.
Wenn Interesse an sowas besteht, kann ich gerne alle Paar Tage die
Statistik erstellen lassen.

 >Bundesland: Nordrhein-Westfalen Gesamtanzahl Fehler:3950
  Nicht verbundene Straße 1m: 1200
  Nicht verbundene Straße 2m: 631
  Nicht verbundene Straße 5m: 2111

 >Bundesland: Rheinland-Pfalz Gesamtanzahl Fehler:2224
  Nicht verbundene Straße 1m: 810
  Nicht verbundene Straße 2m: 375
  Nicht verbundene Straße 5m: 1036

 >Bundesland: Baden-Wuerttemberg Gesamtanzahl Fehler:2862
  Nicht verbundene Straße 1m: 768
  Nicht verbundene Straße 2m: 383
  Nicht verbundene Straße 5m: 1706

 >Bundesland: Bayern Gesamtanzahl Fehler:2464
  Nicht verbundene Straße 1m: 665
  Nicht verbundene Straße 2m: 370
  Nicht verbundene Straße 5m: 1425

 >Bundesland: Niedersachsen Gesamtanzahl Fehler:1764
  Nicht verbundene Straße 1m: 596
  Nicht verbundene Straße 2m: 280
  Nicht verbundene Straße 5m: 884

 >Bundesland: Hessen Gesamtanzahl Fehler:1359
  Nicht verbundene Straße 1m: 439
  Nicht verbundene Straße 2m: 202
  Nicht verbundene Straße 5m: 716

 >Bundesland: Thueringen Gesamtanzahl Fehler:1050
  Nicht verbundene Straße 1m: 313
  Nicht verbundene Straße 2m: 159
  Nicht verbundene Straße 5m: 578

 >Bundesland: Sachsen Gesamtanzahl Fehler:1059
  Nicht verbundene Straße 1m: 307
  Nicht verbundene Straße 2m: 155
  Nicht verbundene Straße 5m: 593

 >Bundesland: Brandenburg Gesamtanzahl Fehler:654
  Nicht verbundene Straße 1m: 272
  Nicht verbundene Straße 2m: 98
  Nicht verbundene Straße 5m: 282

 >Bundesland: Schleswig-Holstein Gesamtanzahl Fehler:646
  Nicht verbundene Straße 1m: 197
  Nicht verbundene Straße 2m: 98
  Nicht verbundene Straße 5m: 351

 >Bundesland: Berlin Gesamtanzahl Fehler:520
  Nicht verbundene Straße 1m: 190
  Nicht verbundene Straße 2m: 70
  Nicht verbundene Straße 5m: 259

 >Bundesland: Mecklenburg-Vorpommern Gesamtanzahl Fehler:475
  Nicht verbundene Straße 1m: 177
  Nicht verbundene Straße 2m: 49
  Nicht verbundene Straße 5m: 248

 >Bundesland: Sachsen-Anhalt Gesamtanzahl Fehler:540
  Nicht verbundene Straße 1m: 173
  Nicht verbundene Straße 2m: 84
  Nicht verbundene Straße 5m: 282

 >Bundesland: Saarland Gesamtanzahl Fehler:315
  Nicht verbundene Straße 1m: 102
  Nicht verbundene Straße 2m: 62
  Nicht verbundene Straße 5m: 151

 >Bundesland: Hamburg Gesamtanzahl Fehler:353
  Nicht verbundene Straße 1m: 68
  Nicht verbundene Straße 2m: 51
  Nicht verbundene Straße 5m: 234

 >Bundesland: Bremen Gesamtanzahl Fehler:122
  Nicht verbundene Straße 1m: 31
  Nicht verbundene Straße 2m: 15
  Nicht verbundene Straße 5m: 76


gruesse
pascal


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

Re: [Talk-de] Cebit und Table-PC's für OSM

moin

On 11.03.2010, at 22:50, Jan Tappenbeck wrote:
> 
> hat einer von Euch vielleicht die Cebit besucht und einmal einen Blick 
> auf die neuen Table-PC's werfen können ???
> 
> Gibt es da etwas was für einen mobilen OSM-Einsatz mit JOSM sich lohnt 
> anzusehen ?

im grunde das gleiche wie seit 10 jahren.

alle meinen sie hätten den heiligen gral gefunden und wüsten wie man die teile 
besser machen kann das mehr leute sie kaufen, aber letztlich hat sich nix 
geändert.
da hat man wieder nen wunderbares beispiel von ei und henne.
Geräte sind überteuert, weil kaum leute sie kaufen und nur nen kleiner markt da 
ist... also ist die produktionsmenge gering und wegen der geringen verbreitung 
schreibt kaum jemand software dafür... also fragen sich die leute warum man 
sowas kaufen soll wenn es kaum nutzbare software gibt und die geräte so teuer 
sind.

im ernst, wirklich was neues hab ich da nicht gesehen.

cu assetburned

smime.p7s
Description: S/MIME cryptographic signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Dank an OSM > Frankfurt Gestalten Projekt

2010-03-14 Diskussionsfäden Christian Kreutz

Hallo!

mit dieser E-Mail möchte ich mich bei der OSM Gemeinde bedanken. Ich war
letztes Jahr auf der State of the Map und bin seither begeistert von
OpenStreetMap.

Wir haben ein Projekt zur Transparenz und Teilhabe an der Frankfurter
Lokalpolitik gestartet: www.frankfurt-gestalten.de. Ohne die großartigen Daten
von Openstreetmap hätten wir diese Projekt nicht so umsetzen können. Auf
www.frankfurt-gestalten.de werden alle Entscheidungen der Lokalpolitik
georeferenziert und per E-Mail Abo an die Bürgerinnen und Bürger Frankfurt
angeboten. Außerdem können Bürger selber Initiativen eintragen. WIr wollen auch
weitere Ideen mit digitalen Karten und Lokalisierung umsetzen, die Politik
transparenter machen und Bürgern ein verbesserter Service für ihre
Nachbarschaft geben.

Für weitere Infos zum Projekt:
http://www.netzpolitik.org/2010/frankfurt-gestalten-offene-daten-partizipative-lokalpolitik/
oder direkt: www.frankfurt-gestalten.de

Wir möchten außerdem ein Treffen (Camp) organisieren, dass Menschen
zusammenbringt, die das Potenzial digitaler Karten für gemeinnützige Zwecke
nutzen wollen. Bei Interesse bitte bei mir melden. In Kürze werden ich dazu
mehr Information schicken. Ein spannendes Projekt ist zum Beispiel Map Kibera
(http://mapkibera.org/), was u.a. von Mikel Maron in Kenia organisiert wird.
Wir denken es gibt hier aber auch im deutschen Raum ein großes Potenzial
digitale Karten für soziale Zwecke zu nutzen. Ein interessantes Netzwerk in
dieser Hinsicht sind die Socialbars: http://www.socialbar.de/

Beste Grüße

Christian Kreutz
(OSM: ckreutz)

Blog: www.crisscrossed.net
Twitter: ckreutz
Email: c...@crisscrossed.de
www.frankfurt-gestalten.de
Twitter: ffminfo

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

Re: [Talk-de] Fahrschule

Am 14. März 2010 22:57 schrieb Florian Gross
:
> Und nachher ist jede Schule unter was anderem eingeordnet?
>
> Hauptschule unter school[1], Fahrschule[2] unter business,
> Tanzschule[3] unter amenity?

ja, bei den 3 genannten ist es m.E. überhaupt nicht sinnvoll, die
unter einem Haupttag zu subsummieren. Die haben überhaupt nichts
miteinander zu tun. unter "school" würde ich wie schon erwähnt nur
allgemein- und berufsbildende Schulen führen, und diese auch mit
weiteren Tags noch differenzieren.

Gruß Martin

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

Re: [Talk-de] Bot Vorschlag: St. NAME --> Sankt NAME

2010-03-14 Diskussionsfäden Walter Nordmann


teil-lob mit ganz-ablehnung   ;-(

gut gemeint aber halt ich auch nicht für vernünftig.

wambacher

-
Ich geh zugrunde.  wer kommt mit?
-- 
View this message in context: 
http://n2.nabble.com/Bot-Vorschlag-St-NAME-Sankt-NAME-tp4733260p4733805.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

Re: [Talk-de] Fahrradparken

Am 13. März 2010 13:23 schrieb Chris-Hein Lunkhusen :
> Schon mal versucht mit einem Auto auf einem Fahrradparkplatz
> zu parken? ;-)
> Unter "Parkplatz" versteht man in der autofixierten Welt nunmal
> in erster Linie einen Autoparkplatz.


ja, mit dem Fahrrad braucht man i.d.R. auch gar keinen Parkplatz, weil
der effektive Platzbedarf verglichen mit dem Auto so verschwindend
gering ist, dass man es praktisch überall abstellen kann. In
Einzelfällen sieht das natürlich anders aus (vor der Uni, am Bahnhof,
...).

Gibt's eigentlich auch ein allgemeines Zweiradparken-tag und eins für
motorisierte Zweiräder?

Gruß Martin

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

Re: [Talk-de] JOSM

2010-03-14 Diskussionsfäden Walter Nordmann


hi wolfgang,

hab noch nie probleme damit gehabt. im 3131 (latest?) geht es auf jeden
fall.

gruss

wambacher

-
Ich geh zugrunde.  wer kommt mit?
-- 
View this message in context: http://n2.nabble.com/JOSM-tp4733472p4733785.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

Re: [Talk-de] Bot Vorschlag: St. NAME --> Sankt NAME

Am 14. März 2010 22:09 schrieb Volker :
>>> Macht das so Sinn und falls ja, moechte das jemand in seinen Bot
>>> aufnehmen?
>> dagegen!
> *dagegen.* Ich bin grundsätzlich gegen den massenhaften Einsatz von
> Bots. Sie vergrößern die Datebank nur unnötig: Der Nutzen ist meist eher
> gering.

auch dagegen. Es ist bei solchen Bot-Einsätzen neben dem potentiellen
Gewinn auch immer mit zusätzlichen Fehlern zu rechnen, die dadurch
überhaupt erst eingeschleppt werden.

Gruß Martin

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

Re: [Talk-de] Fahrschule

2010-03-14 Diskussionsfäden Florian Gross

Nils Heuermann glaubte zu wissen:
> Am Sun, 14 Mar 2010 08:00:49 +0100 hat Florian Gross  
>>> Torsten Leistikow glaubte zu wissen:
>>>
>>> Und genau das ist bei dem aktuellen Vorschlag nicht gegeben. Es gibt  
>>> hier zwar
>>> genug Leute, die argumentieren, dass eine Fahrschule ja auch eine Art  
>>> Schule
>>> sei. Dass das aber zum allgemeinen Verstaendnis von Schule nicht passt,  
>>> ...
>>
>> Was soll denn eine Fahrschule/Tanzschule usw. denn sein, wenn nicht
>> eine Schule? Ein Hot-Dog- Stand?
>
> amenity=business - bitte nicht wörtlich nehmen. Es ist ein Unternehmen wie  
> auch ein Bäcker. Da gibt es für Geschäfte ein shop=*, weil amenity für  
> (mehr oder weniger) wichtige spezielle Einrichtungen vorgesehen ist. Eine  
> Schule ist in meinen Augen eine wichtige Einrichtung, eine Fahrschule aber  
> nicht. Das ist einfach ein Betrieb, den jemand aufgemacht hat.

Was ist mit Privatschulen?

> Daher finde ich auch amenity=driving_school gar nicht sooo sinnvoll. Man  
> Bräuchte also sowas wie business=* oder wie hier [1] vorgeschlagen  
> service=*

Und nachher ist jede Schule unter was anderem eingeordnet?

Hauptschule unter school[1], Fahrschule[2] unter business,
Tanzschule[3] unter amenity? Zur einen wird man "gezwungen", zur
nächsten muß man um den Führerschein zu bekommen und die dritte
kann richtig Spaß machen.

flo
-- 
IRIX ist sowas wie die huebsche, dumme Blondine unter den Unices: weit davon
perfekt zu sein, aber sehr huebsch anzuschauen und aus irrationalen Gruenden
begehrt und beliebt.
Ich mag es jedenfalls. [Dennis Grevenstein in ka.test]


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

Re: [Talk-de] Baumkataster

Am 14. März 2010 20:32 schrieb Falk Zscheile :
> können. Daher empfinde ich Deine Aussage mir gegenüber als (vorsichtig
> ausgedrückt) unangebracht.

ja, ist unangebracht, ich bitte Dich um Entschuldigung. Ich dachte
auch nicht, dass Du das bist, war nur rhetorisch und aus der ersten
Aufregung raus ;-)

Gruß Martin

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

Re: [Talk-de] Bot Vorschlag: St. NAME --> Sankt NAME

2010-03-14 Diskussionsfäden Volker

Guenther Meyer schrieb:
> Am Sonntag 14 März 2010 21:02:04 schrieb Jonas Stein:
>   
>> Strassennamen, die mit St. [1] beginnen, koennte man nach Sankt umbenennen.
>>
>> Abkuerzungen, die man automatisiert anpassen koennte:
>>
>> St. --> Sankt
>> Pfr. --> Pfarrer
>> Pl. --> Platz
>> Dr. --> Doktor
>> Prof. --> Professor
>>
>> Einschraenkung auf Stassennamen und Adressen waere natuerlich wichtig
>> Vielleicht habe ich noch einige Gaengige uebersehen, die bei einer Suche
>> nach . im name= Tag auftauchen wuerden.
>>
>> Bsp:
>> [1]
>>  http://www.openstreetmap.org/?minlon=6.5912446975708&minlat=50.63323211669
>> 92&maxlon=6.5921368598938&maxlat=50.6340217590332
>>
>> Macht das so Sinn und falls ja, moechte das jemand in seinen Bot
>> aufnehmen?
>>
>> 
> dagegen!
>
> ___
>
>   
*dagegen.* Ich bin grundsätzlich gegen den massenhaften Einsatz von 
Bots. Sie vergrößern die Datebank nur unnötig: Der Nutzen ist meist eher 
gering.

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

Re: [Talk-de] Bot Vorschlag: St. NAME --> Sankt NAME

2010-03-14 Diskussionsfäden Gerd Steinburger

Guenther Meyer schrieb:
> Am Sonntag 14 März 2010 21:02:04 schrieb Jonas Stein:
>> Strassennamen, die mit St. [1] beginnen, koennte man nach Sankt umbenennen.
>>
>> Abkuerzungen, die man automatisiert anpassen koennte:
>>
>> St. -->  Sankt
>> Pfr. -->  Pfarrer
>> Pl. -->  Platz
>> Dr. -->  Doktor
>> Prof. -->  Professor
>>
>> Einschraenkung auf Stassennamen und Adressen waere natuerlich wichtig
>> Vielleicht habe ich noch einige Gaengige uebersehen, die bei einer Suche
>> nach . im name= Tag auftauchen wuerden.
>>
>> Bsp:
>> [1]
>>   http://www.openstreetmap.org/?minlon=6.5912446975708&minlat=50.63323211669
>> 92&maxlon=6.5921368598938&maxlat=50.6340217590332
>>
>> Macht das so Sinn und falls ja, moechte das jemand in seinen Bot
>> aufnehmen?
>>
> dagegen!

+1

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

[Talk-de] JOSM

2010-03-14 Diskussionsfäden Wolfgang Wienke

Hallo!
Gibt es in der aktuellen stable Version 3094 im Relationseditor nicht 
mehr die Möglichkeit MEHRERE Elemente markieren und in JOSM anzeigen zu 
lassen?
Das wäre nämlich sehr unschön!


-- 
Mit freundlichen Gruessen

  Wolfgang Wienke

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

Re: [Talk-de] Bot Vorschlag: St. NAME --> Sankt NAME

2010-03-14 Diskussionsfäden Sebastian Klein

Jonas Stein wrote:
> Strassennamen, die mit St. [1] beginnen, koennte man nach Sankt umbenennen.
> 
> Abkuerzungen, die man automatisiert anpassen koennte:
> 
> St. --> Sankt
> Pfr. --> Pfarrer
> Pl. --> Platz
> Dr. --> Doktor
> Prof. --> Professor
> 
> Einschraenkung auf Stassennamen und Adressen waere natuerlich wichtig
> Vielleicht habe ich noch einige Gaengige uebersehen, die bei einer Suche
> nach . im name= Tag auftauchen wuerden.
> 
> Bsp:
> [1] 
> http://www.openstreetmap.org/?minlon=6.5912446975708&minlat=50.6332321166992&maxlon=6.5921368598938&maxlat=50.6340217590332
> 
> Macht das so Sinn und falls ja, moechte das jemand in seinen Bot
> aufnehmen? 
> 

Aua, ich glaube da hast du einen wunden Punkt getroffen. :)
Die meisten Endlosdiskussionen auf der Liste verlaufen ja im Sande, aber 
zu diesem Thema gab es wohl so halbwegs die Übereinstimmung, dass Dr. 
und Prof. in der Regel nicht ausgeschrieben werden sollten...

__

Sebastian

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

Re: [Talk-de] Bot Vorschlag: St. NAME --> Sankt NAME

2010-03-14 Diskussionsfäden Helder Aguiar

auch dagegen!

Was ist denn mit den Prof.Dr.Dr.Hassenichgesehen Strassen? Ausgeschrieben
sehen die doch sicher doof aus. Ausserdem kann es auch passieren, dass der
Name von unserem "Prof.Dr.Dr." dann aus Platzgründen wegfällt


- Original Message - 
From: "Guenther Meyer" 
To: "Openstreetmap allgemeines in Deutsch" 
Sent: Sunday, March 14, 2010 9:42 PM
Subject: Re: [Talk-de] Bot Vorschlag: St. NAME --> Sankt NAME


Am Sonntag 14 März 2010 21:02:04 schrieb Jonas Stein:
> Strassennamen, die mit St. [1] beginnen, koennte man nach Sankt
> umbenennen.
>
> Abkuerzungen, die man automatisiert anpassen koennte:
>
> St. --> Sankt
> Pfr. --> Pfarrer
> Pl. --> Platz
> Dr. --> Doktor
> Prof. --> Professor
>
> Einschraenkung auf Stassennamen und Adressen waere natuerlich wichtig
> Vielleicht habe ich noch einige Gaengige uebersehen, die bei einer Suche
> nach . im name= Tag auftauchen wuerden.
>
> Bsp:
> [1]
>
> http://www.openstreetmap.org/?minlon=6.5912446975708&minlat=50.63323211669
> 92&maxlon=6.5921368598938&maxlat=50.6340217590332
>
> Macht das so Sinn und falls ja, moechte das jemand in seinen Bot
> aufnehmen?
>
dagegen!



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

Re: [Talk-de] Bot Vorschlag: St. NAME --> Sankt NAME

Am Sonntag 14 März 2010 21:02:04 schrieb Jonas Stein:
> Strassennamen, die mit St. [1] beginnen, koennte man nach Sankt umbenennen.
> 
> Abkuerzungen, die man automatisiert anpassen koennte:
> 
> St. --> Sankt
> Pfr. --> Pfarrer
> Pl. --> Platz
> Dr. --> Doktor
> Prof. --> Professor
> 
> Einschraenkung auf Stassennamen und Adressen waere natuerlich wichtig
> Vielleicht habe ich noch einige Gaengige uebersehen, die bei einer Suche
> nach . im name= Tag auftauchen wuerden.
> 
> Bsp:
> [1]
>  http://www.openstreetmap.org/?minlon=6.5912446975708&minlat=50.63323211669
> 92&maxlon=6.5921368598938&maxlat=50.6340217590332
> 
> Macht das so Sinn und falls ja, moechte das jemand in seinen Bot
> aufnehmen?
> 
dagegen!

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

Re: [Talk-de] Rapideye stellt OpenStreetMap Satellitenbilde r von Chile zur Verfügung

2010-03-14 Diskussionsfäden Jonas Stein

> Das ist aber nicht die durch das Erdbeben verursachte, tatsächliche 
> Verschiebung, oder?

Die Erdverschiebungen bei Erdbeben liegen unter der Messgenauigkeit
der Luftaufnahmen.

Die Verzerrungen kommen durch die Aufnahmeoptik.

-- 
Jonas Stein 


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

Re: [Talk-de] Bot Vorschlag: St. NAME --> Sankt NAME

2010-03-14 Diskussionsfäden Andreas Neumann

Am 14.03.2010 21:02, schrieb Jonas Stein:
> Strassennamen, die mit St. [1] beginnen, koennte man nach Sankt umbenennen.
> 
> Abkuerzungen, die man automatisiert anpassen koennte:
> 
> St. --> Sankt
> Pfr. --> Pfarrer
> Pl. --> Platz
> Dr. --> Doktor
> Prof. --> Professor
> 
> Einschraenkung auf Stassennamen und Adressen waere natuerlich wichtig
> Vielleicht habe ich noch einige Gaengige uebersehen, die bei einer Suche
> nach . im name= Tag auftauchen wuerden.
> 
> Bsp:
> [1] 
> http://www.openstreetmap.org/?minlon=6.5912446975708&minlat=50.6332321166992&maxlon=6.5921368598938&maxlat=50.6340217590332
> 
> Macht das so Sinn und falls ja, moechte das jemand in seinen Bot
> aufnehmen? 


Dagegen... Es gibt Orte, wo es ausgeschrieben wird und es gibt Orte, wo
es abgekürzt wird. Hier in Ilmenau wird meines Wissens nach der Dr.
abgekürzt.

MfG Andreas

-- 
Diese Nachricht wurde maschinell erstellt und ist daher ohne
Unterschrift gültig.



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

Re: [Talk-de] Rendern von Seezeichen und Editor

2010-03-14 Diskussionsfäden Olaf Hannemann

Hallo  Frederik,

> Wie wir hier festgestellt haben, gab es voruebergehend das Problem, dass
> mindestens ein OSeaM-Editor irgendwelche de facto existierenden, aber
> nicht normkonformen Seezeichen blindlings (und ohne Kenntnis der
> Realitaet) in normkonforme Seezeichen (die so am angegebenen Ort nicht
> existieren) umgesetzt hat.

Nein, es war immer eine Benutzer-Interaktion nötig.

> Das ist definitiv eine Fehlfunktion in der Software, ich denke, darin
> sind wir uns alle einig. 

Nein

> Wenn irgendwo ein rostiges Benzinfass
> rumduempelt, dann sollte kein Editor der Welt daraus automatisch ein
> "rostiges Benzinfass mit roter Leuchte drauf" machen, bloss weil es nur
> fuer rostige Benzinfaesser mit roter Leuchte eine Norm gibt.

Der Online-Editor hat niemals einem Benzinfass eine rote Leuchte angedichtet.

> Jan Jesse beschreibt in einem Posting vom 3.3. eine solche
> offensichtliche Editor-Fehlfunktion:
> 
> http://www.freietonne.de/index.php?site=126&infotyp=1

Dann schaue dir doch bitte einmal die Knoten-Chronik von:
- http://www.openstreetmap.org/browse/node/431046138/history
- http://www.openstreetmap.org/browse/node/431046061/history
an!

Wer hat die hier angesprochenen Schlüssel:
seamark:light = yes
seamark:light:colour = green
hinzugefügt? Ich nicht. Der Leo auch nicht, und der Online-Editor auch nicht.
Dieser hat nur, wie vorher gefordert, alle existierenden Schlüssel 
zurückgeschrieben.

Markus, Leo und ich haben inzwischen unabhängig voneinander abgeklärt, dass 
diese Tonnen wirklich kein Licht haben. Darf ich dieses jetzt ändern oder nicht?

> Ich gehe davon aus, dass solche Fehler inzwischen nicht mehr vorkommen.
> Ich moechte alle Beteiligten bitten, die Software, falls noch
> fehlerhaft, entsprechend zu verbessern, bzw. die Verwendung derart
> fehlerhafter Software umgehend einzustellen.

Es ist mir nicht bekannt, dass die Software solche Fehler aufweist,  falls dir 
solche Fehler bekannt sind, bitte ich dich mir diese mitzuteilen, damit diese 
umgehend behoben werden können.

> Sollte nach dem 31.3. immer noch derart fehlerbehaftete Software
> eingesetzt werden, werde ich die betroffenen Accounts einzeln
> anschreiben und notfalls so lange sperren, bis sie ihre Software
> dahingehend aktualisiert haben, dass kein versehentliches Um-Taggen, wie
> es hier beschrieben wird, mehr stattfindet. 

Welches Um-Taggen? Zeige mir doch bitte einmal wo wirklich ein Um-Taggen 
stattfindet, ohne dass der Benutzer etwas da zu tut. Hast du dir einmal die  
Source unter http://openseamap.svn.sourceforge.net/viewvc/openseamap/ 
angeschaut?
Des weiteren bitte ich dich nicht Markus sondern mich anzuschreiben, wenn es um 
den Online-Editor geht. Da ich den Editor geschrieben  habe, bin ich allein 
verantwortlich für alles was dort passiert.

> Ich hoffe aber, dass das
> nicht noetig sein wird!

Ich auch!


Beste Grüße

Olaf

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

Re: [Talk-de] Bot Vorschlag: St. NAME --> Sankt NAME

2010-03-14 Diskussionsfäden Ulf Möller

Jonas Stein schrieb:

> Dr. --> Doktor

Bitte nicht! Die Abk. ist bei Personen und Straßennamen vollkommen üblich.


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

Re: [Talk-de] Fahrschule

2010-03-14 Diskussionsfäden Johannes Huesing

Martin Koppenhoefer  [Sun, Mar 14, 2010 at 06:28:38PM 
CET]:
> Delphin-schulen, ...
> 

sind eh zu wenig ortsfest für OSM.


-- 
Johannes Hüsing   There is something fascinating about science. 
  One gets such wholesale returns of conjecture 
mailto:johan...@huesing.name  from such a trifling investment of fact.  
  
http://derwisch.wikidot.com (Mark Twain, "Life on the Mississippi")

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

Re: [Talk-de] Bot Vorschlag: St. NAME --> Sankt NAME

2010-03-14 Diskussionsfäden olvagor

Jonas Stein schrieb:
> Strassennamen, die mit St. [1] beginnen, koennte man nach Sankt umbenennen.
> 
> St. --> Sankt

Was machst du dann mit der Stefan-Meier-Straße, die offiziell
"St.-Meier-Straße" oder "St. Meier Straße" heisst und dementsprechend so
in OSM drin ist.

Ist das ganze wirklich ein Problem?

Gruß,
olvagor

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

[Talk-de] Bot Vorschlag: St. NAME --> Sankt NAME

2010-03-14 Diskussionsfäden Jonas Stein

Strassennamen, die mit St. [1] beginnen, koennte man nach Sankt umbenennen.

Abkuerzungen, die man automatisiert anpassen koennte:

St. --> Sankt
Pfr. --> Pfarrer
Pl. --> Platz
Dr. --> Doktor
Prof. --> Professor

Einschraenkung auf Stassennamen und Adressen waere natuerlich wichtig
Vielleicht habe ich noch einige Gaengige uebersehen, die bei einer Suche
nach . im name= Tag auftauchen wuerden.

Bsp:
[1] 
http://www.openstreetmap.org/?minlon=6.5912446975708&minlat=50.6332321166992&maxlon=6.5921368598938&maxlat=50.6340217590332

Macht das so Sinn und falls ja, moechte das jemand in seinen Bot
aufnehmen? 

-- 
Jonas Stein 


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

Re: [Talk-de] Baumkataster

Am 14. März 2010 20:17 schrieb Martin Koppenhoefer :
 Falk Zscheile wrote:
> Das bisher niemand in größerem Stil Bäume einzeln verzeichnet hat
>
> Du bist wohl nicht zufällig http://www.openstreetmap.org/user/B10xyz ?
> Der hat massenweise Bäume gelöscht, die ich eingetragen habe und die
> es auch gibt.
>

Nein, bin ich nicht. Wenn sich jemand die Mühe mit den Bäumen macht,
dann respektiere ich das. Ich denke auch nicht, dass meine bisherigen
Ausführungen Anlass für die von Dir vorgebrachte Vermutung sein
können. Daher empfinde ich Deine Aussage mir gegenüber als (vorsichtig
ausgedrückt) unangebracht.

Gruß, Falk

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

Re: [Talk-de] ÖPNV: from to: das, was vorne drau fsteht?

2010-03-14 Diskussionsfäden nimix



Tirkon wrote:
> 
> Falls wirklich das, "was vorne draufsteht", (Fall 1) angegeben werden
> soll: Woher "weiß" die ÖPNV-Relation dann, welches die Zielhaltestelle
> ist? Denn wenn ich es richtig sehe, wurde die Rolle "terminal"
> abgeschafft. "Weiß" die Relation dies anhand der Reihenfolge, in der
> die Haltestellen in der Relation erfasst sind?
> 
Genau so ist es, die Namen der ersten und letzten Haltestelle ergeben sich
aus der Reihenfolge. Die Tags from und to dienen einer allgemeineren
Ortsbezeichnung, wie sie meist auf den Fahrzeugen angezeigt wird. So kann
man z.B. sagen, dass eine Linie von Charlottenburg nach Kreuzberg fährt,
während die Haltestellen vielleicht Luisenplatz und Moritzplatz heißen.


Tirkon wrote:
> 
> Weitere Frage:
> Ist eigentlich im Falle, dass die beiden Fahrtrichtungen durch
> getrennte Routenrelationen erfasst werden, die Angabe der Rolle
> forward/backward bei den beinhalteten ways nicht mehr erforderlich?
> Gilt das auch für die ÖPNV Karte? 
> 
Theoretisch sind die Rollen bei getrennter Erfassung und richtiger
Sortierung redundant. Bisher kann die ÖPNV-Karte diese aber nicht
selbstständig ergänzen. Wenn man also momentan die kleinen Pfeile sehen will
muss man sie doch erfassen.
Gruß,
Melchior

-- 
View this message in context: 
http://n2.nabble.com/OPNV-from-to-das-was-vorne-draufsteht-tp4731309p4733119.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

Re: [Talk-de] Baumkataster

Am 14. März 2010 20:08 schrieb Martin Koppenhoefer :
> Am 14. März 2010 19:32 schrieb Falk Zscheile :
>> 2010/3/14 Frederik Ramm :
>>> Falk Zscheile wrote:
 Das bisher niemand in größerem Stil Bäume einzeln verzeichnet hat

Du bist wohl nicht zufällig http://www.openstreetmap.org/user/B10xyz ?
Der hat massenweise Bäume gelöscht, die ich eingetragen habe und die
es auch gibt.

http://www.openstreetmap.org/browse/changeset/4085957

kann man das rückgängig machen? Ist ja echt mühselig, wenn solche
"Aufräumer" die Daten wieder löschen, die man mühselig eingetragen
hat, insbesondere bei Nodes.

Gruß Martin

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

Re: [Talk-de] Baumkataster

Am 14. März 2010 19:32 schrieb Falk Zscheile :
> 2010/3/14 Frederik Ramm :
>> Falk Zscheile wrote:
>>> Das bisher niemand in größerem Stil Bäume einzeln verzeichnet hat
>>
>> http://www.openstreetmap.org/?lat=49.0102&lon=8.41345&zoom=17&layers=B000FTF
>>
> Ok, dann haben wir schon zwei (Anubis und Mirko), die es entgegen
> meiner Schwarzseherei getan haben. Das hat mit Sicherheit eine Menge
> Arbeit gemacht und sieht auch schön aus. Aber an jeder Allee in
> Mecklenburg-Vorpommern stehen vermutlich mehr Bäume.

http://www.openstreetmap.org/?lat=52.54371&lon=13.35547&zoom=16&layers=B000FTF

wenn jemand Lust hat, die Bäume in Meck-Pomm einzeln zu taggen, kann
er das auch gern tun, ich beschränke mich erstmal auf Gebiete, in
denen ich mich bewege...

Gruß Martin

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

Re: [Talk-de] Treppe mit Rampe

2010-03-14 Diskussionsfäden Tobias Knerr

Jan Tappenbeck schrieb:
> es gibt Treppen mit einer Rampe für Kinderwagen und Fahrräder.

highway=steps, dazu dann eben eines oder mehrere der folgenden Tags:

ramp:stroller=yes - Rampe für Kinderwägen
ramp:bicycle=yes - Rampe für Fahrräder
ramp:wheelchair=yes - Rampe für Rollstühle

http://wiki.openstreetmap.org/wiki/Key:ramp

Sollte die meisten Bedürfnisse abdecken.

Tobias

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

[Talk-de] Treppe mit Rampe

2010-03-14 Diskussionsfäden Jan Tappenbeck

hi !

es gibt Treppen mit einer Rampe für Kinderwagen und Fahrräder.

Tagt Ihr diese als highway=steps - oder ich denke hierbei um die 
Berücksichtigung beim Routing (!) und die Barrierefreiheit.

Gruß Jan .-)

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

Re: [Talk-de] Baumkataster

2010/3/14 Frederik Ramm :
> Falk Zscheile wrote:
>> Das bisher niemand in größerem Stil Bäume einzeln verzeichnet hat
>
> http://www.openstreetmap.org/?lat=49.0102&lon=8.41345&zoom=17&layers=B000FTF
>
Ok, dann haben wir schon zwei (Anubis und Mirko), die es entgegen
meiner Schwarzseherei getan haben. Das hat mit Sicherheit eine Menge
Arbeit gemacht und sieht auch schön aus. Aber an jeder Allee in
Mecklenburg-Vorpommern stehen vermutlich mehr Bäume.

Nur aus Interesse -- hat vielleicht jemand ein Beispiel wo eine
(längere)  Allee mit einzelnen Bäumen eingetragen wurde?

Gruß, Falk

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

Re: [Talk-de] sabotage in florians strassenliste?

2010-03-14 Diskussionsfäden Andreas Labres

On 12.03.10 21:21, Florian Lohoff wrote:
> Mal sehen wie sich das entwickelt ... Sonst muesste man
> was captcha aehnliches einbauen ...
>   

Ich fände Authentication (OAuth) bequemer und sinnvoller...

Wie auch immer Comment-Spam nachzulaufen ist... (ich denk mir das jetzt,
was ich da sagen würde... ;)

Servus, Andreas

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

Re: [Talk-de] Baumkataster

2010-03-14 Diskussionsfäden Frederik Ramm

Hi,

Falk Zscheile wrote:
> Das bisher niemand in größerem Stil Bäume einzeln verzeichnet hat

http://www.openstreetmap.org/?lat=49.0102&lon=8.41345&zoom=17&layers=B000FTF

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

Re: [Talk-de] Baumkataster

Am 14. März 2010 18:35 schrieb Martin Koppenhoefer :
> Am 11. März 2010 13:58 schrieb Falk Zscheile :
>> Mir geht es jetzt nicht um den Import jedes einzelnen dort verzeichneten
>> georeferenzierten Baums.
>
>
> mir schon, was spricht dagegen?

Das es kein Mensch aktuell halten kann. Was uns schon bei Restaurants
und Geschäften mehr schlecht als recht gelingt, daran werden wir bei
Bäumen auf jeden Fall scheitern. Außerdem geht es mir um den
Landschaftsbestandteil Allee. Der Einzelne Baum interessiert mich
herzlich wenig. Und ich werde nicht derjenige sein, der einzelne Bäume
über eine Allee-Relation verknüpft. Aber das darf natürlich jeder, der
ein Baumkataster importiert, machen wie er möchte. Bisher scheinen wir
auf dem Gebiet aber kein einziges Beispiel zu haben.

>
>> Das kann ja kein Mensch aktuell halten.
>
> naja, Bäume sind schon relativ stabil, die sind wohl eher eines der
> dauerhafteren Features, die wir taggen, Aktualität sehe ich daher
> nicht als Problem an.
>
Ich sehe das anders. Jedes Jahr verschwinden eine Menge Bäume von den
Straßenrändern. Aber ich sehe den praktischen Aspekt im Vordergrund.
Das bisher niemand in größerem Stil Bäume einzeln verzeichnet hat (vom
Mirko einmal abgesehen) und auch Alleen bisher eher sporadisch erfasst
sind, ist für mich ein Zeichen, hier besser vom einzelnen Baum zu
abstrahieren.

Aber noch ist es nicht soweit. Wir haben bisher kein Baumkataster als
-- wie auch immer geartete -- Importvorlage zur Verfügung.

>
>
>> Aber man
>> könnte anhand solcher Daten sicher schön erkennen, wo Straßen von Alleen
>> gesäumt sind und um welche Baumarten es sich handelt. Und diese Information
>> gehört meiner Meinung nach schon in unsere Datenbank.
>
> als Zwischenschritt kann man die Allee natürlich erstmal als Tag an
> die Straße hängen, aber langfristig sehe ich die Bäume schon eher als
> einzelne Punkte in der DB, vor allem in urbanen Gebieten. Bäume sind
> übrigens auch aus Luftbildern meist sehr einfach abzuleiten und durch
> kopieren und einfügen sehr schnell gemappt.

Welche Luftbilder? Landsat? :-)

Gruß, Falk

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

Re: [Talk-de] Baumkataster

Am 11. März 2010 13:58 schrieb Falk Zscheile :
> Mir geht es jetzt nicht um den Import jedes einzelnen dort verzeichneten
> georeferenzierten Baums.


mir schon, was spricht dagegen?

> Das kann ja kein Mensch aktuell halten.

naja, Bäume sind schon relativ stabil, die sind wohl eher eines der
dauerhafteren Features, die wir taggen, Aktualität sehe ich daher
nicht als Problem an.


> Aber man
> könnte anhand solcher Daten sicher schön erkennen, wo Straßen von Alleen
> gesäumt sind und um welche Baumarten es sich handelt. Und diese Information
> gehört meiner Meinung nach schon in unsere Datenbank.

als Zwischenschritt kann man die Allee natürlich erstmal als Tag an
die Straße hängen, aber langfristig sehe ich die Bäume schon eher als
einzelne Punkte in der DB, vor allem in urbanen Gebieten. Bäume sind
übrigens auch aus Luftbildern meist sehr einfach abzuleiten und durch
kopieren und einfügen sehr schnell gemappt.

Gruß Martin

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

Re: [Talk-de] Fahrschule

Am 12. März 2010 23:45 schrieb Claudius :
> Da haben die Wikipedia und du formell ja völlig Recht, aber die erste
> Assoziation bei "Schule" ist immer noch eine der ersten
> Bildungseinrichtungen nach dem Kindergarten und nicht derlei
> "Spezialschulen". Daher bin ich auch eher dafür das etablierte Tag nicht
> durch ein nachträglich eingeführtes Zweit-Tag zu verwässern.
>
> Dann lieber ein neues für die Fahrschulen einführen.

+1
ich würde unter Schule auch erstmal allgemein- und berufsbildende
Schulen verstehen, und nicht Volkshochschulen, Baumschulen,
Fahrschulen, Delphin-schulen, Yogaschulen,...

Gruß Martin

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

Re: [Talk-de] Fahrschule

2010-03-14 Diskussionsfäden Florian Gross

Chris-Hein Lunkhusen glaubte zu wissen:
> Guenther Meyer schrieb:

>> und eine fahrschule ist keine spezialisierung?
>
> Nicht, wenn man unter "Schule" eine Schule im herkömmlichen Sinne
> meint.

Was bedeutet "herkömmlicher" Sinn?

Der eine sieht das so, der andere so.

> Deine Fahrschule ist hier im Wikipediaartikel zu "Schule"
> übrigens nicht als Schultyp aufgeführt:
>
>

Wobei Wikipedia auch nicht alles weiß. ;-)


-- 
Das schöne an einem öffentlichen Medium ist, daß wir uns 
gegenseitig nicht das Schreiben verbieten können.
 [Rainer Georg Blankenagel in dsn]


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

Re: [Talk-de] Neues Proposal für boat_rental

Am 14. März 2010 11:24 schrieb Dimitri Junker :

>>Deswegen bietet es sich an amenity=rental und retal=* für reine
>>Mietgeschichten zu nutzen. Das rental=* könnte man dann auch noch an
>>bestehende Firmen, Shops etc. hängen.
>
>
> Die Notwendigkeit für das amenity sehe ich nicht, es gibt je nach Branche
> Läden die nur verkaufen(z.B. Einzelhandel), nur verleihen(z.B.
> Autovermietung) oder beides(z.B. Tauchladen) machen. Deshalb würde ich
> vorschlagen diese woe normale Läden zu taggen und zusätzlich ein
> rental=yes/no/only
> zu setzen

Ich würde die beiden hier genannten Vorschläge nicht im Widerspruch
zueinander sehen. Wie in einer anderen Mail bereits erwähnt gibt es
Haupt- und Nebenzwecke. In einem Autohaus kann man in der Regel auch
Autos mieten. Deswegen ist es immer noch ein Autohaus und keine
Autovermietung. Der Verkauf steht im Vordergrund, nicht die Miete. Um
aber einen Nebenzweck zu verdeutlichen kann ich mir ein rental=yes/no
durchaus an einem amenity=Geschäft vorstellen. Gerade ein Tauchladen
scheint mir hierfür ein sehr gutes Beispiel zu sein.

Gruß, Falk

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

Re: [Talk-de] ÖPNV: from to: das, was vorne dr aufsteht?

2010-03-14 Diskussionsfäden Andreas Neumann

Moin,

ich handhab das bisher so: Bei Überregionalen Linien wird der Ziel-Ort
in From/To reingeschrieben. Evtl. wird auch die Haltestellenbezeichnung
mit dazugeschrieben, dann aber immer als "[Ort], [Haltestelle]." Das hat
vor allem dann Sinn, wenn die Linie unterschiedliche Haltestellen im
selben Ort als Ziel oder Start haben kann.

Bezüglich der unterschiedlichen Benennung: Ich halte mich immer an die
Haltestellenbezeichnung im Fahrplan.

MfG Andreas

-- 
Diese Nachricht wurde maschinell erstellt und ist daher ohne
Unterschrift gültig.



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

Re: [Talk-de] Fahrschule

2010-03-14 Diskussionsfäden Johannes Huesing

Guenther Meyer  [Sun, Mar 14, 2010 at 01:00:36PM CET]:
[...]
> 
> warum geht sowas bei POIs nicht?
> 

Weil sich die Is so stark unterscheiden.

Ich glaube, dass es ganz sinnvoll ist, die Grobkategorisierung danach
vorzunehmen, in welche Richtung eine Karte gehen soll. Wenn man eine
Gewässerkarte macht, sollte sich vieles unter waterway= oder natural=water
finden. Insofern wäre tatsächlich wenigen mit einer Zusammenfassung durch
school= geholfen, die vielleicht alle Bildungseinrichtungen in eine 
Karte bringen wollen.

Sinnvoll ist zum Beispiel, wenn die Wassersportler und die Bahnfreaks
ihre Tags unter wenigen Schlüsseln sammeln. Dabei ist wichtig, den 
umfriedeten Garten zu vermeiden, der Außenstehende abschreckt.

Daher finde ich den älteren Vorschlag im Wiki zum Kanuverleih etwas besser
als ein allgemeines rental-Tag, es sei denn es ist abzusehen, dass
jemand eine Verleih- und Vermietkarte plant.

-- 
Johannes Hüsing   There is something fascinating about science. 
  One gets such wholesale returns of conjecture 
mailto:johan...@huesing.name  from such a trifling investment of fact.  
  
http://derwisch.wikidot.com (Mark Twain, "Life on the Mississippi")

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

Re: [Talk-de] Baumkataster

moin

On 11.03.2010, at 13:58, Falk Zscheile wrote:
> hat schon einmal jemand versucht, ein Baumkataster[1] vom Amt zu bekommen?
> 
> Mir geht es jetzt nicht um den Import jedes einzelnen dort verzeichneten 
> georeferenzierten Baums. Das kann ja kein Mensch aktuell halten. Aber man 
> könnte anhand solcher Daten sicher schön erkennen, wo Straßen von Alleen 
> gesäumt sind und um welche Baumarten es sich handelt. Und diese Information  
> gehört meiner Meinung nach schon in unsere Datenbank.

hm das wäre doch mal ne nützliche Information für Allergiker. Sowohl "Da kann 
man hinziehen weil wenige Bäume der Sorte X" als auch "Blöde Idee da ne Radtour 
zu machen."

Mal etwas ernster, wenn du da was erfolgreich Geschaft hast, poste das bitte 
auf der Mailingliste. Ich denke deine Idee mit den Alleen würden andere Lokale 
OSM Gruppen auch gerne aufgreifen.

cu AssetBurned

smime.p7s
Description: S/MIME cryptographic signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Mapping von Kleingartenvereinen?

Moin

Ich bin gerade mal auf die Idee gekommen das ich mal bei den Vorsitzenden eines 
mir bekannten größeren Kleingartenvereines nachfragen könnte ob sie Karten 
Material haben das man in OSM einbinden könnte.
Spontan ist mir aufgefallen das der Verein zwar eingezeichnet ist, aber die 
Entwässerungsgräben, Oberirdische Stromleitungen und nichtmal die Nummern der 
einzelnen Gärten.

Nun würde ich gerne mal wissen ob jemand schonmal so eine Anfrage gestellt hat 
(mir evl also nen Musterbrief zuschicken könnte) und ob euch noch andere dinge 
einfallen die man mit Mappen könnte/sollte.

Und besonders wichtig, wenn man karten Material bekommt. Wie soll man das 
behandeln?
Also ich denke da an "Wie mach ich in OSM die Quellenangabe", "Muß ich den 
Schriftverkehr dokumentieren und wie" und all solche Dinge die sich dann ja evl 
zu Rechtlichen Problemen entwickeln könnten wenn man das vorhandene Material 
nutzt.

cu AssetBurned

smime.p7s
Description: S/MIME cryptographic signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Garmin Europa:all in one karte auf eTrex

2010-03-14 Diskussionsfäden Lars Schimmer

On 14.03.2010 07:50, Joerg Fischer wrote:
> Lars Schimmer wrote:
> 
>> Nachdem ich etwas gebastelt habe, wollte ich mal mein Garmin eTrex
>> nutzen zum Routen don Graz nach Chemnitz zum LinuxTag.
>>
>> Bisher hatte ich die Karte von Computerteddy, dieses mal hab ich die
> 
> Ich nehme an Du bist der, mit dem ich gestern am OSM-Stand ins Gespräch
> kam, oder? ;-)

Na, ich war noch ned bei euch, mein Garmin liegt im Hotel.

>> Und dann: diese Detail-fülle!
> 
> Ich weiß nicht ob der eTrex das kann, mein Edge 705 kann im Menü
> "Einstellungen", "Karte" auf verschiedene Detailgrade eingestellt werden.

Bisher habe ich diesen Punkt nicht so ganz gefunden und/oder die Layer
sind nicht korrekt beschriftet.

>> In .at ist auch oft noch das Problem, das viele Tracks nicht korrekt
>> getaggt sind und diese als "dicke rote" Linien dargestellt werden, die
> 
> Das steckt in den Layern, schalte einfach die Layer ab die Du nicht sehen
> willst. Am Edge auch wieder in Einstellungen, Karte.

Was nicht hilft, wenn die Tracks im selben Layer sind wie die
"wichtigen" ;-)

>> Was noch nervt: die Grenzen der Bezirke/Gemeinde/.. werden zu zu dick
>> gezeichnet - stören meist nur beim Routen.
> 
> Das Layer boundary abschalten, iirc.

Muß ich mal auf die Jagd gehen.

> Tschaui, Jörg
> 


MfG,
Lars Schimmer
-- 
-
TU Graz, Institut für ComputerGraphik & WissensVisualisierung
Tel: +43 316 873-5405   E-Mail: l.schim...@cgv.tugraz.at
Fax: +43 316 873-5402   PGP-Key-ID: 0x4A9B1723

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

Re: [Talk-de] Garmin Europa:all in one karte auf eTrex

2010-03-14 Diskussionsfäden Lars Schimmer

On 14.03.2010 10:02, Ulf Lamping wrote:
> Am 13.03.2010 13:00, schrieb Lars Schimmer:
>> On 13.03.2010 11:06, Torsten Leistikow wrote:
>>> Lars Schimmer schrieb am 13.03.2010 10:52:
 IMHO ist der eTrex zu blöde, in den
 Zoomstufen 2km, 5km,... die unwichtigen Daten auszufiltern.
>>>
>>> Da wuerde ich dem Etrex keine Schuld geben.
>>>
>>> Zum einen kann der Bediener bei den Garmin Geraeten irgendwo in den
>>> Einstellungen den Detaillevel zu veraendern, womit genau diesem Problem 
>>> begegnet
>>> werden kann.
>>
>> Schon, aber die filtert nicht das raus, was für Autos unwichtig ist ;-)
>> Und selbst in der "weniger" Einstellung sind es noch zuviel.
> 
> Du erkennst schon die Ironie?
> 
> Eine Karte zu nehmen die sich selbst "alles in einer" nennt, und sich 
> dann zu wundern: "da ist aber zuviel drauf" ;-)

Ich mecker ned über zuviel Daten sondern um die Darstellung der Daten,
das ist ein kleiner Unterschied,


> Gruß, ULFL
> 


MfG,
Lars Schimmer
-- 
-
TU Graz, Institut für ComputerGraphik & WissensVisualisierung
Tel: +43 316 873-5405   E-Mail: l.schim...@cgv.tugraz.at
Fax: +43 316 873-5402   PGP-Key-ID: 0x4A9B1723

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

Re: [Talk-de] Garminkacheln (war: All in One mit git)

Carsten Schwede schrieb am 14.03.2010 13:24:
> Ich habe mit das jetzt mal an der Ecke angesehen, also es sieht danach
> aus, daß mkgmap das wegwirft. In der con splitter produzierten OSM-Datei
> ist die fehlende Waldecke drin.

Vielleicht mal die neuste Version von mkgmap probieren. WanMil hat ja gerade mit
Release 1601 seinen neusten multipolygon-Patch veroeffentlicht.
Wenn das auch damit nicht will, solltest du ihm die von splitter erzeugte
OSM-Datei zuschicken, damit er da mal einen Blick draufwerfen kann.

> Ansonsten habe ich aber auch gesehen,
> daß der Overhead doch recht massiv ist, was splitter da erzeugt.

Das kann man ja einstellen. (Was auch immer das fuer Auswirkungen haben mag.)

Gruss
Torsten

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

Re: [Talk-de] ÖPNV: from to: das, was vorne dr aufsteht?

"Helder Aguiar"  wrote:

>Der
> from= und to= -Tag sollte aber wirklich nur Start- und Zielhaltestelle
> angeben.

Gut, Deine Meinung widerspricht offenbar derjenigen der Gruppe um
Jochen Topf, die das Oxomoa Prinzip seinerzeit ausgekocht haben. Aber
mit den gegebenen Infos hat die from/to Angabe lediglich Infocharakter
und ist zum korrekten "Funktionieren" der Relation nicht erforderlich.
Das war der entscheidende Punkt, um den es mir bei meiner Frage ging.
Man kann sich also ohne Funktionalitätseinbuße streiten, was man
einträgt.

http://wiki.openstreetmap.org/wiki/User:Oxomoa/%C3%96PNV-Schema

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

Re: [Talk-de] Garminkacheln (war: All in One mit git)

Carsten Schwede schrieb am 14.03.2010 12:41:
> Mapsource ist nicht das Maß aller Dinge, und ich denke, wir sollten eher
> auf QLandkarte setzen, der kann übrigens mehrere Karten als Layer
> übereinander darstellen. Außerdem können wir hier auf die Entwicklung
> des Programmes direkten Einfluß nehmen, wie ich ja im Prinzip auch schon
> getan habe, wegen der Einführung von Typ-Dateien in meinen Karten hat
> Oliver die Darstellung ebendieser in QLandkarte nämlich eingebaut.

Mapsource ist sicherlich eine Kruecke. Es ist fuer mich aber erste Wahl, um am
PC die Routing-Funktionen der Karte auszuprobieren. Normalerweise liefert
Mapsource da ja die gleichen Ergebnisse wie das Navi-Geraet, aber am viel
groesseren PC-Bildschirm kann man sich die natuerlich besser anschauen.

> Nö, sehe ich nicht so, das Grenzproblem an sich muss gelöst werden und
> nicht am Symptom gedoktort werden.

Das setzt voraus, dass das Problem auch wirklich loesbar ist. Wenn es nun aber
gar nicht von der Gestalltung der Kachelgrenzen abhaengt, sondern die interne
Software der Navis das begrenzende Element ist?
Da das ja aber z.Z. nicht bekannt ist, bevorzuge ich einen moeglichst
pragmatischen Ansatz, will sagen: Ich will mit heutigem, freien Wissen und den
verfuegbaren Werkzeugen moeglichst gute Resultate erzielen.

> Was nützt Dir so eine Kachelung denn. Ich hier in Frankfurt habe
> deswegen bisher keinen Sinn darin gesehen, weil mir hier eine Kachelung
> nichts nützt, wenn ich von anderen "Ländern" umgeben bin. Dann muss man
> eh die Kacheln drumherum mitnehmen.

Ich habe neulichst mal meine Karten so umgebaut, dass die einzelnen Kacheln
nicht mit irgend einer Nummer sondern mit einem sprechenden Namen auf dem Navi
angezeigt werden. Bei rein schematisch geschnittenen Kacheln ist das manchmal
ziemlich schwer, dann einen passenden Namen fuer den Ausschnitt zu finden.
Ausserdem koennte man bei freiem Kachelschnitt auch Themenkarten erzeugen, die
sich an aeusseren Vorgaben ausrichten. Z.B. Wanderkarten die entsprechend den
Tourismusregionen oder den ausschildernden Wanderverbaenden geschnitten waeren.

> Die originalen Garminkarten sind aber auch eine gute Grundlage, wo man
> sicher auch mal hinsehen sollte, hier gibt es nämlich soetwas wie
> übereinanderliegende Kartelemente oder doppelte Wege gar nicht. (Siehe
> z.B. Topo V1 in mapedit)

Yepp. Schade, dass wir nicht bei allen Sachen wissen, wie das genau 
funktioniert.
Wenn man sich eine Garmin-Karte selber baut, so ist man bestimmt die Haelfte der
Zeit damit beschaeftigt, fuer irgendwelche Probleme einen Workaround zu finden.
Und die andere Haelfte der Zeit verbringt man damit, die Workarounds wieder
zurueck zu bauen, wenn die mkgmap-Gemeinde ein neues Feature entschluesselt und
verwirklicht hat.

Gruss
Torsten

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

Re: [Talk-de] Garminkacheln (war: All in One mit git)

Hi,

Am 14.03.2010 12:22, schrieb Torsten Leistikow:
> Ich meinte, du solltest dir mal die OSM-Datei angucken, die aus splitter raus
> kommt, damit man entscheiden kann, ob das wirklich ein splitter Problem ist 
> oder

Ich habe mit das jetzt mal an der Ecke angesehen, also es sieht danach
aus, daß mkgmap das wegwirft. In der con splitter produzierten OSM-Datei
ist die fehlende Waldecke drin. Ansonsten habe ich aber auch gesehen,
daß der Overhead doch recht massiv ist, was splitter da erzeugt.

-- 
Viele Grüße
Carsten

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

Re: [Talk-de] Neues Proposal für boat_rental

Am Sonntag 14 März 2010 13:07:26 schrieb Guenther Meyer:
> Am Sonntag 14 März 2010 05:23:28 schrieb Mirko Küster:
> > Deswegen bietet es sich an amenity=rental und retal=* für reine
> > Mietgeschichten zu nutzen. Das rental=* könnte man dann auch noch an
> > bestehende Firmen, Shops etc. hängen.
> 
> +1
> 
> ergaenzung:
> amenity=rental nicht nur fuer reine mietgeschichten, sondern auch fuer
>  firmen, die *primaer* mietgeschaeft betreiben.
> 

wenn ich's mir recht ueberlege, waere vielleicht shop=rental noch besser als 
amenity...

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

Re: [Talk-de] Neues Proposal für boat_rental

Am Sonntag 14 März 2010 05:23:28 schrieb Mirko Küster:
> Deswegen bietet es sich an amenity=rental und retal=* für reine
> Mietgeschichten zu nutzen. Das rental=* könnte man dann auch noch an
> bestehende Firmen, Shops etc. hängen.
> 
+1

ergaenzung:
amenity=rental nicht nur fuer reine mietgeschichten, sondern auch fuer firmen, 
die *primaer* mietgeschaeft betreiben.

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

Re: [Talk-de] Fahrschule

Am Sonntag 14 März 2010 11:58:50 schrieb Torsten Leistikow:
> Nun gibt es ja immer wieder Leute, die einen Schemawechsel fordern (siehe
>  auch den Thread bzgl. rental, wobei ich den dort vorgeschlagenen Ansatz
>  wesentlich gelungener finde, weil da ein neues Schema neben den bisherigen
>  Tags vorgeschlagen wird, und nicht ein bestehendes Tag umgedeutet werden
>  soll). Wo bleiben aber die Vorschlage, wie so ein Schemawechsel als
>  Prozess laufen soll?

das ist eines der grossen probleme bei osm; denn dafuer da muesste man sich ja 
erstmal auf irgendwas einigen ;-)

bei den adressen hat's komischerweise funktioniert:
da haben sich ein paar leute zusammengesetzt und ein klares schema 
ausgearbeitet, und es wird benutzt.
beim oepnv-schema ist es glaub ich aehnlich...

warum geht sowas bei POIs nicht?

>  Strukturbedingt koennen wir halt nicht so einfach von
>  einem Tag auf den anderen das Tagging-Schema umschalten.

sicher koennte man das (also quasi osm 2.0).
es sind halt bestimmte vorraussetzungen zu erfuellen, bevor man sowas macht.
aber es wuerde wahrscheinlich trotzdem ein grosses geheule geben.

es gab hier auf der liste ja auch schon mal den vorschlag, eine versionierung 
einzufuehren, damit eine anwendung einfach erkennen kann, auf welche tags sich 
man zur zeit verlassen kann.

> Nochmal ein Vergleich mit dem rental-thread:
> Wenn man hier jetzt vollgendes vorschlagen wuerde
> amenity=education
> education=driving
> so waere das ein wesentlich gesuenderer Ansatz, da es keine Probelem mit
>  bereits etablierten Tags geben wuerde. (Allerdings macht bei diesem
>  Vorschlag das amenity=education keinen Sinn mehr und koennte ganz
>  weggelassen werden.)

eben, das amenity kann man sich dann sparen, "education" waere der neue 
"hauptschluessel".

>  Wobei ich persoenlich die Fahrschule eher im
>  business/shop Bereich als in school/education sehe. Aber das ist eine
>  reine Geschmacksfrage, die nichts mit einem technisch besser oder
>  schlechter Sein zu tun hat.

dann muesstest du aber konsequenterweise jede privat gefuehrte schule als 
business einordnen. dann ist es doch besser, das merkmal 
oeffentlich/privat/kommerziell/... als separates tag hinzuzufuegen.




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

Re: [Talk-de] ÖPNV: from to: das, was vorne dr aufsteht?

2010-03-14 Diskussionsfäden Claudius

Am 14.03.2010 12:45, Tirkon:
> Jochen Topf  wrote:
>
>>> Weitere Frage:
>>> Ist eigentlich im Falle, dass die beiden Fahrtrichtungen durch
>>> getrennte Routenrelationen erfasst werden, die Angabe der Rolle
>>> forward/backward bei den beinhalteten ways nicht mehr erforderlich?
>>
>> Ja.
>
> Zur Sicherheit: "Ja" heißt?
> 1) Rolle forward/backward bei den beinhalteten ways ist !!nicht!!
> erforderlich.
> 2) Rolle forward/backward bei den beinhalteten ways ist erforderlich.

Ja, die Rollen forward/backward sind bei getrennten Routenrelationen 
nicht mehr erforderlich.

Claudius


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

Re: [Talk-de] All in one Garmin Map Styles?mit?git?versionsverwaltung!

2010-03-14 Diskussionsfäden Guido Scholz

Am Sat, 13. Mar 2010 um 10:37:18 + schrieb Sven Geggus:

> Zukunft Karten mit verschiedenen Styles erzeugen. Besonders
> interessant finde ich eigentlich Mashups. Soll heißen ich fände es
> cool Radrouten, Wanderroute und ÖPNV-Linien in zuschaltbaren Layern
> zu haben so wie Christoph das schon mit Openstreetbugs etc. macht.

ja, dem kann ich zustimmen. An einem einblendbaren Radrouten-Layer wäre
ich auch interessiert. Das würde einen echten Sprung nach vorne für
Karten-Anwender bieten.

Gruß
Guido

-- 
http://www.bayernline.de/~gscholz/
http://www.lug-burghausen.org/


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

Re: [Talk-de] Fahrschule

Am Sonntag 14 März 2010 11:23:59 schrieb Falk Zscheile:
> Die Frage ist doch, ob der status quo wirklich so gut ist, das er es
> Wert ist an ihm festzuhalten, obwohl man mittlerweile erkannt hat, das
> ein hierarchisches Tagging gegenüber dem am Einzelfall orientierten
> Vorteile bringt.
> 
> Was sind die Vorteile der Kategoriebildung im Allgemeinen?
> 
> 1. Jemand ohne genaue Sachkenntnis kann schon einmal die grobe
> Einordnung vornehmen, die Einteilung in eine Unterkategorie kann dann
> jemand mit mehr Sachverstand vornehmen.
> 
> 2. Man vermeidet eine Unübersichtlichkeit im Bereich von amenity=value.
> 
+1

3.  eine software hat einen besseren anhaltspunkt, mit dem sie ein neues noch 
unbekanntes tag verarbeiten kann. z.B. liesse sich ein POI schon (mit dem Icon 
der Kategorie)  einzeichnen, obwohl man den typ selbst noch gar nicht kennt.


irgendwie kommt mir das alles sehr bekannt vor... ;-)


> 
> Punkt 1 passt in unserem Fall nicht. Jeder ist in der Lage zu sagen ob
> er eine Fahrschule, eine "richtige" Schule oder eine Volkshochschule
> vor sich hat. Anders ist das bei Hydranten etc. Genau aus diesem Grund
> ist im Bereich von amenity=value das am Einzelfall orientierte Tagging
> so verbreitet.
> 
da haengt immer von der definiton und vom jeweiligen kontext ab.
generell ist das osm durchaus anwendbar.

> Punkt 2 ist eher ein Schönheitsaspekt den man gelten lassen kann, der
> aber jedenfalls keinen zwingenden Handlungsbedarf auslöst.
> Kategoriebildung mit hierarchischem Tagging sollte kein Selbstzweck
> sein, sondern handfeste Vorteile bieten.
> 
wegen der vorteile macht man es ja...



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

Re: [Talk-de] ÖPNV: from to: das, was vorne dr aufsteht?

Jochen Topf  wrote:

>> Weitere Frage:
>> Ist eigentlich im Falle, dass die beiden Fahrtrichtungen durch
>> getrennte Routenrelationen erfasst werden, die Angabe der Rolle
>> forward/backward bei den beinhalteten ways nicht mehr erforderlich?
>
>Ja.

Zur Sicherheit: "Ja" heißt?
1) Rolle forward/backward bei den beinhalteten ways ist !!nicht!!
erforderlich.
2) Rolle forward/backward bei den beinhalteten ways ist erforderlich.

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

Re: [Talk-de] Garminkacheln (war: All in One mit git)

Hi,

Am 14.03.2010 12:22, schrieb Torsten Leistikow:

> Ich meinte, du solltest dir mal die OSM-Datei angucken, die aus splitter raus
> kommt, damit man entscheiden kann, ob das wirklich ein splitter Problem ist 
> oder

Achso, das kann ich mal machen.

> Mir ging es nur darum, dass man aus einem Funktionieren in der Vergangenheit
> recht schlecht ein Funktionieren in der Zukunft ableiten kann.

Neine, das natürlich nicht, aber ich kann auch nicht imemr das
Schlimmste annehmen, nur damit ich ja kein Risiko eingehe.

>> (OK wenn ich mir alle Gebäude in DE vorstelle, dann kann es eng werden)
> 
> Die kleinsten Kacheln hat bei mir splitter bislang in der Region Udine
> geliefert, wo genau damit angefangen wurde. Und zum Kippen des einheitlichen
> Rasters reicht ja allein ein Problemfall aus.

Ist bei mir überhaupt kein Problem, trotz 1°x1° Raster. Siehe aktueller
EU-Ausschnitt von mir (vom 10.3.10)

> Naja, da Mapsource ja nur einen Layer zur Zeit darstellen kann, ist die Idee
> nicht ganz so abwegig.

Mapsource ist nicht das Maß aller Dinge, und ich denke, wir sollten eher
auf QLandkarte setzen, der kann übrigens mehrere Karten als Layer
übereinander darstellen. Außerdem können wir hier auf die Entwicklung
des Programmes direkten Einfluß nehmen, wie ich ja im Prinzip auch schon
getan habe, wegen der Einführung von Typ-Dateien in meinen Karten hat
Oliver die Darstellung ebendieser in QLandkarte nämlich eingebaut.

> Schwierigkeiten gekommen (z.B. bei SRTM-Daten), so dass ich eine variablerer
> Kachelaufteilung bevorzuge.

Die srtm-Dateien sind in der Tat schwierig, wobei ich nicht begriffen
habe warum überhaupt. Datentechnisch können da eigentlich gar nicht
soviele Daten drin sein.

> Da die Kachelgrenzen mindestens potentielle Problemstellen sind, sollte man
> bestrebt sein, moeglichst wenige, d.h. also moeglichst gleichmaessig 
> gefuellte,
> Kacheln zu haben. Da die Datenlage bei OSM regional aber sehr unterschiedlich
> ist, geht das mit einem derartig starren Raster nicht.

Nö, sehe ich nicht so, das Grenzproblem an sich muss gelöst werden und
nicht am Symptom gedoktort werden.

> Die originalen Garminkarten sind uebrigens nicht rechteckig sondern entlang 
> von
> Verwalltungsgrenzen geschnitten. Das ist natuerlich auch nett, nur fuer sowas
> fehlen uns bislang noch die passenden Werkzeuge.

Was nützt Dir so eine Kachelung denn. Ich hier in Frankfurt habe
deswegen bisher keinen Sinn darin gesehen, weil mir hier eine Kachelung
nichts nützt, wenn ich von anderen "Ländern" umgeben bin. Dann muss man
eh die Kacheln drumherum mitnehmen. Außerdem hilft es auch bei Grenzen
an anderen Staaten nicht, weil da die Einteilung in Bundesländer oder so
ja meist völlig anders ist. Ich persönlich würde es eher sinnvoll finden
die ganze Welt in eine nutzbare Karte zu packen. (Ich weiss auch schon
ungefähr wie ich das machen kann, mal sehen wo da die Grenzen der
Technik dann liegen)

Die originalen Garminkarten sind aber auch eine gute Grundlage, wo man
sicher auch mal hinsehen sollte, hier gibt es nämlich soetwas wie
übereinanderliegende Kartelemente oder doppelte Wege gar nicht. (Siehe
z.B. Topo V1 in mapedit)


-- 
Viele Grüße
Carsten

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

Re: [Talk-de] Fahrschule

Am Sonntag 14 März 2010 09:55:42 schrieb Falk Zscheile:
> Wir betreiben hier nichts anderes als Kategorienbildung.
+1


> Wie sich hier langsam herauskristallisiert hängt es wesentlich von der
> Definition "Schule" ab, unter welcher Kategorie man landet. Die einen
> mit einer engen Definition meinen hier die klassischen
> Bildungseinrichtungen, für die Schulpflicht besteht. Diese müssen für
> alle übrigen Einrichtungen in eine andere Kategorie einordnen. Hier
> bietet sich entweder ein am Einzelfall orientiertes Schema an oder
> aber eine andere Kategorie. Das am Einzelfall orientierte Schema hat
> den Vorteil, dass Abgrenzungsschwierigkeiten weitgehend vermieden
> werden, allerdings um den Preis eines ausufernden amenity=value.
+1

dann nehmen wir halt education = ...


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

Re: [Talk-de] ÖPNV: from to: das, was vorne dr aufsteht?

2010-03-14 Diskussionsfäden Helder Aguiar




 Für diejenigen, die gerade an der Haltestelle stehen und auf irgendeinem
 Wege (zur Zeit wüsste ich nicht wie, aber das wird sich ja sicher ändern)
 wäre es sicherlich von Vorteil die Wagenbeschilderung mit drin zu haben. 
Der
 from= und to= -Tag sollte aber wirklich nur Start- und Zielhaltestelle
 angeben.

 Ich kann mir denken, dass es dafür ein Tag gibt, oder bald geben wird.

 Mit Gruß

 Hélder
>
>
> Für den ÖPNV wird im Wiki und auch hier in der Liste erwähnt, dass als
> Werte für "from" und "to" dasjenige einzutragen wäre, "was vorn
> draufsteht".
> http://wiki.openstreetmap.org/wiki/DE:%C3%96pnvkarte
>
> Nun ist das, "was vorne draufsteht" (Zielbeschriftung) nicht immer
> identisch mit der Benennung der Zielhaltestelle. Daher würde ich hier
> das Ganze noch einmal präzisieren wollen. Zum Beispiel heißt die
> Zielhaltestelle "München Hauptbahnhof". Auf dem Bus, der dorthin
> fährt, steht als Zielbeschriftung aber nur "München".
>
>
> Gegeben sei so ein Fall, dass der Name der Zielhaltestelle und
> Zielbeschriftung voneinander abweichen. Was soll die Angabe from/to
> bewirken?
>
> 1) Soll from/to dem Benutzer der Karte bei tatsächlicher Benutzung des
> Verkehrsmittels einen Service bieten? Soll er die from/to Angabe mit
> der Zielbeschriftung vergleichen, so dass er in der richtigen
> Fahrtrichtung einsteigt?
>
> 2) Soll from/to den exakten Namen der Zielhaltestelle angeben, wie sie
> in der Relation erfasst ist, damit die Relation "weiß", welches die
> Zielhaltestelle ist?
>
> Falls wirklich das, "was vorne draufsteht", (Fall 1) angegeben werden
> soll: Woher "weiß" die ÖPNV-Relation dann, welches die Zielhaltestelle
> ist? Denn wenn ich es richtig sehe, wurde die Rolle "terminal"
> abgeschafft. "Weiß" die Relation dies anhand der Reihenfolge, in der
> die Haltestellen in der Relation erfasst sind?
>
> Weitere Frage:
> Ist eigentlich im Falle, dass die beiden Fahrtrichtungen durch
> getrennte Routenrelationen erfasst werden, die Angabe der Rolle
> forward/backward bei den beinhalteten ways nicht mehr erforderlich?
> Gilt das auch für die ÖPNV Karte?
>
>
> ___
> 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] Fahrschule

Am Sonntag 14 März 2010 09:38:43 schrieb Chris-Hein Lunkhusen:
> Guenther Meyer schrieb:
> >> Hingegen wäre eine Spezialisierung
> >> (school=Hauptschule/Grundschule/Gymnasium) vollkommen in
> >> Ordnung.
> >
> > und eine fahrschule ist keine spezialisierung?
> 
> Nicht, wenn man unter "Schule" eine Schule im herkömmlichen Sinne
> meint.
> 
> Deine Fahrschule ist hier im Wikipediaartikel zu "Schule"
> übrigens nicht als Schultyp aufgeführt:
> 
> 
> 
in der wikipedia steht viel... ;-)

die berufsschule wird z.B. aufgezaehlt, private lehrinstitute dagegen nicht., 
obwohl diese fuer eine berufsausbildung gleichwertig sind.

in anderen laender gibt es andere schulsysteme, wo die schularten die als 
"schule" bezeichnet werden, wieder andere sind.

hier kann viel viel streiten und diskutieren... :-)

worum es mir im grunde geht:
ich finde, es sollte einfach zusammengepackt werden, was sinngemaess 
zusammengehoert.

beispiel:
highway bedeutet ja eigentlich soviel wie strasse.
trotzdem ordnen wir footways und tracks darunter ein, und keiner beschwert 
sich...

hmm, so gesehen waere es vielleicht noch besser, nicht amenity=school zu 
taggen (der amenity-key ist sowieso ein abladeplatz fuer alles moegliche), 
sondern education=school...



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

Re: [Talk-de] ÖPNV: from to: das, was vorne dr aufsteht?

2010-03-14 Diskussionsfäden Jochen Topf

On Sun, Mar 14, 2010 at 12:12:08PM +0100, Tirkon wrote:
> Für den ÖPNV wird im Wiki und auch hier in der Liste erwähnt, dass als
> Werte für "from" und "to" dasjenige einzutragen wäre, "was vorn
> draufsteht". 
> http://wiki.openstreetmap.org/wiki/DE:%C3%96pnvkarte
> 
> Nun ist das, "was vorne draufsteht" (Zielbeschriftung) nicht immer
> identisch mit der Benennung der Zielhaltestelle. Daher würde ich hier
> das Ganze noch einmal präzisieren wollen. Zum Beispiel heißt die
> Zielhaltestelle "München Hauptbahnhof". Auf dem Bus, der dorthin
> fährt, steht als Zielbeschriftung aber nur "München". 
> 
> 
> Gegeben sei so ein Fall, dass der Name der Zielhaltestelle und
> Zielbeschriftung voneinander abweichen. Was soll die Angabe from/to
> bewirken? 
> 
> 1) Soll from/to dem Benutzer der Karte bei tatsächlicher Benutzung des
> Verkehrsmittels einen Service bieten? Soll er die from/to Angabe mit
> der Zielbeschriftung vergleichen, so dass er in der richtigen
> Fahrtrichtung einsteigt?

Ja

> 2) Soll from/to den exakten Namen der Zielhaltestelle angeben, wie sie
> in der Relation erfasst ist, damit die Relation "weiß", welches die
> Zielhaltestelle ist? 

Nein.

> Falls wirklich das, "was vorne draufsteht", (Fall 1) angegeben werden
> soll: Woher "weiß" die ÖPNV-Relation dann, welches die Zielhaltestelle
> ist? Denn wenn ich es richtig sehe, wurde die Rolle "terminal"
> abgeschafft. "Weiß" die Relation dies anhand der Reihenfolge, in der
> die Haltestellen in der Relation erfasst sind?

Ja.

> Weitere Frage:
> Ist eigentlich im Falle, dass die beiden Fahrtrichtungen durch
> getrennte Routenrelationen erfasst werden, die Angabe der Rolle
> forward/backward bei den beinhalteten ways nicht mehr erforderlich?

Ja.

> Gilt das auch für die ÖPNV Karte? 

Weiss ich nicht.

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.remote.org/jochen/  +49-721-388298


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

Re: [Talk-de] Garminkacheln (war: All in One mit git)

Carsten Schwede schrieb am 14.03.2010 11:55:
> Nein. Bei mir ist das Polygon ja komplett. Was sollte ich da in josm
> mehr sehen?

Ich meinte, du solltest dir mal die OSM-Datei angucken, die aus splitter raus
kommt, damit man entscheiden kann, ob das wirklich ein splitter Problem ist oder
ein mkgmap Problem. Wenn man ein Problem genau einkreisen und mit einem Beispiel
versehen kann, dann findet sich auf der mkgmap Liste eiegtnlcih meist auch recht
schnell jemand, der sich dessen annimmt.

> Toller Vergleich.

Deshalb ja auch der Smiley.
Mir ging es nur darum, dass man aus einem Funktionieren in der Vergangenheit
recht schlecht ein Funktionieren in der Zukunft ableiten kann.

> (OK wenn ich mir alle Gebäude in DE vorstelle, dann kann es eng werden)

Die kleinsten Kacheln hat bei mir splitter bislang in der Region Udine
geliefert, wo genau damit angefangen wurde. Und zum Kippen des einheitlichen
Rasters reicht ja allein ein Problemfall aus.

> Ich dachte wir sprechen von einer Grundlage für Garminkarten? Wer kommt
> hier auf die Idee in einen einzigen "Layer" (=eine unabhängige
> Kartenkachel) alle Elemente der Datenbank abzubilden? Die AllInOne hat
> genau daher mehrere Layer.

Naja, da Mapsource ja nur einen Layer zur Zeit darstellen kann, ist die Idee
nicht ganz so abwegig.

Von der Idee finde ich deinen Ansatz eigentlich gut, und ich habe mich frueher
auch an deinem Raster orientiert. Inzwischen bin ich damit aber wiederholt in
Schwierigkeiten gekommen (z.B. bei SRTM-Daten), so dass ich eine variablerer
Kachelaufteilung bevorzuge.
Da die Kachelgrenzen mindestens potentielle Problemstellen sind, sollte man
bestrebt sein, moeglichst wenige, d.h. also moeglichst gleichmaessig gefuellte,
Kacheln zu haben. Da die Datenlage bei OSM regional aber sehr unterschiedlich
ist, geht das mit einem derartig starren Raster nicht.

Die originalen Garminkarten sind uebrigens nicht rechteckig sondern entlang von
Verwalltungsgrenzen geschnitten. Das ist natuerlich auch nett, nur fuer sowas
fehlen uns bislang noch die passenden Werkzeuge.

Gruss
Torsten

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

[Talk-de] ÖPNV: from to: das, was vorne dr aufsteht?

Für den ÖPNV wird im Wiki und auch hier in der Liste erwähnt, dass als
Werte für "from" und "to" dasjenige einzutragen wäre, "was vorn
draufsteht". 
http://wiki.openstreetmap.org/wiki/DE:%C3%96pnvkarte

Nun ist das, "was vorne draufsteht" (Zielbeschriftung) nicht immer
identisch mit der Benennung der Zielhaltestelle. Daher würde ich hier
das Ganze noch einmal präzisieren wollen. Zum Beispiel heißt die
Zielhaltestelle "München Hauptbahnhof". Auf dem Bus, der dorthin
fährt, steht als Zielbeschriftung aber nur "München". 


Gegeben sei so ein Fall, dass der Name der Zielhaltestelle und
Zielbeschriftung voneinander abweichen. Was soll die Angabe from/to
bewirken? 

1) Soll from/to dem Benutzer der Karte bei tatsächlicher Benutzung des
Verkehrsmittels einen Service bieten? Soll er die from/to Angabe mit
der Zielbeschriftung vergleichen, so dass er in der richtigen
Fahrtrichtung einsteigt?

2) Soll from/to den exakten Namen der Zielhaltestelle angeben, wie sie
in der Relation erfasst ist, damit die Relation "weiß", welches die
Zielhaltestelle ist? 

Falls wirklich das, "was vorne draufsteht", (Fall 1) angegeben werden
soll: Woher "weiß" die ÖPNV-Relation dann, welches die Zielhaltestelle
ist? Denn wenn ich es richtig sehe, wurde die Rolle "terminal"
abgeschafft. "Weiß" die Relation dies anhand der Reihenfolge, in der
die Haltestellen in der Relation erfasst sind?

Weitere Frage:
Ist eigentlich im Falle, dass die beiden Fahrtrichtungen durch
getrennte Routenrelationen erfasst werden, die Angabe der Rolle
forward/backward bei den beinhalteten ways nicht mehr erforderlich?
Gilt das auch für die ÖPNV Karte? 


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

Re: [Talk-de] Fahrschule

Falk Zscheile schrieb am 14.03.2010 11:23:
> Wie ihr seht bin ich mir auch alles andere als sicher, ob man das
> Schema hier wechseln sollte :-)

Ich finde das aktuelle Schema auch arg besch...eiden.

Es ist ja aber nicht gezielt so entworfen worden, sondern es hat sich im Laufe
der Zeit so entwickelt. Rein darwinistisch betrachtet hat sich diese Entwicklung
durchgesetzt, nicht weil das Endergebniss besonders gut ist, sondern weil dieses
Wachstum in die Breite als Entwicklungsprozess den anderen Alternativen
ueberlegen ist: Wenn man jedes Mal ein neues Tag erfindet, schaft man halt keine
Probleme mit den bisherigen Tags.

Nun gibt es ja immer wieder Leute, die einen Schemawechsel fordern (siehe auch
den Thread bzgl. rental, wobei ich den dort vorgeschlagenen Ansatz wesentlich
gelungener finde, weil da ein neues Schema neben den bisherigen Tags
vorgeschlagen wird, und nicht ein bestehendes Tag umgedeutet werden soll).
Wo bleiben aber die Vorschlage, wie so ein Schemawechsel als Prozess laufen
soll? Strukturbedingt koennen wir halt nicht so einfach von einem Tag auf den
anderen das Tagging-Schema umschalten. Und wie gut ein selbstorganisierender
Wechsel klappt, kann man ja am Beispiel path vs cycleway und footway sehen.

Nochmal ein Vergleich mit dem rental-thread:
Wenn man hier jetzt vollgendes vorschlagen wuerde
amenity=education
education=driving
so waere das ein wesentlich gesuenderer Ansatz, da es keine Probelem mit bereits
etablierten Tags geben wuerde. (Allerdings macht bei diesem Vorschlag das
amenity=education keinen Sinn mehr und koennte ganz weggelassen werden.)
Wobei ich persoenlich die Fahrschule eher im business/shop Bereich als in
school/education sehe. Aber das ist eine reine Geschmacksfrage, die nichts mit
einem technisch besser oder schlechter Sein zu tun hat.

Gruss
Torsten

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

Re: [Talk-de] Garminkacheln (war: All in One mit git)

Hi,

Am 14.03.2010 11:41, schrieb Torsten Leistikow:
> Hast du dir die geschnittene Kachel mal als OSM-Datei in JOSM angeschaut? 
> Meine

Nein. Bei mir ist das Polygon ja komplett. Was sollte ich da in josm
mehr sehen?

> Frage zielt darauf, ob der Fehler wirklich beim splitter liegt, oder ob beim
> finalen Schnitt bei mkgmap was schief laeuft. Letztens hatte ich naemlich

Ich selbst habe das Schneiden in mkgmap deshalb abgeschaltet, damit
mkgmap mir da nicht reinfunkt.

> verursacht wurden (Von einem Polygon, dass durch die Kachelgrenze in mehrer
> Teile zerteilt wird, erschien nur einer dieser Teile in der Garminkarte).

Ja davon spreche ich ja, vielleicht ist das ja in meinem Beispiel genau
sowas.

> Und die Interstate-35W-Mississippi-River-Brücke hat 40 Jahre gehalten, ohne 
> dass
> da jemals was passiert waere  :-)

Toller Vergleich.

> Fuer eine einzige Karte sicherlich nicht. Weiter oben im Thread ging es aber 
> mal
> darum, wie man die verschiedenen Kartenstile besser aufeinander abstimmen 
> koennte.

Das ist von den Kartenstilen doch unabhängig, mir geht es darum eine
einheitliche Basis zu haben. Wenn eben so eine Basis auf eine sinnvolle
Kachelgröße, die vorraussichtlich die nächsten 5 Jahre hält getellt
wird, dann wird jetzt ein Schnitt gemacht, und gut ist es. Ich glaube
kaum, daß z.B. eine Halbierung der Kacheln auf 0,5°x1° für so einen
Zeitraum nicht reichen sollte. Selbst wenn wirklich viele Daten
hizukommen. (OK wenn ich mir alle Gebäude in DE vorstelle, dann kann es
eng werden)

> Auch hier greift das Argument wieder nur fuer eine einzige Karte, nicht aber
> fuer einen einheitlichen Aufbau von unterschiedlichen Kartenstilen.

Ich dachte wir sprechen von einer Grundlage für Garminkarten? Wer kommt
hier auf die Idee in einen einzigen "Layer" (=eine unabhängige
Kartenkachel) alle Elemente der Datenbank abzubilden? Die AllInOne hat
genau daher mehrere Layer.


-- 
Viele Grüße
Carsten

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

Re: [Talk-de] Fahrschule

2010-03-14 Diskussionsfäden Nils Heuermann

Am Sun, 14 Mar 2010 11:23:59 +0100 hat Falk Zscheile  
 geschrieben:

> Am 14. März 2010 10:58 schrieb Torsten Leistikow :
>
>> Der entscheidende Punkt ist: Ein Fahrschule ist nicht das, was wir z.Z.  
>> mit
>> amenity=school in OSM meinen.
>
> Die Frage ist doch, ob der status quo wirklich so gut ist, das er es
> Wert ist an ihm festzuhalten, obwohl man mittlerweile erkannt hat, das
> ein hierarchisches Tagging gegenüber dem am Einzelfall orientierten
> Vorteile bringt.
> ...
> Kategoriebildung mit hierarchischem Tagging sollte kein Selbstzweck
> sein, sondern handfeste Vorteile bieten.

Kategorien mit entsprechender Verfeinerung in einem weiteren Tag sind  
natürlich eine vernünftige Sache. Und funktioniert auch bei Schulen. Nur  
finde ich, dass eine Fahrschule und eine Grundschule nun mal etwas  
grundlegend anderes sind.

Daher sollte man amenity=school so belassen wie es ist, damit man ggf.  
Grund-, Realschule etc. ergänzen kann. Und für Gewerbe wie Fahrschulen  
eben was anderes/neues. Da kann man dann gerne alle *-schulen drunter  
zusammenfassen.

Wie wir festgestelt haben, gibt es auch Grenzfälle; da wird man jedoch  
sowieso nicht drumrumkommen. Aber für eindeutige Sachen wie Grundschule  
<-> Fahrschule ist es doch jedem Mapper möglich, zu entscheiden, ob es  
amenity=school oder [noch zu definieren]=driving(_school) ist.

Ich klink mich jetzt mal aus; die an der Diskussion bereits Beteiligten  
wissen ja, dass es diese zwei Sichtweisen für "Schulen" gibt und wir haben  
nun einige Argumente für das eine und andere gebracht. Wir werden uns nur  
weiter im Kreis drehen, wenn immer nur die selben Leute antworten :)

Gruß,
Nils

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

Re: [Talk-de] Garminkacheln (war: All in One mit git)

Carsten Schwede schrieb am 14.03.2010 11:20:
> Nicht innerhalb der Kacheln, sondern am Rand. Welche Konstellation dazu
> führt weiß ich auch nicht, es passiert nicht immer.
> 
> http://openstreetmap.teddynetz.de:81/fehler_splitter.jpg
> http://openstreetmap.teddynetz.de:81/ohnefehler.jpg

Hast du dir die geschnittene Kachel mal als OSM-Datei in JOSM angeschaut? Meine
Frage zielt darauf, ob der Fehler wirklich beim splitter liegt, oder ob beim
finalen Schnitt bei mkgmap was schief laeuft. Letztens hatte ich naemlich
aehnliche Effekte, die allerdings durch die Multipolygonverarbeitung in mkgmap
verursacht wurden (Von einem Polygon, dass durch die Kachelgrenze in mehrer
Teile zerteilt wird, erschien nur einer dieser Teile in der Garminkarte).

> Meine Meinung ist, daß es deshalb sein muß, weil eben genau dann echte
> Lücken entstehen, weil eben keine Zwischenpunkte berechnet werden.

Naja, diese Berechnung ist nun mal nach mkgmap verlagert worden. Ob sie da
besser aufgehoben ist oder nicht, mag ich nicht beurteilen.

> Mein Kachelsystem verwende ich seit 2 Jahren konstant.

Und die Interstate-35W-Mississippi-River-Brücke hat 40 Jahre gehalten, ohne dass
da jemals was passiert waere  :-)

> Und ich denke alle paar Jahre eine solche Änderung, die eben
> einen einmaligen Aufwand erfordert ist nicht wirklich ein Problem.

Fuer eine einzige Karte sicherlich nicht. Weiter oben im Thread ging es aber mal
darum, wie man die verschiedenen Kartenstile besser aufeinander abstimmen 
koennte.

> Es läßt sich ja auch relativ einfach steuern, was in
> der Karte erscheint, und selbst wenn die Daten noch viel dichter werden,
> was davon in den Garminkacheln ankommt ist doch per Style geregelt, also
> selbst wenn jeder Pflasterstein in der Datenbank ist, muß das trotzdem
> nicht heißen, dass die Garminkachel dann ein Problem bekommt. Ich würde
> dann diese eben einfach weglassen, da sie für die Karte im GPS-Gerät
> keine Rolle spielen.

Auch hier greift das Argument wieder nur fuer eine einzige Karte, nicht aber
fuer einen einheitlichen Aufbau von unterschiedlichen Kartenstilen.

Gruss
Torsten

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

Re: [Talk-de] Postgis Datenbank, Größe des Index

2010-03-14 Diskussionsfäden Florian Lohoff

On Sat, Mar 13, 2010 at 11:51:28PM +0100, Stephan Knauss wrote:
> Hallo zusammen,
> 
> mir ist aufgefallen, dass die Datenbank ziemlich viel Platz belegt für 
> einen kleineren extract.
> Habe dann mal genauer hingesehen. Der Index ist ziemlich groß.
> 
> Ist das normal, dass er 4 mal so groß ist wie die eigentlichen Daten?
> VACUUM FULL und REINDEX haben nichts geändert.
> 
> Table statistics planet_osm_ways
> 
> Table Size408 MB
> Toast Table Size  30 MB
> Indexes Size  1635 MB

Sowas habe ich nicht gesehen - das der (speziell fuer die node geometry)
groesser ist als die daten das ist bei mir auch der fall.

Aber das der um ein solches vielfaches groesser ist...

Ich nehme an du hast eine 64bit architektur? Ich habe das bisher
immer nur auf 32bit laufen gehabt - Doppelte int groesse, doppelter
index oder so?

Flo
-- 
Florian Lohoff f...@zz.de
"Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat
im Internet Zensur- und Überwachungsabsichten zu unterstellen."
- - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin 


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

Re: [Talk-de] Neues Proposal für boat_rental

2010-03-14 Diskussionsfäden Dimitri Junker

Hallo,


>Deswegen bietet es sich an amenity=rental und retal=* für reine
>Mietgeschichten zu nutzen. Das rental=* könnte man dann auch noch an
>bestehende Firmen, Shops etc. hängen.


Die Notwendigkeit für das amenity sehe ich nicht, es gibt je nach Branche 
Läden die nur verkaufen(z.B. Einzelhandel), nur verleihen(z.B. 
Autovermietung) oder beides(z.B. Tauchladen) machen. Deshalb würde ich 
vorschlagen diese woe normale Läden zu taggen und zusätzlich ein
rental=yes/no/only 
zu setzen

Dimitri

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

Re: [Talk-de] Fahrschule

Am 14. März 2010 10:58 schrieb Torsten Leistikow :
> Florian Gross schrieb am 14.03.2010 08:00:
>> Was soll denn eine Fahrschule/Tanzschule usw. denn sein, wenn nicht
>> eine Schule? Ein Hot-Dog- Stand?
>
> Der entscheidende Punkt ist: Ein Fahrschule ist nicht das, was wir z.Z. mit
> amenity=school in OSM meinen. Und wenn man sie da jetzt mit drunter packt, 
> dann
> laeuft alle Auswertung, die auf dem heutigen Verstaendniss beruht, in die 
> Irre.

Die Frage ist doch, ob der status quo wirklich so gut ist, das er es
Wert ist an ihm festzuhalten, obwohl man mittlerweile erkannt hat, das
ein hierarchisches Tagging gegenüber dem am Einzelfall orientierten
Vorteile bringt.

Was sind die Vorteile der Kategoriebildung im Allgemeinen?

1. Jemand ohne genaue Sachkenntnis kann schon einmal die grobe
Einordnung vornehmen, die Einteilung in eine Unterkategorie kann dann
jemand mit mehr Sachverstand vornehmen.

2. Man vermeidet eine Unübersichtlichkeit im Bereich von amenity=value.

3. ... ?

Punkt 1 passt in unserem Fall nicht. Jeder ist in der Lage zu sagen ob
er eine Fahrschule, eine "richtige" Schule oder eine Volkshochschule
vor sich hat. Anders ist das bei Hydranten etc. Genau aus diesem Grund
ist im Bereich von amenity=value das am Einzelfall orientierte Tagging
so verbreitet.

Punkt 2 ist eher ein Schönheitsaspekt den man gelten lassen kann, der
aber jedenfalls keinen zwingenden Handlungsbedarf auslöst.
Kategoriebildung mit hierarchischem Tagging sollte kein Selbstzweck
sein, sondern handfeste Vorteile bieten.

Wie ihr seht bin ich mir auch alles andere als sicher, ob man das
Schema hier wechseln sollte :-)

Gruß, Falk

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

Re: [Talk-de] Garminkacheln (war: All in One mit git)

Hi,

Am 14.03.2010 10:55, schrieb Torsten Leistikow:
> Splitter wirft polygone innerhalb der Kacheln komplett weg? Hast du mal ein
> Beispiel dafuer?

Nicht innerhalb der Kacheln, sondern am Rand. Welche Konstellation dazu
führt weiß ich auch nicht, es passiert nicht immer.

http://openstreetmap.teddynetz.de:81/fehler_splitter.jpg
http://openstreetmap.teddynetz.de:81/ohnefehler.jpg

> Meinem Verstaendniss nach uebernimmt splitter in der Standardeinstellung sogar
> mehr, als man eigentlich durch die Kachelgrenzen vorgibt. Die Kachelgrenzen

Das weiss ich, das ist für mich eben meine Aussage, daß die
Grenzelemente verdoppelt werden.

> selber werden mit in der XML-Datei gespeichert und mkgmap uebrnimmt dann das
> genaue Zuschneiden.

mkgmap schneidet normalerweise  exakt an den im xml-File vorgegebenen
Boundary-Grenzen, und zwar rigoros. Die werden allerdings von splitter
offenbar entsprechend großzügig erzeugt.

> Die Groesse dieses ueberstehenden Bereiches kann man per Parameter vorgeben,
> keine Ahnung was passiert, wenn man da auf Null runter geht. Ich vermute mal,
> dass das fuer die Garminkartenerzeugung auch nicht sinnvoll ist, sonst wuerde
> man das ja standardmaessig tun.

Meine Meinung ist, daß es deshalb sein muß, weil eben genau dann echte
Lücken entstehen, weil eben keine Zwischenpunkte berechnet werden.

> Der Ansatz mit der festen Zuordnung von Kacheln hat ein prinzipielles Problem.
> Die maximale Anzahl der Elemente in einer Garminkachel ist naemlich
> offensichtlich begrenzt (auch wenn noch nicht genau verstanden ist, wieviele
> Knoten, Wege und Flaechen maximal moeglich sind). Nun ist die OSM-Datenbank ja

Das weiß im Moment wie es aussieht niemand außer Garmin selbst.

> aber stetig am Wachsen, und ich denke mal, dass man davon ausgehen kann, dass
> das noch eine ganze Weile so bleiben wird. Da ist es dann nur eine Frage der
> Zeit, bis einige der heute festgelegten Kacheln in Zukunft die Maximalgroesse
> ueberschreiten.

Mein Kachelsystem verwende ich seit 2 Jahren konstant.

> Das Problem wird noch dadurch verstaerkt, dass man wohl davon ausgehen kann,
> dass dort, wo die Datendichte schon jetzt am groessten ist, auch in absehbarer
> Zeit das Wachstum am groessten sein wird. Insofern duerfte dein 1° Raster
> langfristig fuer die Garminkarten denkbar ungeeignet sein.

Der Witz ist, daß ich problemlos die Kacheln nochmals unterteilen kann,
wenn es erforderlich wird. Dazu ist nur eine Parameteränderung
notwendig, die dann wieder auf Jahre ein konstantes Nummernsystem
erzeugt. Und ich denke alle paar Jahre eine solche Änderung, die eben
einen einmaligen Aufwand erfordert ist nicht wirklich ein Problem.

Selbst in den Niederlanden oder in DE ist noch kein Problem
diesbezüglich entstanden.  Es scheint auch so, daß es eine Verschiebung
dieser Grenze gegeben hat, vor einiger Zeit gab es nämlich ein solches
Problem kurzfristig, was mit der nächsten mkgmap-Version wieder
verschwunden war. Es läßt sich ja auch relativ einfach steuern, was in
der Karte erscheint, und selbst wenn die Daten noch viel dichter werden,
was davon in den Garminkacheln ankommt ist doch per Style geregelt, also
selbst wenn jeder Pflasterstein in der Datenbank ist, muß das trotzdem
nicht heißen, dass die Garminkachel dann ein Problem bekommt. Ich würde
dann diese eben einfach weglassen, da sie für die Karte im GPS-Gerät
keine Rolle spielen.


-- 
Viele Grüße
Carsten

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

Re: [Talk-de] Fahrschule

Florian Gross schrieb am 14.03.2010 08:00:
> Was soll denn eine Fahrschule/Tanzschule usw. denn sein, wenn nicht
> eine Schule? Ein Hot-Dog- Stand?

Der entscheidende Punkt ist: Ein Fahrschule ist nicht das, was wir z.Z. mit
amenity=school in OSM meinen. Und wenn man sie da jetzt mit drunter packt, dann
laeuft alle Auswertung, die auf dem heutigen Verstaendniss beruht, in die Irre.

Gruss
Torsten

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

Re: [Talk-de] Garminkacheln (war: All in One mit git)

Carsten Schwede schrieb am 14.03.2010 08:31:
> Die Polygone komplett wegzuwerfen finde ich nicht sehr gut. Es ist im
> Moment so, daß dann ganze Wälder weg sind.

Splitter wirft polygone innerhalb der Kacheln komplett weg? Hast du mal ein
Beispiel dafuer?

Ich benutze Splitter nur im Zusammenspiel mit mkgmap, deshalb interessiert es
mich normalerweise nicht, wer von beiden was genau macht. Nur falls es zu
Problemen kommt, schaue ich dann mal genauer hin. Und z.Z. sind mir da keine
Probleme bekannt, wobei ich natuerlich nur die Bereiche beobachte, von denen ich
auch weiss, was ich als Ergebnis erwarte.

Meinem Verstaendniss nach uebernimmt splitter in der Standardeinstellung sogar
mehr, als man eigentlich durch die Kachelgrenzen vorgibt. Die Kachelgrenzen
selber werden mit in der XML-Datei gespeichert und mkgmap uebrnimmt dann das
genaue Zuschneiden.
Die Groesse dieses ueberstehenden Bereiches kann man per Parameter vorgeben,
keine Ahnung was passiert, wenn man da auf Null runter geht. Ich vermute mal,
dass das fuer die Garminkartenerzeugung auch nicht sinnvoll ist, sonst wuerde
man das ja standardmaessig tun.

Nebenbei bemerkt:
Der Ansatz mit der festen Zuordnung von Kacheln hat ein prinzipielles Problem.
Die maximale Anzahl der Elemente in einer Garminkachel ist naemlich
offensichtlich begrenzt (auch wenn noch nicht genau verstanden ist, wieviele
Knoten, Wege und Flaechen maximal moeglich sind). Nun ist die OSM-Datenbank ja
aber stetig am Wachsen, und ich denke mal, dass man davon ausgehen kann, dass
das noch eine ganze Weile so bleiben wird. Da ist es dann nur eine Frage der
Zeit, bis einige der heute festgelegten Kacheln in Zukunft die Maximalgroesse
ueberschreiten.
Das Problem wird noch dadurch verstaerkt, dass man wohl davon ausgehen kann,
dass dort, wo die Datendichte schon jetzt am groessten ist, auch in absehbarer
Zeit das Wachstum am groessten sein wird. Insofern duerfte dein 1° Raster
langfristig fuer die Garminkarten denkbar ungeeignet sein.

Gruss
Torsten

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

Re: [Talk-de] Neues Proposal für boat_rental

2010-03-14 Diskussionsfäden Frederik Ramm

Hallo,

inhaltlich d'accord, aber stilistisch...

Mirko Küster wrote:
> ... Krücke ...
> ... Mist ...
> ... unerträglich ...
> ... Mist ...
> ... kann es langsam nicht mehr lesen ...

Wenn das Deine ganz normale Ausdrucksweise ist, will ich Dich lieber 
nicht erleben, wenn Du mal sauer bist.

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

Re: [Talk-de] Garmin Europa:all in one karte auf eTrex

2010-03-14 Diskussionsfäden Ulf Lamping

Am 13.03.2010 13:00, schrieb Lars Schimmer:
> On 13.03.2010 11:06, Torsten Leistikow wrote:
>> Lars Schimmer schrieb am 13.03.2010 10:52:
>>> IMHO ist der eTrex zu blöde, in den
>>> Zoomstufen 2km, 5km,... die unwichtigen Daten auszufiltern.
>>
>> Da wuerde ich dem Etrex keine Schuld geben.
>>
>> Zum einen kann der Bediener bei den Garmin Geraeten irgendwo in den
>> Einstellungen den Detaillevel zu veraendern, womit genau diesem Problem 
>> begegnet
>> werden kann.
>
> Schon, aber die filtert nicht das raus, was für Autos unwichtig ist ;-)
> Und selbst in der "weniger" Einstellung sind es noch zuviel.

Du erkennst schon die Ironie?

Eine Karte zu nehmen die sich selbst "alles in einer" nennt, und sich 
dann zu wundern: "da ist aber zuviel drauf" ;-)

Gruß, ULFL

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

Re: [Talk-de] Fahrschule