Re: [Talk-de] Live-Map ÖPNV für Ulm/Neu-Ulm

2016-08-27 Diskussionsfäden Alexander Matheisen
Am Samstag, den 27.08.2016, 16:09 +0200 schrieb
> Gibt es überhaupt noch derartige Live-Maps in anderen dt. Gemeinden /
> für andere Verkehrsverbünde?  Oder hat man sich mit dem Verweis auf
> Bedrohungslagen und der Behauptung, das verunsichere Teile der
> Bevölkerung, davon generell im OSM-Univerum distanziert?

Kennst du TRAVIC (http://tracker.geops.ch/?z=6=1=1242914.2612=663
2341.6975=transport)? Dargestellt werden die Soll-Positionen auf
Basis der Fahrplandaten. In Deutschland ist die Abdeckung relativ hoch,
praktisch alles, was in der DB-Auskunft erscheint, wird auch auf der
Karte dargestellt. Live-Daten gibt es aktuell leider nur in einigen
Regionen außerhalb Deutschlands.


Gruß
Alex

signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Eisenbahn-Sprint(er) am Samstag, dem 13.2. u.A. in Frankfurt

2016-02-03 Diskussionsfäden Alexander Matheisen
Am Donnerstag, den 04.02.2016, 01:19 +0100 schrieb Hakuch:
> 
> On 03.02.2016 12:46, Stefan Kaufmann wrote:
> > Die Bahn ist so freundlich, ihren Teil dazu
> > beizutragen und stellt dafuer ab dem Mittag im Bahnhof einen Raum
> > mit
> > Internet zur Verfuegung, 
> 
> und so freundlich, tickets auszugeben oder zu vergünstigen?

Das wollte ich auch schon fragen, schließlich wurde von Vertretern der
DB neulich etwas in dieser Richtung hier angekündigt: https://lists.ope
nstreetmap.org/pipermail/talk-de/2015-December/112295.html

Es wäre natürlich schön, wenn die DB finanziell beitragen würde, aber
ich persönlich werde in jedem Fall nach Frankfurt kommen, auch wenn es
keine vergünstigten Tickets für uns gäbe. Dank Semesterticket kann ich
einen Teil der Strecke ohnehin kostenlos fahren.


Gruß
Alex

signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


[OSM-talk] OpenLinkMap will be shut down

2016-01-11 Diskussionsfäden Alexander Matheisen
Hi everybody,

some of you may know and use the project OpenLinkMap. For those who do
not know it, just have a look at the wiki page 
http://wiki.openstreetmap.org/wiki/OpenLinkMap or try it at 
http://www.openlinkmap.org/.

Now the bad news: On January 27, the project will be shut down. Due to
technical reasons I disabled the data update some days ago, but the
website will be accessible until January 27. There are the following
reasons for my decision to stop the project:

My focus switched to my other project OpenRailwayMap, so I have not
enough time any more to develop the OpenLinkMap. The design is not up
to date, the website is not responsive and the code is not very
elegant, but I have not time to correct all the design mistakes.

The final decision to stop the project right now was the situation that
the domain expires on January 27. For a while I had the plan to stop
the project in the feature, but now I do not want to spend money again
to renew the domain for one or two years.

The source code can be found in a repository on Github: 
https://github.com/rurseekatze/OpenLinkMap. You are free to take the
code and continue the project on your own server. The domain
openlinkmap.org will be available again soon, and there is no problem
for me if someone would like to register it to continue the project
under this name.

I hope that you understand my decision. It is just a hobby project
which takes a lot of my spare time and is mainly paid by my own money.

Users who currently embed OpenLinkMap into their own websites using
iframes should consider to remove that code from their websites.

Thanks to all the people who supported this project by donations, code
or their feedback!


Regards
Alex

signature.asc
Description: This is a digitally signed message part
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


[Talk-de] OpenLinkMap wird eingestellt

2016-01-11 Diskussionsfäden Alexander Matheisen
Hallo zusammen,

vielen dürfte das Projekt OpenLinkMap gut vertraut sein. Wer es nicht
kennt: Einfach mal im Wiki unter 
http://wiki.openstreetmap.org/wiki/DE:OpenLinkMap nachlesen oder unter 
http://www.openlinkmap.org/ die Seite ausprobieren.

Nun die schlechte Nachricht: Am 27. Januar wird das Projekt eingestellt
. Aus technischen Gründen werden die Daten bereits seit einigen Tagen
nicht mehr aktualisiert, die Webseite bleibt aber bis zum 27.01.
erreichbar. Die Einstellung des Projekts hat folgende Gründe:

Da mein Fokus mittlerweile auf der OpenRailwayMap liegt, fehlt mir die
Zeit für eine Weiterentwicklung der OpenLinkMap. Das Design der
Webseite ist mittlerweile nicht mehr ganz zeitgemäß, die Webseite ist
nicht für mobile Geräte angepasst und der Code enthält auch so manche
"Jugendsünden", die ich heute anders lösen würde, aber für deren
Überarbeitung mir schlicht Zeit und Lust fehlen.

Des weiteren entlastet die Einstellung der OpenLinkMap meinen Server,
auf dem auch parallel die OpenRailwayMap gehostet wird.

Der entscheidende Auslöser, das Projekt genau jetzt einzustellen, war
das Auslaufen der Domain am 27. Januar. Da ich schon länger geplant
hatte, das Projekt langsam auslaufen zu lassen, will ich nun nicht
nochmal Geld in eine Verlängerung für ein oder zwei weitere Jahre
stecken.

Das Projekt kann gerne von einer anderen Person auf einem eigenen
Server weiterbetrieben werden. Der gesamte Quellcode findet sich in
einem Github-Repository: https://github.com/rurseekatze/OpenLinkMap. Da
die Domain openlinkmap.org ja demnächst frei wird, kann gerne jemand
anderes sie registrieren, falls derjenige das Projekt unter diesem
Namen weiterführen will.

Ich hoffe, meine Entscheidung ist nachvollziehbar, schließlich handelt
es sich nur um ein Hobbyprojekt, das die leider begrenzte Freizeit in
Anspruch nimmt und zum Großteil aus eigener Tasche bezahlt wird.

Nutzer, die momentan die OpenLinkMap per iframe in eine andere Webseite
einbinden, sollten daran denken, ihre Webseiten entsprechend
anzupassen.

Ich danke allen, die in der Vergangenheit das Projekt durch Spenden,
Codebeiträge oder Feedback unterstützt haben!


Gruß
Alex

signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Feedback zum Vorschlag einer möglichen Mappingaktion zu Aufzuggeodaten?

2015-12-09 Diskussionsfäden Alexander Matheisen
Hallo,

Am Mittwoch, den 09.12.2015, 21:38 +0100 schrieb Michael Reichert:
> Hallo Axel, hallo Sven,
> 
> Am 2015-12-08 um 18:16 schrieb Sven Anders:
> > > Die erste naheliegendste Idee war, einer neutralen Instanz ein
> > > Kontingent Netzkarten o.ä. zu spenden. Ganz ohne erwartete
> > > Gegenleistung, aber natürlich in der Hoffnung, dass die Karten
> > > auch
> > > für die Erhebung der Aufzugskoordinaten genutzt werden. Nach
> > > welchen
> > > Kriterien die Karten vergeben würden, wäre euch überlassen, da
> > > wollen
> > > wir keine Auflagen machen. Deswegen wäre mir auch sehr wichtig,
> > > dass
> > > der Spendenempfänger bzw. die Vergabestelle so unbefangen und
> > > neutral
> > > wie nur irgendwie möglich ist. Dieser Ansatz würde zwar die
> > > Fahrtkostenproblematik für umfangreichere Bahn-Mappingaktionen
> > > entschärfen. Aber wahrscheinlich haben diese Mapper bereits sowie
> > > eine Bahncard. Ich bin mir auch nicht sicher, ob das ein
> > > tragfähiger
> > > Vorschlag ist. Einerseits könnte ich mir vorstellen, dass das zu
> > > Streitigkeiten führt, wenn sich Leute bei der Vergabe übergangen
> > > fühlen. Andererseits liegt auf den Empfänger/innen der Karten im
> > > ungünstigsten Fall ein ganz schöner Erwartungsdruck, innerhalb
> > > der
> > > Geltungsdauer auch möglichst viel zu mappen, auch wenn wir diesen
> > > nicht erzeugen wollen. Egal, ob der Druck dann von außen kommt
> > > oder
> > > sich selber auferlegt wird, unter Umständen kann das trotzdem
> > > belastend sein.
> > 
> > Ich teile da Deine/Eure bedenken. Wobei wenn Ihr das konkrete
> > Gegenleistungen koppelt (also sowas wie: Wer 5 Aufzüge mit
> > Koordinaten einträgt, bekommt einen 5 Euro Gutschein, bei 20 gibt
> > es
> > eine Freifahrt für Deutschland etc. wäre es wieder transparent und
> > für mich okay.)
> 
> Ich persönlich würde mich, obwohl ich recht viel Bahnsachen mappe,
> mit
> einer BahnCard 100 für drei Monate unter Druck gesetzt fühlen und
> wahrscheinlich von einer Bewerbung für eine solche absehen. Wenn man
> soetwas machen will, sollte es eher ein Google-Summer-of-Code
> -Äquivalent
> zur Datenerfassung sein, d.h. die DB spendiert Deutschlandpässe [3],
> mit
> denen die Mapper dann Strecken und Bahnhöfe abfahren können. (Auf
> eigene
> Kosten habe ich das diesen Sommer mit Alexander Matheisen zusammen
> gemacht)

bis auf wenige Ausnahmen betreiben Mapper ihre Arbeit als Hobby in
ihrer Freizeit neben Beruf, Studium, Ausbildung, etc. Kaum ein Mapper
wird also über einen längeren Zeitraum am Stück intensiver herumfahren
und mappen können. Wenn man als Beispiel eine BahnCard für drei Monate
nimmt, so wird also kaum ein Mapper die Zeit haben, die auch wirklich
auszunutzen, sich aber gleichzeitig in gewisser Weise der DB
verpflichtet fühlen.

Freikarten über kürzere Zeiträume bis 4 Wochen (also z.B.
Deutschlandpass bis hin zu Wochen(end)tickets) sehe ich da als
sinnvoller an.

Kürzere Gültigkeitszeiträume dürften nach meiner Einschätzung eher zu
effektivem Mapping mit bestimmten Zielvorgaben verleiten. Bei zu langen
Zeiträumen kann es passieren, dass sich ein Mapper entweder zu viel
vornimmt oder aber schon nach kurzer Zeit nicht mehr weitermacht und
unnvollständige Ergebnisse hinterlässt. Aktionen wie Mapping Partys
oder Wochenaufgaben mit einem definierten Zeitraum und Aufgabenumfang
dürften effektiver sein.

> > > Die zweite Idee war, ein ganz allgemeines Kontingent an
> > > Freikarten
> > > bzw. Gutscheinen bereitzustellen, das dann auch einer viel
> > > breiteren
> > > Basis an Mapper/innen zugute kommen kann, auch über das
> > > Bahnmapping
> > > hinaus. Zum Beispiel für Fahrten zu OSM-Treffen, zu Konferenzen,
> > > zu
> > > Developertreffen, Hackathons usw. So wäre die OSM-Community
> > > insgesamt
> > > etwas breiter gefördert.
> > 
> > Das fände ich wesentlich besser. 
> 
> Kleinere Einzelleistungen wären IMHO sinnvoller. Ladet doch, wenn es
> (ich habe es nicht genauer untersucht) Regionen mit schlechten
> Aufzugdaten gibt, dort zu einer Mappingparty ein. DB Station &
> Service
> dürfte bestimmt irgendwo ein Raum haben, den man als Basislager
> nutzen
> könnte. Von dort aus können dann die Mapper losfahren und mit
> Verbunds-
> oder Ländertickets die Stationen abklappern und die Daten einsammeln.
> Aufzugsmapping lässt sich i.d.R. gut mit Bahnsteigmapping (auf der
> Mentzschen Detaillierungstufe oder auch noch detaillierter)

Wie schon erwähnt betreiben die meisten Mapper ihre Mitarbeit bei OSM
als Hobby

Re: [Talk-de] tracer2 NRW-Atlas - ALK umgezogen

2015-06-03 Diskussionsfäden Alexander Matheisen
On Di, 2015-06-02 at 20:56 +0200, Johannes wrote:
 Was ist jetzt im tracer2 Plugin einzutragen?
 
 Wenn ich den alten Wert
 wms:http://www.wms.nrw.de/geobasis/wms_nw_alk_vektor?FORMAT=image/pngVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLAYERS=nw_alk_vektor_gebaeudeSTYLES=SRS={proj}WIDTH={width}HEIGHT={height}BBOX={bbox}
 
 den URL-Teil durch
 http://www.wms.nrw.de/geobasis/wms_nw_alkis
 ersetze, funktioniert das tracer2 Plugin nicht mehr. Liegt vermutlich
 daran dass, das ganze anders aussieht.

du musst auch noch die Layer anpassen, sonst funktioniert das natürlich
nicht. Schau mal unter
https://josm.openstreetmap.de/wiki/Maps/Germany#NRW-Atlas:ALKIS, da
findest du die vollständige URL.

Übrigens kannst du den ALKIS-Layer auch ganz komfortabel über die
JOSM-Einstellungen hinzufügen, schließlich wurde der neue Layer ja schon
in der oben verlinkten Konfiguration eingetragen.


Gruß
Alex


signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] tracer2 NRW-Atlas - ALK umgezogen

2015-06-01 Diskussionsfäden Alexander Matheisen
On Di, 2015-06-02 at 00:14 +0200, Michael Reichert wrote:
 Hallo Florian,
 
 Am 2015-06-01 um 15:02 schrieb Florian Lohoff:
  On Mon, Jun 01, 2015 at 11:06:42AM +0200, Florian Lohoff wrote:
  wie es scheint sind am 1.6 die URLs des NRW-Atlas e.g. ALK umgezogen
  dadurch funktioniert vermutlich der tracer2 auch nicht mehr. Das dingen
  sieht auch anders aus (Beschriftungen etc)
 
  Nur falls jemand sich wundert und hier nachfragt ;)
  
  Im RSS feed findet man auch eine Ankündigung - So auf der Webseite
  nicht:
  
  http://www.wms.nrw.de/rssfeeds/content/geobasis/html/030.html
 
 Danke, dass du uns das mitteilst. Ich habe
 https://josm.openstreetmap.de/wiki/Maps/Germany
 angepasst, sodass in JOSM in wenigen Minuten (Liste ggf. neuladen, wird
 nämlich gecacht) der neue WMS angeboten wird.

ich habe gerade auch noch https://wiki.openstreetmap.org/wiki/NRW-Atlas
angepasst.


Gruß
Alex


signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland

2015-04-21 Diskussionsfäden Alexander Matheisen
Hallo,

On Di, 2015-04-21 at 17:16 +0200, Frederik Ramm wrote:
 Hallo,
 
schade, dass diese Diskussion von allen Seiten ein bisschen überhitzt
 geführt wird.
 
 Ich finde, dass solche grossflächigen Edits - ob mechanisch oder nicht -
 mit sehr grosser Sorgfalt angegangen werden sollten. Dazu zählt, dass
 man sich gut überlegt, was man machen will, aber auch, dass man mit
 Einwänden vernünftig umgeht.

die Änderungen wurden detailliert geplant und dokumentiert:
http://forum.openstreetmap.org/viewtopic.php?id=30676

Die Einwände von fly bezogen sich allerdings nicht auf die geplanten
Änderungen, sondern auf das Taggingschema allgemein. Fly hat die
Diskussion um den mechanischen Edit zum Anlass genommen, viele
grundsätzliche Dinge des Taggingschemas in Frage zu stellen.

 Von vorn herein nur im Forum zu posten und auf Nachfrage zu erklären,
 die Mailingliste sei ja eh am Sterben, ist asking for trouble - einen
 breiten Konsens erreicht man nicht, indem man die (nach eigenem Befinden
 kleinere) Hälfte der Community ignoriert.

Das ist zugegebenermaßen nicht gut gelaufen. Ich selbst hätte es auch
auf der Mailingliste gepostet. Die Begründung, dass die Mailingliste am
Sterben sei, finde ich auch nicht wirklich passend.

 Ausserdem sehe ich hier eine gefährliche Tendenz von das ist
 OpenRailwayMap-Sache, wir haben uns das überlegt, und warum sollten wir
 auf jemanden hören, der nicht mal zu uns gehört. Folgerichtig hat
 Michael (Nakaner) seine Aktion auch nicht zur Diskussion gestellt
 (denn er war sich ja schon sicher, dass er alles richtig macht und sich
 nicht reinreden lassen wird), sondern nur angekündigt.

Die geplanten Änderungen wurden ausgiebig auf unseren Treffen diskutiert
(zu denen auf diversen Kanälen eingeladen wurde, aber kaum jemand
gekommen ist). Nach den Treffen wurden diese Änderungsvorschläge auch
nochmal auf der ORM-Mailingliste, im Forum und auf ein paar anderen
Kanälen bekanntgegeben, ohne dass noch irgendwelche Einwände kamen.
Deshalb darf man ja spätestens dann davon ausgehen, dass niemand mehr
einen Einwand hat.
Dazu sind die Änderungen wie bereits beschrieben sehr unspektakulär, da
nur Fehler aus der Anfangszeit des Schemas behoben wurden. Es ändert
sich ja praktisch nichts durch den Edit.

Warum sollten wir also plötzlich ein funktionierendes Taggingschema auf
den Kopf stellen, weil ein einziger Mapper Kritik übt, aber selbst keine
brauchbaren Verbesserungen aufzeigen kann?

 Es ist etwas ungeschickt, dass fly selbst nicht auf der
 OpenRailwayMap-Mailingliste ist und sich zugleich gern an der weiteren
 Diskussion bezüglich Tagging von Eisenbahnanlagen beteiligen will. Wäre
 er auf dieser Liste gewesen, hätte er vermutlich im Vorfeld an der
 Diskussion teilnehmen können, statt Verbesserungsvorschläge erst
 einzubringen, als der Edit angekündigt wurde.

Nicht nur das. Was ich fly vorwerfe ist, dass es jetzt auf einmal
anfängt, nicht nur Details, sondern grundsätzliche Dinge eines
Taggingschemas in Frage zu stellen, das seit Jahren etabliert und in
breiter Verwendung ist.

Vor allem hat seine Kritik überhaupt nichts mit dem eigentlichen Edit zu
tun:

* Erfassung von Signalen mit railway:signal:direction=* und
railway:signal:position=* ist kaputt
* Tags sind zu lang
* Signaltypen sollten nicht abgekürzt, sondern ausgeschrieben werden
* die Signalvorschriften sind zu kompliziert

Wenn jemand begründete Einwände hat, bin ich gerne bereit, mir diese
Kritik anzuhören und gegebenenfalls das Tagging zu verbessern.
Voraussetzung dafür ist jedoch, dass derjenige konstruktive Vorschläge
hat, wie es seiner Meinung besser gemacht werden könnte.

 (Dann wieder - OpenRailwayMap ist eine private Mailingliste auf einer 
 privaten Domain,
 wo der private Betreiber jeden rauswerfen kann, der ihm nicht passt -
 insofern stellt sich die Frage, ob eine Meinungsbildung auf der
 OpenRailwayMap-Liste für OSM überhaupt eine Bedeutung haben sollte.)

Auf sämtlichen anderen offiziellen Mailinglisten kann man doch auch
jederzeit rausgeworfen werden?!

 Ich habe jetzt keine Lust, die hier diskutierten Edits zu reverten, aber
 ich erwarte künftig vom OpenRailwayMap-Team, dass sie den Rest des
 Projekts nicht wie Idioten behandeln, die ja eh nichts zu sagen haben,
 sondern dass man sie und ihre Bedenken ernst nimmt. Dazu zählt, dass man
 seine Edits nicht bloss ankündigt, sondern tatsächlich innerlich zu
 Kompromissen bereit ist, und dazu zählt auch, dass man auf talk-de nicht
 bloss auftaucht, um Leuten mitzuteilen, dass man mit ihnen jetzt nicht
 mehr spricht.

Wir haben niemanden wie Idioten behandelt, allerdings sollte man Kritik
auch zurückweisen dürfen.


Gruß
Alex


signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland

2015-04-17 Diskussionsfäden Alexander Matheisen
On Fr, 2015-04-17 at 15:58 +0200, fly wrote:
 Wenn schon so viele Objekte angefasst werden, können wir doch vorher uns
 auf geschicktes Tagging verständigen und ich sehe dieses Vorgehen immer
 noch als mechanischen Edit.
 
 z.B. könnten wir auch das völlig kaputte System um
 railway:signal:direction und railway:signal:position verbessern und dann
 alles auf einmal korrigieren.

Du bezeichnest das etablierte Tagging als völlig kaputt, hast aber
selbst bislang auch kein besseres Konzept vorgestellt. Zwar hast du
immer mal wieder direction=* oder Relationen ins Spiel gebracht, aber
mehr als vage Ideen waren das nicht. Erstelle doch mal eine Wikiseite,
auf der du deine Ideen detailliert beschreibst, mit ein paar
Taggingbeispielen anreicherst und dir Gedanken über die
Praxistauglichkeit machst. Danach können wir weiter reden...

 Am meisten kotzt mich hier die Art und Weise des Vorgehens und die
 mangelnde Bereitschaft sich auf eine konstruktive Diskussion
 einzulassen, an.

Da stimme ich dir zu. Von deiner Seite fehlen mir bislang konstruktive
und durchdachte Vorschläge.

 Wie es scheint fehlen hier ein paar grundsätzlichen Verständnisse einer
 Gemeinschaft und ich müss jetzt halt doch die DWG einschalten. Habe ich
 bisher fast immer erfolgreich vermeiden können.

Und was willst du der DWG sagen? Dass die Leute von der OpenRailwayMap
ihr Taggingschema nicht nach deinen Vorstellungen ändern wollen? Und was
soll die DWG dann dazu sagen?


Gruß
Alex,
der nun ebenfalls keine Lust mehr auf diese Diskussion hat


signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland

2015-04-15 Diskussionsfäden Alexander Matheisen
On Di, 2015-04-14 at 22:34 +0200, fly wrote:
 Am 14.04.2015 um 21:13 schrieb Michael Reichert:
  Am 2015-04-14 um 19:43 schrieb fly:
  Am 09.04.2015 um 08:25 schrieb Rolf Eike Beer:
  Wenn ich das mit dem Tagging vergleiche, bei dem mir auch regelmäßig 
  namespace-Tags begegnen, dann ist es doch leicht anders:
 
  emergency=fire_hydrant
  fire_hydrant:type=underground
 
  railway=signal
  railway:signal:...
 
  railway:signal:main:state:forward=*
  
  Lass mich raten, das Signal stammt von rayquaza und ist – für
  OpenRailwayMap-Verhältnisse – schon ewig gemappt?
 
 Nein, nur meiner Logik entsprungen.

du denkst dir ein Tag selbst aus und kritisierst dann, dass es zu lang
sei, oder wie soll ich das jetzt verstehen?

  Das sind Versuche,
  Signale zu mappen, die für verschiedene Richtungen gelten und am selben
  Mast hängen. Es hat sich nie durchgesetzt (das
  railway:signal:TYP:state:forward/backward=* werten wir nicht aus und
  wird auch nicht ausgewertet werden), wir mappen stattdessen zwei kurz
  nacheinander folgende Nodes auf dem Gleis, einer für die eine Richtung,
  der andere für die andere Richtung.
 
 Habe ich das im Wiki überlesen ?
 Welche Gründe sprechen denn dafür ?

Das Tagging so zu gestalten, dass Signale an einem Mast für verschiedene
Richtungen eingetragen werden können, würde die Tags noch komplizierter
machen. Da es nur wenige Signale gibt, wo das vorkommt, haben wir uns
entschieden, in diesen Fällen zwei Nodes zu taggen und dafür insgesamt
kürzere Tags zu schaffen. Das ist doch in deinem Sinne, oder?

 Mapped Ihr dann auch noch den Masten ?
 
 Finde ich inkonsistent und jede Ausnahme/Sonderregel macht es eher
 komplizierter.

Ich finde es deutlich komplizierter, als zwei Nodes zu mappen.

 Warum nicht gleich eine type=node Relation oder ähnliches, dann ist auch
 die Verknüpfung mit der eigentlichen Position (Masten) möglich und wir
 können jedes Signal einzeln eintragen.

Das Thema Signalrelationen haben wir in der Vergangenheit schon öfter
auf diversen Kanälen diskutiert und sowohl für Mapper als auch die
Auswerter für nicht praktikabel befunden. Deshalb habe ich keine Lust,
dieses Thema hier wieder neu auszudiskutieren, nur weil du jetzt
plötzlich meinst, das Taggingschema der Signale in Frage zu stellen.

  Wenn möglich sollte doch der ein oder andere Tag auch mit weniger
  Pre-/Postfixen auskommen (siehe auch :lanes-Tagging).
 
  state:main:forward=*
 
  bzw wenn möglich sogar nur
 
  state=*
  height[:TYPE][:DIRECTION]
  Eindeutig ist das ganze doch schon durch railway=signal
 
  Das macht die Zuordnung interessiert mich der key für den Benutzer 
  etwas 
  einfacher, aber andere Dinge wir ref fallen da trotzdem aus der 
  Reihe[1]. 
 
  Welche Benutzer*innen meinst Du ?
 
  Bei Vorlagen ist es erstmal egal aber aufgelistet füllen solche langen
  Schlüssel schon eine Menge Platz aus und die wichtige Information steht
  am Ende.
 
  Ich sehe nicht, dass der Verzicht auf railway: bei den key-Namen eine 
  große 
  Verwirrung stiften würde, da der Rest der Keys, zumindest so weit ich das 
  überblicken kann, zu Kollisionen mit anderen Taggings führen würde.
 
  Wolltest wohl zu keinen Kollisionen schreiben
 
  Kann mir auch nicht richtig Probleme vorstellen in Bezug auf railway=signal
  
  An einem Hauptsignalmasten hängen oft (Signaltyp laut Taggingschema in
  eckigen Klammern):
  - ein Vorsignal (v.a. in Bahnhöfen und auf stark befahrenen Strecken)
[distant]
  - ein Geschwindigkeitsanzeiger [speed] und/oder
Geschwindigkeitsvoranzeiger [speed_limit]
  - ein Gegengleisanzeiger (bei Ausfahrsignalen) [wrong_road]
  - ein Richtungsvoranzeiger [route_distant] und/oder Richtungsanzeiger
[route](bei Streckenverzweigungen und mancherorts auch bei
Gleiswechseln)
  - eine Haltetafel [stop] (die mit dem H)
  - Ein Hauptsignal hat oft auch noch die Funktion eines Rangiersignals
[minor].
 
 Was war denn jetzt an meinen Vorschlägen jetzt falsch ?
 
 state:main:forward=* resp. state:main=*
 height[:TYPE][:DIRECTION] resp. height[:TYPE]
 
 Warum reicht nicht state=* wenn es sich nur um ein Hauptsignal dreht ?
 (railway:signal:main:state=*)

Wie soll man denn so etwas auswerten? Oder JOSM-Vorlagen für so ein
Tagging erstellen? Denke erstmal etwas über deine Vorschläge nach, bevor
du solchen Unsinn schreibst.

  Lektüreempfehlung:
  http://fahrweg.dbnetze.com/file/fahrweg-de/2397820/nwGeHFo3ET6OL80ylv-JlU0vWcI/8332992/data/rw_301_aktualisierung_8.pdf
  :-) Ein gleichzeitiger Aufenthalt auf einem Bahnhof ist empfehlenswert
  für Nicht-Bahnaffine.
 
 Nein danke, wenn die Zeit reicht, mache ich mal einige Fotos und
 versuche dann mein Glück
 
 Solch ein Regelwerk ist nicht zumutbar und sollte übersetzt werden, Lese
 ja auch nicht die gesamte STVO um eine Ampel bzw Verkehrsschild einzutragen.

Wenn du ein wenig im Internet recherchieren würdest, würdest du recht
schnell auf einfachere Erklärungen stoßen. Wikipedia ist ein guter
Anfang, ebenso die auf den ORM-Wikiseiten bei jedem 

Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland

2015-04-07 Diskussionsfäden Alexander Matheisen
Hallo,

On Di, 2015-04-07 at 15:09 +0200, fly wrote:
 Grundsätzlich spricht nichts gegen eine Anpassung, allerdings sollten
 solche Änderungen möglichst breit diskutiert werden und dann bringt es
 nichts wenn der Autor hier nicht einmal persönlich einen Link
 veröffentlicht und dann auch mitdiskutiert !

ich nehme an, dass Nakaner das schlicht vergessen hat.

 * Wie sieht das denn im Ausland aus ? Wurde auch über den Tellerrand
 (Europa) hinausgeschaut ?

Andere Länder sind nicht betroffen (Ausnahme: Österreich), da es anfangs
nur ein Taggingschema für Deutschland gab. Somit gibt es im Ausland im
Grunde keine Signale, da ja bisher ein Taggingschema dafür fehlte.

Beim Entwurf des Schemas für Österreich wurde das Problem der fehlenden
Eindeutigkeit erkannt und von Anfang an das Länderkürzel AT: verwendet.
Da wir ja mittlerweile ein Länder-Betreiber-Präfix verwenden, ist das
auch nicht mehr ganz korrekt. Da es aber nicht viele Signale mit dem
alten Schema gibt und ein Großteil davon auch von mir erfasst wurden,
sehe ich hier erstmal keinen Bedarf für größere Umtagaktionen. 

Das Taggingschema für die Schweiz, das vor wenigen Tagen fertiggestellt
wurde, verwendet von Anfang an das neue Länder-Betreiber-Präfix.

 * Können wir kein internationales Schema entwickeln und nur
 länderspezifische Signale mit LC erweitern.

Alle Signale sind länderspezifisch!

Das Taggingschema ist ja schon weitgehend international ausgelegt,
sodass die Art und Bedeutung des Signals mit einem generischen Schema
abgebildet wird. Nur muss eben trotzdem bei jedem Signal der konkrete
länderspezifische Typ mitgetaggt werden, weil sonst wichtige
Informationen fehlen.

 * Warum werden den die Werte als Abkürzungen definiert ? Was spricht
 gegen zB Hauptsignal statt hp ?

Es handelt sich dabei um offizielle Abkürzungen, die durch das
Signalbuch festgelegt sind (so wie die Verkehrszeichen in der StVO).
Unter Eisenbahnern sind diese Abkürzungen auch gebräuchlicher als die
Langnamen.

Ausgeschriebene Bezeichnungen werden z.B. bei den österreichischen
Signalen verwendet, da dort die Signale keine offiziellen Abkürzungen
tragen.

 * Wie wäre es mit operator=* anstatt der Präfixe der Werte ?

Das ist nicht praktikabel. Um etwa auf einer Karte das richtige
Signalicon zu zeichnen, müsste man nämlich die externe Information
haben, welche Signale und welches Regelwerk bei einem bestimmten
Betreiber verwendet werden. Außerdem können an einem Signalmast auch
Signale verschiedener Signalordnungen hängen.

 Die Beispiele am Ende hängen in der Luft und genau die Unterschiede sind
 nicht herausgearbeitet, da nur jeweils ein Beispiel für jeden Haupttag
 vorhanden ist. Noch sind die Tags railway:signal:main=*,
 railway:signal:combined=*, railway:signal:*:states=* und was da noch so
 herumschwirrt gut dokumentiert. Das Hauptsignal und das stillgelegte
 Signal verwenden exakt das gleiche Bild !

Es könnten definitiv noch ein paar mehr Beispiele auf der Seite stehen.
Mit der Zeit werden sicherlich auch noch einige dazukommen.

Ansonsten verstehe ich nicht so genau, was du eigentlich kritisierst...

 Gibt es Proposals ?

Nein.

 Insgesamt ist die Situation eher unbefriedigend, da es sich hier wohl
 eher um einen kleineren Kreis von Profis handelt und interessierte Laien
 schon Probleme bekommen.

Mit der Verwendung der JOSM-Vorlagen kann man sich das Eintragen der
Signale schonmal deutlich vereinfachen. Etwas Bahnwissen gehört aber
dennoch dazu, das gebe ich zu. Das hebt zwar die Einstiegshürde und
schreckt die große Masse ab, sichert aber auch eine gewisse Qualität der
Daten.

 Auch wird, nach wie vor, an forward/backward und left/right an Punkten
 festgehalten, was so von keinem einzigen Editor unterstützt wird.

Das ist momentan eben die beste Möglichkeit, um einerseits die Daten
einfach eintragen zu können, andererseits auch gut auswerten zu können.
Wenn du eine bessere Idee hast, kannst du uns die gerne vorstellen.

 Somit komme ich zu dem Schluss, dass es wohl immer noch an einer
 gelungen Ausarbeitung des Tagging-Schemas und der entsprechenden auch
 für normale User verständlichen Wikiseiten fehlt und ein mechanischer
 Edit zur Zeit zu wenig Verbesserung mit sich bringt.

Hast du konkrete Verbesserungsvorschläge für die Wikiseiten?

Der mechanische Edit bringt deutliche Verbesserungen. Er vereinheitlicht
das Tagging und korrigiert Design-Fehler, die wir beim Entwurf des
Taggingschemas gemacht haben, nämlich die fehlende internationale
Eindeutigkeit der Tags.


Gruß
Alex


signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Need help to fix? osm data in german

2014-12-17 Diskussionsfäden Alexander Matheisen
On Mi, 2014-12-17 at 14:07 +0100, Martin Vonwald wrote:
 Auszug aus dem Impressum von www.limburg-bernd.de:  Der Urheber räumt Ihnen
 ganz konkret kein Nutzungsrecht ein, um sich eine private Kopie für
 persönliche Zwecke anzufertigen.

wundert mich etwas, denn Bernd Limburg ist sonst aktiver Wikipedianer im
Bereich Denkmäler und hat all seine Fotos Wikimedia gespendet:
http://de.wikipedia.org/wiki/Benutzer:Huckety

Vielleicht stammen die Nutzungsrechte noch aus einer Zeit bevor er auf
Wikipedia aufmerksam wurde.

 Ich meine, dass es so eine Seite definitiv nicht wert ist irgendwo verlinkt
 zu werden.

Vielleicht sollte man stattdessen lieber die Denkmallisten in der
Wikipedia verlinken? Dort steht praktisch das gleiche wie auf seiner
Homepage, inklusive der gleichen Bilder. Beim Verlinken privater
Webseiten gibt es immer die Gefahr, dass die Inhalte irgendwann
verschwinden oder die Links nicht stabil bleiben. Dieses Problem hat man
bei der Wikipedia nicht.


Gruß
Alex


 Am 17. Dezember 2014 um 12:48 schrieb Martin Vonwald imagic@gmail.com:
 
 
 
  2014-12-17 12:41 GMT+01:00 Mark Obrembalski m...@obrembalski.de:
 
  On 17.12.2014 12:13, Martin Vonwald wrote:
   Offensichtlich meint er, dass das website-Tag hier nicht hingehört.
   Und wenn ich mir das so ansehe, würde ich ihm auch eher zustimmen.
 
  Die Einzelseite zu dem Kreuz ist offenbar
 
  http://www.limburg-bernd.de/DenkUeb/Nr.%203.htm
 
  Von der angegebenen Hauptseite kommt man da nur mit ein wenig Suchen hin.
 
 
  So gesehen könnten wir auf jedes Objekt website=www.google.com
  draufgeben, oder? Mal abgesehen davon, dass der direkte Link gesetzt sein
  sollte, bin ich mir nicht so sicher ob unbedingt eine private
  Sammelwebseite verlinkenswert ist. Ist aber nicht meine Baustelle, daher
  nur als Denkanstoß gedacht.
 
  bg,
  Martin
 
 
 ___
 Talk-de mailing list
 Talk-de@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-de



signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] priority=* an railway=*

2014-11-05 Diskussionsfäden Alexander Matheisen
On Mi, 2014-11-05 at 15:38 +0100, fly wrote:
 Am 04.11.2014 um 20:15 schrieb Michael Reichert:
  Hallo Fly,
  
  Am 2014-11-04 um 18:48 schrieb fly:
  Dachte, die wären doch zu Google gegangen.
 
  Mentz war noch nie sehr diskussionsfreudig von Doku ganz zu schweigen.
  Hier hat mal wieder eine Firma ihre Mitarbeiter*innen nicht unter 
  Kontrolle.
 
  Am besten allen eine Mail schreiben und darauf hinweisen, dass so was im
  Vorhinein zu diskutieren ist.
  
  http://lists.openrailwaymap.org/archives/openrailwaymap/2014-October/000157.html
  http://lists.openrailwaymap.org/archives/openrailwaymap/2014-October/000159.html
  http://lists.openrailwaymap.org/archives/openrailwaymap/2014-November/000164.html
  http://lists.openrailwaymap.org/archives/openrailwaymap/2014-November/000165.html
  http://lists.openrailwaymap.org/archives/openrailwaymap/2014-November/000166.html
 
 Danke, aber sowas gehört doch auch auf eine offizielle Mailingliste wie
 transit@ oder tagging@
 
 Auch auf dieser Liste hätte ja zumindest ein Link zur Diskussion
 mitgeteilt werden können.
 
 Bei wievielen Mailinglisten soll ich mich denn sonst noch überall anmelden ?

Rückfrage: Auf wie vielen verschiedenen Kanälen soll denn nun über
Eisenbahntagging diskutiert werden? Wer an Eisenbahnthemen in OSM
interessiert ist, dürfte meist ohnehin bei der ORM-Mailingliste
angemeldet sein. Der Sinn der ORM-Mailingliste ist es ja,
Eisenbahnthemen unter interessierten Mappern zu diskutieren. transit und
tagging sind für solche Themen nicht wirklich geeignet.

Unabhängig davon sehe ich im vorliegenden Fall auch überhaupt keinen
Grund, das Thema auf den genannten Mailinglisten anzusprechen. Statt
eines etablierten und vieldiskutierten Taggingschemas hat Mentz - warum
auch immer - ein veraltetes und ungeeignetes Taggingschema angewendet.
Ich sehe bei dem Thema keinen Diskussionsbedarf mehr...


Gruß
Alex


signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


[Talk-de] OpenRailwayMap Mappingwochenende

2014-06-23 Diskussionsfäden Alexander Matheisen
Hallo zusammen,

die Bahnmapper rund um das Projekt OpenRailwayMap veranstalten vom 11.
bis 13. Juli 2014 in Köln das erste OpenRailwayMap-Mappingwochenende.

Eingeladen sind natürlich nicht nur die Bahnexperten unter den Mappern,
sondern auch interessierte Neulinge, die das Thema Bahnmapping einmal
näher kennenlernen möchten.

Weitere Informationen findet ihr im Wiki unter
https://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Mappingwochenende_2014_1 
- tragt euch auch bitte dort ein, falls ihr kommen wollt.

Ich hoffe auf reges Interesse!


Gruß
Alex


signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


[Talk-de] Mappingevent OpenRailwayMap

2014-05-22 Diskussionsfäden Alexander Matheisen
Hallo,

wie einige vielleicht schon über die OpenRailwayMap-Mailingliste oder
die Wochennotiz mitbekommen haben, planen wir ein Mappingevent für
Bahnmapper.

Zweck dieser Veranstaltung soll es sein, andere Bahnmapper einmal
persönlich kennenzulernen, gemeinsam ein kleines Gebiet in einer
Mappingparty zu erfassen und Neulinge an das Thema Eisenbahnmapping
heranzuführen. Eingeladen sind aber nicht nur Mapper, sondern auch
interessierte Bahnunternehmen und Entwicklerfirmen, um gegenseitig
Kontakte zu knüpfen. Weitere Infos finden sich auf der Wikiseite. [1]

Falls ihr Interesse an einer Teilnahme habt, tragt euch und eure
Ortsvorschläge bitte im Wiki ein. Zur Zeit sind wir noch dabei, einen
passenden Ort für diese Veranstaltung zu suchen. Sobald sich hier etwas
ergeben hat, werden wir nach einem passenden Termin suchen.

Ich hoffe auf reges Interesse. 

[1]
http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Mappingwochenende_2014_1


Gruß
Alex


signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


[Talk-de] Neue OpenRailwayMap Mailingliste

2014-02-23 Diskussionsfäden Alexander Matheisen
Hallo,

für alle Mapper, die an Eisenbahnen und der OpenRailwayMap interessiert
sind, gibt es nun eine neue Mailingliste:
http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap

Ich hoffe, dass sich dadurch die Bahnfreaks unter euch besser
austauschen können... ;)


Gruß
Alex


signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Openrailwaymap zoom 11 tile rendering

2014-01-18 Diskussionsfäden Alexander Matheisen
Hallo Philipp,

On Sa, 2014-01-18 at 11:05 +0100, Philipp Klaus Krause wrote:
 I noticed that Openrailwaymap seems to take a very long time to
 rerender the big tiles:
 
 At zoom level up to 10, changes that have been made weeks ago are
 still not visible. But when I zoom in to 11 or further, even changes
 made a day ago seem to be there.
 Is there any particular reason for this?

Die OpenRailwayMap befindet sich ja auch noch im Entwicklungsstadium
(wie auch die Hinweisbox beim Seitenaufruf verrät), daher funktioniert
vieles auch noch nicht optimal und auch der Kartenstil ist noch lange
nicht fertig.

Seit einiger Zeit habe ich in der Tat einige Schwierigkeiten mit der
Aktualisierung der Karte.
Ich bin aber kurz davor, diese gelöst zu haben. Wenn soweit alles wieder
funktioniert, wird auch die Meldung beim Seitenaufruf verschwinden.


Gruß
Alex


signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


[Talk-de] Vandalismus im Wiki

2013-09-24 Diskussionsfäden Alexander Matheisen
Hallo,

hier treibt gerade ein Nutzer ziemlichen Unsinn und löscht wahllos die
Inhalte von Wikiseiten:
http://wiki.openstreetmap.org/wiki/Special:Contributions/Socksock

Wer auch immer das Wiki administriert möge den User bitte sperren und
die Änderungen zurücksetzen.


Gruß
Alex


signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Vandalismus im Wiki

2013-09-24 Diskussionsfäden Alexander Matheisen
Am Dienstag, den 24.09.2013, 21:12 +0200 schrieb Alexander Matheisen:
 Hallo,
 
 hier treibt gerade ein Nutzer ziemlichen Unsinn und löscht wahllos die
 Inhalte von Wikiseiten:
 http://wiki.openstreetmap.org/wiki/Special:Contributions/Socksock
 
 Wer auch immer das Wiki administriert möge den User bitte sperren und
 die Änderungen zurücksetzen.

Ist wohl gerade gesperrt worden.
Kann man irgendwie all seine Änderungen in einem Schritt wieder
rückgängig machen?


Gruß
Alex


signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Vandalismus im Wiki

2013-09-24 Diskussionsfäden Alexander Matheisen
Am Dienstag, den 24.09.2013, 21:19 +0200 schrieb Alexander Matheisen:
 Am Dienstag, den 24.09.2013, 21:12 +0200 schrieb Alexander Matheisen:
  Hallo,
  
  hier treibt gerade ein Nutzer ziemlichen Unsinn und löscht wahllos die
  Inhalte von Wikiseiten:
  http://wiki.openstreetmap.org/wiki/Special:Contributions/Socksock
  
  Wer auch immer das Wiki administriert möge den User bitte sperren und
  die Änderungen zurücksetzen.
 
 Ist wohl gerade gesperrt worden.
 Kann man irgendwie all seine Änderungen in einem Schritt wieder
 rückgängig machen?

Thema hat sich erledigt, die Wiki-Admins haben alle Änderungen
zurückgesetzt.


Gruß
Alex


signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Eisenbahnen in Korea

2013-09-23 Diskussionsfäden Alexander Matheisen
Hallo,

 ich habe umfangreiche Daten zum Bahnnetz in Nord-Korea, Asien und Japan 
 bekommen, mit Stationen und Strecken-Kilometern.
 
 Wem kann ich das per PM schicken?
 Vielleicht ist ja Brauchbares dabei...

das klingt interessant, vor allem für die OpenRailwayMap.

Kannst mir die Daten gerne mal zuschicken. Ist denn geklärt, unter
welcher Lizenz die stehen und ob sie für OSM verwendet werden dürfen?


Gruß
Alex


signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Drohung an Mapper

2013-09-23 Diskussionsfäden Alexander Matheisen
Am Dienstag, den 24.09.2013, 02:22 +0900 schrieb Max:
 Interessante Entdeckung:
 eine Drohung an Mapper (an einer Mauer des Camp George in Daegu, Südkorea).
 
 Das Schild list sich so:
 
 WARNING
 RESTRICTED AREA
 
 This installation has been declared a restricted area by authority of the 
 Installation Commander in accordance with the provisions of the directive 
 issued by the Secretary of Defense on 20th August 1954, pursuant to the 
 provisions of Section 21, Internal Security Act of 1950. Unauthorized entry 
 is prohibited. All persons and vehicles entering herin are liable to 
 dearch.Photographing or making notes drawings, maps, or graphic 
 representations of this area or its activities are prohibited unless 
 specifically authorized by the commander. Any such material found in the 
 posession of unauthorized persons will be confiscated.
 
 (Darunter das gleiche noch mal auf Koreanisch )

Solche Schilder findet man aber auch an US-Einrichtungen in Deutschland.
Finde aber gerade leider kein Beispielbild (kein Wunder bei einem
Schild, das das Fotografieren verbietet...)


Gruß
Alex


signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] OpenRailwayMap [Was: Re: Korrektur vom Schienenetz in Deutschland]

2013-09-19 Diskussionsfäden Alexander Matheisen
Am Freitag, den 13.09.2013, 18:58 +0200 schrieb Philipp Klaus Krause:
 Eine Legende wäre schön. Die Geschwindigkeitskarte ist dank der Zahlen
 auf der Karte auch ohne verständlich, aber bei den anderen Merkmalen
 sieht es anders aus. Und auch für die Geschwindigkeit schadet eine
 Legende nicht.

Ist alles in Arbeit.
Die Karte ist ja auch noch nicht fertig und eher unfreiwillig hier
publik geworden...


Gruß
Alex


signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Korrektur vom Schienenetz in Deutschland

2013-09-19 Diskussionsfäden Alexander Matheisen
Am Freitag, den 13.09.2013, 20:05 +0200 schrieb fly:
 On 11.09.2013 11:43, Alexander Matheisen wrote:
  Im Zusammenhang mit meiner OpenRailwayMap habe ich vor einiger Zeit ein
  Taggingschema entwickelt, das bereits intensiv genutzt wird:
  http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Vereinfachtes_Tagging#Gleis
  
  Ich habe auch eine Vorlage für JOSM erstellt, die das Tagging deutlich
  erleichtert:
  https://raw.github.com/rurseekatze/OpenRailwayMap/master/josm-presets/de.xml
 
 Leider finde ich Dein Preset nicht unter den externen Presets in JOSM,
 dafür ist es nötig im JOSM Trac auf der Preset-Seite die URL einzutragen.

Da das Preset noch nicht endgültig fertig ist, habe ich bisher auch noch nicht
dort eingetragen, was aber geplant ist.

 Super wäre es einen eigenen Style zur Verfügung zu stellen.

Das geht bereits. Dazu musst du nur die MapCSS-Dateien und das
Verzeichnis icons, die unter
https://github.com/rurseekatze/OpenRailwayMap/tree/master/styles zu
finden sind, in JOSM einbinden.
Bisher habe ich das auf der Wikiseite der OpenRailwayMap noch nicht
dokumentiert, aber das kommt noch...


Gruß
Alex


signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] OpenRailwayMap [Was: Re: Korrektur vom Schienenetz in Deutschland]

2013-09-12 Diskussionsfäden Alexander Matheisen
Am Mittwoch, den 11.09.2013, 21:22 + schrieb Sven Geggus:
 Alexander Matheisen alexandermathei...@ish.de wrote:
 
  Liverendering mit Mapserver oder Mapnik habe ich bisher noch nicht
  ausprobiert.
 
 In kleinen Zoomleveln ist das kein Problem. Der OSM Inspektor macht
 das zum Beispiel so.

Bei Zoomstufen =10 ist die Geschwindigkeit beim Rendering im Browser ja
auch kein Problem.

Schwierig wird es in den niedrigen Zoomstufen bis etwa z7, bei denen ich
die Datenkacheln per Cronjob vorher erzeugen und cachen muss, weil eine
Live-Erzeugung zu langsam wäre.
Das müsste man bei einem Liverendering von Bitmap Tiles wahrscheinlich
auch. Aber dann hätte man wieder den Nachteil, dass man jede Kachel in
jedem Kartenstil rendern muss...


Gruß
Alex


signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Korrektur vom Schienenetz in Deutschland

2013-09-11 Diskussionsfäden Alexander Matheisen
Hallo,

 Allerdings haben wir noch ein anderes Problem. Das Tagging der Gleise ist
 nur wenig differenziert. Das hat zur Folge, dass der Router auch mal durch
 einen Bahnbetriebshof oder über einen Rangierbahnhof fährt. Wenn uns jemand
 sagen kann, wie wir Gleise erkennen und kennzeichnen können, die nicht für
 den Personenverkehr genutzt werden können, wäre das hilfreich.

Im Zusammenhang mit meiner OpenRailwayMap habe ich vor einiger Zeit ein
Taggingschema entwickelt, das bereits intensiv genutzt wird:
http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Vereinfachtes_Tagging#Gleis

Ich habe auch eine Vorlage für JOSM erstellt, die das Tagging deutlich
erleichtert:
https://raw.github.com/rurseekatze/OpenRailwayMap/master/josm-presets/de.xml


Gruß
Alex


signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] OpenRailwayMap [Was: Re: Korrektur vom Schienenetz in Deutschland]

2013-09-11 Diskussionsfäden Alexander Matheisen
Am Mittwoch, den 11.09.2013, 13:34 +0200 schrieb Philipp Klaus Krause:
 Am 11.09.2013 11:43, schrieb Alexander Matheisen:
 
  Im Zusammenhang mit meiner OpenRailwayMap […]
 
 Funktioniert da bereits etwas bahnspezifisches? Mit Firefox 23 auf
 GNU/Debian sehe ich auf http://www.openrailwaymap.org/ nur eine
 OpenStreetMap (langsam ladend, mit höhenschattierung, wahlweise in
 Grau oder Farbe, und per default in dieser MapQuest-Darstellung die
 Autobahnen sehr betont).

Du hast mich gerade auf einen Bug aufmerksam gemacht, den ich bisher
noch nicht entdeckt habe. Bei meiner letzten Codeänderung hatte ich wohl
einen Variablennamen falsch geschrieben...
Jetzt sollte wieder alles funktionieren.

Die Karte ist soweit fertig und benutzbar, wenn auch besonders in
niedrigen Zoomstufen etwas langsam, da die Karte mit KothicJS im Browser
gerendert wird.


Gruß
Alex


signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] OpenRailwayMap [Was: Re: Korrektur vom Schienenetz in Deutschland]

2013-09-11 Diskussionsfäden Alexander Matheisen
 Danke. Eine Eisenbahnkarte auf OSM-Basis scheint mir eine sehr gute
 Idee. Und abgesehen von der Langsamkeit ist die gefällt mir die Karte
 auch. Ist es geplant, da noch weitere Informationen einblendbar zu
 machen (z.B. Oberstromgrenzwerte, Neigetechnik, etc)?

Ja, die Kartenstyles sollen nach und nach erweitert werden.
Konkret geplant sind bereits Ansichten für Elektrifizierung und
Spurweite, aber es können natürlich noch unzählige weitere Stile
erstellt werden.

Konkrete Vorschläge sind gerne gesehen und können per Mail oder als
Github Issue mitgeteilt werden.


Gruß
Alex


signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] OpenRailwayMap [Was: Re: Korrektur vom Schienenetz in Deutschland]

2013-09-11 Diskussionsfäden Alexander Matheisen
Am Mittwoch, den 11.09.2013, 14:55 + schrieb Sven Geggus:
 Alexander Matheisen alexandermathei...@ish.de wrote:
 
  Die Karte ist soweit fertig und benutzbar, wenn auch besonders in
  niedrigen Zoomstufen etwas langsam, da die Karte mit KothicJS im Browser
  gerendert wird.
 
 Da man die Features ohnehin nicht anklicken kann. Spricht was dagegen mit
 Mapserver oder Mapnik live aus der serverseitigen Datenbank zu rendern?

Grundsätzlich spricht nichts dagegen.
Für KothicJS und gegen einen herkömmlichen Tileserver hatte ich mich aus
folgenden Gründen entschieden:
* Geringerer Rechenaufwand auf dem Server durch Rendering im Client;
weniger Speicherplatzbedarf auf dem Server, da für mehrere angebotene
Renderingstyles nicht jede Kachel mehrfach abgelegt werden muss
* Möglichkeit des Stylewechsels und Sichtbarkeit von Änderungen am
Renderingstyle, ohne die Kacheln neu rendern zu müssen

Liverendering mit Mapserver oder Mapnik habe ich bisher noch nicht
ausprobiert. Bis auf den höheren Rechenaufwand auf dem Server würden
sich damit scheinbar auch meine Anforderungen erfüllen lassen. Wie sich
beide Lösungen hinsichtlich der Performance verhalten, müsste man
ausprobieren.

 Was ich auf die Schnelle nicht gefunden habe ist eine Legende.

Die Anwendung ist ja auch noch nicht komplett fertig, sonst hätte ich
hier auch schon mehr Werbung gemacht.

 Ach ja und railway = funicular scheint nicht dargestellt zu werden, oder hab
 ich da was vergessen zu taggen?

Dass Standseilbahnen nicht dargestellt werden, ist so gewollt. Die Karte
beschränkt sich nämlich auf die richtigen Eisenbahnen, also
schienengebundene und aus eigener Kraft fahrende Verkehrsmittel.
Siehe
http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap#Projektbeschreibung.


Gruß
Alex


signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Güterbahnhöfe / Verladestationen

2013-04-19 Diskussionsfäden Alexander Matheisen
 Es existieren neben den normalen Bahnhöfen für Menschen auch
 Güterbahnhöfe oder Güterverkehrszentren (Umladestationen). Wie könnte
 man sowas taggen? (Mir wäre am liebsten ein railway=* Tag). In indien
 bin ich über railway=freight_station gestolpert, was ich gar nicht sooo
 verkehrt finde. Was meint ihr?

Im Rahmen des Taggingschemas für meine OpenRailwayMap habe ich mit
bereits einige Gedanken darüber gemacht:

Für Güter- und Rangierbahnhöfe habe ich railway=yard vorgesehen.

Was Containerterminals angeht: Da habe ich einfach mal
man_made=container_terminal und railway=container_terminal gewählt,
wobei Containerverladeterminals irgendwo auch wieder ein railway=yard
sind.
Daher man_made=container_terminal für alle Arten von Containerumschlag
und zusätzlich railway=container_terminal für solche mit Verladung auf
Güterwagen.

Das Tagging von Logistikeinrichtungen bedarf aber noch eines
detaillierten Taggingschemas. Bisher hat sich noch niemand eingehender
mit diesem Thema beschäftigt.


Grüße
Alex


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


Re: [Talk-de] Neue Features in der OpenLinkMap: Abfahrtszeiten und Adressen

2013-03-13 Diskussionsfäden Alexander Matheisen
Hallo Jimmy,

 mit einer public_transport=station und area=yes wird der Link
 (irgendwo?) an der Linie gesetzt und nicht im Schwerpunkt (oder
 ähnlichem). Siehe z.B. hier:
 http://www.openlinkmap.org/?zoom=18lat=48.34056lon=16.73432layers=BFT

Das ist schon der Centroid, nur der wird bei mir von osmconvert
berechnet und liegt daher nicht auf dem von Mapnik berechneten Centroid.
Um das zu verbessern müsste entweder osmconvert angepasst werden, oder
aber ich stelle meinen Code so um, dass die Centroids von PostGIS
berechnet werden.
Auf welche Weise ich das Problem löse, weiß ich noch nicht so recht...


Grüße
Alex


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


Re: [Talk-de] Neue Features in der OpenLinkMap: Abfahrtszeiten und Adressen

2013-03-12 Diskussionsfäden Alexander Matheisen
Hallo,

 Genau das ist das Problem, denn hier in der Region ist es eher selten das es
 als VVS getaggt wird sondern es wird mehr über den Verkehrsbetrieb getaggt.

Ich habe herausgefunden, dass die Auskunft der Deutschen Bahn soweit
auch Bushaltestellen unterstützt. Dazu sind auch keine UIC-Nummern
notwendig, denn die Abfrage geht auch mit einer Kombination aus
Haltestellennamen und Ort:

http://reiseauskunft.bahn.de/bin/bhftafel.exe/dn?country=DEUrt=1use_realtime_filter=1productsFilter=1100boardType=Abfahrtstart=Sucheninput=tennisplatz,ludwigsburg

Daher sollte es funktionieren, wenn man ein Tag uic_name=* hinzufügt,
das einen Wert nach dem Schema Haltestellenname, Stadthat.
Die entsprechende Regel in der Datei habe ich hinzugefügt.

Wobei ich dafür wäre, zur Vereinfachung allen Haltestellen ein
network=VVS zu geben, damit nicht eine lange Liste von Betreibern in
allen Schreibvarianten abfragen muss.


Grüße
Alex


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


Re: [Talk-de] Neue Features in der OpenLinkMap: Abfahrtszeiten und Adressen

2013-03-11 Diskussionsfäden Alexander Matheisen
Hallo Michael,

 Also ich hab mich jetzt mal ein wenig damit beschäftigt, jedoch reichen
 meine Programmierkenntnisse in XSLT und html nicht aus um die Abfrage zu
 gestalten, weil mit uic_ref wird das bei Bustationen nichts.
 
 translation
 nameVVS/name
 descriptionTimetables for public station stop positions operated by the
 traffic network Stuttgart Verkehrsverbund Stuttgart(VVS)./description
 match mode=and
 match mode=or
 tag k=highway v=bus_stop/
 tag k=railway v=station/
 tag k=railway v=halt/
 tag k=public_transport v=stop_position/
 tag k=public_transport v=platform/
 tag k=railway v=stop/
 /match
 match mode=or
 tag k=operator v=(.*;|^)SSB(;.*|$)/
 tag k=operator v=(.*;|^)Stuttgarter Strassenbahnen(;.*|$)/
 tag k=operator v=(.*;|^)Stuttgarter Straßenbahnen(;.*|$)/
 tag k=operator v=(.*;|^)SVE(;.*|$)/
 tag k=operator v=(.*;|^)LVL(;.*|$)/
 tag k=operator v=(.*;|^)Schlienz(;.*|$)/
 tag k=operator v=(.*;|^)Bader(;.*|$)/
 tag k=operator v=(.*;|^)Böltz(;.*|$)/
 tag k=operator v=(.*;|^)Dannenmann(;.*|$)/
 tag k=operator v=(.*;|^)Däuble(;.*|$)/
 tag k=operator v=(.*;|^)Eberhardt(;.*|$)/
 tag k=operator v=(.*;|^)Eisemann(;.*|$)/
 tag k=operator v=(.*;|^)END(;.*|$)/
 tag k=operator v=(.*;|^)Fischle(;.*|$)/
 tag k=operator v=(.*;|^)Flattich(;.*|$)/
 tag k=operator v=(.*;|^)Ganter(;.*|$)/
 tag k=operator v=(.*;|^)Hassler(;.*|$)/
 tag k=operator v=(.*;|^)Haussmann  Bauer(;.*|$)/
 tag k=operator v=(.*;|^)Jäger(;.*|$)/
 tag k=operator v=(.*;|^)Kappus(;.*|$)/
 tag k=operator v=(.*;|^)Klingel(;.*|$)/
 tag k=operator v=(.*;|^)Knauss(;.*|$)/
 tag k=operator v=(.*;|^)Kniesel(;.*|$)/
 tag k=operator v=(.*;|^)Ludwigsburger Verkehrslinien(;.*|$)/
 tag k=operator v=(.*;|^)Melchinger(;.*|$)/
 tag k=operator v=(.*;|^)Omnibusverkehr Ernst Maier(;.*|$)/
 tag k=operator v=(.*;|^)Ernst Maier(;.*|$)/
 tag k=operator v=(.*;|^)OVK(;.*|$)/
 tag k=operator v=(.*;|^)Omnibus Verkehr Kirchheim(;.*|$)/
 tag k=operator v=(.*;|^)OVR(;.*|$)/
 tag k=operator v=(.*;|^)Pflieger(;.*|$)/
 tag k=operator v=(.*;|^)Pflüger(;.*|$)/
 tag k=operator v=(.*;|^)Römer(;.*|$)/
 tag k=operator v=(.*;|^)Schefenacker(;.*|$)/
 tag k=operator v=(.*;|^)Seitter(;.*|$)/
 tag k=operator v=(.*;|^)Seiz(;.*|$)/
 tag k=operator v=(.*;|^)Spillmann(;.*|$)/
 tag k=operator v=(.*;|^)Stadtwerke Herrenberg(;.*|$)/
 tag k=operator v=(.*;|^)Stadtwerke Remseck(;.*|$)/
 tag k=operator v=(.*;|^)Stäbler(;.*|$)/
 tag k=operator v=(.*;|^)Städtischer Verkehrsbetrieb Esslingen(;.*|$)/
 tag k=operator v=(.*;|^)VBN(;.*|$)/
 tag k=operator v=(.*;|^)Verkehrsbetriebe Nagoldtal(;.*|$)/
 tag k=operator v=(.*;|^)WEG(;.*|$)/
 tag k=operator v=(.*;|^)Wöhr(;.*|$)/
 tag k=network v=(.*;|^)VVS(;.*|$)/
 /match
 /match
 output
 copy-all/
 tag from_match=uic_ref k=departures
 v=http://www2.vvs.de/vvs/XSLT_DM_REQUEST?Oberesslingen%2C%20Rosenau%7C50040
 23%7Cstop=SpEncId=0anyMaxSizeHitList=500anySigWhenPerfectNoOtherMatches=1
 command=convertPOIsITKernel2LocationServer=1convertStopsPTKernel2Location
 Server=1dmLineSelection=alldmLineSelectionAll=1execInst=normalitdDateTim
 eDepArr=depitdLPxx_agbAccepted=yeslanguage=delocationServerActive=1lsSho
 wTrainsExplicit=1requestID=1selectAssignedStops=1sessionID=efa04.dc.vvs.d
 e_614894976stateless=1submit=submittryToFindLocalityPOIs=1tryToFindLocal
 ityStops=1useRealtime=1w_objPrefAl=2w_objPrefAl=12w_regPrefAm=1/
 /output
 /translation


Es hat mir bereits ein anderer Mapper eine Regel für den Verkehrsverbund
Stuttgart geschickt. Dort wird mit dem Tag ref:vvs=* gearbeitet. Statt
mehreren operator=* Tags wird dort nur die Existenz des Tags ref:vvs=*
abgefragt und wenn das vorhanden ist, wird damit die Auskunft unter
www2.vvs.de aufgerufen.

Vielleicht könntest du mal ausprobieren, ob das auch für die
Haltestellen in deiner Umgebung funktioniert? Wie du schon schreibst
wird das mit uic_ref wohl nichts (wobei streng genommen auch für
Bushaltestellen solche Nummern existieren, die aber glaube ich nicht
offiziell sind).

Falls doch eine andere Lösung notwendig ist, können wir da sicherlich
etwas passendes zusammenbasteln.


Grüße
Alex


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


Re: [Talk-de] Neue Features in der OpenLinkMap: Abfahrtszeiten und Adressen

2013-03-06 Diskussionsfäden Alexander Matheisen
Hallo Jimmy,

 eine kleine Frage:
 Hast du absichtlich bei den ÖBB einen Link generiert wo nur 5 Fahrten
 angezeigt werden? Mit showJourneys= kannst du auch mehr draus machen.

Danke für den Hinweis! Habe die Zahl jetzt auf 20 gesetzt.

 Für Wien und die Wiener Linien gibt es leider keinen zugänglichen
 Monitor. Außer man spielt es über quando.at (z.B.:
 http://m.qando.at/qr/00486), aber die Nummern müssten extra eingepflegt
 werden.

Wenn es offizielle Nummern des Verkehrsunternehmens sind, sollten die
meiner Meinung erfasst werden.
Wenn es nur interne Nummern eines Anbieters oder einer Software sind,
natürlich nicht.


Grüße
Alex


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


Re: [Talk-de] Neue Features in der OpenLinkMap: Abfahrtszeiten und Adressen

2013-03-06 Diskussionsfäden Alexander Matheisen
Hallo Paule,

 Warum hast Du die Mobilauskunft der Bahn eingefügt und nicht die
 ausführlichere Abfahrtstafel auf der Homepage der Bahn direkt?

Habe es korrigiert. Hatte ursprünglich vor, die Abfahrtsseite direkt in
die Anwendung mit einem iframe einzubinden, wofür sich natürlich die
mobile Version besser eignen würde. Hatte die Idee aber dann (vorerst)
doch verworfen und vergessen, den Link zu ändern... ;)


Grüße
Alex


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


[Talk-de] Neue Features in der OpenLinkMap: Abfahrtszeiten und Adressen

2013-03-05 Diskussionsfäden Alexander Matheisen
Hallo allerseits,

nach langer Zeit gibt es wieder einige neue Features in der OpenLinkMap:

Die wichtigste Neuerung ist der Public transport-Layer. Dies ist ein
zusätzlicher Layer, der Zusatzinformationen zu Bushaltestellen,
Bahnhöfen, etc. anzeigt. Die interessanteste Funktion ist dabei die
Verlinkung zu Echtzeit-Abfahrtszeiten auf der Homepage des jeweiligen
Verkehrsunternehmens. Die Idee zu dieser Funktion stammt von Mappern aus
der belgischen Community.
Beispiel:
http://www.openlinkmap.org/?lat=50.87921lon=4.71299zoom=16layers=BFT

Das Ganze funktioniert folgendermaßen: Die Software generiert anhand
einer Regeldatei, dessen Format dem für das Tagtransform Plugins von
Osmosis (http://wiki.openstreetmap.org/wiki/Osmosis/TagTransform)
entspricht, ein neues Tag mit einer URL zur Seite mit den Abfahrtszeiten
für diese Haltestelle.
Bei der belgischen Gesellschaft De Lijn beispielsweise wird bei
Auswerten der Datei ein neues Tag erzeugt, das einen Link zur Seite mit
den Abfahrtszeiten für eine bestimmte Haltestelle enthält. In diesem
Fall wird dabei die Haltestellen-ID aus dem Tag ref=* an eine bestimmte
URL des Verkehrsunternehmens gehängt.

Ich habe bereits Regeln für die Fahrplanauskunft der DB und ÖBB
hinzugefügt. Dadurch wird in Deutschland bei Bahnhöfen, die mit
operator=DB AG/DB/DB Regio/... und uic_ref=* getaggt sind, ein Link zur
Fahrplanauskunft der Deutschen Bahn angezeigt. Da die ÖBB wie auch die
Deutsche Bahn das Hafas-System zur Fahrplananzeige nutzen, brauchte ich
nur die URL anzupassen.

Trotzdem fehlen weiterhin noch Regeln für viele Verkehrsverbünde und
Unternehmen, sowohl im Inland, als auch im Ausland. Ich würde mich sehr
freuen, wenn andere Interessierte Regeln für weitere
Unternehmen/Verkehrsverbünde erstellen und diese in der Datei ergänzen.
Bei der Datei habe ich bewusst das bereits existierende Format gewählt,
damit auch andere Anwendungen (z.B. Osmosis) diese Datei auswerten
können. Ich lade andere Entwickler explizit dazu ein, die Datei in
eigenen Projekten zu verwenden und rufe auf, Regeln zu allen möglichen
Fahrplanauskünften in dieser Datei zu sammeln, um so das Wissen zu
teilen und viel Arbeit zu ersparen.
Regeldatei:
https://github.com/rurseekatze/OpenLinkMap/blob/master/locales/departures.xml

Außerdem gab es vor einiger Zeit einige Verbesserungen bei der Anzeige
von Adressen: Zum einen wird das Tag addr:suburb nun ausgewertet, damit
werden Adressen, die z.B. als addr:city=Berlin und addr:suburb=Kreuzberg
erfasst sind, in den Popups als Berlin-Kreuzberg angezeigt.
Eine andere Neuerung bei den Adressen betrifft die Adressformate: Dort
bestand das Problem, dass diese je nach Land völlig unterschiedlich
aufgebaut sein können (z.B. Unterschied Deutschland-USA). Damit die
Adressen also je nach Land unterschiedlich formatiert werden, gibt es
eine Datei mit Platzhaltern für verschiedene Länder. Viele Länder sind
noch nicht vorhanden, wer welche ergänzen möchte, findet die Datei hier:
https://github.com/rurseekatze/OpenLinkMap/blob/master/api/addressformats.php


Grüße
Alex


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


Re: [Talk-de] Gesucht - einen Punkt pro BAB-Anschlusstelle (Kreuz)

2012-11-14 Diskussionsfäden Alexander Matheisen
Hallo Jan,

 mal eine Frage an unsere DB-Spezies.
 
 Ist es möglich  pro Anschlussstelle (alle Fahrbahnrichtungen) einen Note
 mit der Ref-Nummer und dem AS-Namen zu generieren. Am einfachsten könnte
 ich es mir vorstellen, wenn die Nodes, der AS, einfach gemittelt werden.

Der vermutlich einfachste Weg ist es, wenn du z.B. mit PostGIS eine Fläche aus 
den zu einer Anschlussstelle gehörenden Punkten bildest und dir dann den 
Centroid dieser Fläche zurückgeben lässt.


Gruß
Alex

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


[Talk-de] Neuimport nach Lizenzwechsel?

2012-09-12 Diskussionsfäden Alexander Matheisen
Hallo,

eine kurze Frage: der Lizenzwechsel scheint ja nun durch zu sein. Muss ich nun 
ein neues Planetfile herunterladen und importieren, oder kann ich einfach die 
normalen Diff-Updates laufen lassen?
Eigentlich müsste sich ja an den Daten seit dem Durchlaufen des Redaction Bots 
nichts mehr geändert haben, sodass kein Neuimport notwendig wäre, aber an 
verschiedenen Stellen (u.a. Forum) hörte es sich so an, als sei ein Neuimport 
notwendig.

Ich hoffe, die Experten können mich ein wenig aufklären.


Grüße
Alex

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


[Talk-de] Digitale Denkmal-Liste

2012-08-26 Diskussionsfäden Alexander Matheisen
Hallo,

bin auf folgendes interessantes Projekt gestoßen:
http://www.wz-newsline.de/lokales/rhein-kreis-neuss/dormagen/sisyphos-aufgabe-
ehepaar-erstellt-digitale-denkmal-liste-1.1080293

OSM wäre doch eine gute Grundlage für die Erfassung, bzw. haben unser und 
deren Projekt einige Gemeinsamkeiten und ließen sich doch gut kombinieren:
Vielleicht könnte man die Daten in OSM importieren oder die Denkmäler auf 
einer POI-Karte darstellen.
Sie nehmen ja kein Geld für ihre Arbeit und sind eventuell sogar bereit, ihre 
Daten der Öffentlichkeit zur Verfügung zu stellen.
Jedenfalls wäre es vielleicht ganz nützlich, wenn andere Leute ebenfalls die 
Daten pflegen könnten.

Gibt es hier Experten für Denkmäler und historische Daten?
Vielleicht kann einer von denen Kontakt zum Projekt aufnehmen, denn mir fehlt 
einfach die Zeit, um mich auch noch um dieses Projekt zu kümmern... ;)


Grüße
Alex

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


Re: [Talk-de] Digitale Denkmal-Liste

2012-08-26 Diskussionsfäden Alexander Matheisen
 Schade um die Doppelarbeit.
 Zusammenarbeit in so einer Sache ist wirklich wichtig - aber warum mit
 dem naturgemäß beschränkten Projekt weniger Privatpersonen? Wäre es
 nicht besser, die Kräfte in einem großen Projekt zu sammeln?

Genau der Gedanke, der mir beim Lesen des Artikels auch kam. Die Fotos könnte 
man ziemlich gut in Wikipedia brauchen oder mit einem image=* Tag in OSM 
verlinken.

Ich vermute die beiden Projektteilnehmer haben noch nichts von OSM gehört und 
würden sich von den Vorteilen überzeugen lassen. Denn die Beweggründe für das 
Selber-Mappen sind bei denen ziemlich ähnlich wie die bei uns...

 Ich würde es sehr begrüßen, wenn es in der OSM-Community mehr Interesse
 für Kulturdenkmäler gäbe.

Grundsätzlich habe ich schon ein Interesse daran - aber genauso auch z.B. an 
Bahnthemen. Bei letzterem gibt es auch nicht viele Experten und das finde ich 
für mich persönlich wichtiger.
Für alle Projekte und Hobbys (sind bei mir auch noch ein paar andere neben 
OSM) reicht eben nicht die Zeit und man muss Prioritäten setzen. Ich wünschte, 
ich könnte all meine Ideen realisieren, aber ich werde wahrscheinlich selbst 
als Rentner nicht genug Zeit für alles haben. Daher teile ich meine Ideen 
lieber anderen Leuten mit, damit sich dort Leute finden können, die sich für 
solche Projekte einsetzen... ;)


Gruß
Alex

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


Re: [Talk-de] Funkamateur

2012-08-25 Diskussionsfäden Alexander Matheisen
Am Samstag, 25. August 2012, 11:44:25 schrieb Michael Kugelmann:
 Am 24.08.2012 11:38, schrieb Alexander Matheisen:
  Oder eher eine Karte, wo man die Standorte der Verbindungspartner sehen
  kann? Sowas habe ich nämlich schon gebaut:
  http://rurseekatze.bplaced.net/map/
 Legst Du die Marker quasi als Liste in einer extra Dabei (mit
 Koordinaten) ab oder wie machst Du das?

Ich lade mein Logfile als ADIF auf den Server hoch und schreibe die Daten dann 
mit einem PHP-Script in eine MySQL Datenbank. Dabei liest das Scipt das 
Locatorfeld aus und rechnet die Angabe in eine Koordinate um. Theoretisch 
könnte man die Daten auch von qrz.com auslesen, aber das war mir bisher zu 
viel Arbeit...

Wenn du willst, kannst du das Script mal haben, oder ich stelle es auf Github.


73 de DO4NE (Alex)

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


Re: [Talk-de] Funkamateur

2012-08-24 Diskussionsfäden Alexander Matheisen
Am Freitag, 24. August 2012, 09:21:53 schrieb Markus:
 Gibt es hier einen funkenden OSMer?
 Vielleicht könnten wir ja eine Spezialkarte bauen...

Ja, ich bin einer.
Was willst du denn bauen? Kartenübersicht von Clubstationen, Baken, Relais und 
ähnlichem?
Oder eher eine Karte, wo man die Standorte der Verbindungspartner sehen kann? 
Sowas habe ich nämlich schon gebaut: http://rurseekatze.bplaced.net/map/


Grüße
Alex (DO4NE)

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


Re: [Talk-de] Funkamateur

2012-08-24 Diskussionsfäden Alexander Matheisen
Am Freitag, 24. August 2012, 12:01:37 schrieb Markus:
 Hallo Alex,
 
  Kartenübersicht von Clubstationen, Baken, Relais und ähnlichem
 
 Wäre hübsch...

Die Idee dazu hatte ich schonmal, aber leider habe ich nicht genug Zeit, um so 
viele Projekte zu starten...


Gruß
Alex

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


Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??

2012-07-08 Diskussionsfäden Alexander Matheisen
Hallo,

 siehe Lonvias Rad- und Wanderkarten, oder die ÖPNV-Karte. Wenn Relationen so
 unnütz oder kompliziert auszuwerten wären, würde es diese Karten nicht
 geben.
 
 spatialite bietet für kleinere Projekte gute Möglichkeiten mit OSM-Daten zu
 arbeiten, erfordert aber etwas Ahnung von SQL.

Ich muss meine Aussage mal ein wenig korrigieren. Ich habe nicht gesagt, dass 
Relationen generell kompliziert auszuwerten sind. Das ist es nur bei der Art 
und Weise, wie ich bisher die Datenbank der OLM befüllt habe.
Für mich waren die site-Relationen in diesem Fall im Verhältnis zum Nutzen zu 
schiwerig auszuwerten, der benötigte Arbeits- und Rechenaufwand lohnte sich 
für mich nicht unbedingt.

Mittlerweile muss ich mich da aber etwas selbst korrigieren, denn mir ist noch 
ein einfacherer Weg der Auswertung eingefallen, als ich erst gedacht hatte. 
Jetzt sollte zumindest der Rechenaufwand recht klein sein. Die Sache mit dem 
Arbeitsaufwand verschiebe ich dann mal auf die Zeit nach dem Urlaub... ;)


Grüße
Alex

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


Re: [Talk-de] Taggingschema OpenRailwayMap

2012-06-22 Diskussionsfäden Alexander Matheisen
 Ja sowas ruft nach einer Relation.

Ich habe beschlossen, dass ich die für die Karte interessanten Firmen mit den 
entsprechenden Funktionen von PostGIS heruasfiltere.
Das ist für den Mapper die einfachste Lösung, spart Speicher und sollte in den 
meisten Fällen auch korrekte Ergebnisse liefern.

 Ich würde mich beim taggen vom Güterverkehr eher an den
 public_transport=* Tags orientieren.
 
 Für die verschiedenen Haltepunkte ist dann eine Relation analog der
 stop_area wohl das beste.

Warum manche hier die Erfassung der Beladestellen in Industrieanlagen so 
wichtig finden, kann ich nicht ganz nachvollziehen. Ich jedenfalls werde sie 
nicht in meiner Karte berücksichtigen und finde auch die Erfassung (zumindest 
zur Zeit) wenig sinnvoll.

 und für die Fabrik eine site-relation.

Und von site-Relationen halte ich nicht besonders viel. Ein Polygon mit der 
Ausdehnung eines Fabrikgeländes erledigt das gleiche und ist weniger 
kompliziert.


Gruß
Alex

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


Re: [Talk-de] Status Lizenzwechsel

2012-06-19 Diskussionsfäden Alexander Matheisen
 On 18.06.2012 15:52, Alexander Matheisen wrote:
  * Wie sieht es mit dem Status der Datenbereinigung aus?
 
 Hat noch nicht angefangen. Es heisst, dass die Software, die eingesetzt
 werden soll, nun weitgehend fertig sei. Bevor sie loslaeuft, wird es
 aber einen Testlauf auf einer vollstaendigen Datenbankkopie geben.
 
  * Wann ist der Lizenzwechsel vollständig abgeschlossen?
 
 Ist nicht klar - eben dann, wenn der Bot fertig ist und die OSMF den
 Startschuss fuer ODbL gibt. Ich wuerd mal so Ende Juli, Anfang August
 damit rechnen, aber ich hab schon oft daneben gelegen ;)
 
  * Wann kommt das erste Odbl-Planetfile bzw. wann die Diffs (ich weiß, zur
  Zeit erscheinen sie unter
  http://planet.openstreetmap.org/redaction-period/), aber wann sind sie
  wieder unter der alten URL verfügbar?
 
 Das erste ODbL-Planetfile kommt fruehestens wenn OSMF die Verwendung der
 neuen Lizenz verkuendet, spaetestens einige Tage danach. Dieser
 Verkuendungstermin ist nicht identisch mit dem Datenbereinigung ist
 fertig-Termin.

Da bin ich ja beruhigt. Ich dachte schon, ich hätte das alles verschlafen.

Ich erhielt nämlich bereits Mails, warum die OpenLinkMap nicht mehr 
aktualisiert wurde, denn der Lizenzwechsel sei ja längst abgeschlossen...


Gruß
Alex

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


Re: [Talk-de] Taggingschema OpenRailwayMap

2012-06-18 Diskussionsfäden Alexander Matheisen
Am Samstag, 16. Juni 2012, 18:36:38 schrieb Martin Koppenhoefer:
 Am 16. Juni 2012 16:16 schrieb Alexander Matheisen 
alexandermathei...@ish.de:
  Am Samstag, 16. Juni 2012, 14:37:10 schrieb Martin Koppenhoefer:
  Am 16. Juni 2012 14:35 schrieb Martin Koppenhoefer 
dieterdre...@gmail.com:
   Am 15. Juni 2012 21:11 schrieb Alexander Matheisen
  
  alexandermathei...@ish.de:
   Was haltet ihr von dieser Idee?
   
   ich würde das automatisch bestimmen lassen aus den Gleisen, die auf
   das Gebiet führen, und ggf., falls bisher Werksgleise nicht als
   solches erkennbar sind (gerade zu faul, das im Wiki nachzuschlagen),
   dann lieber die Gleise näher definieren.
  
  bzw. den Haltepunkt. Also anstatt indirekt am Gesamtgelände zu taggen:
  hat einen Eisenbahnhaltepunkt/ Bahnverladung, lieber konkret dieses
  Feature taggen.
  
  Was ist z.B. mit einem großen Stahlwerk? Wo sind da die Haltepunkte?
  Und wie soll man dann den Bezug zur Fabrik haben? Ich will ja auf der
  Karte
  die Fabrik mit Namen und möglichst ihre Fläche sehen und nicht eine
  Haltestelle als kleiner Punkt ohne Namen und Ausdehnung.
 
 das muss ja nicht unbedingt ein kleiner Punkt sein. Ich habe z.B. mal
 die Bahnverladung bei Mercedes in Sinderfingen gesehen, das ist ein
 größerer Bereich, eine Art Güterbahnhof. Wer einen eigenen
 Gleisanschluss hat, wird normalerweise wohl auch innerhalb des
 Geländes für den Umschlag einen größeren Bereich vorsehen. Vermutlich
 ist das auch der Anteil, der für Eisenbahnkarten interessant ist.

Meist gibt es aber gerade in großen Industrieanlagen wie Stahlwerken oder 
Chemiefabriken über das ganze Gelände verteilt Beladeeinrichtungen. Da hat man 
dann wieder das Problem, dass man eine Beziehung zwischen diesen einzelnen 
Punkten herstellen muss. Das kann man über eine Relation machen, aber wenn man 
ein Tag an die Fläche hängt, lässt sich dieses Problem auch einfacher lösen.


Gruß
Alex

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


Re: [Talk-de] Taggingschema OpenRailwayMap

2012-06-18 Diskussionsfäden Alexander Matheisen
Am Sonntag, 17. Juni 2012, 18:03:45 schrieb Jimmy_K:
 Am 16.06.2012 14:37, schrieb Martin Koppenhoefer:
  bzw. den Haltepunkt. Also anstatt indirekt am Gesamtgelände zu taggen:
  hat einen Eisenbahnhaltepunkt/ Bahnverladung, lieber konkret dieses
  Feature taggen.
 
 Finde ich eine gute Idee. Vielleicht sollte man das Tag usage erweitern
 oder deren Inhalt konkretisieren.
 Ich würde den Gleisabschnitt auf dem die Verladung stattfindet/
 stattfinden kann, entsprechend mit Tags versehen.
 
 z.B.: usage=container_loading (jetzt mal als Beispiel in einem
 Container-Terminal)

Für den von dir angesprochenen Zweck gibt es bereits das Tag service=spur.
Diese Erfassungsvariante bringt aber nur Nachteile mit sich:
1. Ich habe dann meist mehrere Gleise mit diesem Tag und muss die irgendwie 
zusammenfassen, einen Centroid bestimmen oder eine Beziehung zueinander 
herstellen.
2. Auf der Karte will ich die Ausdehnung der Fabrik sehen, was hier nicht 
möglich ist.
3. Ich will auf der Karte den Namen der Firma haben. Um den zu ermitteln, 
bräuchte ich wieder eine Relation oder muss es mit Funktionen der Geodatenbank 
ermitteln.

Ganz ehrlich: Man kann es sich auch unnötig kompliziert machen. Ein simples 
Tag und die Sache ist erledigt. Keine zeitraubende Erfassung mit Relationen, 
keine komplizierte Auswertesoftware schreiben, ganz zu schweigen vom 
Mehraufwand bei den Ressourcen, die bei den OSM-Projekten bekanntlich nicht im 
Überfluss vorhanden sind.


Gruß
Alex

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


[Talk-de] Status Lizenzwechsel

2012-06-18 Diskussionsfäden Alexander Matheisen
Hallo,

mittlerweile ist bei mir einige Unklarheit zum aktuellen Status des 
Lizenzwechsels entstanden. Wiki, Forum und Mailingliste haben mir bei meinen 
Fragen nicht wirklich Klarheit verschafft:

* Wie sieht es mit dem Status der Datenbereinigung aus?

* Wann ist der Lizenzwechsel vollständig abgeschlossen?

* Wann kommt das erste Odbl-Planetfile bzw. wann die Diffs (ich weiß, zur Zeit 
erscheinen sie unter http://planet.openstreetmap.org/redaction-period/), aber 
wann sind sie wieder unter der alten URL verfügbar?


Gruß
Alex

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


Re: [Talk-de] Taggingschema OpenRailwayMap

2012-06-18 Diskussionsfäden Alexander Matheisen
Am Montag, 18. Juni 2012, 15:48:49 schrieb Martin Koppenhoefer:
 Am 18. Juni 2012 15:28 schrieb Alexander Matheisen 
alexandermathei...@ish.de:
  Meist gibt es aber gerade in großen Industrieanlagen wie Stahlwerken oder
  Chemiefabriken über das ganze Gelände verteilt Beladeeinrichtungen.
 
 um so besser ist es doch, diese auch zu mappen.

Klar, die könnte man auch erfassen, auch wenn es für meine Anwendung nicht von 
Interesse ist und es auch sonst keine Anwendung geben wird, die daran 
interessiert sind.

  Da hat man
  dann wieder das Problem, dass man eine Beziehung zwischen diesen einzelnen
  Punkten herstellen muss.
 
 das sollten die Gleise doch eigentlich tun

Wie soll man anhand der Gleise eine Zusammengehörigkeit verschiedener 
Ladestellen herstellen?
Das musst du mir jetzt mal genauer erklären...

  Das kann man über eine Relation machen, aber wenn man
  ein Tag an die Fläche hängt, lässt sich dieses Problem auch einfacher
  lösen.

 welches Problem?

Das Problem ist, dass man die verschiedenen Ladestellen, die über ein 
Werksgelände verteilt sind, irgendwie zusammenfassen muss.

 In dem einen Fall ergänzt man Details in der Karte,
 die vielfältig genutzt werden können, und alle möglichen Probleme
 lösen,

Wie gesagt habe ich nichts gegen die Erfassung dieser Ladestellen, aber die 
müssen einen Bezug untereinander und zur Firma erhalten. Jedoch kann ich mir 
zur Zeit auch noch keine Anwendung vorstellen, die ernsthaft an den 
Ladestellen interessiert wäre. Wenn, dann wären dies nur Routinganwendungen 
für Güterzüge, aber damit die sich zu einer Ladestelle routen lassen können, 
brauchen die noch weitere Informationen, an die wir von OSM nicht so leicht 
rankommen.

 im anderen Fall ein schnödes Attribut, das praktisch keine
 Mehrinformation bietet, da es auch automatisch ableitbar ist, und nur
 für eine ganz bestimmte Frage eine (grobe) Antwort liefert.

Diese Information ist sonst aber nur mit einem Mehraufwand an geografischen 
Operationen in der Datenbank verbunden und möglicherweise auch nicht immer 
100%ig korrekt. Natürlich wäre der Implementierungsaufwand nicht sehr hoch, 
aber der Rechenaufwand steigt und es sind eventuell größere Server nötig.
Ein Tag dagegen vereinfacht das ganze sehr stark und ist völlig eindeutig.


Gruß
Alex

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


Re: [Talk-de] Taggingschema OpenRailwayMap

2012-06-16 Diskussionsfäden Alexander Matheisen
Am Samstag, 16. Juni 2012, 14:35:41 schrieb Martin Koppenhoefer:
 Am 15. Juni 2012 21:11 schrieb Alexander Matheisen 
alexandermathei...@ish.de:
  Was haltet ihr von dieser Idee?
 
 ich würde das automatisch bestimmen lassen aus den Gleisen, die auf
 das Gebiet führen, und ggf., falls bisher Werksgleise nicht als
 solches erkennbar sind (gerade zu faul, das im Wiki nachzuschlagen),
 dann lieber die Gleise näher definieren.
 
 Solche Sachverhalte wie oben, die sich bereits aus Topologie und Lage
 der Daten ergeben, sollte man möglichst nicht unnötig redundant auch
 noch mit tags eintragen.

Das ist jedoch nur mit erheblichem Rechenaufwand verbunden und würde das 
Rendering langsamer machen.

Gruß
Alex

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


Re: [Talk-de] Taggingschema OpenRailwayMap

2012-06-16 Diskussionsfäden Alexander Matheisen
Am Samstag, 16. Juni 2012, 14:37:10 schrieb Martin Koppenhoefer:
 Am 16. Juni 2012 14:35 schrieb Martin Koppenhoefer dieterdre...@gmail.com:
  Am 15. Juni 2012 21:11 schrieb Alexander Matheisen 
alexandermathei...@ish.de:
  Was haltet ihr von dieser Idee?
  
  ich würde das automatisch bestimmen lassen aus den Gleisen, die auf
  das Gebiet führen, und ggf., falls bisher Werksgleise nicht als
  solches erkennbar sind (gerade zu faul, das im Wiki nachzuschlagen),
  dann lieber die Gleise näher definieren.
 
 bzw. den Haltepunkt. Also anstatt indirekt am Gesamtgelände zu taggen:
 hat einen Eisenbahnhaltepunkt/ Bahnverladung, lieber konkret dieses
 Feature taggen.

Was ist z.B. mit einem großen Stahlwerk? Wo sind da die Haltepunkte?
Und wie soll man dann den Bezug zur Fabrik haben? Ich will ja auf der Karte 
die Fabrik mit Namen und möglichst ihre Fläche sehen und nicht eine 
Haltestelle als kleiner Punkt ohne Namen und Ausdehnung.


Gruß
Alex

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


Re: [Talk-de] Taggingschema OpenRailwayMap

2012-06-15 Diskussionsfäden Alexander Matheisen
Hallo,

noch eine weitere Ergänzung meinerseits für das Taggingschema:

Ich habe mir gedacht, dass man Fabriken, Industriebetriebe, etc., die über 
einen Gleisanschluss verfügen, mit einem besonderen Tag kennzeichnet. So würde 
z.B. ein Chemiewerk oder ein kleiner Landhandel zusätzlich zu man_made=works 
(oder als was das auch immer getaggt ist) ein Tag wie etwa railway_access=yes 
erhalten.

Mit dem Tag wäre es dann möglich, solche Betriebe auch der Karte zu rendern. 
So sieht man schnell, welche Firmen einen Bahnanschluss haben. Außerdem ist es 
etwa für Bahnunternehmen interessant, die bei einer Lieferung an Firma X 
schnell sehen können, wie man dort hingelangt.
Auch für Bahninteressierte ist es in Simulatoren oder rein aus Interesse von 
Relevanz.

Bereits existierende Eisenbahn-Atlanten zeigen zumindest die größeren Fabriken 
mit Bahnanschluss auf der Karte... 

Was haltet ihr von dieser Idee?


Gruß
Alex

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


Re: [Talk-de] Mehrgleisige Bahnübergänge

2012-06-01 Diskussionsfäden Alexander Matheisen
  Übrig bleiben jetzt noch folgende Möglichkeiten:
  
  * Relation
 
 Das ist noch kein Datenmodell. Je nachdem, ob Punkte oder auch
 Wegsegmente Relationsmitglieder sind und wie man die role-Elemente
 definiert, ergeben sich verschiedene Vor- und Nachteile.

Ja stimmt, da muss man noch entscheiden, wie man es dann genau macht. Mit ging 
es jetzt erstmal grundsätzlich um die Akzeptanz einer Erfassung per Relation.

Möglich wäre eine Rolle outline wie bei diesem Bridge-Proposal. Das wäre 
dann ein Weg, der die Fläche des BÜs beschreibt. Dann könnte man noch 
Schrankenpositionen und Kreuzungspunkte von Straße und Schiene als Mitglieder 
hinzufügen.

  -Vorteile: ein OSM-Objekt für einen Bahnübergang, sämtliche Sonderfälle
  abdeckbar, Mikromapping möglich
  -Nachteile: komplizierte Erfassung, in der Regel schwieriger auszuwerten
 
 - je nach Modell fehleranfällig


  * Fläche
  -Vorteile: ein OSM-Objekt für einen Bahnübergang, einfacher zu erfassen
  als
  eine Relation, gibt reale Ausdehnung wieder, Positionierung von Schranken
  einfach möglich (zumindest in den meisten Fällen), einfachere Auswertung
  als Relation
 
 - Datenmodell auf andere Verkehrswegekreuzungen (Straßenkreuzung,
 Klappbrücke) übertragbar

Bei Straßenkreuzungen gibt es auch bereits ein Proposal für einen Ampel-Way, 
damit man die Zusammengehörigkeit von mehreren Ampeln an einer Kreuzung 
insbesondere in Routern besser auswerten kann.

  -Nachteile: Probleme bei manchen Sonderfällen (T-Kreuzung mit eigener
  Schranke vor BÜ)
 
 Alex, kannst du ein Beispiel geben? Die Fläche, die bei herannahenden
 Zügen geräumt werden muss, ist doch recht eindeutig.

Vor allem den Mikromappern ging es ja um die genaue Positionierung der 
Schranken und Warnlichter. Bei Standardfällen kann man die Schranken oder 
Lichter automatisch auf die Schnittpunkte von BÜ-Fläche und Straße setzen. 
Allerdings kann es - soweit ich weiß - auch Sonderfälle wie folgenden geben:

| |
===  - Gleis
| |
| |--
| |--
| |

Vor dem Bahnübergang befindet sich in diesem Fall eine Einmündung, die ein 
eigenes Warnsignal/Schranke besitzt. Da dort aber kein Kreuzungspunkt zwischen 
Straße und BÜ-Fläche ist, würde nach dem Standardverhalten dort kein Warnlicht 
gesetzt.

Ein anderer Problemfall: Ein Fußwegübergang neben einer Straße bildet zwar 
zusammen mit dem Straßen-BÜ einen Bahnübergang, aber die Sicherungstechnik des 
Fußwegüberganges kann anders sein als die des Straßen-BÜs. An die gemeinsame 
BÜ-Fläche lässt sich jedoch nur die Sicherungstechnik eines der beiden BÜs 
taggen.

Auf der anderen Seite stellt sich natürlich die Frage, ob man es überhaupt so 
detailliert haben will...


Grüße
Alex

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


Re: [Talk-de] Taggingschema OpenRailwayMap

2012-06-01 Diskussionsfäden Alexander Matheisen
Am Donnerstag, 31. Mai 2012, 11:24:25 schrieb Martin Koppenhoefer:
 Am 30. Mai 2012 21:28 schrieb Alexander Matheisen 
alexandermathei...@ish.de:
   Nicht zu einem Bahnhof zählen danach:
   * Pendlerparkplatz (man kann auch ohne sie mit dem Zug fahren)
   * Radstation (gleicher Grund wie oben)
  
  -1, auch diese gehören m.E. nach der o.g. Definition dazu, weil sie
  den Zu- und Abgang ermöglichen oder fördern. Oder interpretiere ich
  das falsch? Sofern es sich um Einrichtungen auf Bahngelände handelt,
  würde ich es dem Bahnhof zuschlagen.
  
  ...Nebenbetriebsanlagen sowie sonstige Anlagen einer Eisenbahn, die das
  Be- und Entladen sowie den Zu- und Abgang ermöglichen oder fördern.
  
  Für mich klingt das eher nach Bahnsteigen, Beladerampen und Zugangswege.
  So gesehen fallen Bahnsteige nämlich nicht unter zur Abwicklung oder
  Sicherung des Reise- oder Güterverkehrs auf der Schiene erforderlich,
  denn in einen Zug kann man auch ohne Bahnsteig einsteigen (ist dann nur
  etwas hoch). Mit Bahnsteig dagegen ist es angenehmer, damit fördern sie
  den Zu- oder Abgang zum Zug.
 
 Klar, Bahnsteige gehören natürlich damit auch dazu. Ein
 ParkRide-Parkplatz aber auch ein beliebiger anderer Parkplatz auf
 Bahngelände an einem Bahnhof gehört m.E. auch dazu.

Bei den Parkplätzen kann man sich wirklich streiten: Gehört ein Parkplatz für 
Bahnmitarbeiter zum Bahngelände oder nicht?
Meiner Meinung sollte man es aber bei solchen strittigen Punkten nicht zu 
genau nehmen. Ob das nun zum Bahngelände gehört oder nicht liegt dann 
letztendlich in der Freiheit des Mappers.


Grüße
Alex

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


Re: [Talk-de] Mehrgleisige Bahnübergänge

2012-05-31 Diskussionsfäden Alexander Matheisen
  Gegenvorschlag:
  Bahnübergänge können als Fläche erfasst werden. Die Fläche umfasst in
  Straßenrichtung den Bereich zwischen den Andreaskreuzen/Schranken, in
  Gleisrichtung den mit Platten oder Asphalt versehenen Bereich. Die
  Fläche und die kreuzenden Wege haben gemeinsame Punkte.
  
  Hört sich grundsätzlich nicht schlecht an, macht die Erfassung aber auch
  wieder schwieriger: Bei einem Gleis und einer Straße ein Punkt, bei zwei
  Gleisen und einer Straße einen Weg, bei zwei Gleisen und zwei Straßen eine
  Fläche, und was ist dann bei einem Gleis und zwei Straßen?
 
 Nein, nur als Punkt oder als Fläche. Die Flächendefinition ist genauso
 auf nur ein Gleis oder nur einen highway anwendbar.
 Oft hilft ein Bild beim Verständnis. Ich habe einen großen Bahnübergang
 zum Test als Fläche erfasst: [1]. Die Details habe ich von
 Aerowest-Luftbild übernommen.
 
  Und wie erkennt dann ein Routingprogramm den Bahnübergang?
 
 Daran, dass die Straße teilweise innerhalb einer solchen Fläche liegt.
 
 [1] www.osm.org/browse/way/163036823

Um die Diskussion noch einmal aufleben zu lassen:

Eine gute Lösung haben wir ja weiterhin noch nicht gefunden, aber auf jeden 
Fall kann ich schonmal sagen, dass ich von der Way-Lösung Abstand genommen 
habe. Auch dort hat man nämlich ein Problem mit mehreren kreuzenden Straßen.

Übrig bleiben jetzt noch folgende Möglichkeiten:

* Relation
-Vorteile: ein OSM-Objekt für einen Bahnübergang, sämtliche Sonderfälle 
abdeckbar, Mikromapping möglich
-Nachteile: komplizierte Erfassung, in der Regel schwieriger auszuwerten

* Fläche
-Vorteile: ein OSM-Objekt für einen Bahnübergang, einfacher zu erfassen als 
eine Relation, gibt reale Ausdehnung wieder, Positionierung von Schranken 
einfach möglich (zumindest in den meisten Fällen), einfachere Auswertung als 
Relation
-Nachteile: Probleme bei manchen Sonderfällen (T-Kreuzung mit eigener Schranke 
vor BÜ)

* Einzelne Punkte
-Vorteile: einfache Erfassung, einfache Auswertung für Router
-Nachteile: mehrere OSM-Objekte für ein reales Objekt, Zusammengehörigkeit 
nicht immer erkennbar, Positionierung von Schranken etc. nicht einfach möglich

Wer noch weitere Argumente findet, möge die bitte ergänzen!


Gruß
Alex

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


Re: [Talk-de] Taggingschema OpenRailwayMap

2012-05-30 Diskussionsfäden Alexander Matheisen
  Nicht zu einem Bahnhof zählen danach:
  * Pendlerparkplatz (man kann auch ohne sie mit dem Zug fahren)
  * Radstation (gleicher Grund wie oben)
 
 -1, auch diese gehören m.E. nach der o.g. Definition dazu, weil sie
 den Zu- und Abgang ermöglichen oder fördern. Oder interpretiere ich
 das falsch? Sofern es sich um Einrichtungen auf Bahngelände handelt,
 würde ich es dem Bahnhof zuschlagen.

...Nebenbetriebsanlagen sowie sonstige Anlagen einer Eisenbahn, die das Be- 
und Entladen sowie den Zu- und Abgang ermöglichen oder fördern.

Für mich klingt das eher nach Bahnsteigen, Beladerampen und Zugangswege.
So gesehen fallen Bahnsteige nämlich nicht unter zur Abwicklung oder 
Sicherung des Reise- oder Güterverkehrs auf der Schiene erforderlich, denn in 
einen Zug kann man auch ohne Bahnsteig einsteigen (ist dann nur etwas hoch). 
Mit Bahnsteig dagegen ist es angenehmer, damit fördern sie den Zu- oder Abgang 
zum Zug.


Gruß
Alex

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


Re: [Talk-de] Taggingschema OpenRailwayMap

2012-05-23 Diskussionsfäden Alexander Matheisen
Am Montag, 14. Mai 2012, 18:42:33 schrieb Garry:
 Am 14.05.2012 16:45, schrieb Max:
  n Deutschland stimmt das. In vielen anderen Ländern gibt es keine
  Verbindungen zwischen Hochgeschwindigkeitsnetz und regulärer Bahn.
  Nachtrag: mir ist ein Beispiel eingefallen.
  In Taiwan gibt es die High-Speed-Rail (HSR). Die wird im Linksverkehr
  betrieben, das restliche Schienennetz im Rechtsverkehr. Möglicherweise
  hat die HSR auch eine andere Spurweite und eine andere Elektrifizierung.
 Der Mischbetrieb dürfte dennoch häufiger sein, ist mir jetzt jedenfalls
 nicht bekannt dass es sehr viele Länder überhaupt mit
 Hochgeschwindigkeitsnetz gibt.
 Von daher sehe ich es als praxistauglicher ein Zusatztag für die
 Hochgeschwindigkeitsbereiche zu vergeben als Streitfälle zu provozieren
 ob das jetzt eine
 rail = highspeed Streckentyp ist.

OK, werde es ändern. Mir ist nämlich auch aufgefallen, dass es bei den 
Ausbaustrecken schwierig zu definieren ist. Ich würde vorschlagen usage=main 
und highspeed=yes.


Gruß
Alex

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


Re: [Talk-de] Taggingschema OpenRailwayMap

2012-05-23 Diskussionsfäden Alexander Matheisen
 Wo endet ein Personenbahnhof? Am Bahnsteigende, am Ausfahrsignal oder
 an der letzten Weiche? Gehören das Nebengleis ohne Bahnsteig, das alte
 Bahnhofsgebäude mit Fahrkartenautomat, Restaurant und Bankfiliale, die
 Fahrradständer und der Pendlerparkplatz dazu?

Ich würde sagen, man übernimmt weitgehend die Definition der EBO 
(http://www.gesetze-im-internet.de/ebo/__4.html). Auch wenn das Projekt 
international ist, lassen sich die deutschen Definitionen wahrscheinlich ohne 
Probleme auch auf andere Länder übertragen.

Bahnhofsbegrenzung in Gleisrichtung:
Die Einfahrsignale oder Trapeztafeln beider Richtungen, sonst die 
Einfahrweichen bzw. ersten Weichen. Im Ausland sollte sich die Definition mit 
den Einfahrsignalen auch anwenden lassen. Sonst nimmt man eben die 
Einfahrweichen.

Bahnhofsbegrenzung zur Seite:
Laut EBO: Bahnanlagen sind alle Grundstücke, Bauwerke und sonstigen 
Einrichtungen einer Eisenbahn, die unter Berücksichtigung der örtlichen 
Verhältnisse zur Abwicklung oder Sicherung des Reise- oder Güterverkehrs auf 
der Schiene erforderlich sind. Dazu gehören auch Nebenbetriebsanlagen sowie 
sonstige Anlagen einer Eisenbahn, die das Be- und Entladen sowie den Zu- und 
Abgang ermöglichen oder fördern. Es gibt Bahnanlagen der Bahnhöfe, der freien 
Strecke und sonstige Bahnanlagen. Fahrzeuge gehören nicht zu den Bahnanlagen.

Auch diese Definition lässt sich meiner Meinung gut auf OSM übertragen.
Für mich zählen nach dieser Definition zu einem Bahnhof:
* Gleise
* Bahnsteige
* Lokschuppen
* Bahnhofsgebäude
* Stellwerk
* Verladerampen für Autozüge

Nicht zu einem Bahnhof zählen danach:
* Pendlerparkplatz (man kann auch ohne sie mit dem Zug fahren)
* Radstation (gleicher Grund wie oben)

Unklar bin ich mir noch bei Parkplätzen für Bahnmitarbeiter, die mit Schildern 
als Bahngelände - Betreten verboten gekennzeichnet sind. Die sind so gesehen 
auch nicht für den Bahnbetrieb notwendig, aber rechtlich schon Bahngelände. 
Genauso wie stillgelegte oder zugewucherte Bahngelände, die mit Schildern als 
Bahngelände markiert sind.

  - Die Verbindung verschiedener Gleise sollte auch ohne Zusatztag
  
  railway=switch als Weiche ausgewertet werden.
  Der Sonderfall (Kreuzung ohne Kreuzungsweiche) sollte die
  Zusatzinformation als Tag oder Abbiegerelation bekommen.
  
  Du hast schon recht, allerdings lasse ich das lieber zur Verdeutlichung.
  An
  den anderen Tags wue würde sich ja nichts ändern und so wäre eine normale
  Weiche z.B. mit ref=W1 und railway:manual=yes getaggt. Für
  nicht-eingeweihte ist dann nicht unbedingt klar, worauf sich die Tags
  beziehen. Eine statistische Abfrage, wieviele Weichen erfasst sind, ist
  außerdem einfacher möglich (z.B. in Taginfo).
 
 Die bislang etablierte Logik, dass eine Verbindungspunkt ohne Tags als
 Weiche ausgewertet wird, darf man nicht umkehren. Wie bei den
 Abbiegerelation sollte man die Ausnahmen erfassen. Für eine einfache
 Kreuzungsweiche braucht man ohnehin solch ein Modell, um die möglichen
 Verbindung korrekt zu erfassen.
 Wer Details der Weiche erfassen möchte, mag railway=switch verwenden.
 Aber muss man nicht überall das Tag nachtragen.

Ich wäre für ein explizites Tagging.
Bei Weichen (dreigleisigen Gleisverbindungen) würde ich zur Kompatibilität 
aber vorschlagen, dass solche Gleisverbindungen ohne railway=switch als Weiche 
interpretiert werden.
Bei Kreuzungen (viergleisigen Gleisverbindungen) ist auf jeden Fall explizites 
Tagging notwendig. (Doppel-)Kreuzungsweichen würden dann mit railway=switch 
und den entsprechenden Tags und Kreuzungen ohne Weichenfunktion mit 
railway=level_junction getaggt.

  - usage=highspeed ist inkompatibel zum etablierten usage=main
  
  Die Diskussion hatten wir bereits...
  Ich bleibe dabei: Eine Hochgeschwindigkeitsstrecke ist etwas anderes als
  eine normale Hauptstrecke und sollte daher anders getaggt werden. Eine
  Autobahn taggt man auch nicht highway=primary und highspeed=yes...
 
 Eine Autobahn ist keine spezielle Bundesstraße während eine
 Hochgeschwindigkeitsstrecke vermutlich als Hauptstrecke gilt.
 Aber abgesehen von Spitzfindigkeiten: wenn du ein etabliertes Tag wie
 usage=main umdefinieren willst, muss du das als gesondertes Proposal
 und nicht innerhalb eines umfangreichen Eisenbahnschemas vorschlagen.

Habe es mittlerweile doch geändert (siehe entsprechender Mail).


Gruß
Alex

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


Re: [Talk-de] Taggingschema OpenRailwayMap

2012-05-23 Diskussionsfäden Alexander Matheisen
Am Mittwoch, 23. Mai 2012, 20:06:27 schrieb Jimmy_K:
 Am 14.05.2012 00:14, schrieb Stephan Wolff:
  Am 13.05.2012 00:45, schrieb Alexander Matheisen:
  - Für alle Flächen, insbesondere die Bahnhöfe/Rangierbahnhöfe, solltest
  
  du definieren, was dazu gehört
  
  Ist das nicht irgendwie selbstverständlich? (Gut, ich als Bahnexperte
  kann
  jetzt wahrscheinlich nicht nachvollziehen, wo da die Unklarheit ist. Du
  müsstest mir da mal auf die Sprünge helfen).
  
  Wo endet ein Personenbahnhof? Am Bahnsteigende, am Ausfahrsignal oder
  an der letzten Weiche? Gehören das Nebengleis ohne Bahnsteig, das alte
  Bahnhofsgebäude mit Fahrkartenautomat, Restaurant und Bankfiliale, die
  Fahrradständer und der Pendlerparkplatz dazu?
 
 Das ist das alte Problem, mit welchem auch schon die EWG kämpft.
 Bei der Festlegung vom ETCS hatte man schon Probleme einen Zug zu
 definieren.
 
 Ich bin bei der Definition sehr großzügig und würde fast alles, was nur
 irgendwie einen direkten Zusammenhang zum Bahnhof hat, in die Fläche
 integrieren.

Ich würde es da auch nicht so eng sehen. Schließlich brauchen wir keine 
genauen Katasterdaten, sondern die Information, welche Fläche von der Bahn
Wenn man Gleise, Bahnsteige, Lokschuppen, Bahnhofsgebäude und Stellwerke mit 
dieser Fläche erfasst hat, dann ist das auf jeden Fall nicht falsch. Ob jetzt 
irgendein Parkplatz dazu gehört, darüber kann man sich streiten. Und Ausnahmen 
bestätigen immer die Regel... In Einzelfällen kann man immer noch individuell 
entscheiden.


Gruß
Alex

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


Re: [Talk-de] railway = crossing

2012-05-23 Diskussionsfäden Alexander Matheisen
  Ich überlege daher, ob ich ich nicht bei meinem Taggingschema zur
  OpenRailwayMap diese Unterscheidung herausnehme. Allerdings hat das wieder
  Konflikte mit den bisherigen Definitionen zur Folge.
  Was meint ihr dazu?
 
 Wir sollten überflüssiges nicht grundlos weiterverwenden.
 Im Taggingschema solltest du aber deutlich schreiben, dass dies
 ein Vorschlag ist, der nicht der bisherigen Definition entspricht.
 
 Da niemand auf meine Frage Welche Anwendung benötigt die
 Unterscheidung? ein Beispiel nennen konnte, gibt es vermutlich
 auch keine Konflikte zu bestehenden Anwendungen.

Für welche (bisherige) Anwendung sollte diese Unterscheidung auch interessant 
sein? Auf einer normalen Karte wie Mapnik ist es eher unnötig, da der 
Standardnutzer wahrscheinlich wenig am Unterschied interessiert ist. Der will 
nur auf der Karte sehen, ob er da rüber kann und erkennt den Rest am 
kreuzenden Weg. Soweit ich das bisher gesehen habe, gibt es da auch keine 
Unterscheidung.
Routing-Anwendungen interessiert nur, dass da ein Übergang ist. Dass er nur 
für Fußgänger ist, ergibt sich schon aus dem kreuzenden Weg.


Einzig Bahn-Anwendungen wären vielleicht daran interessiert.
Wenn man beispielsweise einen Streckenverlauf erzeugen will, auf dem in 
abgefahrener Reihenfolge Bahnhöfe, BÜs und anderes aufgelistet werden, braucht 
man zwar keine Unterscheidung zwischen Fuß-Übergang und Fahrzeug-Übergang, 
aber es wäre schön, wenn man keine kleinen Holzbohlen-Überwege für 
Bahnmitarbeiter als normale Bahnübergänge aufgelistet bekommt.
Beispiel: 
http://upload.wikimedia.org/wikipedia/commons/e/e2/Gleis%C3%BCbergang_Bad_Kissingen_Bahnhof.JPG
im Gegensatz zu solchen Bahnübergängen, die ich einheitlich mit Straßen-BÜs 
taggen würde:

http://farm6.static.flickr.com/5039/5871036474_df23ffd879_b.jpg
http://upload.wikimedia.org/wikipedia/commons/3/38/Umlaufgitter.jpg


Es stellt sich aber die Frage, ob man auch diese Unterscheidung wirklich 
braucht. Denn auf der anderen Seite könnte man auch sagen, dass nur 
öffentliche Bahnübergänge eingetragen werden sollen.
Kleine Überwege für Bahnmitarbeiter dagegen sind unnötig, weil sie in dem 
Sinne keinen Bahnübergang darstellen (keine Sicherung, kein Andreaskreuz, 
keine Pfeiftafel) und Bahnmitarbeiter eigentlich überall auf dem Bahngelände 
Gleise auf eigene Gefahr überqueren dürfen.

 Ich würde allerdings gleich einen Schritt weitergehen und ein
 Datenmodell einführen, dass auch für einen Bahnübergang aus
 mehreren railways und/oder mehreren highways genau ein OSM-
 Objekt vorsieht (entweder als Flächen- oder Relationmodell).
 Das würden einen Vorteil speziell für Routinganwendungen
 bringen.

Damit beschäftige ich mich bereits und dazu läuft auch seit einiger Zeit eine 
Diskussion hier auf der Liste.


Gruß
Alex

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


Re: [Talk-de] railway = crossing

2012-05-21 Diskussionsfäden Alexander Matheisen
Hallo,

  railway = crossing --  Fußweg kreuzt mit Bahnschienen
  railway = level_crossing --  Straße kreuzt mit Bahnschienen
  
  Was setzt man, wenn sich ein Gleis, eine Straße und ein Fußweg im gleichen
  Punkt kreuzen?
 
 Im Zweifel kann man railway = level_crossing setzen. An fast jedem
 Bahnübergang mit Straßenverkehr kreuzen auch Fußgänger das Gleis.
 
 Welche Anwendung benötigt die Unterscheidung? Braucht man die Tags
 überhaupt? Die Information ist doch schon vorhanden, wenn ein Punkt
 sowohl in einen railway als auch highway enthalten ist. Für Router
 oder Bahnsimulatoren dürfte ein Objekt Bahnübergang wertvoller sein
 als mehrere einzelne Kreuzungspunkte (siehe Thread Mehrgleisige
 Bahnübergänge).

Ich verstehe irgendwie auch nicht so ganz die Unterscheidung. Was ist bei 
einem kleinen unbeschrankten Bahnübergang an einem Feldweg? Wenn dort 
Traktoren fahren ist es ein level_crossing und wenn nur Fußgänger dort lang 
dürfen ein crossing?

Für mich ist diese Unterscheidung irgendwie unnötig, da sich der Typ anhand 
des Typs des kreuzenden Weges herausfinden lässt.

Ich überlege daher, ob ich ich nicht bei meinem Taggingschema zur 
OpenRailwayMap diese Unterscheidung herausnehme. Allerdings hat das wieder 
Konflikte mit den bisherigen Definitionen zur Folge.
Was meint ihr dazu?


Gruß
Alex

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


Re: [Talk-de] Taggingschema OpenRailwayMap - disused/abandoned

2012-05-15 Diskussionsfäden Alexander Matheisen
 http://wiki.openstreetmap.org/wiki/Railway
 die Seite nennt noch mehr Stufen, die Sinn machen wie ich finde:
 
 preserved - noch als Museumsbahn in Betrieb
 
 disused - nicht benutzt aber funktionsfähig oder mit geringem Aufwand
 wieder in Betrieb zu nehmen
 
 abandoned - Gleis abgebaut oder dem Verfall Preis gegeben , Strecke
 noch erkennbar
 
 obliterated - vollständig rückgebaut, ggf. durch Neubauten überformt,
 Strecke ggf. nicht mehr ohne Weiteres erkennbar


Ist in meinem Schema bereits genu so vorhanden, außer, dass ich statt 
railway=obliterated railway=razed verwende.


Gruß
Alex

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


Re: [Talk-de] Taggingschema OpenRailwayMap - disused/abandoned

2012-05-15 Diskussionsfäden Alexander Matheisen
  Der Rechtsstaus dürfte für praktisch keinen Anwender von Bedeutung sein.
  Und
 Das ist für jeden relevant der sich auf dem Gelände aufhält. Bei
 Stillgelegt ist es nach wie vor ein Bahngelände und das
 Eisenbahngesetz greift.
 z.B.
 http://www.jusline.at/47._Betreten_hief%C3%BCr_nicht_bestimmter_Stellen_von_
 Eisenbahnanlagen_EisBG.html
 
 Bei einer entwidmeten Strecke ist es dagegen kein Bahngelände mehr im
 Sinne des Eisenbahngesetz so dass dieses nich mehr greift.

Es hat keinen praktischen Nutzen! 

  Leute, für die das wichtig ist, würden dafür sowieso nicht OSM benutzen.
 
 Wenn man mit schwammigen Tags diese Unterscheidungsmöglichkeit in OSM
 unterbindet haben sie erst gar keine Möglichkeit OSM dafür zu nutzen.

Schwammige Tags? In meinem Schema wird gibt es eine klare Definition der Tags, 
die auch mit bisherigen Definitionen im Wiki übereinstimmt.
Und natürlich bleibt eine andere Unterscheidungsmöglichkeit offen. OSM ist 
frei, man kann einfach ein passendes Tag für genau diese Information 
definieren.


Gruß
Alex

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


Re: [Talk-de] Taggingschema OpenRailwayMap - disused/abandoned

2012-05-15 Diskussionsfäden Alexander Matheisen
  Spricht ja nichts dagegen wenn er den Gleiszustand einträgt, aber dafür
  ist disused/abandoned nicht geeignet.
  
  Doch, das Tag ist genau dafür geeignet.
 
 Was machst Du bei einer Strecke an der abschnittsweise die Gleise
 fehlen, (was recht häufig vorkommt)?
 Stillgelegt oder entwidment ist meist die komplette Strecke, nicht nur
 die Abschnitte an denen die Gleise (nicht)entnommen wurden.

Da, wo die Gleise vorhanden sind, ist es disused (Wiki-Definition: the 
feature is still in working order, or could be brought back to working order 
easily). Auch wenn die Strecke endwidmet ist, kann rein physikalisch ohne 
größeren Aufwand wieder der Betrieb aufgenommen werden.
An den Stellen, an denen keine Gleise vorhanden sind, taggt man es als 
abandoned (Wiki-Definition: The track has been removed and the line may have 
been reused or left to decay but is still clearly visible, either from the 
replacement infrastructure, or purely from a line of trees around an original 
cutting or embankment.).

Sorry, aber mittlerweile hat diese Diskussion keinen wirklichen Sinn mehr. 
Diskutiere von mir aus mit anderen hier weiter, ich habe wirklich besseres zu 
tun...


Gruß
Alex

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


Re: [Talk-de] Taggingschema OpenRailwayMap - disused/abandoned

2012-05-14 Diskussionsfäden Alexander Matheisen
  - ein Mapper den Gleiszustand sieht und einfach eintragen kann,
 
 Spricht ja nichts dagegen wenn er den Gleiszustand einträgt, aber dafür
 ist disused/abandoned nicht geeignet.

Doch, das Tag ist genau dafür geeignet.

  - für typische OSM-Nutzer (Wanderer, Radfahrer, Segelflieger) der
  
physikalische relevanter als der rechtliche Status ist

+1

Zumindest im Eisenbahnatlas Deutschland (http://www.schweers-
wall.de/atlas_deutschland.html), der unter anderem von der Deutschen Bahn und 
vielen Privatbahnen verwendet wird, unterscheidet man auch neben der aktiven 
Strecken nur zwischen außer Betrieb und abgebaut bzw. unbefahrbahr.

Das zeigt doch, dass selbst für professionelle und geschäftliche Anwender der 
physikalische Zustand völlig ausreichend ist.
Wir erfassen Daten für normale Menschen. Und die interessiert nur der 
physikalische Zustand. Der rechtliche Status ist höchstens für Katasterämter 
interessant.

Parallel dazu ist doch bei einem Geschäft auch nur interessant, ob es etwas 
verkauft oder nicht. Ob die Geschäftsräumlichkeiten noch dem Besitzer gehören 
oder nicht, ist auch nur eine Behörde von Relevanz.

  Den Rechtsstatus (stillgelegt/entwidmet) kann man, sofern bekannt,
  in ein Zusatztag stecken.

+1


Grüße
Alex

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


Re: [Talk-de] Taggingschema OpenRailwayMap - disused/abandoned

2012-05-14 Diskussionsfäden Alexander Matheisen
 Ich bin anderer Meinung. disused/abandoned sollte nach vorhandenen/
 entfernten Gleisen unterscheiden, weil
 - dies der bisherigen Definition im Wiki entspricht
 - ein Mapper den Gleiszustand sieht und einfach eintragen kann,
den rechtlichen Status aber meist nicht kennt
 - für typische OSM-Nutzer (Wanderer, Radfahrer, Segelflieger) der
physikalische relevanter als der rechtliche Status ist

+1

 Den Rechtsstatus (stillgelegt/entwidmet) kann man, sofern bekannt,
 in ein Zusatztag stecken.

+1

Der Rechtsstaus dürfte für praktisch keinen Anwender von Bedeutung sein. Und 
Leute, für die das wichtig ist, würden dafür sowieso nicht OSM benutzen.


Grüße
Alex

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


Re: [Talk-de] Taggingschema OpenRailwayMap

2012-05-12 Diskussionsfäden Alexander Matheisen
Hallo Stefan,

 Am 07.05.2012 19:33, schrieb Alexander Matheisen:
  Das Taggingschema habe ich aufgeteilt in das vollständige
  http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Erweitertes_Tagging
  sowie eine gekürzte Version für Bahnlaien:
  http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Vereinfachtes_Tagging
 
 Schon das vereinfachte Schema ist sehr umfangreich. Ich konnte die Texte
 bislang nur überfliegen, habe aber trotzdem einige Anmerkungen:
 
 - Bitte markiere, welche Tags etabliert sind und welche neue Vorschläge
von dir sind

OK, werde ich noch ergänzen.

 - Für alle Flächen, insbesondere die Bahnhöfe/Rangierbahnhöfe, solltest
du definieren, was dazu gehört

Ist das nicht irgendwie selbstverständlich? (Gut, ich als Bahnexperte kann 
jetzt wahrscheinlich nicht nachvollziehen, wo da die Unklarheit ist. Du 
müsstest mir da mal auf die Sprünge helfen).

 - Ich habe railway=station als Personenbahnhof verstanden. Die
Ausweitung auf Güterbahnhöfe finde ich falsch.

Dafür ist auch eigentlich railway=yard vorgesehen. Da hatte ich wohl noch eine 
alte Definition nicht überall angepasst. Ist nun korrigiert.

 - Die Verbindung verschiedener Gleise sollte auch ohne Zusatztag
railway=switch als Weiche ausgewertet werden.
Der Sonderfall (Kreuzung ohne Kreuzungsweiche) sollte die
Zusatzinformation als Tag oder Abbiegerelation bekommen.

Du hast schon recht, allerdings lasse ich das lieber zur Verdeutlichung. An 
den anderen Tags wue würde sich ja nichts ändern und so wäre eine normale 
Weiche z.B. mit ref=W1 und railway:manual=yes getaggt. Für nicht-eingeweihte 
ist dann nicht unbedingt klar, worauf sich die Tags beziehen. Eine 
statistische Abfrage, wieviele Weichen erfasst sind, ist außerdem einfacher 
möglich (z.B. in Taginfo).
Nebenbei bemerkt: Nach deiner Argumentation könnte man bei Bahnübergängen auch 
das Tag railway=level_crossing weglassen, denn eine Kreuzung von Straße und 
GLeis kann nur ein Bahnübergang sein.

 - bridge_name ist bislang häufiger als bridge:name (siehe taginfo)

Das ist mir bewusst, aber man wird zwangsläufig sich auf eine Variante einigen 
müssen. Wenn meine Karte die erste(?) Anwendung ist, die dieses Tag auswerten 
würde, dann ließe sich bei dieser Gelegenheit endlich eine Vereinheitlichung 
durchführen. Übrigens kommt tunnel:name wiederum häufiger vor als tunnel_name. 
Wenn, dann sollte bei beiden ein einheitliches Schema gewählt werden.
Ich bin klar für die Variante tunnel/bridge:name, weil dort deutlicher wird, 
dass der Name auf das Tag tunnel/bridge bezogen ist (und weil ich sowieso ein 
Freund von Subkeys bin, siehe meinem Taggingschema).

 - railway:short ist kein intuitiv verständlicher Name. ref oder
railway:ref wären sinnvoller.

ref würde ich nicht verwenden, da es bisher oft für andere Dinge wie die ÖPNV-
Linien verwendet wurde. railway:ref hört sich aber ganz gut an...

 - usage=highspeed ist inkompatibel zum etablierten usage=main

Die Diskussion hatten wir bereits...
Ich bleibe dabei: Eine Hochgeschwindigkeitsstrecke ist etwas anderes als eine 
normale Hauptstrecke und sollte daher anders getaggt werden. Eine Autobahn 
taggt man auch nicht highway=primary und highspeed=yes...


Gruß
Alex

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


Re: [Talk-de] Mehrgleisige Bahnübergänge

2012-05-10 Diskussionsfäden Alexander Matheisen
 Kannst du das mal mittels eines Beispieltaggigns untermauern? Bü-Tag
 kann alles und nichts bedeuten. Ich würde darunter verstehen, dass ich
 das kurze Wegstück als
 
 highway=secondary
 railway=level_crossing
 ref=A4
 maxspeed=50
 
 erfassen würde. Sieht irgendwie etwas komisch aus mit der Mischung aus
 Straßen- und Bahntags.

Genau so meinte ich das.

 Ich glaube, die Zusammengehörigkeit lässt sich viel einfacher
 algorithmisch auf Grund der Nähe der Übergänge erfassen.

Das ist zwar auf diese Weise möglich, aber auch wieder aufwändig. Außerdem 
widerspricht es ein wenig der Logik: mehrere Bü-Punkt für einen tatsächlichen 
Bahnübergang.


Gruß
Alex

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


Re: [Talk-de] Mehrgleisige Bahnübergänge

2012-05-10 Diskussionsfäden Alexander Matheisen
 Was ist gemeint mit zwischen den Bahngleisen? Ich
 vermute mal, zwischen den Schnittpunkten der Schienen mit den Straßen,
 aber logischer wäre m.E., wenn es im Bahnübergangsbereich wäre
 anstatt zwischen den Schienen. Dann bräuchte man auch nicht zwischen
 ein- und mehrgleisigen Strecken unterscheiden. Bei unbeschrankten
 Bahnübergängen muss man sich ggf. eine Definition überlegen, wo der
 Bahnübergang anfängt, bei solchen mit Schranken würde ich diese als
 Grenze sehen.

Ich meinte zwischen den Schnittpunkten der Schienen (abstrakter), aber man 
könnte sich auf darauf festlegen, die Trennung an der Position der Schranke, 
des Andreaskreuzes, der Haltelinie, etc. zu machen (realitätsgetreuer).


Gruß
Alex

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


Re: [Talk-de] Mehrgleisige Bahnübergänge

2012-05-10 Diskussionsfäden Alexander Matheisen
 Büs ohne Schranken, haben meist eine Haltelinie. Würde sich auch gut als
 Start- und Endpunkt eignen.
 Relationen würde ich nicht wirklich als notwendig erachten.

+1

 Zwischen den Schranken bzw. Haltelinien an die Straße
 railway=level_crossing; an die Position des Schranken ein
 barrier=railway_gate oder an die Haltelinie ein barrier=railway_light
 oder =railway_stop.

Das macht es meiner Meinung wieder ein bisschen kompliziert. Trennt man den 
Bahnübergangsweg an den Positionen der Schranken oder am Andreaskreuz, dann 
kann man doch die Schranke standardmäßig an den Endpunkten des Bü-Weges 
setzen. Außnahme sind natürlich Sonderfälle wie eine Einmündung vor einem Bü, 
sodass an der einmündenden Straße auch nochmal Andreaskreuze und Warnlichter 
stehen.
Würde man zum Bü-Weg separat nochmal die Schranken erfassen, hätte das den 
Nachteil, dass man dort auch wieder Voll-/Halbschranke, etc. angeben müsste, 
die Informationen also doppelt vorliegen. Denn am Bü-Weg müssten sie bleiben, 
sonst wären Abfragen wie Alle BÜs mit Halbschranken in Deutschland nicht 
möglich (bzw. mit etwas Schwierigkeiten schon: alle Bü-Wege, auf denen ein 
Node einer Halbschranke sitzt).


Gruß
Alex

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


Re: [Talk-de] Mehrgleisige Bahnübergänge

2012-05-10 Diskussionsfäden Alexander Matheisen
  Büs ohne Schranken, haben meist eine Haltelinie. Würde sich auch gut als
  Start- und Endpunkt eignen.
  Relationen würde ich nicht wirklich als notwendig erachten.
 
 Eigentlich halte ich den way-Ansatz auch für ausreichend - zumindest,
 wenn man sich mit einer gewissen Abstraktion abfinden kann.

+1

 Wenn man es abstrahiert, fallen Halteline und Schranken eh zusammen -
 wenn nicht, sind wir wieder beim Micro-Mapping - früher oder später
 wahrscheinlich sowieso. ;-)

In den Normalfällen kann man wie bereits gesagt die Schranken und Lichter 
immer an die Endpunkte der Wege setzen. Bei Sonderfällen wäre das dann nicht 
exakt realitätsgetreu, aber ich wüsste nicht, wofür außer bei 3D Anwendungen 
die Positionen der Schranken und Lichter so wichtig ist. Für alle anderen 
Anwendungen ist die abstrahierte Variante völlig ausreichend. Beim Routing zum 
Beispiel ist doch nur die Anzahl der BÜs wichtig.

Nebenbei bemerkt: Wenn man ein realitätsgetreues 3D-Abbild der Umgebung, ist 
es glaube ich einfacher, eine Art Streetview aufzusetzen, statt mit Tags jedes 
kleinste Detail zu beschreiben. Wir wollen bei OSM doch eher abstrahierte 
Geodaten, die vor allem für Karten (und nicht Pseudo-Luftbilder), für Suchen 
und fürs Routing verwendet werden sollen.
Soweit meine Meinung... 

an die Position des Schranken ein
  
  barrier=railway_gate oder an die Haltelinie ein barrier=railway_light
  oder =railway_stop.
 
 Wenn man es abstrahiert, sind die Tags am crossing-way besser
 aufgehoben, da sie dann bereits eine Richtung beinhalten. Z. B. gelten
 nur Vollschranken in absolut beide Richtungen. ;-)
 
 Und beim Micro-Mapping weiß ein 3D-Renderer ohne nähere Information oder
 Ableitung der Gesamtsituation auch nicht weiter, wie herum er das
 Blinksignal und wo er die einseitige(!) Haltelinie ausrichten soll.

+1


Gruß
Alex

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


Re: [Talk-de] Mehrgleisige Bahnübergänge

2012-05-10 Diskussionsfäden Alexander Matheisen
 Es gibt aber auch Situationen wie hier [1], wo die Haltelinie für Autos
 vor einer Kreuzung liegt, die nicht zum Bahnübergang gehört.
 
 Darüberhinaus gibt es auch Bahnübergänge, bei denen sich der Weg
 zwischen den Schranken verzweigt. Das habe ich gerade letztes Wochenende
 gesehen, ich glaube es war hier [2]. Wenn das die richtige Stelle ist,
 dann ist eine Schranke auf jeder Seite der Merkelstraße  (das als
 abandoned eingezeichnete Gleis existiert noch) und eine Schranke bei der
 Straße Am Bahndamm (wenn das nicht die richtige Stelle ist, dann
 existiert eine andere Stelle, die diese Topografie hat).
 
 Das - und ähnliche Topografien - wird schwierig mit einem Weg
 darstellbar sein, es sei denn, man definiert, dass keine Schranke
 gerendert wird, wenn der BÜ-Weg an einem anderen BÜ-Weg aufhört. Hier
 fände ich aber eine Relation sinnvoller.
 
 Ich glaube, ich fände es am sinnvollsten, wenn man beides zulässt - eine
 Relation mit BÜ-Wegen und Schranken-Knoten oder einzelne BÜ-Wege, die
 implizite Schranken-Knoten an jedem Ende haben.

Wenn man wirklich all diese Sonderfälle abdecken will, dann ist man wieder 
beim Micromapping. Aber: Für welche Anwendung außer 3D-Rendering ist es denn 
ernsthaft interessant, wo genau nun die Schranken stehen. Beim 3D-Rendering 
gibt es meiner Meinung erstmal wichtigere Dinge - bevor man Bahnübergänge bis 
ins Detail erfasst, sollte man sich eher um eine in Ansätzen realitätsnahe 
Darstellung von Gebäuden oder mehrspurigen Straßen kümmern. Die beeinflussen 
das Aussehen einer 3D-Stadtansicht doch mehr als ein einzelner Bahnübergang, 
bei dem eine Schranke fehlt.


Gruß
Alex


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


Re: [Talk-de] Mehrgleisige Bahnübergänge

2012-05-10 Diskussionsfäden Alexander Matheisen
 Nachteile:
 - Oft kreuzen mehrere highways die Gleise (Radweg, Straße,
 Straße-Gegenrichtung, Radqweg). Dann hätte man nicht ein OSM-Objekt
 sondern vier Bü-Wege. Die Zählung, wie viele BÜ es auf einer Bahnstrecke
 gibt,
 wäre falsch.

Stimmt.

 - Bü-Wege und einfache Kreuzungspunkte lassen sich schlecht in einer
 universellen Renderregel zusammenfassen.

Wieso? Zumindest für Mapnik wüsste ich konkret, wie man das Rendern kann.

 - Einen BÜ als lineares Objekt anzulegen, finde ich unlogisch

Das ist dann eben die Abstraktion...
So gesehen ließe sich alles als Fläche erfassen, aber schon bei den Straßen 
sieht man, dass ein wenig Abstraktion (Wege statt Flächen) hilfreich sein 
kann.

 Gegenvorschlag:
 Bahnübergänge können als Fläche erfasst werden. Die Fläche umfasst in
 Straßenrichtung den Bereich zwischen den Andreaskreuzen/Schranken, in
 Gleisrichtung den mit Platten oder Asphalt versehenen Bereich. Die
 Fläche und die kreuzenden Wege haben gemeinsame Punkte.

Hört sich grundsätzlich nicht schlecht an, macht die Erfassung aber auch 
wieder schwieriger: Bei einem Gleis und einer Straße ein Punkt, bei zwei 
Gleisen und einer Straße einen Weg, bei zwei Gleisen und zwei Straßen eine 
Fläche, und was ist dann bei einem Gleis und zwei Straßen?

Und wie erkennt dann ein Routingprogramm den Bahnübergang?
Dass es ein Problem gibt, wenn mehrere Straßen das Gleis überqueren stimmt, 
aber von BÜs als Flächen bin ich noch nicht so recht überzeugt.


Gruß
Alex

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


Re: [Talk-de] Mehrgleisige Bahnübergänge

2012-05-10 Diskussionsfäden Alexander Matheisen
  Meine bisherigen Ideen: Relation oder Bü-Weg.
 
 Mit dem Bü-Weg sehe ich das mögliche Problem, dass gegenüber einem Tag
 an den einzelnen Kreuzugsnodes bei diesem Weg keine leicht
 nachvollziehbare Kennzeichnung an der Bahnlinie mehr dran ist. Will ich
 also möglicherweise eine Auswertung machen, wo ich Bahnlinien entlang
 fahre und ihre Bahnübergänge ansehe, dann kann ich nicht mehr nur auf
 die Nodes der Bahnlinie selbst schauen, sondern muss die kreuzenden
 Highways auch mit interpretieren.

+1
Dein Einwand ist berechtigt. Es ist damit tatsächlich etwas schwieriger 
auszuwerten. Allerdings ist das mit ein wenig Aufwand auch möglich. Zuerst 
würde man alle railway=rail und railway=level_crossing aus den Daten 
herausfiltern. Dann könnte man bei jedem BÜ-Weg die Tags auf die Nodes 
vererben, aus denen er besteht. Und schon hat man die BÜs wieder als 
einzelne - wenn auch doppelte - Punkte auf dem Gleis. Für Anwendungen wie du 
sie beschreibst ist es ja ohnehin besser, auf jedem Kreuzungspunkt einen BÜ-
Punkt zu haben.

 Ob es solche Auswertungen in der Praxis gibt, ist natürlich eine andere
 Frage.

Noch gibt es solche Auswertungen nicht, aber ich habe durchaus den Plan, so 
eine Funktion zu meiner OpenRailwayMap irgendwann hinzuzufügen. Meine Vision: 
Man gibt Start und Ziel oder eine Streckennummer an und die Software generiert 
einem eine Liste ähnlich der Streckverläufe in Wikipedia:

KM 12.3 Köln Hbf
KM 14.7 BÜ I - Lindenstraße
KM 16.1 Abzw Musterstadt - nach Beispielstadt
KM 20.8 Düsseldorf Hbf

Wie gesagt aber noch eine Vision... ;)

Was natürlich bei einem Bü-Weg einfacher ist, ist die Ermittlung des Namens 
der kreuzenden Straße.


Gruß
Alex

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


[Talk-de] Mehrgleisige Bahnübergänge

2012-05-09 Diskussionsfäden Alexander Matheisen
Hallo,

im Zusammenhang mit dem Taggingschema meiner (geplanten) OpenRailwayMap ist 
wieder die Frage aufgekommen, wie man mehrgleisige Bahnübergänge sinnvoll 
erfassen sollte.

Meine bisherige und pragmatische Lösung ist einfach ein Bü-Punkt für jede 
Kreuzungsstelle: 
http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Erweitertes_Tagging#Bahn.C3.BCbergang

Problem: Es ist schwierig auszuwerten, ob die einzelnen Bahnübergänge 
zusammengehören.
Man müsste eine Lösung finden, die bei allen möglichen Anwendungsfällen 
(Rendering, 3D, Routing, Suche) Sinn macht.

Meine bisherigen Ideen: Relation oder Bü-Weg. Bei der Relation habe ich noch 
keine genaueren Vorstellungen (finde ich auch etwas kompliziert), bei der 
zweiten Variante schwebt mir folgendes vor:

Bei eingleisigen BÜs wird wie bisher der Kreuzungspunkt getaggt. Bei z.B. 
zweigleisigen Strecken bekommt das Wegstück zwischen beiden Gleisen die 
üblichen Bü-Tags. Vorteil: Der Bahnübergang ist ein Objekt (gut für 
Suchanwendungen), das Routing könnte solche Wegstücke vermeiden, bei 3D-
Anwendungen ließen sich Schranken an den Wegenden rendern und beim normalen 
2D-Kartenrendering zeichnet man das Bü-Symbol an die Mitte des Weges (also 
zwischen beide Gleise).
Außerdem lässt sich ermitteln, mit wievielen Gleisen sich der Bü schneidet.


Grüße
Alex

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


Re: [Talk-de] Taggingschema OpenRailwayMap

2012-05-09 Diskussionsfäden Alexander Matheisen
Hallo,

 Das Thema _Bahnübergänge_ wurde im Forum früher schon diskutiert. Dein
 Vorschlag enthält trotz der damaligen Anmerkungen nur ein Taggingkonzept
 für die Kreuzungsknoten und keinen Ansatz zum Zusammenfassen mehrerer
 Knoten - etwa über ein entsprechendes Markieren der dazwischenliegenden
 Wegstücke oder über eine Relation.
 Da aber speziell Schranken als Attribut an den Knoten stehen, lassen sie
 sich dann nicht so rendern, dass pro Bahnübergang nur ein Schrankenpaar
 erscheint.

Dazu habe ich tatsächlich bisher keine Lösung gefunden. Steht daher auch unter 
den Todos 
(http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap#Bugs_.2F_Zuk.C3.BCnftige_Entwicklungen_.2F_Ideen_.2F_TODOs).

Bei Bahnübergängen müsste man zusammen mit Experten für Routing und eventuell 
3D eine Lösung finden, die für alle Anwendungstypen sinnvoll ist.
Habe gleich mal einen neuen Thread dazu geöffnet.

 Dein Vorschlag zu _disused und abandoned_ schlägt vor, ein Präfix für
 den Wert zu verwenden, also z.B. railway=disused_signal. Auf der
 Wikiseite zum Schlüssel disused dokumentiert ist aber die Verwendung
 als Präfix für den Schlüssel - für dieses Beispiel wäre das
 disused:railway=signal. Was spricht aus deiner Sicht für die von dir
 gewählte Variante?

Das kannte ich noch gar nicht, Danke für den Hinweis. Werde es bei Gelegenheit 
ändern.

 Und zuletzt: Die Tags für _Signale_ nehmen Bezug auf die Wegrichtung. Es
 ist also vorgesehen, dass ein solcher Knoten nur dann an der Grenze
 zweier Ways verwendet werden darf, wenn diese eine zusammenpassende
 Wegrichtung haben, richtig?

Stimmt, den Fall hatte ich bisher gar nicht bedacht. Dann werde ich diesen 
Sonderfall mit einem Hinweis auf der Wikiseite vermerken.


Gruß
Alex

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


Re: [Talk-de] Taggingschema OpenRailwayMap

2012-05-09 Diskussionsfäden Alexander Matheisen
Hallo,

 Warum die Beschränkung auf:
 Berücksichtigt werden nur vollwertige Eisenbahnen, die Teil des
 internationalen Eisenbahnnetzes sind. Nicht berücksichtigt werden
 Straßenbahnen, Seilbahnen, Standseilbahnen, Miniaturbahnen und U-Bahnen.
 ?
 Kennst Du beispielsweise das Karlsruher Schienennetz? Da sind die
 Übergänge zwischen Strassenbahnen und vollwertigen Eisenbahnen sehr
 fliessend.
 Und wenn Du Dir die Schweiz anschaust - wo setzt Du da die Grenze bei
 den vielen Schmalspurbahnen die teils auch ehr Strassenbahn, teils aber
 auch ehr vollwertige Eisenbahn sind.
 Und oftmals sind es doch gerade die kleinen Bahnen die besonderes
 Interesse hervorrufen.

Eigentlich wollte ich wirklich nur eine Karte für die richtige Eisenbahn. 
Wie du aber schon sagtest ist es etwa beim Beispiel Karlsruhe schwierig, da 
einen Schnitt zu machen. Straßen- und U-Bahnen würde ich daher noch mit 
aufnehmen.
Bei Seilbahnen, Standseilbahnen und Miniaturbahnen bin ich mit aber recht 
unschlüssig.
Seilbahnen fallen für mich definitiv raus, die haben nichts mehr mit Eisenbahn 
zu tun.
Bei Standseilbahnen bin ich ein wenig unsicher, da sie eine Mischung aus 
Eisenbahn und Seilbahn sind. Da sie aber nicht an das reguläre große 
Bahnnetz angeschlossen sind, fallen sie für mich hinaus.
Und Miniaturbahnen sind meiner Meinung einfach nur größere Modellbahnen.

 Ich wäre daher für die Formulierung Alle schienen-/seilgebundenen
 Personen- und Güter befördernde Bahnen, also alles ab der
 personenbefördernden Parkbahn aufwärts.

Ich würde folgende Definition vorschlagen: Alle schienengebundenen und aus 
eigener Kraft fahrenden Verkehrsmittel, also Eisenbahnen, Stadtbahnen, U-
Bahnen und Straßenbahnen.
Seilbahnen sind nicht schienengebunden und haben keinen Eigenantrieb, 
Standseilbahnen sind zwar schienengebunden, haben aber auch keinen 
Eigenantrieb.
Bei Miniaturbahnen greift die Definition übrigens nicht...


Gruß
Alex

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


[Talk-de] Taggingschema OpenRailwayMap

2012-05-07 Diskussionsfäden Alexander Matheisen
Hallo,

bereits seit längerem arbeite ich an dem Plan, eine Spezialkarte zum Thema 
Eisenbahn unter dem Namen OpenRailwayMap zu schaffen:
http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap

Nun habe ich das Taggingschema nach meiner Meinung soweit fertig und würde 
gerne andere fragen, wie sie es finden und was verbessert werden könnte:

Das Taggingschema habe ich aufgeteilt in das vollständige
http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Erweitertes_Tagging
sowie eine gekürzte Version für Bahnlaien:
http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Vereinfachtes_Tagging

Alles genau hier zu erklären, wäre wahrscheinlich ein bisschen zu umfangreich. 
Schaut es euch einfach an und bei Verständnisfragen oder Fragen wie Warum 
soll etwas auf diese Weise getaggt/erfasst werden? kann ich euch einzelne 
Dinge genauer erläutern.

Sollten hier vorerst keine weiteren Ergänzungswünsche oder Kritikpunkte 
auftreten, werde ich mir die Arbeit machen, die Seiten ins Englische zu 
übersetzen und als Proposal einzutragen.


Grüße
Alex

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


Re: [Talk-de] Unter Denkmalschutz stehen de Gebäude

2012-04-28 Diskussionsfäden Alexander Matheisen
Am Samstag, 28. April 2012, 18:03:38 schrieb Steffen Heinz:
 Jeder Ort hat ja dutzende / Hunderte von unter Schutz stehenden Gebäuden
 usw. sollen die, können die vermerkt werden?
 Beispiel:
 http://de.wikipedia.org/wiki/Liste_der_Baudenkm%C3%A4ler_in_Simmerath
 
 macht das überhaupt Sinn?

Ich habe vereinzelt schon Gebäude mit dem NRW-Wappen und Denkmal oder der 
blau-weißen Raute ganz pragmatisch mit heritage=yes getaggt. Muss nicht 
korrekt sein, aber man kann es später immer noch ändern.


Alex

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


Re: [Talk-de] Geografische Regionen innerhalb der Datenbank?

2012-04-28 Diskussionsfäden Alexander Matheisen
Am Samstag, 28. April 2012, 18:58:09 schrieb Falk Zscheile:
 Am 28. April 2012 15:45 schrieb Peter Wendorff wendo...@uni-paderborn.de:
  Für OSM haben wir das häufiger diskutiert, und hängen da quasi an einem
  blöden Problem: Geographische Regionen haben oft nicht fest definierte
  Grenzen.
  Wo hören die Alpen auf?
  Wo die norddeutsche Tiefebene?
  Es gibt eindeutige Grenzen (z.B. bis zum Rhein), aber meist sind die
  Grenzen nicht eindeutig, und das lässt sich nur sehr schwer (wenn
  überhaupt) abbilden.
  
  Wenn Du da allerdings 'ne gute Idee haben solltest...
  interessieren würde mich das Thema durchaus.
 
 Da wurde etwas für  API 0.7 zu Diskussion gestellt, aber nicht weiter
 erläutert und für mich bisher auch nicht überzeugend:
 
 http://wiki.openstreetmap.org/wiki/API_v0.7#Geografic_regions

Wozu braucht man dafür eine neue API-Version? Ließe sich doch auch mit der 
bisherigen Software eintragen. Vielleuicht mit Relationen, die die Hierarchien 
nachbilden und Mulipolygonen oder Wegen, die die Bereiche grob markieren.


Alex

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


Re: [Talk-de] Geografische Regionen innerhalb der Datenbank?

2012-04-28 Diskussionsfäden Alexander Matheisen
 Geographische Regionen haben keine scharfen Ränder, sondern ziemlich
 schwammige Grenzen, und so etwas lässt sich momentan tatsächlich nicht
 abbilden.

Das kann man ja beim Auswerten berücksichtigen. Etwa eine Ungenauigkeit von 
+/- 20km bei Mittelgebirgen vielleicht...


Alex

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


Re: [Talk-de] Erfassung Ortshistorischer Objekte

2012-04-09 Diskussionsfäden Alexander Matheisen
Für solche historischen Daten ist es schwierig, sie in die jetzige OSM 
Datenbank einzutragen. Wie willst du zum Beispiel eine Kneipe eintragen, die in 
den vergangenen 30 Jahren mehrmals Besitzer und Küche gewechselt hat?

Ich habe da folgende Vorstellung: Man müsste eine Art Zeitachse einfügen. In 
JOSM ließe sich dann die Zeit über einen Regler einstellen, für die man 
editieren will. Das kollidiert dann nicht mit den heutigen Daten und ein 
Problem wie oben beschrieben hat man auch nicht, weil man auf einer Zeitachse 
die Gültigkeit des Objekts einstellen könnte. Der Editor müsste diese Zeitdaten 
bei jedem Objekt mitspeichern.
Vielleicht ginge das alles jetzt schon mit einem Plugin: Mit start_date und 
end_date gibt man den Zeitrahmen eines Objekts an. Das Plugin würde dafür 
sorgen, dass der Editor nur Objekte anzeigt, die in einem vom User 
eingestellten Zeitintervall oder einem Zeitpunkt existent sind. Damit ließen 
sich z.B. auch abgerissene Gebäude eintragen, ohne, dass sie wie zur Zeit beim 
Editieren stören. Und Renderer, die nicht historische Daten auswerten, müssten 
Objekte nur rendern, wenn sie kein end_date besitzen.

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


Re: [Talk-de] Welche Tags für Bahngleise

2012-02-20 Diskussionsfäden Alexander Matheisen
  Ich beschäftige mich schon seit einiger Zeit mit einem Taggingschema für
  Eisenbahnen:
  http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap
 
 Die Seite hatte ich bei der Suche im Wiki nicht entdeckt.
 
 Du hast dort einige Erweiterungen vorgeschlagen, die nicht mit den
 Wiki-Definitionen kompatibel sind (usage=highspeed).

Wieso nicht kompatibel?
Es werden ja nur zusätzliche Values für usage=* definiert, die sich nicht mit 
den im Wiki vorgeschlagenen Werten in die Quere kommen.


Alex

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


Re: [Talk-de] Welche Tags für Bahngleise

2012-02-20 Diskussionsfäden Alexander Matheisen
Am Montag, 20. Februar 2012, 14:11:41 schrieb Martin Koppenhoefer:
 Am 20. Februar 2012 13:42 schrieb Alexander Matheisen
 
 alexandermathei...@ish.de:
  Du hast dort einige Erweiterungen vorgeschlagen, die nicht mit den
  Wiki-Definitionen kompatibel sind (usage=highspeed).
  
  Wieso nicht kompatibel?
  Es werden ja nur zusätzliche Values für usage=* definiert, die sich
  nicht mit den im Wiki vorgeschlagenen Werten in die Quere kommen.
 
 Doch, das kommt sich potentiell mit den anderen Werten in die Quere.
 Warum nicht highspeed=yes (oder ggf. detaillierter bis zu welcher
 Geschwindigkeit, etc.)?

Ist das nicht unnötig kompliziert? Schließlich taggt man eine Autobahn ja auch 
nicht als highway=trunk und highspeed=yes...

Nach meiner Definition überschneiden sich main und highspeed nicht: main sind 
normale Hauptstrecken und highspeed bezeichnet Strecken wie die SFS Köln-
Frankfurt (nur Hochgeschwindigkeitsverkehr, frei von Bahnübergängen, etc.)

Siehe http://de.wikipedia.org/wiki/Schnellfahrstrecke
wobei ich in der Regel Ausbaustrecken wie die Schnellfahrstrecke Köln-Aachen 
noch zu main zählen würde (auch andere Zuggattungen, mehr Bahnhöfe entlang der 
Strecke.

Dann muss die bisherige Definition von main eben geändert werden.


Alex

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


Re: [Talk-de] OpenRailwayMap (war: Welche Tags für Bahngleise)

2012-02-20 Diskussionsfäden Alexander Matheisen
Am Montag, 20. Februar 2012, 15:02:51 schrieb Stephan Wolff:
 Am 20.02.2012 13:42, schrieb Alexander Matheisen:
  http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap
  
  Du hast dort einige Erweiterungen vorgeschlagen, die nicht mit den
  Wiki-Definitionen kompatibel sind (usage=highspeed).
  
  Wieso nicht kompatibel?
  Es werden ja nur zusätzliche Values für usage=* definiert, die sich
  nicht mit den im Wiki vorgeschlagenen Werten in die Quere kommen.
 
 Hochgeschwindigkeitsstrecken sollten laut Wiki als usage=main getaggt
 werden, nach deinem Vorschlag als usage=highspeed. Wer eine Karte nur
 mit den Hauptstrecken erstellen will und usage=main filtert, sieht dann
 die Strecken mit usage=highspeed nicht.

Man könnte ja in diesem Fall alle usage=main und usage=highspeed anzeigen. 
Trägt man dagegen auch alle Hochgeschwindigkeitsstrecken als usage=main ein, 
dann kann man keine Karte für solche Linien erstellen.

Besser ein differenziertes Tagging, das man beim Auswerten wieder etwas 
zusammenfassen kann, als umgekehrt.

 usage=main mit highspeed=yes
 wäre eine kompatible Erweiterung. Aber ich will dieses Detail nicht als
 entscheidenden Kritikpunkt bewerten.

Hochgeschwindigkeitslinien, die schon als usage=main getaggt sind, müsste man 
bei beiden Varianten umtaggen.

 Die Wikiseite ist sehr lang und enthält viele Vorschläge. Viele werden
 wohl spätestens ab railway:signal:main:substitute_signal nicht mehr
 weiterlesen, obwohl 100 Zeilen danach noch allgemein interessante und
 für Eisenbahnlaien erfassbare Objekte (Bahnhof, Stellwerk,
 Bahnübergang, Betriebsbahnhof und Containerumschlagbahnhof) beschrieben
 werden.
 
 Alexander, vielleicht könntest du den Text aufteilen in einen
 allgemeinen Teil für Eisenbahnlaien einen Spezialteil für Pufferküsser
 und Simulanten.

OK, ich habe es etwas aufgeteilt. Das vereinfachte Schema lässt sich aber 
vielleicht noch weiter vereinfachen.

Das Problem ist, dass das Tagging möglichst allgemein gehalten ist (vor allem 
das Tagging der Signale), um es international anwendbar zu machen. Damit wird 
es dann eben sehr komplex, aber je nach Land ergeben sich dann wieder einige 
Tags von selbst, sodass das Tagging dann nicht mehr so kompliziert ist.
Zur Zeit erstelle ich daher JOSM-Vorlagen (getrennt für verschiedene Länder), 
damit das Tagging vereinfacht wird. 

 Ich finde das Signalschema mit einer Relation pro Signal sehr
 kompliziert. Wäre es nicht ausreichend, einen Punkt auf dem Gleis zu
 setzen und den Standort (right/left/above) und Richtung in jeweils
 einem Zusatztag unterzubringen?

Werde mal drüber nachdenken... ;)


Alex

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


Re: [Talk-de] Welche Tags für Bahngleise

2012-02-20 Diskussionsfäden Alexander Matheisen
 Nach meiner Definition überschneiden sich main und highspeed nicht: main sind
 normale Hauptstrecken und highspeed bezeichnet Strecken wie die SFS Köln-
 Frankfurt (nur Hochgeschwindigkeitsverkehr, frei von Bahnübergängen, etc.)
 
 
 siehst Du, Du definierst main um: das sind plötzlich nur noch
 normale Hauptstrecken, den Hochgeschwindigkeitsverkehr schmeisst Du
 raus. M.E. wäre es sowieso nicht schlecht, man könnte bei highspeed
 noch näher dazuschreiben, welcher Ausbau (wenn man will), d.h. auch
 aus diesem Grund wäre ein eigener Key besser.
 
 
 Dann muss die bisherige Definition von main eben geändert werden.
 
 
 eben, müsste. Definitionsänderungen sollten aber nicht passieren,
 indem jeder nach Lust und Gutdünken im Wiki rumändert, ohne sich mit
 den anderen abzustimmen.

1. Ich ändere nichts an der Definition, denn dort ist nur von höherer 
Geschwindigkeit (im Vergleich zu branch) die Rede.

2. Wenn bisherige Definitionen verbesserungswürdig sind (zum Beispiel der 
damalige Ersteller nicht alle Fälle bedacht hat), dann sollte man sie 
korrigieren und erweitern.

3. Ich ändere nichts im Wiki, sondern habe nur einen Taggingvorschlag für eine 
geplante Anwendung entworfen.

4. Bezüglich abstimmen: Manchmal kommt man nur weiter, wenn man ganz 
pragmatisch einfach etwas macht statt zu warten, bis sich irgendwann alle 
geeinigt haben. Spätestens wenn eine coole Anwendung ihre eigenen Tags benutzt 
gilt doch wieder das Prinzip wir mappen für die Renderer.


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


Re: [Talk-de] Welche Tags für Bahngleise

2012-02-17 Diskussionsfäden Alexander Matheisen
Hallo,

 wie viele andere Dinge sind auch Bahngleise in OSM recht unterschiedlich
 erfasst.
 Welche der folgenden Tags sind in Deutschland für Bahngleise mit
 railway=rail sinnvoll?
 
 - gauge=1435: brauchen wir den Standardwert in Deutschland?

Ich denke, das Tag kann man weglassen, außer natürlich bei Schmalspurbahnen 
oder anderen abweichenden Strecken.

 - operator: wird manchmal für den Betreiber des Personenverkehrs
 genutzt (m.E. falsch), manchmal für den Betreiber des Gleises.
 Dabei gibt es noch unterschiedliche Schreibweisen (DB, DB-Netz,...)
 Ist für Ferngleise operator=Deutsche Bahn Netz AG sinnvoll? Für
 Industriegleise ist der Betreiber oft nicht erkennbar.

Ich gebe es bisher nur bei Industrie- oder Privatbahnen an. Sonst ist ja wie 
bei gauge=* ein Standardwert vorhanden.

 - network=XYZ: ist das eine Eigenschaft des Gleises oder gehört das
 Tag an die Relation route=train?

Kommt eher an die Relation.

 - lines=XY;YZ: steckt die Information nicht schon in den Relationen?

Ja.

 - oneway: ist oneway=yes sinnvoll, wenn jedes Gleis einer
 zweigleisigen Strecke nur Signale für eine Fahrtrichtung hat?

Ist nicht selbst in diesem Fall z.B: bei Bauarbeiten auf dem anderen Gleis das 
Befahren des Gegengleises möglich?

 - ref: was bedeutet ref bei Bahngleisen? Ist es die Gleisnummer in
 Bahnhöfen oder gibt es dafür ein anderes Tag?

Bei Strecken nehme ich die vierstellige Streckennummer. An Bahnhofsgleisen das 
Gleis, wobei dann ein Konflikt mit der Streckennummer entsteht. Für den Fall 
muss ich mir auch noch etwas einfallen lassen.

 - usage: gibt usage die offizielle Einteilung in Haupt- und
 Nebenbahnstrecken an oder die aktuelle Verkehrsbedeutung?
 Beispiel: die Bahnstrecke Neumünster–Bad Oldesloe ist laut Wikipedia
 Hauptbahn, wird aber nur stündlich mit Triebwagen befahren.

Da sollte man sich meiner Meinung nicht an länderbezogene Einteilungen halten, 
sondern das nach eigenem Gefühl machen, wie wir das auch schon mit 
primary/secondary/tertiary-Straßen machen.
Bei deinem Fall würde ich die Strecke als Nebenbahn taggen.
 
 Fast alle Bahnhöfe haben mehrere getrennt erfasste Gleise. Sollte ein
 Punkt eines beliebigen Gleises als railway=station erfasst sein oder
 jeder way einen Punkt mit public_transport=stop_position, train=yes
 haben?

Darauf habe ich auch noch keine Antwort gefunden.

Ich beschäftige mich schon seit einiger Zeit mit einem Taggingschema für 
Eisenbahnen:
http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap


Grüße
Alex

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


Re: [Talk-de] Amtliche Stelle?! Läßt BING Militärgebiete zensieren!

2012-01-31 Diskussionsfäden Alexander Matheisen
Hallo,

 so viel also zum Thema Open Data...
 
 Für alle diejenigen von euch die wie ich das Forum seltener lesen möchte ich
 dann doch die Diskussion auch mal hierher bringen.

Die Diskussion ist hier schon längst angekommen...


Alex

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


Re: [Talk-de] Amtliche Stelle?! Läßt BING Militärgebiete zensieren!

2012-01-31 Diskussionsfäden Alexander Matheisen
 Huch hab ich einen thread übersehen?

Scheinbar.
Thread siehe hier:
http://lists.openstreetmap.org/pipermail/talk-de/2012-January/092407.html


Alex

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


Re: [Talk-de] Potlach 2 - kein bing-Hintergrund-Bild mehr bei Militaerflaechen

2012-01-30 Diskussionsfäden Alexander Matheisen
Am Montag, 30. Januar 2012, 18:23:32 schrieb Simon Poole:
 Und weiter
 
 [18:22] SteveC I can confirm that the blurring polygons were given to
 us by the government and we didn't use OSM or anything like that.
 
 Am 30.01.2012 17:54, schrieb Simon Poole:
  17:52] *** SteveC has joined #osm-de
  [17:52] SteveC Hello osm.de
  [17:52] SteveC I have asked our imagery people about the blurring
  [17:52] SteveC And I can pass back that we were asked to do it by a
  branch of the German government

Ich will ja keine Verschwörungstheorien aufstellen, aber ein bisschen 
beunruhigt mich das schon. Wenn man davon ausgeht, dass das alles so stimmt 
wie Steve hier schreibt, dann frage ich mich, ob es eine konkrete Bedrohung 
für Deutschland gibt, weshalb man ausgerechnet jetzt aus dem Nichts heraus die 
Luftbilder zensieren lässt.


Alex

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


Re: [Talk-de] Potlach 2 - kein bing-Hintergrund-Bild mehr bei Militaerflaechen

2012-01-30 Diskussionsfäden Alexander Matheisen
  Ich will ja keine Verschwörungstheorien aufstellen, aber ein bisschen
  beunruhigt mich das schon. Wenn man davon ausgeht, dass das alles so
  stimmt wie Steve hier schreibt, dann frage ich mich, ob es eine
  konkrete Bedrohung für Deutschland gibt, weshalb man ausgerechnet jetzt
  aus dem Nichts heraus die
  Luftbilder zensieren lässt.
 
 Ach, wahrscheinlich sucht so eine Planstelle nur nach einer
 Existenzberechtigung.
 Bei einer echten Bedrohung würde man wohl auch die unzensierten WMS der
 Landesvermessungsämter abschalten.

Das ist natürlich ein Argument...

 Außerdem wirkt die Verschleierung bei Licht betrachtet doch eher wie eine
 Markierung aller relevanten militärischen Ziele.

Wo die Einrichtungen liegen, weiß sowieso jeder. Aber ohne Verschleierung 
könnte man gezielt ein bestimmtes Gebäude angreifen, daher ist eine 
Verschleierung nicht ganz unnütz. (Niederländische Militäreinrichtungen sind 
in Google Maps auch mit einem auffälligen Muster zensiert)


Alex

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


Re: [Talk-de] Potlach 2 - kein bing-Hintergrund-Bild mehr bei Militaerflaechen

2012-01-30 Diskussionsfäden Alexander Matheisen
 ich habe mal eine Analyse für Nordrhein-Westalen durchgeführt:
 
 * Nutzung der aktuellen Datei für NRW von der geofabrik.
 * Filtern mittels osmosis nach Wegen mit landuse=military.
 * Laden dieser Datei in JOSM.
 * Visueller Vergleich aller diese Gebiete mit dem Bing-Hintergrund.
 * Tagging der Gebiete mit blurred_by_bing=no|partly|exactly.
 * Lokal gesichert, aber nicht hochgeladen.
 * Zählung der Gebiete mittels grep.
 
 Ergebnis:
 
 Gebiete in NRW mit way landuse=military:  156.
 
 Davon sind 2 teilweise verpixelt, 89 exakt mit OSM-Konturen verpixelt
 und 60 Gebiete sind nicht verpixelt. 
 
 5 Gebiete sind mir wohl bei der visuellen Kontrolle durchgerutscht.
 
 Beobachtung: Es gibt noch einige andere verpixelte Gebiete in NRW.
 (Vielleicht als Relationen?)
 
 Es wurden auch Übungsgebiete von Bereitschaftspolizei, Technischem Hilfswerk 
 und Deutschem Rotem Kreuz verpixelt.
 
 Fragen:
 Stellen die noch unverpixelt dargestellten 60 Militärgebiete in NRW ein 
 Problem für unsere Landesverteidigung dar?
 Welche Behörden können wir darüber verständigen?

Wieviele der unverpixelten Gebiete gehören denn zur Bundeswehr? Ich habe bisher 
festgestellt, dass Gelände anderer Streitkräfte nicht zensiert sind, z.B. 
Flugplätze der US-Armee.
Gibt es überhaupt zensierte nicht- deutsche Einrichtungen?


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


Re: [Talk-de] Die neuen Google Luftbilder

2012-01-29 Diskussionsfäden Alexander Matheisen
 habe ich gerade in Google Earth gesehen.

Als ich zuerst nur den Betreff gelesen hatte, dachte ich, dass die jetzt auch 
schon wie Bing auf zensierte Bilder aktualisiert haben...

Bin ich ja beruhigt, dass es nicht so ist, sonst wäre es beunruhigend.

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


Re: [Talk-de] Themen-Karte: Grenz- und Meilensteine

2012-01-06 Diskussionsfäden Alexander Matheisen
Hallo,

 boundary = marker oder marker = stone - was das Haupttag ?

marker=* scheint nur dazu dienen, die Art des Grenzpunktes zu spezifizieren 
(Stein, Felsen, Pfahl, ...). 
http://taginfo.openstreetmap.org/keys/marker#values

Von daher würde ich boundary=marker auswerten, auch wenn es Grenzpfähle statt 
Grenzsteinen sein könnten. Die Unterscheidung kannst du ja noch später 
einbauen.

  Thematisch würde es ganz gut passen, dann natürlich mit einem anderen
  Symbol zur Unterscheidung.
 
 Einen Vorschlag 

Wie ist http://rurseekatze.bplaced.net/grenzstein.png ? (man sieht 
wahrscheinlich, dass ich wenig künstlerische Begabung besitze... ;)


Alex

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


Re: [Talk-de] Einbinden von Image-Tags aus Wikimedia

2012-01-06 Diskussionsfäden Alexander Matheisen
Hallo,

 es gibt ja ein Tag im IMAGES einzubinden und wikimedia bietet sich bei
 historischen Dingen insbesondere an.
 
 In diesem Zusammenhang ist mir folgendes aufgefallen.
 
 Die Seite mit dem Bild hat zum Beispiel die URL:
 http://commons.wikimedia.org/wiki/File:Meilenstein_Chaussee_Altona-L%C3%BCbe
 ck_-_Altona_5M_%28Bargfeld-Stegen%29_02.jpg?uselang=de
 
 Geht man auf der rechten Seite auf den Punkt - Einbinden, dann wird für
 das Bild die URL:
 http://upload.wikimedia.org/wikipedia/commons/5/5d/Meilenstein_Chaussee_Alto
 na-L%C3%BCbeck_-_Altona_5M_%28Bargfeld-Stegen%29_02.jpg
 
 angeboten.
 
 Da ich nun überlege diese Bilder automatisch in einer Karte darzustellen
 wäre es sinnvoll den richtigen Bildnamen auch anzusetzen.
 
 Wie macht Ihr das oder liege ich mit meinem Gedanken gar falsch ? Beim
 Image-Tag habe ich im Wiki [1] keinen entsprechenden Hinweis gefunden.
 
 [1] http://wiki.openstreetmap.org/wiki/Image

In meiner OpenLinkMap werte ich dieses Tag bereits aus.
Beispiel: 
http://www.openlinkmap.org/?lat=51.1990129lon=6.6932413zoom=17id=28562993type=way

Und dann auf Mehr Infos klicken.

Ich werte nur die zweite Variante aus - die direkte URL - da ich so direkt das 
Bild einbinden kann. Bei der ersten Variante müsste ich erst noch die Bild-URL 
aus der HTML-Seite herausfiltern.

Bezüglich Lizenzhinweis hatte ich das Problem, dass man den Autor und die 
Lizenz nicht per API abfragen kann. Daher habe ich das mit diesem Link unter 
dem Bild gelöst, der auf die Bildseite (die erste URL) verweist. Ob das 
rechtlich reicht, weiß ich nicht.
Meiner Meinung sollte sich aber seitens Wikimedia keiner beschweren, dass der 
Lizenzhinweis nicht ausreicht, wenn die es nicht hinkriegen, diese Daten 
maschinenlesbar bereitzustellen.

Außerdem prüfe ich noch, ob das Bild von Wikimedia stammt. Bilder von anderen 
Webseiten zeige ich (um rechtliche Probleme zu vermeiden) gar nicht an.


Alex

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


Re: [Talk-de] Themen-Karte: Grenz- und Meilensteine

2012-01-06 Diskussionsfäden Alexander Matheisen
Am Freitag, 6. Januar 2012, 15:11:31 schrieb Jan Tappenbeck:
 Am 06.01.2012 13:55, schrieb Alexander Matheisen:
  Hallo,
  
  boundary = marker oder marker = stone - was das Haupttag ?
  
  marker=* scheint nur dazu dienen, die Art des Grenzpunktes zu
  spezifizieren (Stein, Felsen, Pfahl, ...).
  http://taginfo.openstreetmap.org/keys/marker#values
  
  Von daher würde ich boundary=marker auswerten, auch wenn es Grenzpfähle
  statt Grenzsteinen sein könnten. Die Unterscheidung kannst du ja noch
  später einbauen.
  
  Thematisch würde es ganz gut passen, dann natürlich mit einem
  anderen
  Symbol zur Unterscheidung.
  
  Einen Vorschlag 
  
  Wie ist http://rurseekatze.bplaced.net/grenzstein.png ? (man sieht
  wahrscheinlich, dass ich wenig künstlerische Begabung besitze... ;)
  
  
  Alex
 
 eingespielt !

Danke, sieht gut aus.

Um Aachen sind schon viele Grenzsteine erfasst:
http://www.tappenbeck.net/osm/maps/deu/index.php?id=1044zoom=12lat=50.67221lon=6.15871layers=BFTlang=de

Man sollte vor allem die Mapper in Grenzregionen dazu motivieren, die Steine 
zu erfassen. Das macht nämlich Spaß und hat was von Geocaching... ;)


Alex

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


Re: [Talk-de] Themen-Karte: Grenz- und Meilensteine

2012-01-04 Diskussionsfäden Alexander Matheisen
Hallo,

 ich habe einmal wieder gebastelt - eine Sonderkarte zu dem Thema Grenz-
 und Meilensteine.
 Für Ideen und Anregungen bin ich immer offen. Weitere Thematische Karten
 von mir finden sich unter
 http://wiki.openstreetmap.org/wiki/User:L%C3%BCbeck#Meine_Karten.

Könntest du auch normale (nicht historische) Grenzsteine anzeigen? 
Habe schon einige eingetragen, leider werden die in keiner Karte angezeigt.
http://www.openstreetmap.org/browse/node/324100655

Thematisch würde es ganz gut passen, dann natürlich mit einem anderen Symbol 
zur Unterscheidung.


Alex

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


Re: [Talk-de] OpenGeoDB eingestellt

2012-01-03 Diskussionsfäden Alexander Matheisen
Am Montag, 2. Januar 2012, 21:24:27 schrieb Stefan Keller:
 Lieber Sven, liebe Mapper
 
 Wie schon an anderer Stelle erwähnt, würde es meiner Erfahrung nach
 der OSM Datenbank sehr gut tun, wenn man die OpenGeoDB Tags löschen
 würde. Wenn's gut gemacht ist, wieso auch nicht automatisch?
 
 Bisher hatte ich mich davor gescheut. Aber wenn nun auch Sven mit
 Löschen einverstanden ist - wenn ich ihn richtig verstehe -, steht dem
 nichts mehr im Wege. Dabei habe ich nichts gegen OpenGeoDB (im
 Gegenteil) und auch nichts gegen solche Imports (wenn sie gut laufen
 
 :-).
 
 Die OpenGeoDB-tags jedenfalls haben bis auf wenige ihren Dienst getan
 und sind nun nur noch Ballast für die tag-Liste pro Node.
 
 Zu den Löschkandidaten gehören m.E. u.a. folgende: opengeodb:lat,
 opengeodb:lon, openGeoDB:name, openGeoDB:type,openGeoDB:is_in,
 openGeoDB:layer, openGeoDB:version, openGeoDB:sort_name,
 openGeoDB:auto_update, openGeoDB:is_in_loc_id, openGeoDB:postal_codes,
 openGeoDB:community_identification_number
 
 Was man behalten könnte ist:
 
 openGeoDB:loc_id
 population  = value aus
 openGeoDB:population=value, falls tag population nicht schon
 vorhanden
 source:population=OpenGeoDB
 
 oder - etwas vorsichtiger:
 
 openGeoDB:loc_id
 openGeoDB:population

Ich würde es so machen:

openGeoDB:community_identification_number (Gemeindeschlüssel) = 
de:amtlicher_gemeindeschluessel
openGeoDB:population = population
openGeoDB:telephone_area_code (Telefonvorwahl) = telephone_area_code
openGeoDB:license_plate_code (Autokennzeichen) = license_plate_code

restliche openGeoDB-Tags löschen


Alex

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


Re: [Talk-de] deutsche Abkürzungen in Eisenbahn-Spezialtags

2011-12-13 Diskussionsfäden Alexander Matheisen
  Die Eisenbahninfrastruktur ist aber auch für die vielen
  Eisenbahnunternehmen oder Bahnmuseen interessant, auch wenn die
  vielleicht jetzt noch nicht unsere Karten nutzen.
 Genau deswegen sehe ich hier Handlungsbedarf und einen Grund diese
 Informationen einzutragen.
 Meine Frage ist nun: Kann ich Daten aus Führerstandsmitfahrten wie man
 sie z.B. auf Youtube findet, Nutzen und eintragen?
 
 Prinzipiell wird es doch sicherlich schwierig Streckendetails zu
 erfassen, da die wenigsten von uns im Führerstand sitzen ;-)
 Mich würde die praktische Erfassung der Daten daher sehr interessieren.

Entweder man geht zu Fuß, etc. an die Gleise ran (wirklich nur soweit es 
erlaubt ist). Bei mir am Niederrhein sind die Gleise vor allem außerhalb der 
Bebauung leicht zugänglich, oft führen Feldwege parallel zum Gleis. Innerhalb 
von Bahnhöfen kann man natürlich auch von den Bahnsteigen aus alles 
fotografieren.

Bei Videos auf Youtube würde ich immer den jeweiligen Ersteller fragen.


Alex

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


  1   2   3   4   5   6   >