Re: [Talk-de] Challenge accepted?

[Martin Simon]

Andreas Schmidt  schrieb am Do., 8. März 2018,
22:54:

> Was steht eigentlich im Protokoll, wenn auf der Straße etwas passiert,
> sei es ein Verkehrsunfall oder ein Wasserrohrbruch?
> Die Straße muss doch irgendwie benannt werden.
>

Eine gute Frage.
Nach ein bisschen stöbern habe ich das hier gefunden:
https://www.presseportal.de/blaulicht/pm/14915/3868218

Eine konkrete Position kann also durch 2 angrenzende Quadrate angegeben
werden, eine Kreuzung durch zwei diagonal gegenüberliegende Quadrate.

Häufig wird auch nur von einem betroffenem Quadrat gesprochen:
https://www.presseportal.de/blaulicht/pm/14915/3872879
Das ist als pauschale Aussage ohne Hausnummer auch nicht unbedingt
ungenauer als die Angabe des Straßennamens ohne Hausnummer bei einer
durchschnittlichen "normalen" Straße (das typische Quadrat hat ca. 340 m
Umfang).

Gruß,

-Martin

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

Re: [Talk-de] Challenge accepted?

[Martin Simon]

Als jemand, der dort häufig unterwegs ist und der Meinung ist, dass Dinge
so getaggt werden sollten, wie sie sind und nicht so, wie es der Renderer
oder Router gerne hätte möchte ich anregen, die Straßen nicht zu benennen.

Im Video wirs es ja bereits gesagt: sie haben tatsächlich keinen Namen.
Und das ist durchaus OK so!

Im Grunde haben wir ja die gleiche Situation bei kleinen Orten ohne
Straßennamen, die postalisch über Hausnummer und Ortsname angesprochen
werden: addr:housenumber + addr:place.
Auch dort gibt es dann Leute, die den Ortsnamen auf die Straßen übertragen,
um wie gewohnt addr:street verwenden zu können.

Ich halte das in beiden Fällen für falsch und rufe daher die challenge aus,
es so zu lassen, wie es derzeit ist. ;-)

Gruß,

-Martin

Martin Koppenhoefer  schrieb am Mo., 19. Feb. 2018,
22:51:

> name:left und name:right
>
> Gruß,
> Martin
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] zur Info: Bicycle=yes/designated als Anzeige Benutzungspflicht aufgeben

[Martin Simon]

Am 05.06.2016 8:09 nachm. schrieb "Joerg Fischer" <o...@jfis.de>:
>
> Martin Simon wrote:
>
> > Selbst wenn man die letzten ~8 Jahre unter einem Stein verbracht hat
kann
>
> *plonk*

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

Re: [Talk-de] zur Info: Bicycle=yes/designated als Anzeige Benutzungspflicht aufgeben

[Martin Simon]

Am 03.06.2016 10:25 vorm. schrieb "Joerg Fischer" :

> Oder niemals. Aber gescheite Darstellung von Rad- und Fußwegen und das
> dazugehörige Routing ist ja schließlich nur einer _der_ Vorteile von OSM
> gegenüber anderen Kartenanbietern, das kann man schon mal sinnlos kaputt
> machen, indem man breite, asphaltierte Radwege als Trampelpfade mappt.
Ist
> sicher nicht so wichtig.

Selbst wenn man die letzten ~8 Jahre unter einem Stein verbracht hat kann
man eigentlich wissen, dass path nicht mit Trampelpfad gleichzusetzen ist -
weder als tag in osm, noch der Bedeutung des Wortes in der englischen
Sprache nach (siehe "bike path"). Es sei denn,  man bemüht diesen false
friend absichtlich, um nicht über das tagging selbst diskutieren zu müssen
ist ja schließlich auch einfacher, als das naive,  unpräzise und unflexible
ducktagging-Modell, das hinter den Alternativen steht, zu verteidigen.

Aber die Diskussion ist eigentlich längst durch, nix gut ungut.

Gruß,

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

Re: [Talk-de] Frage zum Mappen von Gemüsefeldern

[Martin Simon]

Am 20.03.2015 08:34 schrieb Garry garr...@gmx.de:

 Am 19.03.2015 um 13:09 schrieb Martin Simon:

 Anbau von Gehölzen (zur Lebensmittelgewinnung) - orchard
 Anbau von Gedöns (auch Spargel) - farmland / meadow

 Platt, aber eindeutig.

 Noch nie in einen holzigen Spargel gebissen?
 ;-)

Schon, aber das war bis jetzt nie so schlimm wie ein Biss in einen
Apfelbaum.

Gruß,

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

Re: [Talk-de] Frage zum Mappen von Gemüsefeldern

[Martin Simon]

Anbau von Gehölzen (zur Lebensmittelgewinnung) - orchard
Anbau von Gedöns (auch Spargel) - farmland / meadow

Platt, aber eindeutig.

Gruß,

Martin

Am 19. März 2015 um 08:55 schrieb Volker Schmidt vosc...@gmail.com:

 
  Dann wird verwiesen auf das andere Wiki:
   http://en.wikipedia.org/wiki/Orchard
  Und da steht dann wieder Gemuese, aber auch irgendetwas mit Beeren.
 
 
  Nein, dort steht nichts von Gemuese im Sinne von Kohl oder Rueben.

 An *orchard* is an intentional planting of trees
 https://en.wikipedia.org/wiki/Tree or shrubs
 https://en.wikipedia.org/wiki/Shrub that is maintained for food
 https://en.wikipedia.org/wiki/Food production
 https://en.wikipedia.org/wiki/Agriculture.
 und
 Orchards comprise fruit https://en.wikipedia.org/wiki/Fruit_tree,
 vegetable https://en.wikipedia.org/wiki/Vegetable, and nut
 https://en.wikipedia.org/wiki/Nut_%28fruit%29-producing trees which are
 grown for commercial production.

 Hier ist die Rede von Gemuese-produzierenden *Baeumen*. Ich denke etwa an
 Avocado.
 ___
 Talk-de mailing list
 Talk-de@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] heise berichtet ueber osm.org-Routing integration

[Martin Simon]

Am 17. März 2015 um 10:50 schrieb chris66 chris66...@gmx.de:

 WIKI:
  Diese Unterscheidung ist für Navigationssysteme interessant:
 highway=track wird vom Navigationssystem (Router) beim normalen
 KFZ-Routen nicht berücksichtigt (z.B. OpenRouteService). 

 Wenn also KFZ-Router tracks aus Performancegründen gar nicht mit
 aufnehmen in ihren Graphen dann sehe ich das nicht als Fehler an.


Nur weil irgendwo im Wiki jemand eingetragen hat, dass highway=track von
Routern nicht ausgewertet würde (von welchem bitte? alle? definitiv
nicht!), ist es richtig, wenn Router tracks ignorieren?

Zudem arbeiten einige router beidseitig (auch das erwähnte Osmand): vom
Start in Richtung Ziel und vom Ziel in Richtung Start - tracks etc müssen
also nur geprüft werden, bis die Route das erste mal auf das normale
Straßennetz trifft - oder höchstens noch ein paar Zyklen länger, um
eventuell günstigere Alternativen zu finden. Danach kann man sich auf Wege
= residential beschränken das gilt dann für Start- und Zielpunkt.

Gruß,

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

Re: [Talk-de] heise berichtet ueber osm.org-Routing integration

[Martin Simon]

Am 19.03.2015 16:18 schrieb Martin Koppenhoefer dieterdre...@gmail.com:

 Am 19. März 2015 um 13:20 schrieb Martin Simon grenzde...@gmail.com:

 das ist allerdings auch nur eine Optimierung, die auf Wahrscheinlichkeiten
 beruht, es könnte ja an jeder Stelle der Strecke günstiger sein, eine
kurze
 Abkürzung über einen Feldweg zu nehmen (auch wenn das viele Autofahrer
 sicher nicht wollten, selbst wenn man ein paar Minuten oder Sekunden
spart).

Klar, aber für hiesige Verhältnisse sollte es gut funktionieren und es wäre
immer noch sinnvoller, als die Betrachtung von tracks komplett
auszuschließen. (wenn man sie denn unbedingt aus dem Graph fernhalten will)

Gruß,

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

Re: [Talk-de] heise berichtet ueber osm.org-Routing integration

[Martin Simon]

Am 16.03.2015 15:46 schrieb Florian Lohoff f...@zz.de:


 Bei mir ist der Track der EINZIGE weg zu mir nach Hause. Trotzdem
 verweigert mit der router die Nutzung.

Ist bei mir genauso. Es gibt mehrere Zufahrten über asphaltierte
highway=track,  aber beispielsweise Osmand verweigert sich seit Monaten und
routet nur bis zum Ende der nächsten residential.

Zumindest tracks (die per Definition für zweispurige Fahrzeuge zumindest
prinzipiell geeignet sind) sollte ein Router mit niedriger Priorität für
die ersten und letzten Kilometer berücksichtigen.

Gruß,

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

Re: [Talk-de] Wieder einmal lcn Sammelrelationen

[Martin Simon]

Am 06.02.2015 09:43 schrieb Manuel Reimer manuel.s...@nurfuerspam.de:
 Bei ausgeschilderten Wanderwegen handelt es sich um eine, von einer
 zuständigen Stelle, genau festgelegten Route die oft an bestimmten
 Sehenswürdigkeiten vorbeigeht. Hier macht es Sinn diese Wege zusammen in
 eine Relation zu packen und weitere Daten zu genau diesem Wanderweg zu
 sammeln. Zum Beispiel der Betreiber, eventuell am Weg angebrachte Tafeln,
 die Webseite zum Weg, ...

 Bei den hier diskutierten Wegverläufen handelt es sich aber primär erstmal
 um aufgestellte Wegweiser die für mich genauso viel Aussage haben wie der
 große gelbe Pfeil an einer Straßenkreuzung der mir zeigt, dass es rechts
rum
 nach Buxtehude geht. Bei den Straßenschildern würde auch keiner auf die
 Idee kommen eine Relation als Sammlung aller Straßen, auf die ein
Wegweiser
 hinweist, aufzumachen.

Das stimmt so nicht.
Diese Routen sind bewusst als fahrradtaugliche Stecken zur alltäglichen und
touristischen Nutzung festgelegt, und das ziemlich genau. Das ganze ist als
Netz konzipiert und berücksichtigt sehr wohl auch die Erreichbarkeit von
Sehenswürdigkeiten. Genau wie bei Wanderrouten erfolgt die Beschilderung
meist dort, wo man sich auch tatsächlich verlaufen könnte, also z.B. an
Kreuzungen und Einmündungen.

Lässt sich aber sicherlich alles auch auf den Seiten der zuständigen
Stellen nachlesen.

 Genau das sind diese lcn-Sammelrelationen aber. Eine Sammlung von Wegen
 auf die ein Wegweiser hinweist. Ob diese sich nun besser zum Radfahren
 eignen oder schnellster zum Ziel führen wie ein anderer Weg, das wird hier
 nicht ausgesagt.

Das muss eine Route nebenbei bemerkt auch nicht aussagen.

 Um die Güte von Wegen zu beurteilen gibt es andere Mittel. Zum Beispiel
das
 surface-Tag oder den tracktype. Es gibt beim Routing keinerlei Grund
 sich an diesen ausgeschilderten Wegen zu orientieren. Dafür hat man ja ein
 GPS dabei um sich auf dem schnellsten Weg zu einem Ziel lotsen zu lassen
und
 einen komplett verschlammten Weg, auf den ein solcher Rad-Wegweiser
 eventuell hinweist, auch mal links liegen lassen zu können.

Wenn du diese Routen nicht benötigt, willst oder magst, schlage ich vor,
einfach auf der Ausgabeseite zu filtern, wie es hier schon seit Urzeiten
gute Tradition ist.


Gruß,

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

Re: [Talk-de] Wieder einmal lcn Sammelrelationen

[Martin Simon]

Am 02.02.2015 22:01 schrieb Manuel Reimer manuel.s...@nurfuerspam.de:

 Es würde meiner Ansicht nach bestenfalls Sinn machen den Wegweiser selbst
zu mappen.

 Die Wege sind keine Radwege sondern meist einfache Feldwege oder
Waldwege. Teilweise auch weniger befahrene Straßen.

Natürlich nicht. Es sind ja auch (netzförmige) Radrouten, das ist etwas
völlig anderes als Radwege.

 Es ist also eher ein Wegweiser für Radfahrer als ein zusammenhängender
Radweg. Zu allem Überfluss teilweise auch noch lückenlos ausgeschildert.
Wer dann in fremden Gebieten kein GPS hat, der verfährt sich trotz der
gutgemeinten Wegweiser. Mir selber schon passiert...

Dasselbe Problem gibt es auch bei Fuß- oder Wanderrouten. Dort auch nur die
Schilder oder Markierungen erfassen?

Ob es jetzt Relationen sein müssen oder nicht ist natürlich eine aber Frage.

Gruß,

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

Re: [Talk-de] Gibt es einen Tag für Kasseler Sonderbords?

[Martin Simon]

Am 22.07.2014 02:07 schrieb Andreas Neumann andr-neum...@gmx.net:

 Moin,

 wie taggt man am besten Kasseler Sonderbords (die hohen weißen, etwas
 angeschrägten Bordsteine an Bushaltestellen)? Laut alter Diskussion[0]
 ist ein wheelchair=yes unangebracht. Ich bin mir ziemlich sicher schon
 einmal ein entsprechendes Tagging an einer Haltestelle gesehen zu haben,
 finde aber nichts im Wiki dazu. Kann jemand helfen?

Hallo,

ich denke nicht, dass das bloße Vorhandensein eines Kasseler Bordes (oder
eines anderen Busbordes) eine Haltestelle Rollstuhl-ungeeignet macht. Gibt
es da abgesenkte Borde oder Rollstuhlüberfahrsteine am Überweg? Ist das
überqueren der Straße überhaupt möglich oder sinnvoll (baulich getrennt?)?

Gruß,

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

Re: [Talk-de] Tag für Viehunterstand?

[Martin Simon]

Am 19. November 2013 18:08 schrieb Stephan Wolff s.wo...@web.de:

 Ich finde amenity=shelter völlig unpassend. Seit 2006 ist das Tag als
 Wetterschutz für Menschen definiert. Jetzt soll ein Anfang 2013 auf einer
 Unterseite eingetragenes Zusatztag die Bedeutung aufheben. Damit provoziert
 man Missverständnisse ähnlich wie bei disused=yes. Wer bei Regen eine
 Schutzhütte sucht, möchte nicht vor einem eingezäunten Viehunterstand
 landen.


+1
Zumal Viehunterstände auf Weiden selten Einrichtungen für die Allgemeinheit
sein dürften, die von jedem betreten werden dürfen oder sollen.

Zum Vergleich: für Carports haben wir auch einen eigenen tag, obwohl sie
sich teilweise vorzüglich als Wetterschutz eignen. ;-)

Gruß,

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

Re: [Talk-de] innerorts oder außerorts

[Martin Simon]

Am 4. November 2013 08:37 schrieb Florian Lohoff f...@zz.de:


 Und wo wir dabei sind. Was ist eigentlich mit den vielbeschworenen
 Deutschen Umweltzonen - Gibt es da eigentlich einen vorschlag? Ist
 ja im Prinzip ein ähnliches Problem.


Als Pilot eines 27 Jahre alten Diesels würde mich das (und eine Möglichkeit
zur Auswertung) brennend interessieren... ;-)

Gruß,

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

Re: [Talk-de] Spezialgebiet Fahrrad-Mapping

[Martin Simon]

Am 06.10.2013 11:04 schrieb Florian Lohoff f...@zz.de:

 path ist noch so eine pest - Eigentlich als trampelpfad aufgenommen wird
 das heute flächendeckend zum umtaggen von cycle und footway benutzt.

Moment mal, es war genau anders herum. Path war von Anfang an ein
generischer Weg mit zu ergänzenden Attributen.
Seine Gegner haben es dann zum 'Trampelpfad' erklärt.

Gruß,

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

Re: [Talk-de] Dörfer ohne Straßennamen

[Martin Simon]

Am 12.09.2013 20:31 schrieb BBO osm@gmx.de:

 Moin

 Wo zieht ihr eigtl. die Grenze zwischen kein Straßenname und
Straßenname
 identisch mit Ortsname?

 Zumindest Straßen mit Straßennamenschildern (auf denen der selbe Name
steht
 den auch der Ort trägt) haben für mich schlicht und einfach den selben
Namen
 wie der Ort.

 In manchen Dörfern fehlen diese Schilder vlt., an anderen Straßen mit
Namen
 die vom Ortsnamen abweichen allerdings auch.

Es gibt auch viele Fälle, in denen Straßennamensschilder missbräuchlich
verwendet werden, obwohl die Straße nicht diesen oder keinen Namen trägt,
um z.B. kleine Orte, Höfe oder Parks zu kennzeichnen - dieser Fall sollte
auch bedacht werden. Wahrscheinlich sind diese Schilder einfach günstiger.

Gruß,

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

Re: [Talk-de] Dörfer ohne Straßennamen

[Martin Simon]

Am 13.09.2013 11:35 schrieb Martin Koppenhoefer dieterdre...@gmail.com:



 Il giorno 13/set/2013, alle ore 11:11, Martin Simon grenzde...@gmail.com
ha scritto:

  Es gibt auch viele Fälle, in denen Straßennamensschilder
missbräuchlich
  verwendet werden, obwohl die Straße nicht diesen oder keinen Namen
trägt,
  um z.B. kleine Orte, Höfe oder Parks zu kennzeichnen - dieser
  Fall sollte
  auch bedacht werden.


 evtl. mit loc_name mappen?

 Gruß,
 Martin

Wenn, wie gesagt, der Name nicht zur Straße gehört, wieso sollte ich ihn
dann als loc_name an die Straße hängen?  Ich hänge ihn einfach als name an
das Objekt, zu dem er gehört.

Gruß,

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

Re: [Talk-de] Dörfer ohne Straßennamen

[Martin Simon]

Am 13.09.2013 12:14 schrieb Martin Koppenhoefer dieterdre...@gmail.com:

 Sorry, da hatte ich Dich falsch verstanden, nämlich dass eine Straße
keinen oder einen anderen Namen hat als auf dem Straßenschild steht. Du
meintest aber wohl, es gäbe Schilder die wie ein Straßenschild aussehen,
aber etwas anderes als eine Straße kennzeichnen?

Genau so war's gemeint. :)
Ein Beispiel ist iirc in Köln am Hiroshima-Nagasaki-Park, nahe Dürener
Straße, sowie an vielen anderen Parks in Köln.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] OSMF-Vorstandswahl

[Martin Simon]

Am 16. August 2013 13:54 schrieb Michael Buege mich...@buegehome.de:

 Zitat Frederik Ramm:

  Hallo,
 
  On 15.08.2013 16:50, Sven Geggus wrote:
  Gesucht wird also eine junge (oder alte) Frau mit dunkler Hautfarbe, die
  freiwillig einen ehrenamtlichen Job macht.
 
  Und idealerweise nicht aus Europa ;)

 Um sich dann mit mehrheitlich jungen weißen männlichen Europäern
 rumzuschlagen? Die arme Frau.


Da liegt die Lösung ja schon auf der Hand: wir brauchen einen rein
weiblichen Vorstand, um die Fesseln dieser patriarchalen
Unterdrückungskultur hier abzustreifen.

Etwas breiter aufgestellt wäre vielleicht der Ansatz, nur Bewerber
zuzulassen, die Gruppen angehören, die bisher _statistisch gesehen_  ein
geringes Interesse an OSM zeigte. Spontan fallen mir da die Amish ein, aber
es gibt sicherlich auch einige andere.

scnr,

Martin

P.S.: Sarah Hoffmann fällt mir zuerst ein, wenn ich an Frauen bei OSM
denke, die engagiert sind und coole Dinge auf die Beine gestellt haben(z.B.
Lonvia-Wanderkarte).
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] OSMF-Vorstandswahl

[Martin Simon]

Am 16.08.2013 15:07 schrieb Dirk Sohler s...@0x7be.de:

[...]

Sorry, da ist wohl beim Versand nach Neuland der Aufkleber mit der
Ironiedeklaration abgefallen.

Ich dachte es kommt von alleine rüber, dass ich nix davon halte. ;-)

Gruß,

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

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

[Martin Simon]

Am 29. Juli 2013 22:11 schrieb Tirkon tirko...@yahoo.de:

 Ich weiß vermutlich seit der ersten Woche bei OSM, dass der Username
 an jeder Änderung hängt. Das merkt man spätestens dann, wenn man die
 Chronik aufruft. Mir war aber nicht bewusst, dass dieser mit
 herausgegeben wird. Ich bin überhaupt nicht auf die Idee gekommen,
 dass es dafür irgendeinen Grund geben könnte.


Ähm, JOSM als offline-Editor erhält mit jeder Download-Anfrage auch den
letzten Account, der ein Objekt bearbeitet hat. Das sollte nun wirklich
jeder merken, der mit dem Ding öfter als ein paar Mal gearbeitet hat. Und
welchen Grund gibt es dann, anzunehmen, diese (wichtige) Information sei in
den größeren Downloads (planet, Länderextrakte, etc) oder gar der
Datenbank nicht enthalten?


 Zudem habe ich freie
 Projekte eigentlich immer als die Datenschutz-freundliche Bastion im
 Internet angesehen. Wenn man dann noch liest, dass hier eine Geodatei
 herausgegeben wird, ist das falsche Bild schnell komplett. Denn der
 reine Anwender der Geodaten - so war mein sicheres Bauchgefühl - kann
 diese auch mit weggelassenem Usernamen vollwertig nutzen. Von daher
 war ich auch intuitiv der Meinung, das man die nicht herausgäbe.


Klar, was Daten angeht, die nicht für die Mitarbeit am Projekt wichtig
sind. Freie Projekte sind nämlich i.d.R. vor allem eines: offen und
transparent, um jeden Schritt der Entwicklung nachvollziehen zu können
(siehe git, svn, Wikipedia, etc.).


Wenn man weiß, dass Userdaten herausgegeben werden, kommt man auch auf
 den Trichter, dass die freie Lizenz regelrecht dazu einlädt, die
 Userdaten zu analysieren und explizit von jeglichem Datenschutz
 entbindet - ein Effekt, der eigentlich nichts mehr mit dem Primärziel
 zu tun hat. Als Folgeerkenntnis kann diese also nur neueren Datums
 sein, womit ich an das oben Zitierte anknüpfe.


OSM gibt keine Userdaten heraus, sondern Accountnamen. Sonst nix. Du
entscheidest, was du mappst und damit, was du mit deinem Account
unterschreibst. Inwieweit du deinen Account mit deiner Person verknüpfst
ist die zweite Frage und - wieder - nur von dir selbst zu beantworten.


Gruß,

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

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

[Martin Simon]

Am 30. Juli 2013 08:53 schrieb Dirk Sohler s...@0x7be.de:

 Martin Simon schrieb:
  Und welchen Grund gibt es dann, anzunehmen, diese (wichtige)
  Information sei in den größeren Downloads […] nicht enthalten?

 Die Unnötigkeit der Userdaten beim Erstellen der Karten anhand der
 vorhandenen Geodaten.


Das wäre dann deine Vorstellung davon, was für ein Extrakt sinnvoll ist -
andere benutzen diese Information vielleicht, um das mapping vor Ort zu
erleichtern. Ich habe das für meine Garmin-Karte auch schon ausgewertet.

Aber darum ging es gar nicht. Es ging um die Frage, warum Tirkon damals
dachte, dass es für das Projekt OSM abwegig sei, dies mit zu
veröffentlichen, wenn diese Daten schon quer durch OSM für Kommunikation
und Zusammenarbeit genutzt werden und dort nützlich und wichtig sind (wie
er ja bemerkte).

Und ja, es geht meine Mitmapper etwas an, mit welchem Account ich das
Objekt editiert habe, das ich (unwissentlich) versaubeutelt habe - auf der
Website, im Editor, über die (x)api und in Extrakten. Ja, habe sie haben
ein Recht darauf, den betreffenden User im Rahmen ihrer Arbeit an OSM
kontaktieren zu können, um die Sache zu klären.


Gruß,

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

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

[Martin Simon]

Am 30. Juli 2013 16:18 schrieb Dirk Sohler s...@0x7be.de:

 Warum


Na um sie für mich auszuwerten.
Z.B. für einen Overlay, der mir Objekte eines bestimmten Typs anzeigt, die
mich oder nicht-mich als letzten Bearbeiter haben.

Ist aber auch weniger wichtig, warum _ich_ das benutze. Wichtig ist: die
Daten gehören zum Projekt, zum Workflow, zu den Mitteln der Zusammenarbeit,
zu der Vorstellung von Transparenz (und damit Respekt anderen Mappern und
deren Arbeit gegenüber), die hier seit langer Zeit Konsens ist.
Daher ist es nicht verwerflich, eher sogar geboten, sie den Mappern zur
Verfügung zu stellen.

Gruß,

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

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

[Martin Simon]

Hallo Tracy,

Um die ganze Diskussion hier etwas abzukürzen:

1.: ja, macht es! Verbessertes Routing an Bahnhöfen und eine eindeutige
Zuordnung wäre eine tolle Sache, auch für andere Anwendungen.

2.: um die Hilfe der OSM-Community zu erhalten, tut folgendes: sorgt
einfach dafür, dass eure Quelldaten irgendwo frei zugänglich sind, damit
die Mapper sie genau so prüfen (und damit pflegen) können wie amtliche
Gemeindeschlüssel oder Postleitzahlen.

3.: Ein Änderungs-Verbot kann es bei OSM nicht geben, aber es dürfte
einfach sein, bei jedem Import der Daten in das System des Verkehrsverbunds
selbst eine Prüfung auf verdächtige Änderungen vorzunehmen.

4.: Zum Namen des tags: prüft doch einmal, ob es nicht sinnvoll wäre, die
einzelnen ids getrennt zu taggen, z.B. bei Plattformen nur die
Haltestellennummer und PlattformNr als getrennte tags (einfacher
verständlich), die LandkreisNr ergibt sich ja bereits aus dem Grenzpolygon.
Damit hätte eure Anwendung auch alle Daten,  die sie benötigt und fur die
anderen Mapper wäre es einfacher.

Vielleicht wäre es sinnvoll, die tag-findung auf die entsprechenden
öpnv-Seiten im Wiki zu verlagern.

Gruß,

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

Re: [Talk-de] Bauliche Trennung

[Martin Simon]

Gesetze der Realität, heute Numero drölf:

bauliche Trennung ist baulich.

Damit sollte das Ende der Diskussion doch wohl erreicht sein, oder? ;-)


Gruß,

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

Re: [Talk-de] Adressbestände Köln nun als OpenData

[Martin Simon]

Am 4. Juli 2013 21:50 schrieb jotpe jotpe@gmail.com:

 Für meinen Teil benutze ich sehr häufig Adresssuche in OSM, all denjenigen
 wäre dann schonmal geholfen und nicht erst in 5 Jahren.


Die Adressen von grob 1,2% aller Menschen in Deutschland auf einen Schlag
zu bekommen ist schon ein großer Sprung, ja!

Wenn jetzt Berlin, Hamburg, München und Frankfurt nachziehen sind's sogar
grob 10%. ;-)

Gruß,

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

Re: [Talk-de] Naturtrails in OpenStreetBugs

[Martin Simon]

Am 13.05.2013 09:33 schrieb Falk Zscheile falk.zsche...@gmail.com:

  davon kannst Du nicht grundsätzlich ausgehen, schon gar nicht weltweit.
 

 auch nicht, dass ein highway=secondary überall auf der Welt asphaltiert
 ist. Dennoch ist es in Mitteleuropa eine Grundannahme.

Nein. Das ist nicht nur eine unnötige Implikation, sondern auch eine
falsche.

Vor highway=path wurden *alle* diese Wege als footway/cycleway/bridleway
getaggt.

Diesen behaupteten Konsens hat es also nie gegeben.

Gruß,

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

Re: [Talk-de] Nachtrag Bing Luftbildzensur

[Martin Simon]

Am 8. Mai 2013 22:24 schrieb Martin Koppenhoefer dieterdre...@gmail.com:

Bing durfte schon damals gar keine OSM-Daten verwenden für diese Arbeit,

 weil sonst das komplette Werk unter cc-by-sa veröffentlicht werden müsste.
 Sind denn immer noch Reste dieser alten OSM-Daten in den aktuellen
 Luftbildern?


Wenn ich mir das Bonner Verteidigungsministerium ansehe: nein.
Und ich hätte lieber die alten Daten zurück: hier wurde in Ermangelung
genauerer Daten besonders großzügig verpixelt (sicher ist sicher), so dass
die Terroristen jetzt auch Den benachbarten Park, Die Tennisanlage, Das
Freibad, den Kletterwald, den Kindergarten, die Umspannstation, das
Heizkraftwerk und die Schießsportanlage nebst Biergarten nicht mehr
angreifen können.
Danke, ich fühl' mich gleich viel sicherer.

*Dafür* hätte ich den Zaun damals nicht so detailliert eintragen müssen. ;-)

Gruß,

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

Re: [Talk-de] Naturtrails in OpenStreetBugs

[Martin Simon]

Am 6. Mai 2013 17:29 schrieb fly lowfligh...@googlemail.com:

 Da seid Ihr einem Irrglauben verfallen.

 Noch mal:

 Bis auf Zugangsbeschränkungen gibt es keinen Unterschied zwischen path
 und footway/cycleway.

 Alles andere muß mit Zusatztags beschrieben werden.


+1

Mensch, wie einfach wäre alles in OSM, wenn man einfach für jede
Eigenschaft, die man beschreiben will, ein _explizites_ tag verwenden würde?
Alles, was nicht explizit getaggt ist, ist einfach unbekannt.

Und ja: footway/cycleway/bridleway *ist* ein Paradebeispiel dieses
lähmenden Problems!

Gruß,

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

Re: [Talk-de] Wie Buchstaben-Ergänzung bei Hausnummern mappen?

[Martin Simon]

Am 14.03.2013 07:09 schrieb Manfred A. Reiter ma.rei...@gmail.com:

 Ob A oder a legt die Verwaltung fest,

 aber das Leerzeichen zwischen Hausnummer und Buchstaben (DIN 5008) sollten
 wir für DL schon einheitlich übernehmen.

In welcher Weise hat diese DIN denn Relevanz für Hausnummern?

Mir ist in amtlichen Veröffentlichungen und in der Realität bis jetzt nur
die Schreibweise ohne Leerzeichen aufgefallen (und nutze sie folglich auch
beim mappen)

Gruß,

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

Re: [Talk-de] Wie Buchstaben-Ergänzung bei Hausnummern mappen?

[Martin Simon]

Am 14.03.2013 08:13 schrieb Manfred A. Reiter ma.rei...@gmail.com:

 und hier sind wir bei OSM. Also jeder wie er will ;-)

Natürlich. Ich bin ja auch nicht der, der eine Mindestanforderung für alle
vorgeschlagen hat. ;-)

Gruß,

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

Re: [Talk-de] Garminkarten mit Hillshade/ Hillcolour

[Martin Simon]

Hallo Rainer!

Klar!
Auch die rohen OSM-Daten für die Flächen würde ich gerne weitergeben, es
wäre schön, wenn man die Dinger teilen könnte, da es doch ein ziemlicher
Aufwand ist, sie zu erstellen (Senken z.B. benötigen ein Multipolygon etc.).
Vielleicht komme ich dann im Gegenzug an ein paar Regionen, die ich noch
nicht habe :-).

Die Frage ist, wo und wie man sinnvoll ein solches repository anlegt, da
kenne ich mich leider schlecht aus.

Gruß,

Martin


Am 9. März 2013 08:40 schrieb RainerU ra...@sfr.fr:

 Am 08.03.2013 21:38, schrieb Martin Simon:
  Dann öffne man diese mit JOSM und schließe um die Kanten der Kachel herum
  die Höhenlinien zu Flächen zusammen (immer so, dass ein Schnitt durch das
  gelände auf der jeweiligen Höhe diese Flächen ergeben würde).
 
  Dann braucht man noch eine TYP-Datei, die zu jeder Höhenstufe eine Farbe
  enthält. Ich habe mir mehr Farben erschummelt, indem ich teilweise
  transparente Flächen definiert habe, die Teile der darunter liegenden
 Farbe
  durchscheinen liessen.

 Super Idee! Kann man die TYP-Datei bekommen?

 Gruß
 Rainer


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

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

Re: [Talk-de] Nochmal Adressen in Deutschland

[Martin Simon]

Am 9. März 2013 09:09 schrieb Pascal Neis pascal.n...@gmail.com:

 meines Wissens nach gibt es zwei Seiten die dies können [1][2].
 Eine Erklärung zu [1] findest du hier [3] und im dazugehörigen Thread.
 Bei [2] werden nur Ways und deren letzter Bearbeiter betrachtet.
 Dies macht idR keinen sehr großen Unterschied. Allerdings werden keine
 Nodes gezählt, was einen Unterschied machen kann. Die genauen Angaben
 für DE hat aber keine von beiden Seiten.


Danke!

Ich glaube das ist das, was ich gesucht habe.

 Gruß,

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

Re: [Talk-de] Garminkarten mit Hillshade/ Hillcolour

[Martin Simon]

Ja, eine farbliche Darstellung von Höhen funktioniert, ich habe mir so
etwas 2009 für meine Wanderkarten gebastelt (Eifel, Bergisches Land,
Westerwald etc.)[1].

Man nehme ein tool, das Höhenlinien als osm-Dateien erzeugt (ich glaube ich
habe srtm2osm benutzt) und erzeuge damit regelmässige Kacheln(Ich habe
Kacheln in 1/2 x 1/2 Grad-Schritten mit Höhenlinien in 20 m-Abständen
erzeugt).

Dann öffne man diese mit JOSM und schließe um die Kanten der Kachel herum
die Höhenlinien zu Flächen zusammen (immer so, dass ein Schnitt durch das
gelände auf der jeweiligen Höhe diese Flächen ergeben würde).

Dann braucht man noch eine TYP-Datei, die zu jeder Höhenstufe eine Farbe
enthält. Ich habe mir mehr Farben erschummelt, indem ich teilweise
transparente Flächen definiert habe, die Teile der darunter liegenden Farbe
durchscheinen liessen.

Nun das ganze durch mkgmap jagen und als Underlay für die eigentliche
Karte, die die Straßen und Gewässer enthält, verwenden.
Zusätzlich noch einen Underlay mit den normalen landuse-Flächen und man
kann schön zwischen beiden hin und her schalten.

Gruß,

Martin


[1] http://img30.imageshack.us/img30/9595/img0854oj.jpg


Am 8. März 2013 19:36 schrieb Michael Buege mich...@buegehome.de:


 Garminkarten mit Höhenlinien sind ja mittlerweile einige verfügbar.
 Jetzt tauchte folgende Frage auf: Gibt es Karten für Garmingeräte, die
 Hillshading oder Hillcolors anzeigen können? Ist sowas technisch
 machbar?


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

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

[Talk-de] Nochmal Adressen in Deutschland

[Martin Simon]

Hallo Liste,

nach Frederiks Blogpost zu den Hausnummern in Deutschland im Dezember gab
es ja einige Reaktionen, unter anderem erinnere ich mich an eine Seite, die
für einen bestimmten user die Anzahl angelegter addr:housenumber (in
Deutschland?) anzeigte.
Leider finde ich diese Seite nicht mehr wieder, kann mir jemand auf die
Sprünge helfen?

Der Zweite Punkt ist:
Frederik geht in seinem Beitrag von ~40 M Hausnummern in Deutschland aus -
da mich das Thema vor ein paar Jahren schon mal interessierte, habe ich
damals das Netz umgegraben und bin auch eine Zahl von ~23 M gekommen (in
einem open data-bezogenen Vortrag eines Ministeriumsmitarbeiters auf
SlideShare o.ä.).

Jetzt habe ich mich noch einmal auf die Suche begeben und dies hier
gefunden:
http://www.ioer.de/fileadmin/internet/Oeffentlichkeitsarbeit/Veranstaltungen_2011_pdf/3_DD_FNS_2011/BehnischMartin_KleinraeumigeQuantitativeAbschaetzungDesGebaeudebestandesDeutschlands.pdf
Die Autoren kommen auf 22 M Adressdaten (Seite 10) bei 38 M Gebäuden und
liefern gleich eine Verteilung nach Bundesland mit.

Hat jemand Lust, ein paar Graphen zu basteln, die die Erfassung der
Adressdaten in Deutschland und den einzelnen Bundesländern prozentual über
die Zeit zeigen?
Das könnte eventuell stark motivierend wirken. ;-)

Gruß,

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

Re: [Talk-de] Welche Adressdaten an Gebäuden sind sinnvoll? (war: fixme sinnvoll?)

[Martin Simon]

Am 10. November 2012 12:21 schrieb Falk Zscheile falk.zsche...@gmail.com:
 So kann man die Strasse auch dann noch einer Stadt zuordnen, wenn das
 Polygon mal wieder kaputt ist ;)

 Gibt es diesbezüglich schon ein Fehlerkorrekturwerkzeug, dass einem
 sagt dieses Gebäude hat eine PLZ/addr:city, die vom sie umgebenden
 Polygon abweicht?

Ich würde da zur Vorsicht raten, zumindest an den Stellen, an denen
die Postleitzahlen-Gebiete nicht mit Administrativen Grenzen
übereinstimmen, die wir (in dicht besiedelten Gebieten wie Städten)
einigermaßen verlässlich haben.

Zum Beispiel habe ich in Köln vor einiger Zeit (2010?) mal relativ
viele Geschäfte und Kneipen, die an der Grenze von
Postleitzahlengebieten liegen, mit ihren Postleitzahlen nach ihren
eigenen Adressangaben auf den jeweiligen Homepages sowie
vor-Ort-Informationen getaggt, um der Lage der Grenzen (die nirgends
als Grenzen definiert sind!) anzunähern.
(visualisieren ließ sich das ganz gut mit der Plz-Karte von Walter
Nordmann, die es nicht mehr zu geben scheint.)

Später hat dann jemand Plz-Grenzrelationen angelegt und dazu von
dieser Karte abgezeichnet, die jemand einmal aus von der Post
gekauften Plz-Daten erzeugt und befreit hat - die Abweichungen waren
riesig und es würde mich nicht wundern, wenn mittlerweile einige
meiner Adressnodes von gutmeinenden Mappern nach den ungenauen
Grenzen korrigiert wurden.

Das Problem geht ja schon da los, dass mehrere Plz-Bereiche innerhalb
einer Verwaltungseinheit anscheinend gerne als eine Liste aller
Adressen von kompletten Straßenzügen definiert werden, wodurch
Grundstücke an Kreuzungen mal dem einen, mal dem anderen Gebiet
zufallen. Diese Versprünge sind in den Plz-Grenzen in OSM meist nicht
berücksichtigt.

Gruß,

Martin

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

Re: [Talk-de] Strassennamen Vergleich für die Schweiz

[Martin Simon]

2012/11/9 Andreas Schmidt schmidt-postf...@freenet.de:
 Hallo Fred,

 in welchem Land schreibt man denn thinked als Vergangenheitsform von
 to think?

Auf welcher Mailingliste ist sowas wichtiger als das Thema des Threads?

Denkte der Autor nicht daran, daß es möglich wäre, daß der
Angesprochene diese Sprache nicht von seiner Mutter lernte?
(  http://de.wikipedia.org/wiki/Muttersprache )
;-)

Gruß,

Martin

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

Re: [Talk-de] Image of the week?!

[Martin Simon]

Am 24. September 2012 17:28 schrieb Sven Geggus li...@fuchsschwanzdomain.de:

 Wenn das OSM _ist_ und Apple attributiert das nicht, dann ist das eine
 Lizenzverletzung und dann sollte man Apple höflich aber bestimmt auffordern
 diese einzustellen. Hat jemad ein solches Gerät und kann mal ins Impressum
 schaun?

 Ich finde es ehrlich gesagt sehr wichtig, dass wir für eine Firma, die sich
 IMO schlimmer verhält als Microsoft das jemals getan hat keine Extrawürste
 braten!

*signed*

Ich bin nicht dafür, hier mit zweierlei Maß zu messen, weil Apple
böse ist und sich in kurzen Abständen den Preis goldener Troll der
IT-Industrie selbst verleiht, aber das heißt nicht, dass man die
Zügel hier besonders locker lassen sollte. ;-)
Es dürfte dem wertvollsten Unternehmen der Welt nicht besonders weh
tun, einen gut sichtbaren Lizenzhinweis anzubringen (wenn es sich um
OSM-Daten handelt) und eine mögliche abgeleitete Datenbank frei
verfügbar zu machen.

(gerade per google geangelt: im Forum
(http://forum.openstreetmap.org/viewtopic.php?pid=276682) tauchte
dieser Link auf: http://gspa21.ls.apple.com/html/attribution.html -
dort ist OSM mit aufgeführt, jedoch ohne Lizenz.)

Gruß,

Martin

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

Re: [Talk-de] Adressen

[Martin Simon]

Am 21. September 2012 16:57 schrieb Bernhard Weiskopf bweisk...@gmx.de:
 Ähnlich ist das mit den Heddesheimer Höfen am Hirschländerweg.
 Das Geo-Informations-System der Stadt Mannheim
 http://www.gis-mannheim.de/mapserver_mann/ kennt den Hirschländerweg, teilt
 aber mit Es sind keine Hausnummern eingetragen. Logisch, die Höfe sind
 auch nicht auf Mannheimer Boden.
 Der von Heddesheim verlinkte Stadtplan
 http://www.1001-stadtplan.de/stadtplan/heddesheim/kartenstartpunkt/stadtpla
 n-heddesheim.map kennt dagegen den Hirschländerweg nicht, der liegt ja auch
 in Mannheim.

Ich würde sagen, daß, wenn die Höfe in Heddesheim liegen, sie zwingend
auch eine Heddesheimer Adresse besitzen und würde diese auch bevorzugt
eintragen, Post-interne Kuriositäten hin oder her.

Wem das Flurstück gehört, auf dem die Straße liegt, ist dabei erstmal
egal - es ist m.W. recht selten, dass Grenzen tatsächlich in
Straßenmitte verlaufen, dieser Fall hier ist also eher normal.

Hast du mal das Heddesheimer WebGIS auf deren Homepage befragt? Bei
mir funktioniert das nicht, mangels Internet Explorer.

 Bei www.openstreetmap.org findet man die Höfe auch nicht, egal ob man
 eingibt z. B.
 heddesheim, hirschländerweg 30 oder
 mannheim, hirschländerweg 30
 Nur hirschländerweg 30 findet das richtige Haus, nennt aber Viernheim als
 Stadt.
 viernheim, hirschländerweg 30 wird aber auch nicht gefunden.

Da hast du eine Unzulänglichkeit in Nominatim gefunden. Ich habe es
gerade mal mit einem Beispiel bei mir um die Ecke ausprobiert:
Nominatim scheint immer gesamte Straßen einer Verwaltungsgrenze
zuzuordnen, und damit alle ihre Hausnummern, ungeachtet von deren Lage
oder addr:city. Beim Hirschländerweg wird anscheinend ein Teil
Viernheim zugeordnet, der andere Mannheim - obwohl beide vollständig
im Mannheimer Polygon liegen.

Ich bin übernächste Woche in Heddesheim und wollte dort auch ein wenig
mappen, vielleicht lässt sich vor Ort ja etwas herausfinden.

Gruß,

Martin

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

Re: [Talk-de] Benennung von Wegen

[Martin Simon]

Am 14. August 2012 21:26 schrieb Jan Tappenbeck o...@tappenbeck.net:
 Hi !

 ich habe mir mal die Benennung (name) von highway=* bei uns im Umfeld
 angesehen und mir sind dabei so einige aufgefallen wo ich meine - diese
 Angaben haben  nichts im Namens-Tag zu suchen.

 Fussweg von A nach B
 Zwei Straßennamen - KOMMA getrennt
 Fernwanderweg E.
  nach X-Dorf
 B210 (1. Qartal 2015)  - besser bei REF; wäre schon schön wenn diese mit
 den Standard Renderern dargestellt wird, auch wenn wir nicht 
 xxx Ferienwohungen
 ehemalige Kleinbahn von 
 Fahrradweg A-Dorf 
 Fussweg zur A-Straße

+1

Beschreibungen sind keine Namen - immer wenn man sich dabei ertappt,
eine beschreibende Bezeichnung in das name-tag zu schleusen, sollte
man m.E. darüber nachdenken, ob der Grund dafür nicht sein könnte, daß
das Objekt schlicht keinen Namen *hat*.

Einer meiner Favoriten: name=den Toten der Kriege zum Gedenken etc.

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

Re: [Talk-de] OsmAnd

[Martin Simon]

Am 18. Juli 2012 17:21 schrieb Markus liste12a4...@gmx.de:
 Liebe Anwender,

 Wer kann bei OsmAnd helfen?
 http://wiki.openstreetmap.org/wiki/DE:OsmAnd
 http://www.osmand.de/
 Habe das Prog runtergeladen: funktioniert gut.

 Beim Zappen im Menü habe ich irgendwo die POI-Anzeige eingeschaltet.
 Jetzt sind alle POIs orange hinterlegt.
 Wie schalte ich die Anzeige wieder ab?

Wenn die Karte angezeigt wird: Menütaste - Darstellung - POI.

Dort kannst du auch POI-Gruppen oder eigene Filter wählen.

Gruß,

Martin

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

Re: [Talk-de] Straßenbegleitende Radwege

[Martin Simon]

Am 24. April 2012 15:02 schrieb Wolfgang wolfg...@ivkasogis.de:

 Ich hätte gerne gewusst, wie ich jetzt Trampelpfade taggen soll, nachdem
 das path-Tag durch die FußRadPfadefraktion gekapert wurde.

Da wurde nix gekapert.
highway=path ist ein alternatives Konzept zu dem früheren Ansatz,
alles in eine von 3 (aus der Situation in England abgeleiteten)
Kategorien pressen zu wollen (footway/bridleway/cycleway) und war das
auch von Anfang an.

Vor path wurden deine Trampelpfade ganz selbstverständlich als
highway=footway getaggt.

Nach der Einführung von path gab es leider Leute, die das Konzept
ablehnten, aber trotzdem davon profitieren wollten, daß es nun einen
weiteren highway-tag gab - sie erklärten ihn kurzerhand zum
Trampelpfad und dichteten footway fortan rückwirkend eine höhere
Qualität oder gleich Widmung als Fußweg an.
DAS war der Akt der Piraterie, er wurde aber von der anderen Seite begangen.

Übrigens steht auch das Wort path *nicht* für Trampelpfad, für
Radwege ist z.B. auch bike path gebräuchlich.

Aber viel Spaß mit highway=trail, highway=narrow_trail und
highway=damn_narrow_trail ;-)

Gruß,

Martin

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

Re: [Talk-de] Fahrspuren die 315.

[Martin Simon]

Am 9. März 2012 13:53 schrieb Christian Müller cmu...@gmx.de:

 Ich würde Dich bitten, Dich eingehend mit dem proposal zu beschäftigen.  Was 
 Du hier schreibst stimmt wrt TR einfach nicht.  Du hast TR entweder gar nicht 
 verstanden oder beschränkst Dich nur auf einen Teilaspekt, den Du glaubst 
 verstanden zu haben.  Also nochmal:
[...]

Das hat sich als Mißverständnis herausgestellt: ich hatte deine
Restrictions in JOSM als way-node-way interpretiert, deren via-node an
der Haltlinie liegt (was auch aus meinem Text hervorgehen dürfte) -
sorry dafür.

Technisch sind die restrictions also in Ordnung, ich kenne aber
ehrlich gesagt keinen Router, der via-ways auswertet. Kennst du einen?
Für manche nach derzeitigem Konsens gemappte Kreuzungssituationen
kommt man ja auch nicht drum herum (links abbiegen erlaubt, u-turn
verboten bei baulich getrennten Richtungsfahrbahnen als separate
Ways).

Sei also versichert: ich verstehe TRs - ich war sogar schon vor ihnen hier. ;-)

Was auf jeden Fall bleibt, ist die total verhagelte Geometrie.

 Du hast Recht, wenn Du argumentierst, dass GPS u.U. nicht spurgenau 
 positioniert.  Dafür können die Daten aber nichts und ein paar Galileo Sats 
 sind ja auch schon oben..

Naja, aller Voraussicht nach wird das auch nicht den großen Vorteil in
Standardsituationen bringen, eher in solchen, in denen man heute zu
wenig Satelliten überhaupt empfangen kann.

Das Problem ist auch nicht nur die Genauigkeit der Positionierung,
sondern auch die Trennung von _einer_ Verkehrsfläche mit verschiedenen
Spuren in verschiedene Wege, die keine Verbindung besitzen - das macht
korrektes Routing im Falle einer (Neu)berechnung im Bereich vor einer
Kreuzung auch dann zur Glückssache, wenn du deine Position im
Submeter-Bereich bestimmen könntest. (einzige Chance: du bist zufällig
auf der Spur, die zur korrekten Route gehören würde)

Natürlich kommt jetzt, man könne per Relation das soeben auseinander
gefledderte wieder zusammen kleben... das macht die ganze Konstruktion
nicht unbedingt leichter handhabbar.

 Das stimmt nur dann, wenn die routing engine die TR nicht nutzt.

 Eines noch, wenn mkgmap Abbiegeanweisungen aus der Geometrie errechnet, ist 
 das toll, es entspricht aber nicht der Definition von TR - dort ist die 
 Anweisung, die ein TR-kompatibler Router zu nutzen hat, klar in _*_* kodiert, 
 während also e.g. in no_left_turn das no für den Routinggraph relevant ist, 
 ist der gesamte String Nutzeranweisung.  Aus der Geometrie sollten 
 Anweisungen nur dann erzeugt werden, wenn keine TR vorhanden sind.

Nö, der ist eher Mapperhilfe und war von anfang an nicht als
Routerhinweis gedacht - ein no_lean_right oder no_sharp_right_turn
haben wir ja beispielsweise nicht.
Im Zweifel könnte man natürlich darauf zurückgreifen.

 Das ist auch so herum sinnvoll, da es aufwendiger ist, aus der Geometrie eine 
 Anweisung zu errechnen, als wenn schon eine in der Relation verfügbar ist.

Das muß man eh mindestens für alle Kreuzungen ohne TR (Millionen!) tun
und es funktioniert zuverlässig.

Mit deinem Ansatz wird für jede Kreuzung, an der auch nur eine
Abbiegespur oder auf einer Fahrbahn mehr als eine Spur pro Richtung
existiert ein großer Haufen ways und Relationen fällig - plus
virtuelle Hilfswege zum leidlichen Wechsel der Spuren bei komplexeren
Kreuzungen.

Daß dabei ein paar Hinweise für den Router anfallen, wie eine Aktion
angekündigt werden könnte, vermag ich da nicht als großen Vorteil zu
erkennen...

Noch eine Bemerkung zum Schluss:
Auch highway=*_link ist nicht für Spuren derselben Fahrbahn gedacht,
sondern für Verbindungen, die baulich von der Hauptfahrbahn (so es sie
gibt) getrennt sind.

Gruß,

Martin (der erst vorgestern vom Garmin einmal um den Block gelotst
wurde, weil jemand die Straße fälschlich als baulich getrennt
gemappt hat und das Ziel auf der anderen Straßenseite lag. ;-) )

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

Re: [Talk-de] Fahrspuren die 315.

[Martin Simon]

Am 7. März 2012 01:06 schrieb Christian Müller cmu...@gmx.de:
 Hi Stephan,

 Am 07.03.2012 00:15, schrieb Stephan Wolff:

 Ich kann nicht erkennen, dass die Stern-Topologie die von mir genannten
 Probleme löst. Ob die Ampeln und die Radwegquerungen zur Kreuzung gehören,
 ist aus den Daten nicht erkennbar.


 Aber natürlich ist es das.  Die Radwege queren dort, wo sie auch in der
 Realität queren, selbst die Ampeln sind präziser platziert als vorher - oder
 hast Du schonmal eine Ampel mitten auf der Kreuzung stehen sehen?

Er meint mit Kreuzung die gesamte Anlage - und die Zugehörigkeit zu
dieser ist aus den Daten auch in deinem Modell nicht erkennbar.

 Insbesondere ist ersichtlich, für welche lanes überhaupt Ampeln existieren.
  Abgesehen davon verraten Dir die üblichen Daten nicht gerade mehr darüber,
 was zu einer Kreuzung gehört.  Was gehört denn zu einer Kreuzung?

Leider verwendest du dafür parallele Straßen mit jeweils einer
Ampelanlage, die keinen Bezug zueinander haben...

 Diesen Nachteil habe ich im Wiki schon benannt und auch Lösungsvorschläge
 angegeben.  Vorher konnte der Router auch nicht erkennen, von wo bis wohin
 Spurwechsel erlaubt sind - das ist an verschiedenen Kreuzungen nämlich auch
 sehr verschieden..  Wenn lanes nicht extra gemappt werden, verleitet das
 viel mehr zur Ungenauigkeit solcher Infos.  Wie oft sieht man schonmal ein
 korrekten lanes=* Wert vor Kreuzungen?  Ist doch eher selten - die Leute tun
 bisher so, als ob es den Kreuzungsausbau gar nicht gäbe.  Dabei ist doch
 gerade das wichtig, will man richtig routen.

Nein, gerade nicht, denn in welche Spur ich mich einordne wird in der
Realität durch das schauen durch das große Fenster vorne am Auto
entschieden, nicht durch die Ansage des Navigationssystems.
Umgekehrt ist mit deinem System die Chance, daß der router nicht die
Spur als deinen Standpunkt annimmt, auf der du tatsächlich stehst,
wenn du eine Routenberechnung anstößt, sehr hoch. Das Ergebnis ist
eine anfangs falsche Route - eigentlich, denn ein Fehler im Konzept
der Stern-Topologie macht es egal, welche spur man wählt. Dazu weiter
unten mehr...

 Für einige gerade Kreuzungsquerungen werden vermutlich falsche Anweisungen
 zum Rechtsabbiegen im Sternpunkt ausgeben.
 Der entscheidende Kritikpunkt ist aber, dass das Konzept nicht kompatibel
 zur bestehenden highway-Definition ist.


 Das ist schlichter Unsinn und zeigt, dass Du dich mit turn-restricitions nur
 ungenügend beschäftigt hast.

Ich fürchte es verhält sich anders herum, weiter unten mehr dazu.

 Hier also nochmal, am Beispiel eines
 only_straight_on:

  - für den Router heißt das: nur vom from in den to Weg routen, alle anderen
 als invalid markieren
  - für den Benutzer heißt es immer straight_on - selbst dann noch, wenn
 from und to geometrisch in anderen Winkeln als 180 Grad zueinander stehen.
  - du kannst mit turn_restrictions in osm einen u_turn mit only_straight_on
 bauen und der Benutzer erhielte die Anweisung gerade aus über die
 Kreuzung, obwohl die Geometrie dem nicht entspricht
  - deine Bedenken treffen evtl. für routing engines zu, die
 turn_restrictions nicht auswerten

Das ist Quatsch. Turn restrictions geben allgemein nur eine Erlaubnis
oder ein Verbot des passierens eines Punktes (!) an, unter
Berücksichtigung des Start- und Zielweges.
Schau dir z.B. mkgmap an. Die Anweisung geradeaus / links halten /
links abbiegen werden aus der Geometrie gebildet.

Die Richtungen (no_left...) sind weitgehend egal für den Router, da TR
so angelegt sind, daß Router eigentlich NUR auf restriction=only..
und restriction=no.. schauen müssen, um einen korrekten
Routinggraphen aufzubauen - und meines Wissens nach tun sie auch nur
das. Alles hinter only und no dient nur der Übersicht der Mapper,
um die Relation den entsprechenden realen Verkehrszeichen zuzuordnen.

Der zweite Punkt zu TR ist, daß du sie in deinem
Sterntopologie-Beispiel absolut wirkungslos und nichtssagend einsetzt.
(sorry, es ist so.)
Betrachte hier
http://www.openstreetmap.org/?lat=51.324213lon=12.290977zoom=18layers=M
die aus Westen kommende Linksabbiegerstra äh spur:

Die Turn restriction ist an dem Punkt gesetzt, an dem du im Luftbild
die Haltlinie erkannt hast.
Da an diesem Punkt aber nur 2 Wege aufeinander stoßen und diese
aufeinander folgende Einbahnstraßen sind, bringt eine TR an diesem
Punkt keine zusätzliche Information für das Routing: sie erlaubt nur
die Möglichkeit, die erste Straße zu verlassen, die die einzige ist,
die es überhaupt gibt: über den via-Punkt auf die zweite Straße.

Das zweite große Routingproblem ist, daß man in dieser Sterntopologie
trotz der 13(!) turn restrictions an der Kreuzung von jeder Spur aus
in jede Richtung abbiegen kann, da alle Spuren auf _einen_ Punkt
zulaufen, von dem aus es die Möglichkeit gibt, auf _jede_ andere
Spur, die von diesem weg führt, abzubiegen.
Was würdest du tun, wenn einem der beteiligten Ströme das Links
abbiegen verboten wäre?
Diese Spur einfach geradeaus bis hinter die Kreuzung 

Re: [Talk-de] Fahrspuren die 315.

[Martin Simon]

Am 5. März 2012 21:15 schrieb Steffen Wolf s...@gmx.de:
 Die Notiz ist mir auch aufgefallen, aber die Kreuzung hab ich jetzt erst
 angesehen.

 Die ist uebrigens ein schoenes Beispiel fuer Fahrspurmapping, die
 einzelnen Spuren sind naemlich in Wirklichkeit nicht getrennt. An sich
 ist die Kreuzung gar nicht so kompliziert.

Ein wahres Juwel.
Diese ganzen Geisterspuren in der Kreuzungsmitte dann wieder
sternförmig zusammen zu fassen unterstreicht die Brillanz des mappens
nicht getrennter Spuren als eigene Wege sogar noch besser als das
wilde kreuzen oder überschneiden aller möglichen Abbiegespuren im
Kreuzungsbereich.
Sahnehäubchen: Abbiegerelationen ohne Kreuzungsmöglichkeit, um an der
Haltelinie in JOSM die schönen blauen Pfeile angezeigt zu bekommen.
Schokostreusel obendrauf: layer=-5 für Spuren und und layer=1 für Radwege.
Herr Mapnik macht Freudensprünge.

;-)

Gruß,

Martin

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

Re: [Talk-de] Relation Deutsche Bundesstraßen gelöscht

[Martin Simon]

Am 01.02.2012 08:27 schrieb Ronnie Soak chaoschaos0...@googlemail.com:

 Jemand, dem es nicht zuzumuten ist, eine Wiki-Seite zu editieren, eine
 Windows-Eingabeaufforderung zu starten oder einer technische Anleitung
 zu folgen soll jetzt also Grund sein, eine redundante und
 ueberfluessige Relation bereit zu stellen?

Moin,

es ist eventuell nicht sehr offensichtlich gewesen, aber die Antwort war
ein Hinweis auf die Tatsache, daß sich (für Software) aus ref=* eben nicht
die deutsche “Verwaltungsebene“ einer Straße ablesen lässt - ebenso wenig
wie aus dem name-tag einer Sammelrelation natürlich - und ich habe keine
Sekunde daran gezweifelt, daß Martin das auch so verstehen würde. ;-)
Also in klaren Worten: ich bin auch kein Fan der bloßen Sammlung und würde
einen tag für die Verwaltungsebene befürworten.

Gruß,

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

Re: [Talk-de] Relation Deutsche Bundesstraßen gelöscht

[Martin Simon]

Am 1. Februar 2012 01:42 schrieb Martin Koppenhoefer dieterdre...@gmail.com:
 4. für die Bundesstraßen z.B. das hier eingeben:
 osmfilter.exe germany.osm --keep=highway= and ref=B*
 -o=bundesstrassen-netz.osm

OK, und jetzt für Landesstraßen, oder besser: Kreisstraßen ;-)

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

Re: [Talk-de] Lübeck oder Lübeck-Travemünde

[Martin Simon]

Am 13. Januar 2012 11:32 schrieb Andreas Neumann andr-neum...@gmx.net:
 Mhhh... Ich handhabe das so: addr:city bekommt bei mir den richtigen
 Namen (also den Obernamen bei Städten). Via addr:suburb definiere ich
 dann den Ortsteil.
 Damit tritt man gerade in sehr selbstbewussten eingemeindeten Ortsteilen
 so manchen auf die Füße...

 Einzige Ausnahme bisher: Bei mir um die Ecke gibt es eine
 Dorfgemeinschaft (Verwaltungsgemeinde), die sich einen Namen gegeben
 hat, den bisher gar kein Dorf hat. Da hab ich mal das Dorf in der city
 belassen ;).


 So, und nun sehe ich, dass die mein schönes Attribut gekillt haben :(...
 addr:suburb war vor einiger Zeit mal in der Diskussion, aber scheinbar
 muss man heutzutage addr:district und addr:subdistrict verwenden...
 Vllt. kann ja mal wer nen Bot losschicken, der all meine suburb-Leichen
 in district-Attribute umwandelt.

Hallo Andreas!

Ich habe auch spärlich addr:suburb verwendet und halte es auch für
richtige und wichtig, diese Information zu erfassen. Bei uns in der
Gegend gibt es seit der Gemeindereform einen Haufen Gemeinden, die aus
vielen Dörfern bestehen, die Auswärtige nicht oder nur durch raten der
richtigen Gemeinde zuordnen können.

Teilweise haben diese Dörfer, die jetzt Ortsteile von Gemeinden sind,
selbst noch Ortsteile - also eine dritte Ebene - was jetzt zu
Problemen beim Adress-tagging führt, da suburb nicht ausreicht.
Eventuell sollten wir aber den Begriff suburb überdenken, da die
Assotiation damit doch eher irreführend ist.
Vielleicht wäre etwas analog zu admin_level besser...

Wenn jemand dazu eine Wiki-Seite eröffnen möchte, würde ich gerne an
einer Lösung mitwirken.

Gruß,

Martin

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

Re: [Talk-de] Offline Android App mit Höhenlinen

[Martin Simon]

Am 25. November 2011 19:44 schrieb Sven Anders s...@anders-hamburg.de:
 Moin,
 kennt jemand eine Android OSM Karten/Routing App mit Offline-Funktion die
 Höhenlinien mit einblendet? (Möglichst was Vektorbasiertes)

Hallo!

Osmand kann Vektorkarten, Offline-routing/Adress/Poi-Suche und seit
neuestem gibts dafür auch hier [1] Vektor-Höhenlinien im 20 m-Abstand
für die halbe Welt. :-)

Gruß,

Martin

[1] http://www.pistes-nordiques.org/downloads/

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

Re: [Talk-de] Tiles Downloader bremsen Server aus

[Martin Simon]

Am 5. Oktober 2011 22:46 schrieb Jan Jesse j...@jesse.de:
 Hi,

 Eine Applikation, die gut und schnell selber rendert, ist halt
 schwieriger zu schreiben, als der 1000. Tile-Downloader, den man sich
 mal eben im App-Baukasten zusammenklickt ;)

 Bye
 Frederik

 als gerade selbst betroffener möchte ich mal in eine freundliche Richtung 
 argumentieren. Ich gehe davon aus, daß die Tiles so beliebt sind, weil sie 
 die einfachste Schnittstelle zur Endnutzung darstellen. Das mit der 
 Handy-Render-App ist m.E. Zukunftsmusik.

Nicht ganz. Ich bin da kürzlich (wieder) auf Mapsforge[1] gestoßen.
Zumindest eine Android-App, die es nutzt, kenne ich: c:geo.

(Vielleicht ist es mal Zeit für einen tiled vector map service, von
dem man .osm.pbf-Daten für den jeweiligen Aufenthaltsort (automatisch)
im (beispielsweise) Viertelgrad-Raster herunterladen und lokal rendern
lassen kann.
Viele dürften sich scheuen, mehrere Länder in der Gewichtsklasse von
Deutschland (~1gb) manuell herunterzuladen und hin und wieder aktuell
zu halten, nur um die eigene (Grenz-)Region abzudecken.)

Gruß,

Martin

[1]http://code.google.com/p/mapsforge/

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

Re: [Talk-de] Macht's gut und danke für den Fisch

[Martin Simon]

Am 30. September 2011 14:24 schrieb Gary G: g...@gary68.de:
 Liebe Mitmapper,

 ein wenig traurig, aber dennoch. Ich werde meine aktive Zeit bei OSM beenden. 
 Ich habe lange für OSM „gearbeitet“, viel Spaß gehabt, einiges erreicht und 
 viel gelernt (XML, Perl, bash, SVG). Aber es ist Zeit für etwas Neues. Es 
 fehlen mir auch ein wenig die Anreize und Herausforderungen.

 Abschließen werde ich meine Aktivität auf dem Perl Workshop in Frankfurt, wo 
 ich in drei Wochen Mapweaver vorstellen werde.

 Meine Programme liegen im SVN, wo sie jeder gerne weiter nutzen, modifizieren 
 etc. kann.

 Meinen Server gary68.de werde ich bei Zeiten kündigen, aber ich denke, ein 
 paar Monate hat er noch. Die regelmäßige Erstellung der Reports stelle ich 
 ein.

 Sollte Mapweaver Wartung notwendig werden oder würde eine Erweiterung 
 gewünscht, so kann ich mir das durchaus vorstellen. (Mein „Meisterstück“ kann 
 ich ja schlecht im Stich lassen.)

 Unter meiner privaten eMail Adresse bin ich auch weiter erreichbar.

 Vielen Dank euch allen und weiterhin viel Erfolg und Spaß bei OSM!

Hallo Gary!

Ich finde das sehr schade, Mapgen.pl ist wirklich ein geniales tool,
um aus OSM-Daten relativ einfach Vektorkarten im korrekten Maßstab für
den Druck zu erzeugen!

Ich hab auch schon seit der Ankündigung von Mapweaver vor, mir das
Programm mal anzusehen, meinen Mapgen-Stil darauf umzustellen (wenn
nötig) und dann weiter auszuarbeiten. (mein Fernziel wäre eine Art
Webservice, der mittels mapgen oder Mapweaver .pdfs eines beliebigen
Ortes in beliebigem Maßstab für gängige Papierformate erzeugt, so daß
jeder damit klarkommt - aber dafür fehlen mir die Fähigkeiten)

Vielen Dank für deine ganze Entwicklungsarbeit, den Einbau fast aller
vorgeschlagenen Funktionen (ein paar hätte ich noch in der Schublade
;) ) und natürlich die ellenlangen Diskussionen über die Skalierungs-
und Auflösungsproblematik. ;)

Gruß,

Martin

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

Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel

[Martin Simon]

Am 28.09.2011 00:33 schrieb Garry GarryD2@gmx.

 Multipolygone führen dazu dass ähnliche Flächengrenzen zusammengefasst
werden damit es übersichtlich aussieht (weil nur noch eine statt viele Linie
im Editor zu sehen ist) aber in Wahrheit die realen Flächengrenzen
verfälscht. Ein Wald endet nicht an der Mittellinie einer Strasse oder eines
Flusses!

Das ist Quatsch und das weißt du vermutlich auch selbst.
Die Benutzung von Multipolygonen und das zusammenlegen von Flächengrenzen
und Linienobjekten (Straßen,...) sind zwei verschiedene Dinge. Es gibt
genügend Mapper, die auch “normale“ Flächen an Straßen etc. anpappen -
diejenigen, die dies ablehnen (wie ich) werden wohl auch bei der Nutzung von
MPs nicht plötzlich damit anfangen.
Diese Frage taugt also nicht als Argument gegen MPs.

Gruß,

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

Re: [Talk-de] Suburb vs. Village

[Martin Simon]

Moin! Ich finde es super, daß ihr euch dieses.Themas annehmt und die
Richtung der Diskussion gefällt mir gut.

Ich habe im Moment wenig Zeit, um hier mit zu wirken, möchte euch aber
bitten, auch gleich das Adresstagging im Karlsruhe-Schema mit zu
berücksichtigen.
Ich tagge seit kurzem auch addr:suburb für Stadtteile und auch für einer
Gemeinde angehörende Dörfer (iirc nach einem Vorschlag von Martin hier auf
der Liste). Gerade dort ist es sehr hilfreich, weil kaum jemand Straßen in
einem zugehörigen Ort unter dem Namen des Hauptortes suchen würde (so er
überhaupt weiß, welcher das ist - hier in NRW  sind solche
Gemeindestrukturen die Regel).

Gruß,

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

Re: [Talk-de] Suburb vs. Village

[Martin Simon]

Am 26.09.2011 13:12 schrieb Martin Koppenhoefer dieterdre...@gmail.com


 echt? Meinst Du mich? Ich sehe das eher so, dass Stadtteile, die
 eigentlich Dörfer waren, und nach wie vor räumlich getrennt sind, eher
 als village oder hamlets getaggt werden sollten. Ich schliesse
 allerdings auch nicht vollständig aus, dass ich das vor einiger Zeit
 evtl. anders beantwortet hätte.

Ja, ich meine dich (entschuldige, falls ich mich irre), jedoch nicht in
Bezug auf place=*, sondern nur addr:*=* betreffend, keine Panik! ;)

Gruß,

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

Re: [Talk-de] place=locality nodes und mapnik

[Martin Simon]

Wie wäre es stattdessen mit einem subtagging von place=locality in der Art
von locality=cadastral_section?
Dann kann ein Renderer selbst entscheiden, ab wann er sowas rendert.

Gruß,

Martin
Am 04.09.2011 14:49 schrieb Andi K test9...@gmx.de:
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] living_street + alley?

[Martin Simon]

Am 22. August 2011 10:43 schrieb Sven Geggus li...@fuchsschwanzdomain.de:
 Peter peter@gmx.net wrote:

 sich ausschließt. Falsches Taggingschema?
 living_street hat IMHO mehr was richtung maxspeed.

 Ich fand highway=living_street von Anfang an bescheuert. In 99% der Falle
 in Deutschland sind das ganz normale residential roads. Die Tatsache, dass
 das eine Spielstraße ist sollte in einen eigenen Tag.

+1, genau wie highway=cycleroad und highway=pedestrian handelt es sich
hier um eine Verkehrsregelung, die in einem Bereich (Wegabschnitt oder
sogar Zone) gilt, in dem alle möglichen Arten von Wegen vorkommen
können, auch untergeordnete(Denk an schmale Wege in einer
Fußgängerzone und was Radfahrer hier von ihrer Karte erwarten würden).

Je länger ich bei OSM bin, desto eher wünsche ich mir sehr wenige
highway-tags und dafür lieber aussagekräftiges subtagging - es wäre
einfacher und klarer für Mapper, Renderer und Router nach dem Motto:
Ich trage nur ein, was ich weiß / ich werte nur aus, was ich wissen
will. (aber das führt natürlich über diese Diskussion hinaus.)

Gruß,

Martin

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

Re: [Talk-de] Android

[Martin Simon]

OsmAnd ist sehr zu empfehlen. Offline-OSM-Vektorkarten, Adressuche,
Navigation, Openstreetbugs anzeigen und erstellen, etc

Gruß,

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

Re: [Talk-de] Karten-Navigation auf dem Kindle

[Martin Simon]

2011/6/29 Bjørn Bäuchle baeuc...@th.physik.uni-frankfurt.de:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Am 29.06.2011 18:17, schrieb Barthwo:
 Du sprichst mir aus der Seele.

 Auf der Standardseite openstreetmap.org kann man Mapnik-Karten als pdf
 drucken bzw. exportieren. Dann musst du gar nicht selber rendern.
 Das war mir schon klar, nur…

 Nur in die nächste Zeile also oben und unten navigieren
 geht nicht über einen Link, sondern nur indem man eben 4 oder 6 oder so
 Seiten weiterblättert, je nachdem wieviele Bilder eine Kartenzeile
 bilden.
 DAS ist eben nicht gut. Und ich weiß nicht, wie ich in ein PDF links
 einbauen kann. Außerdem mag ich vielleicht die Farben etwas tweaken,
 aber mal sehen.

 Also, wie kann man pdfs rendern?
 Bjørn

Schaut euch doch mal [1] und die Erweiterung [2] von Gary68 an, damit
kann man auch auf mehrere Seiten verteilt eine Karte eines größeren
Gebiets inkl. Übersicht, POI-Verzeichnis usw. automatisch rendern
lassen - der topo-Stil [3], den ich dazu gebastelt habe ist recht
kontrastreich und evtl. ja für eure eInk-Displays geeignet. Oder ihr
baut einfach einen eigenen.

Gruß,

Martin

[1] http://wiki.openstreetmap.org/wiki/Mapgen.pl
[2] http://wiki.openstreetmap.org/wiki/Hikingbook.pl
[3] http://svn.openstreetmap.org/applications/utils/gary68/topoRules.csv
http://svn.openstreetmap.org/applications/utils/gary68/topoIcons.zip

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

Re: [Talk-de] Luftbilder für JOSM

[Martin Simon]

Am 27. Juni 2011 20:34 schrieb Steffen Heinz eifelhu...@gmx.de:

  kann mir kein eigenes Flugzeug leisten ;)

Hallo Steffen!

Da du dich ja schon lange damit herum quälst:
Hast du mal unseren Propheten Steve Coast (st...@asklater.com)
gefragt, ob das Bing-Team da was dran drehen kann?
Er hat neulich auf der englischen Liste gefragt, in welchen Regionen
die Luftbilder verbessert oder beschafft werden sollten.

Da Microsoft das Material (eventuell) nicht neu einkaufen, sondern
nur vom Hersteller eine korrekte Rektifizierung verlangen müsste,
könnte das problemloser klappen, als man vielleicht denkt... ;-)

Gruß,

Martin (der in der Eifel auch schon auf die krummen Bilder stieß)

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

Re: [Talk-de] Gebäudeteile

[Martin Simon]

Am 24. Juni 2011 15:17 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com:

 m.E. ist diese Art des Mappens weniger gut, obwohl es durchaus Sinn
 macht, Gebäudeteile einzeln zu mappen. Das Problem ist, dass anstatt
 eines großen Gebäudes nun mehrere kleine Einzelgebäude gemappt sind.

 Eine Lösung wäre, einen speziellen Tag für Gebäudeteile zu haben.
 Diese Teile könnte man dann mit einer speziellen Gebäuderelation
 zusammenfügen. Die einzelnen Teile könnte man weiter beschreiben oder
 erstmal auch nicht, die Relation würde man behalten. Eine eigene
 Relation braucht man m.E., weil Multipolygone durch die Überlappungen
 unklar würden. Um die Relation fürs Rendern in Mapnik vorzubereiten,
 würde man osm2pgsql so anpassen, dass Flächen dieser Relationen beim
 Import zusammengefügt würden (so ähnlich wie join areas in JOSM das
 macht), für die Überlappungslinien (die, die beim Zusammenfassen
 wegfallen) könnte man je nach Layer-Reihenfolge und Geschmack
 zusätzliche Linien fürs Rendering generieren lassen.

+1!

Ein erster Schritt, die Akzeptanz für so etwas zu schaffen, wäre m.E.
die Unterstützung des building:part-Tags (wie auch immer es genau
heißen wird) in den beiden Haupt-Renderstilen Osmarender und
OSM-Mapnik dahingehend, daß erst einmal zumindest die betreffenden
Flächen angezeigt werden. (evtl. sogar schon mit einer anderen
Darstellung für building:part=roof oder ähnlichem für freistehende
Dächer wie an Tankstellen etc.)

Dann könnte man anschließend weiter an einer geeigneten Relation für
Gebäude arbeiten (die von mir aus gerne auch noch mehr können darf als
building:part=* zusammen zu kleben)

Gruß,

Martin

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

Re: [Talk-de] Kein Micromapping mit landuse (war: See in Wald in (L|N)SG)

[Martin Simon]

Am 20. Mai 2011 02:02 schrieb Stephan Wolff s.wo...@web.de:
[...]

+1, genau meine Meinung!

Gruß,

Martin

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

Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem

[Martin Simon]

Am 18. Mai 2011 11:59 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com:

 Einzelne identifizierbare Flächen würde ich als solche mappen, und
 nicht zusammenfassen. Letzteres führt zwar kurzfristig schneller zu
 einer kompletter aussehenden Karte, ist aber ungenau und führt zu
 erheblichem Mehraufwand bei der Ergänzung von Details und zu unnötigen
 Multipolygonen. Ausserdem ist der Informationsgehalt ungleich
 geringer.

 Ein (zufällig gefundenes) Beispiel, wie ich es nicht machen würde:
 http://www.openstreetmap.org/browse/way/91584654

 Wie ich es machen würde:
 http://www.openstreetmap.org/browse/way/106441866

Naja, landuse ist ja eigentlich für die Beschreibung der Nutzung
größerer Gebiete gedacht, in denen durchaus auch Wege liegen können
und (m.E.) sollen.

Ich würde wirklich nicht an jedem track oder path (oder für jedes
Feld/Flurstück) ein landuse=farmland unterbrechen, genauso wenig
landuse=residential an jedem highway=residential, path oder gar der
Grundstücksgrenze. Bei breiten Autobahn- oder Bahntrassen sieht es
natürlich anders aus.

Von daher bin ich eher bei deinem ersten Beispiel als beim zweiten, wo
landuse=farmland anscheinend für einzelne Felder (oder sogar die
effektiv genutzte Acker-/Weidefläche via Luftbild) genommen wird,
selbst wenn sie nicht durch (eingezeichnete) Wege unterbrochen werden.

In den Niederlanden gab es einen Import von Waldflächen, der die
Flächen aller Waldwege aussparte - was zu tausenden Miniwäldern
führte und zu dem Problem, daß man z.B. die Funktion von mkgmap, sehr
kleine Landuse-Flächen in niedrigen Zoomleveln auszublenden, dort
nicht nutzen kann, weil man dann praktisch alle Waldflächen
verliert...

Ich denke wir brauchen eher eigene tags für Feld, Flurstück etc.
und sollten landuse=* eine Ebene höher belassen, bei der Nutzung
eines größeren Gebietes.

Gruß,

Martin

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

Re: [Talk-de] Krankenhausgelände

[Martin Simon]

Am 11. Mai 2011 12:14 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com:

 Die einzelnen Gebäude würde ich mit building=hospital (ggf.
 Untersuchungsgebäude, OP-Gebäude, Bettenbau,  etc.) taggen, aber nicht
 mit amenity=hospital.

+1

Mir erscheint hier ein subtagging sinnvoll, also amenity=hospital für
das gesamte Gelände, hospital={Fachbereich/Funktion} (und natürlich
building=hospital) für die einzelenen Gebäude.

Der Vorteil:
-Einzelne Gebäude / Abteilungen werden nicht als ganze Krankenhäuser
interpretiert (es können schon mal ein paar Dutzend werden)
-Fortgeschrittene oder sogar spezialisierte Router/Renderer können die
informationen sehr genau auswerten, ohne daß es für einfachere
unmöglich wird (Das Gesamtkrankenhaus wird immer noch angezeigt und es
ist sehr einfach, aus hospital=* die Information herauszulesen, daß es
sich um einen Bestandteil eines Krankenhauses handelt und es
entsprechend mit name=* und ref=* anzuzeigen.)

Vielleicht gibt es ja Kundige hier, die für den Anfang ein paar Werte
für hospital=* zusammentragen können..?

Gruß,

Martin

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

Re: [Talk-de] Cycleways - oftmals falsch getaggt

[Martin Simon]

Am 29. April 2011 08:53 schrieb Sarah Hoffmann lon...@denofr.de:
 Hi,

 ohje, das kommt davon, wenn man das 1. Gebot von talk-de[1] verletzt. ;)

Das passiert hier allzu leicht. ;-)

 On Thu, Apr 28, 2011 at 11:01:05PM +0200, Peter Wendorff wrote:

 In seiner ersten Mail hat Boris gemeint, dass ein gewoehnlicher Mensch
 unter path einen 'unbuilt single track' versteht. Ich weiss nicht, wie
 es dir geht, aber mir kommt genau das als erstes in den Sinn, wenn ich
 'path' hoere. Das kann man also so unterschreiben (oder zumindest als
 legitime Definition des Wortes in Betracht ziehen.)

Nun, im deutschen ist tatsächlich Pfad am naheliegendsten, nur ist
path nicht unbedingt 1:1 mit Pfad zu übersetzen. (und für andere
Sprachen kann ich es gar nicht einschätzen)
Wie ich Boris anfangs schon geantwortet habe, ist auch durchaus der
bike path geläufig und der meint schon eher ordentliche Radwege.
Ich würde vermuten, daß Pfad näher an trail ist als an path.
(Wo sind unsere englisch-Muttersprachler? ;-) )

 Interessanterweise enthaelt diese Definition weder 'schlecht' noch
 'begehbar' noch 'Gebirge'. Ich weiss also nicht, wie du auf deine
 Definition oben kommst.

unbuilt und dirt (=durch Benutzung auf dem anstehenden Boden
entstandener Pfad) sowie seine Aussage, daß die Benutzung von path für
irgendetwas anderes als Wanderwege in freien Gelände ein künstliches
hineininterpretieren sei, führt schon in Richtung Trampelpfad, das
mit dem Gebirge stammt wohl aus der Diskusion um die Gefährlichkeit,
die euch ja ein Kriterium für die Verwendung von path, zumindest
aber für die nicht-Verwendung von footway ist.

 Desweiteren ist diese Definition eine durchaus legale Untermenge der
 aktuellen Wiki-Definition von path (die sich wie vorher angemerkt am besten
 mit 'irgendwas' zusammenfassen laesst).

 Ich sehe also wirklich nicht, wo das Problem ist, [...]

Ich denke, damit hat keiner ein Problem.
Eher mit der Einengung von path auf Trampelpfade (unbuilt), die von
dir aber hier nicht vertreten wurde.

 Es ist dann einfach eine Frage der Hoeflichkeit, dass man sich an
 die lokalen Gepflogenheiten haelt, wenn man irgendwo Gastmapper
 ist. Sollte ich in eine deutsche Gegend kommen, in der das
 path/designated-Schema benutzt wird, bin ich durchaus in der Lage,
 mich anzupassen und ich hoffe, dass das gleiche
 in die andere Richtung gilt.

Wie schon geschrieben, habe ich kein Problem damit, dann eben *nicht*
footway im Gebirge zu verwenden, auch wenn ich es selbst anders
lösen würde.

Meiner Meinung nach hört der lokale Konsens aber da auf, wo die
grundsätzliche Definition eines global genutzten tags verschoben wird
- da wäre es dann ebenso eine Frage der Höflichkeit, der
Wiki-Definition Respekt zu zollen.
Und euer Mapnik-Fallback, im Gebirge nur das path-Schema zu
nutzen, funktioniert ja auch, ohne die Definition zu ändern. :-)

 wenn man ausschliesslich highway=path fuer Bergpfade benutzt, ist das
 Problem schon geloest. Dass Bergpfade eine Untermenge von highway=path
 bilden, wirst du hoffentlich unterstuetzen. Es ist also kein 'Tagging
 fuer den Renderer', denn hier wird kein Tag missbraucht.

+1, aber ich denke das haben die meisten hier auch so verstanden - es
geht nicht darum, daß ein Bergweg sich natürlich einwandfrei als
path abbilden lässt, sondern darum, daß der tag nicht auf diese
beschränkt wird.

 Ich fuerchte, dass sich hier bei einigen Leuten ein logischer Denkfehler
 eingeschlichen hat. Nur weil alle Bergpfade als highway=path gemappt
 werden sollten, heisst das nicht automatisch, dass der Umkehrschluss
 gilt, also dass alle highway=path Bergpfade sind. Korrekt ist: alle
 highway=path mit einem sac_scale-Tag, das einen Wert groesser 1 hat,
 sind Bergpfade.

Das ist deine Sicht und ich schrub ja bereits, daß wir in *dieser*
Sache einer Meinung sind. (abgesehen davon, daß du den tag selbst für
keine so gute idee zu halten scheinst und eigentlich lieber etwas
spezielleres für Bergwege hättest.)
Mit Boris bin ich in dieser Frage jedoch nicht einer Meinung, für ihn
scheint der Umkehrschluss die Definition von path zu sein. *Das* ist
die Sache, der ich widerspreche.

Gruß,

Martin

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

Re: [Talk-de] Cycleways - oftmals falsch getaggt

[Martin Simon]

Am 27. April 2011 23:51 schrieb Boris Cornet bor...@osm-at.org:
 Schönen guten Tag!

 Heute (27. April) um 10:45 meinte Martin Simon:

 Also müsste man jetzt bei allen Wanderwegen  foot=yes,
 bycicle=no anfügen,

 Warum? Was ist für dich ein Wanderweg? Ein Weg, über den eine
 Wanderroute führt? Ein unbefestigter Weg? Ein befestigter, schmaler
 Weg? Ist Fahrrad fahren in den gesamten Alpen verboten?

 Verboten nicht gerade (oder eigentlich doch - aber das ist ein anderes
 Minenfeld) aber es ist einfach nicht angebracht (aus Selbstschutz).
 Warst du schon mal in den Alpen, und weißt du, wie Wald- und Bergwege
 aussehen (ich rede nicht von Forststraßen)?

Ja, das weiß ich. Ich weiß aber auch, wie das tagging-System hier bei
OSM funktioniert und wie es sich (seit ~Anfang 2007) entwickelt hat.
Ich bin sowohl Radfahrer als auch Wanderer, aber ich halte nichts
davon, Verbote in den Daten zu kennzeichnen, die es in der Realität
(scheinbar?) nicht gibt.

 und noch darauf achten, dass kein mensch
 auf die Idee kommt, foot=designated zu schreiben, denn die werden
 unter Mapnik als footway gerendert, und footways in den Alpen sind ein
 absolutes NO-GO!

 Man muss Leute daran hindern, einen tag zu benutzen, weil _Mapnik_
 dann eine Farbe verwendet, die DU in den Alpen nicht sehen möchtest?
 Hallo?

 Ja man muss. Die Bergrettung hat weiß Gott schon genug zu tun, wenn
 jetzt auch noch alpine Routen gleich gezeichnet werden wie die
 Seepromendade im Tal, dann können wir schon mal Massengräber ausheben
 anfangen.

Tut mir leid, aber das ist wirklich ziemlich daneben...

 Es ist dir offenbar wirklich nicht klar, dass Wege mit einem
 sac-scale ab T3 (demanding_mountain_hiking), bei schlechter Witterung
 auch schon ab T2, für Unerfahrene durchaus zur lebensgefährichen
 Bedrohung werden können.

Mach eine Eingabe an Mapnik, es _gibt_ trac, es _gibt_ die SAC_scale!

Zwei Fragen an dich:

1. Wie würdest du solche Wege kennzeichnen, wäre highway=path nie
eingeführt worden?

2. Woher, verdammte Axt, soll irgend jemand wissen, daß highway=path
_für dich_ lebensbedrohlich, nur von Helden zu benutzen! bedeutet?

 Was, du forderst die Einführung von highway=path? Überraschung: wir
 haben es schon!
 Nein, ich fordere, dass Probleme gelöst werden und nicht einfach durch
 kapern eines Tags verschoben werden.

Ich gehe davon aus, daß du es eh schon weißt, da du ignorierst, wenn
man dich darauf anspricht: du bist der Tagpirat, du verdrehst die
Definition eines Tags auf einen persönlichen Nieschenfall, sähst
dadurch Unsicherheit und Zweifel und ignorierst die gewachsenen
Lösungen, die wir zu diesem Thema in OSM bereits haben. (SAC_scale,
trac als bugreport-System, etc...)

Bitte mach ein Proposal für eine neue highway-Klasse auf, wenn du sie
willst, und stell' es zur Diskussion.
Aber hol' endlich die schwarze Flagge ein.

 Typischer Fall von taggen für den Renderer...

 Typischer Fall von dogmatischer Verbohrtheit und selbstgerechtem
 Besserwissertum.

Das gebe ich gerne zurück, nachträgliche Umdefinition von tags ist
nämlich tatsächlich ein no-go.
Dann denen, die den tag so verwenden, wie er erdacht wurde,
Verdrehung vorzuwerfen, ist einfach nur noch unverschämt und
kontraproduktiv.

 Wenn du mir vorgeworfen hättest, ich verfolge ein Minderheits-
 interesse, denn Radfahrer gäbe es mehr als Bergwanderer, dann wäre das
 wenigstens ein Diskussionsansatz,

Nein, Quantitäten sind (für mich) überhaupt kein Grundsatz zur
Diskussion - wir haben auch einigermaßen vernünftige tags für
Rollstuhlfahrer und viele bemühen sich, diese in die DB zu bringen -
auch wenn die Zielgruppe vergleichsweise gering ist.
Das läuft natürlich über Zusatztags, wie auch sonst...

 aber polemisches Niedermachen eines
 Beitrags ist unterste Schublade.

Ich finde eigentlich wenig Polemik in dem Beitrag, außer in der
Antwort auf deine Forderung nach noch einer neuen Highway-Klasse, die
der ursprünglichen Definition des von dir gekaperten highway=path
entsprechen solle. Das war einfach zu grotesk.
Ach ja: unterm Schrank ist leider keine Schublade mehr... ;-)

 Kommt deine kleine Welt wirklich ins
 wanken, wenn jemand anders denkt und taggt als du?

Niedlich... ignorieren wir das kleine Welt einfach mal:

Ich habe nichts dagegen, wenn du ein anderes _Schema_ benutzt, aber
bitte kapere dafür keine etablierten tags!

Ich hätte auch nichts dagegen, wenn du in den Alpen einfach kein
footway benutzt - aus welchen Gründen auch immer -, solange du nicht
überall verbreitest, path stehe für Gebirgsweg und impliziere
Dinge wie unbefestigt, gefährlich etc.!

Das gehört sowohl nach dem foot/cycle/bridleway-Schema, als auch nach
dem path-Schema in Zusatztags.

Wie gesagt, definiert gerne eine neue Highway-Klasse für Gebirgswege
und schaut, ob sie konsensfähig ist - wenn nicht, benutzt sie halt
einfach so. Mir würde das zwar nicht gefallen, aber es wäre zumindest
innerhalb OSM ein legitimes und toleriertes Vorgehen.

Gruß,

Martin

___
Talk-de

Re: [Talk-de] Cycleways - oftmals falsch getaggt

[Martin Simon]

Am 28. April 2011 09:16 schrieb Sarah Hoffmann lon...@denofr.de:
 On Thu, Apr 28, 2011 at 08:05:31AM +0200, Martin Simon wrote:
 Ja, das weiß ich. Ich weiß aber auch, wie das tagging-System hier bei
 OSM funktioniert und wie es sich (seit ~Anfang 2007) entwickelt hat.
 Ich bin sowohl Radfahrer als auch Wanderer, aber ich halte nichts
 davon, Verbote in den Daten zu kennzeichnen, die es in der Realität
 (scheinbar?) nicht gibt.

 Das hat nicht mit Verboten zu tun, sondern mit einer moralischen Grund-
 verantwortung der Kartenmacher. Die Schweizer (und sicher auch die
 Oesterreicher) Presse ist voll von Berichten ueber Leute, die der
 Meinung waren, dass so ein Bergweg ja nichts anderes ist als ein
 normaler Fussweg. Glueck fuer jene, die die Rettungsflugwacht noch
 rechtzeitig gefunden hat. Wenn man auch nichts gegen die Dummheit
 mancher dieser Leute machen kann, muss man dennoch solches Verhalten
 nicht herausfordern, indem man Karten macht, wo es keine Unterscheidung
 zwischen Seepromenade und Bergweg gibt.

Ich habe ja nichts gegen eine Kennzeichnung der Gefährlichkeit oder
Schwierigkeit eines Weges, nur finde ich, daß dies dann auch mit
entsprechenden tags passieren sollte und nicht beispielsweise mit
access/$Fahrzeug=no, was schon ein Verbot ausdrückt.

Boris hat in seinem ersten Beitrag bicycle=no, foot=yes für Bergwege
erwähnt - um die erwähnten unerfahrenen Wanderer zu fern zu halten,
müsste es nach diesem Vorgehen eigentlich foot=no sein, was aber
ziemlich an der Realität vorbei wäre.

 Dir wuerde ja auch nie im Leben
 einfallen, residental und motorway auf die gleiche Weise darzustellen,
 weil es ja beides Strassen sind und jeder Fahrer selbst wissen muss,
 ob er sie benutzen will.

Mir würde auch nicht einfallen, auf die Autobahn mit dem Fahrrad
aufzufahren oder mit 120 km/h durch eine Wohnstraße zu heizen, nur
weil sie in einer Karte auch blau dargestellt wird.

(oder eine Ortsverbindungsstraße an den Stellen, wo Tempo 100 gilt,
als Autobahn zu taggen, weil Autofahrer hier schnell fahren und es
somit gefährlich für radler wäre ;-) )

 Ehrlich gesagt ist es mir ziemlich egal, wie die path-Diskussion in
 Deutschland am Ende ausgeht. Aber wenn du jemals in die Schweiz oder
 nach Oesterreich kommst, wuerde ich dich doch bitten, die etablierten
 Konventionen zu beachten, die eben besagen, dass highway=footway oder
 *=designated fuer Bergwege ein NO-GO ist. Die lokalen Mapper haben
 sich etwas dabei gedacht.

Das wird so auch nicht passieren, *obwohl* ich sehr wahrscheinlich
innerhalb des nächsten Jahres dort sein werde - was daran liegt, daß
ich für neu erfasste Wege unterhalb track immer path mit
Zusatztags benutze.

Ich möchte euch im Gegenzug bitten, nicht Implikationen wie ist ein
Gebirgsweg, ist unbefestigt oder gar ist gefährlich in path zu
setzen, die dieses definitiv nicht enthält.

Wie wäre es, stattdessen Renderregeln für Mapnik zu entwickeln, die
entsprechende Zusatztags auswerten?
Ich kenne mich zwar mit Mapnik-Styles nicht aus, habe aber ähnliches
im kleinen (berücksichtigung von surface=* für footway, cycleway,
bridleway, path gleichermaßen) schon bei meiner Garmin-Karte und dem
topo-stil für mapgen.pl umgesetzt und halte es für aussagekräftiger
als einfach die genannten 4 highway-typen farblich unterschiedlich
darzustellen.

Gruß,

Martin

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

Re: [Talk-de] Cycleways - oftmals falsch getaggt

[Martin Simon]

Am 28. April 2011 11:52 schrieb Boris Cornet bor...@osm-at.org:
 Servus!

 Danke Sarah, du nimmst mir die Worte aus dem Mund!

 Das ist es was ich eigentlich von Anfang an sagen wollte, und ich habe
 nicht erwartet, dass mir derart grob über den Mund gefahren werden
 würde.

Stellt sich die Frage, warum du das nicht getan hast, sondern so
ungehobelt gegen die Leute gepoltert hast, die path in seiner
ursprünglichen Definition verwenden, und gerade diesen vorwarfst, sie
würden das Tag kapern und künstlich etwas hinein interpretieren.

Ich schrieb ja schon, daß es mich nicht stört, wenn ihr in den Alpen
nur path nehmt, ohne zu versuchen, ihm implikationen zu geben, die
es nicht hat.
Ich kann aus Sarahs Beitrag auch keine Zustimmung zu deinem Wunsch,
path diese Implikation zu geben, erkennen - in der Frage der
Bedeutung von path vertritt sie anscheinend dieselbe Meinung wie ich
auch: ein Weg unterhalb track, der unbestimmt ist und weitere tags
benötigt, da er keine Implikationen mitbringt.

Differenzen haben wir in der Frage, ob man access-Restrictions
benutzen sollte, um die Gefährlichkeit auszudrücken.

 PS. Es läge mir da allerhand zum Thema Besserwisserei und 'am
 deutschen Wesen wird die Welt genesen' auf der Zunge (siehe auch die
 erschreckenden Grabenkämpfe bei Wikipedia), aber vergesst das - nach
 eine kurzen Schrecksekunde - am besten wieder.

Das hat nichts mit Besserwisserei zu tun und schon gar nicht mit
...am deutschem Wesen Aber solche dumpfen Vorwürfe kann man ja
immer sehr einfach 'raushauen, anscheinend besonders, wenn es gegen
vermeindliche Piefkes geht, nicht wahr?

Also spar' dir bitte das Gejaule - wer so zu Werke geht, sollte auch
zumindest ein bischen was selbst einstecken können.

Gruß,

Martin

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

Re: [Talk-de] Cycleways - oftmals falsch getaggt

[Martin Simon]

Am 27. April 2011 10:19 schrieb Boris Cornet bor...@osm-at.org:
 Hallo!

 Darf ich noch etwas Öl ins Feuer gießen?

 In Österreich - so ich das überblicken kann - wurde der Vorschlag,
 path für Geh-/Radwege zu verwenden, glücklicherweise nicht übernommen
 - vielleicht weil hier der Wanderkarten-Aspekt deutlicher gesehen
 wird.

 In meinen Augen kommt man mit dem WischiWaschi-Path vom Regen in die
 Traufe. Das Problem vom unglücklichen cycle/footway auf den path zu
 verlegen bringt nichts ausser noch mehr Uneinheitlichkeit.

Nein, es bringt einen Wegtyp unterhalb track mit möglichst wenig
Implikation, der es ermöglicht, Nutzungsrechte genau und einzeln zu
definieren. Das ist gut.

 Der 'normale' user versteht path als 'Pfad', also 'unbuilt single dirt
 track', und das ist gut so. Path ist der ideale Tag für Wanderwege im
 freien Gelände. Sobald man künstlich etwas anderes hinein
 interpretiert,

Was du hiermit tust. path ist *nicht* mit Trampelpfad gleichzusetzen.
bike path heiß z.B. Radweg und ist durchaus gerne asphaltiert...

 ist man gezwungen, mittels zusatztags die Nutzergruppen
 festzulegen.

Das ist man, wenn man *nichts* künstlich hinein interpretiert - und das ist gut.

 Also müsste man jetzt bei allen Wanderwegen  foot=yes,
 bycicle=no anfügen,

Warum? Was ist für dich ein Wanderweg? Ein Weg, über den eine
Wanderroute führt? Ein unbefestigter Weg? Ein befestigter, schmaler
Weg? Ist Fahrrad fahren in den gesamten Alpen verboten?

 und noch darauf achten, dass kein mensch
 auf die Idee kommt, foot=designated zu schreiben, denn die werden
 unter Mapnik als footway gerendert, und footways in den Alpen sind ein
 absolutes NO-GO!

Man muss Leute daran hindern, einen tag zu benutzen, weil _Mapnik_
dann eine Farbe verwendet, die DU in den Alpen nicht sehen möchtest?
Hallo?

Die Information, die du sehen möchtest, steckt nicht in path/footway,
sondern in width,surface, incline und sac_scale(sowie in
Routen-Relationen).
Typischer Fall von taggen für den Renderer...

 Übrigens sind viele dieser cycle/footway-paths im Freiland eigentlich
 tracks (grade1), weil sie oft auch legal von traktoren u.ä. befahren
 werden.

 IMHO ist die einzige Lösung des Dilemmas eine neue highway-kategorie,
 etwas was einen generischen Fahrweg darstellt - möglicherweise auch
 ein revival von highway=road.

Was, du forderst die Einführung von highway=path? Überraschung: wir
haben es schon!
Frage: würden wir jetzt *noch einen* tag dieses typs einführen, würden
Leute wie du nicht schon wieder ankommen und ihn zu einem Spezialfall
umdefinieren, weil z.B. die Farbe in Mapnik so schön passt? ;-)

 Absolut nicht sinnvoll ist es, einen bestehenden und gut eingeführten
 Weg-Typ (path) umzudefinieren.

Bitte lies das Wiki und das ursprüngliche Proposal. Du definierst hier
um und merkst es noch nicht einmal.

Gruß,

Martin

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

Re: [Talk-de] Taggen von Sporthallen

[Martin Simon]

Am 11. April 2011 18:30 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com:

 Gebäude findet man unter allen möglichen Umständen, das Vorhandensein
 eines geschlossenen Ways mit building=yes reicht mir nicht aus, um
 eine Turnhalle zu beschreiben. Hier ist es durchaus häufig, dass eine
 Reihe von Tennisplätzen, Fussballplätzen, Restaurant, Schwimmbad,
 Basketballplätzen etc. auf einem Gelände unter einem Betreiber und
 unter einem Namen firmiert. Diese Dinger hatte ich bisher als
 leisure=sports_centre beschrieben.

Guten Morgen!

Wieso nicht building=allgemeiner Ausdruck für 'Sporthalle'  +
sport=multi/tennis/etc?

Dann wären Gebäude und Funktion Sauber getrennt, bei einem
Sportzentrum mit mehreren Anlagen liegen solche Dinger dann in einem
leisure=sports_centre... wär' das nix?

Gruß,

Martin

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

Re: [Talk-de] Krankenhausgebäude und -fläche korrekt taggen

[Martin Simon]

Am 10. April 2011 01:04 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com:

 oder building=hospital (oder was es ist, auf einem Krankenhausgelände
 findet man ja allerhand Gebäude, von OP und Untersuchungsgebäuden /
 Labors über Bettenhäuser und Zentralküche bis zur Heizzentrale,
 Kantine, Umspannstation, Rechenzentrum, etc.).

+1,
wenn es einzelne Gebäude mit verschiedenen Fachbereichen gibt, würde
ich für diese zusätzlich einen subtag von hospital verwenden, z.B.
(muss nicht sprachlich richtig sein) hospital=ward oder
hospital=department.

Das mache ich auch bei Universitätsgebäuden auf einem Campus so.

Gruß,

Martin

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

[Talk-de] GPX-Bearbeitung: Liniare Höhenanpassung eines tracks?

[Martin Simon]

Hallo Liste!

Vielleicht weiß ja hier jemand Rat oder hat so etwas selbst schon
einmal gemacht:

gegeben ist:
-Ein gpx-track, der an gleicher Stelle startet und endet und mit einem
Gerät mit barometrischem Höhenmesser aufgezeichnet wurde (vista hcx,
nachführung der GPS-Höhe abgeschaltet!). Dieser track hat nun eine
Höhendifferenz von etwa 3 m innerhalb von etwa 1 h Aufzeichnungszeit
entwickelt (1 Punkts pro sekunde).

-ein Linuxsystem mit installiertem Geo-Gedöns: GRASS, qgis, JOSM,
gpx-editoren, etc.

Gesucht ist:
-Ein tool oder eine Methode, um die entstandene Höhendifferenz linear
auszugleichen, also den Anstieg um 3 m über die Zeit der Aufzeichnung
hinweg linear auf die Trackpunkte verteilt zu eliminieren, so daß
Anfang und Ende ungefähr gleiche ele haben.

Daß die Annahme eines Linearen Druckabfalls nicht der Realität
entsprechen wird, weiß ich natürlich - es geht aber erstmal darum, zu
zeigen, daß das, was ich mit den Daten vorhabe, funktioniert.
(Sollte es bereits eine Methode geben, das ganze mit den wirklichen
Druckverläufen von nahe gelegenen Wetterstationen aus dem Netz zu
kompensieren, nehme ich einen Hinweis darauf natürlich auch sehr gerne
entgegen ;-) )

Gruß,

Martin

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

Re: [Talk-de] GPX-Bearbeitung: Liniare Höhenanpassung eines tracks?

[Martin Simon]

Am 9. April 2011 11:07 schrieb ikonor iko...@gmx.de:
 MyTourbook hat ein Tool, um Höhen anzupassen:

 http://mytourbook.sourceforge.net/mytourbook/index.php/documentation/tools/adjust-altitude

 Für Deinen Fall eignet sich vermutlich die Variante Set START and END to
 the same altitude. Der Track muss dazu importiert und kann danach wieder
 exportiert werden.

Genau so etwas habe ich gesucht, danke! :-)
Ich kannte MyTourbook, wußte aber nicht von dieser Funktion.

@fx99: Ich hatte das schon mit OpenOffice Calc versucht, aber Probleme
mit den Dezimaltrennern, dem umwandeln nach csv via gpsbabel und dem
kopieren und einfügen errechneter Werte in Calc haben mich dann
entnervt aufgeben lassen. ;-)

Gruß,

Martin

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

Re: [Talk-de] Baudenkmäler - Wikipedia:Wiki loves Monuments

[Martin Simon]

Am 28. März 2011 12:15 schrieb Raimond Spekking raimond.spekk...@gmail.com:
 Wikipedia hat nach dem niederländischen Vorbild in 2010 die Aktion Wiki
 loves Monuments [1] gestartet.

 Als aktiver OSMler würde ich beim Fotografieren der Denkmäler auch
 gleichzeitig den Denkmalstatus in OSM eintragen. Aber so recht fündig
 bin ich noch nicht geworden, wie denn z.B. Baudenkmäler, oft ganz
 normale Wohnhäuser, getaggt werden. [2] ist diesbezüglich noch nicht
 aussagekräftig, oder habe ich was überlesen?

 Wie taggt ihr (ganz normale) Baudenkmäler?

Ich habe vor einiger Zeit mal angefangen, die hier in NRW mit Plakette
kenntlich gemachten denkmalgeschützten Häuser einfach mit
class_listed=yes (kam von einer Google-Suche) zu taggen...

Gruß,

Martin

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

Re: [Talk-de] Ziel von OSM

[Martin Simon]

Am 28. März 2011 12:33 schrieb Markus liste12a4...@gmx.de:

 und zusätzlich noch unzählige Kartenstile.

 Nein, eine solche Personifizierbarkeit von Stilen scheint mir nicht
 hilfreich - im Gegenteil: dadurch würde unser Projekt verwässert.
 Es hilft niemandem, wenn die Autobahnen mal grün, blau oder rot sind.
 Da geht es um Kontrast, und um visuelle Information.
 Dieses gilt es zu optimieren.

Lieber Martin, bitte stelle die Herausgabe deiner nicht autorisierten
OSM-Karten ein, sie verwässern das Erscheinungsbild unserer Marke und
verwirrt den Nutzer.

Deine Micros ääh GNO ääh Openstreetmap Foundation

;-)

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

Re: [Talk-de] Relationen Landmasse

[Martin Simon]

Ich habe hier zwar nur mitgelesen, möchte aber zu dieser Aussage:

Am 21. März 2011 20:08 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com:
 M.E. hat irgendwann jemand mal gelesen, dass die Landmasse bei der
 politischen Gliederung eine Rolle spielt (was ja auch stimmt), und
 dann den Schluss gezogen, dass man dafür in OSM eine Relation braucht
 (das stimmt eben nicht). Daraufhin wurde dieses Vorgehen von anderen
 Mappern aufgegriffen und die halbe Welt damit missioniert (Huch, die
 Italiener haben ja noch gar keine Landmasse-Relation, schnell mal eine
 erstellen, diese Schlamper tststs).

 Wenn wir nun aber feststellen, dass uns diese Relationen praktisch
 keine Vorteile bringen, wäre es da nicht am besten, man ergänzte einen
 Hinweis im Wiki und löschte diese Relationen wieder, bevor weitere 200
 Versionen dazukommen?

mal mein +drölf loswerden.

Ergebnisse von Verschneidungen zweier Flächen in OSM vorzuhalten ist
einfach Käse.
Hat die Schweiz eigentlich schon 'ne Landmasse-Relation? Wenn nicht,
wie solle eine automatische Auswertung aller Landmassen aller Länder
wissen, daß sie nicht am Meer liegt? ;-)

Gruß,

Martin

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

Re: [Talk-de] Meeresrelationen

[Martin Simon]

Am 18. März 2011 18:49 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com:
 Mittlerweile finde ich selbst für Meere Multipolygon-Relationen:
 http://www.openstreetmap.org/browse/relation/1159195

 Leider sind diese Dinger derart sperrig, dass ich kaum was damit
 anfangen kann, im Gegenteil, behindern sie beim Editieren der
 Küstenlinie. Ich habe leider keine Ahnung, wer die Relation erstellt
 hat (Sorry, the data for the relation with the id 1159195, took too
 long to retrieve.), aber vielleicht habe ich ja hier Glück?

 Bisher war ich davon ausgegangen, dass wir absichtlich nicht solche
 Relationen erstellen, um es den Mappern nicht allzu schwer zu machen
 (daher ja auch das natural=coastline-Verfahren).


Das ist wirklich Käse - vielleicht eignet sich auch hier der Gedanke,
den wir beim Thema Landschaften schon mal auf dem Tisch hatten; eine
Relation, die eine begrenzte Anzahl (sortierter) nodes enthält und
damit ein Gebiet definiert. Im Falle von Meeren könnten das auf
offener See ein paar alleinstehende Nodes sein und in Küstennähe sehr
wenige (mindestens 2), die zu einem Küstenlinien-way gehören. Ein
Renderer oder Editor könnte so etwas eindeutig auswerten, indem er
zwischen 2 Küstenlinien-Nodes der Küstenlinie folgt, zwischen einem
Küstenlinien-Node und einem offene-See-node einen Sprung macht und
dasselbe zwischen zwei ebensolchen tut.

Damit hat kann man dann sehr großräumige - auch ungenaue und diffuse -
Dinge darstellen, die bewußt weder richtige Ways sein sollen (mich
persönlich stören sogar schon die ways für die pseudo-Grenzen der
innerstädtischen Posteitzahlenbereiche oder - großräumiger -
TMC-Gebiete) noch durch schon vorhandene ways definiert werden können
(wie wie Postleitzahlengebiete, die mit politischen Grenzen
übereinstimmen).

Eigentlich könnten auch Routen spielend einfach über Relationen mit
nodes definiert werden - wenn man mal drüber nachdenkt, sind nodes
noch das robusteste was wir haben... ;-)
(ich habe neulich die Relation 20866 (Rheinsteig-Wanderweg) repariert,
das war schon eine Qual...)

Die Logik, um das ganze zu verarbeiten, dürfte so schwierig (und
fehleranfällig) nicht sein - und man könnte sich auf einen groben
Standard einigen.

Gruß,

Martin

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

Re: [Talk-de] aufgesetzte Gebäudeteile

[Martin Simon]

Am 9. Februar 2011 08:56 schrieb Peter Wendorff wendo...@uni-paderborn.de:
 Hallo Claudius, hallo Jan.
 Ja, Rückmelduingen immer gerne - der Ersteller bin ich ;)

Hallo Peter!

In dem etwas älteren Diskussionsfaden im Archiv hast du mal
geschrieben, daß du mit Komяpa, dem Ersteller des Building layers auf
latlon.org, in Kontakt stehst.

Ich konnte keine Kontaktadresse finden, daher frage ich einfach mal dich:
- weißt du, ob er nochvorhat, Unterstützung für building:height einzubauen?
- in meiner Umgebung werden scheinbar teilweise nur Objekte, die schon
längere Zeit in der Datenbank stehen dargestellt, egal ob die
building:levels-tags erst kürzlich hinzugefügt wurden oder nicht -
weißt du, ob ihm dieses Problem bekannt ist?
-auch Gebäude als Multipolygone scheinen ein Problem darzustellen,
weißt du etwas darüber?

Danke, ich hoffe die Geschichte kommt in nächster Zeit etwas in Schwung!
Ich selbst versuche derzeit, zumindest die markanten Gebäude in meiner
Umgebung wenigstens mit building:levels auszustatten. :)


Am 9. Februar 2011 14:33 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com:

 Ich habe gerade leider keine Zeit dafür, aber ich habe dazu schon
 Längeres auf der Liste geschrieben. Zunächst müsste man mal
 Gebäudeteile definieren, also sagen, dass es sich nicht um ein
 building sondern um einen Teil davon handelt. Das macht wohl der
 Vorschlag von Peter schon.

Das ist mir auch ein wichtiges Anliegen - ein tag wie
building_part=yes/Gebäudeteiltyp und eine Relation vom typ building,
die dann das normale building=yes/Gebäudetyp erhält und die
Gebäudeteile sowie eventuell andere Dinge wie Eingänge oder Nodes, die
First- und Traufpunkte beschreiben können, mit entsprechenden Rollen
enthält, wäre schon ein großer Schritt vorwärts.
Einfache Renderer könnten einfach alle building_part=* wie
building=* rendern und spezialisierte Renderer wüssten genau, ob es
sich um eine Ansammlung selbstständiger Gebäude oder um eines, das aus
Gebäudeteilen besteht, handelt.

Gruß,

Martin

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

Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?

[Martin Simon]

Am 2. Februar 2011 14:07 schrieb Frederik Ramm frede...@remote.org:
 Sobald in OSM ein Node gelöscht wird, ist die Zuordnung für die Katz. Das
 funktioniert nicht, zumal man dann in OSM gar nicht erkennen kann, dass am
 Node etwas dranhängt. Wenn ich einen Node in einem Straßenverlauf lösche,
 nehme ich einen ohne tags.

 Das ist allerdings ein allgemeines Problem, das immer wieder aufkommt - wie
 kann man von extern in OSM hinein linken und dabei halbwegs fehlertolerant
 sein (d.h. ohne in OSM ein Loesch- und Editierverbot des verlinkten Objekts
 zu fordern).

Wieso merkt sich die externe Datenbank dann nicht einfach die
Koordinaten des OSM-Objektes, solange es da ist (und ggf. den groben
Objekttyp und ref/name) und löst einen Bugreport aus, wenn sie
feststellt, daß das verlinkte OSM-Objekt nicht mehr Existiert, seine
Position um mehr als 100m verändert hat oder Objekttyp/ref/name
geändert wurde?

Damit könnte die externe Datenbank Updates erhalten, ohne in OSM
schreiben zu müssen und bei Veränderungen in OSM, auf die die externe
Datenbank linkt, könnte für *deren* Maintainer Alarm ausgelöst
werden. :-)
In einfachen Fällen nach bestimmten Kriterien (z.B. shop-Node gelöscht
und als way mit gleichen tags an gleicher Position (+- X m) wieder
hochgeladen) könnte man die Verlinkung eventuell sogar automatisch
nachführen.

Am besten wäre es vermutlich, für solche Fälle eine API zu haben, über
die sich externe Datenbanken über Veränderungen bestimmter
abonnierter Objekte in OSM informieren können - dann wäre es auch
einfacher, externe Datenbanken wie Fahrpläne, Öffnungszeiten,
Veranstaltungskalender etc. mit OSM-Objekten zu verknüpfen...

Gruß,

Martin (der keine Ahnung hat, ob und wie sowas tatsächlich umgesetzt
werden könnte)

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

Re: [Talk-de] Darstellung von landuse=military in Mapnik-Karte

[Martin Simon]

Am 23. Januar 2011 10:50 schrieb Kolossos tim.al...@s2002.tu-chemnitz.de:

 Ja, ist wirklich extrem hässlich insbesondere auf Zoomlevel 12 werden diese
 Gebiete überaus dominant hervorgehoben:
 http://www.openstreetmap.org/?lat=51.05lon=13.7561zoom=12layers=M
 statt sie wie üblich eher dezent zu machen, wird es hier als wichtigstes
 Gebiet einer Großstadt hervorgehoben.
 Auch die horizontalen Schraffuren bei den Kleingartensparten verwirren, weil
 so kaum noch die Wege erkennbar sind.
 Also ich wäre für einen Revert.

Es geht doch nicht um Wichtigkeit, sondern darum, daß militärische
Gebiete und Anlagen deutlich in der Karte als gesperrte Flächen
hervorgehoben sein sollten, ohne darin enthaltene flächige Objekte zu
verdecken oder von ihnen verdeckt zu werden.

Ich finde die jetzige Darstellung genau richtig, allerdings könnte man
tatsächlich ab zoomstufe 11 oder 12 die Strichstärke sowie den Abstand
der Schraffurlinien verringern.

Gruß,

Martin

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

Re: [Talk-de] Eine Insel im Fluss [Reparaturanfrage]

[Martin Simon]

Am 21. Januar 2011 20:40 schrieb André Reichelt andr...@online.de:
 Hallo!
 Könnte sich bitte jemand dieser Stelle hier zuwenden: Die Inseln werden
 nicht gerendert obwohl ich nach meinem Kenntnisstand alles korrekt
 gemacht habe. Dem Flusslauf nach Norden folgend ist noch so eine Insel.

 http://www.openstreetmap.org/?lat=49.13586lon=10.06868zoom=17layers=M

Hi!

Du hast 2 Multipolygon-Objekte, eins für jedes Loch, definiert. Es
sollte ein Multipolygon mit 2 Löchern sein, sonst überdeckt beim
rendern die jeweils ungelochte Fläche des anderen das Loch. ;-)

Die nördliche Insel hat zudem noch waterway=riverbank, was dazu führt,
daß sie auch als Wasserfläche betrachtet wird(in der äußeren
Wasserfläche).

Gruß,

Martin

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

Re: [Talk-de] Landschafts-Hierarchien in OSM

[Martin Simon]

Am 20. Januar 2011 19:34 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com:
 oder die Alb, den Alpenraum, den Oberrhein, die Koelner Bucht, den
 Schwarzwald oder die Norddeutsche Tiefebene ;)


 ja, geografische Gegenden. Da gabs mal eine m.E. ganz interessante
 Idee hier: Relationen, die einzelne schon existierende Nodes
 enthalten, wo man sich sicher ist, dass sie im Polygon enthalten sind.
 Das wuerde die db kaum belasten, keine unsauberen bzw. strittigen
 Polygone erzeugen, und koennte per Huellenfunktion in ein Polygon
 umgewandelt werden. Das Problem gibt es ja auch fuer Meere und
 Meeresteile, etc. Im ganz kleinen haben wir hingegen schon was:
 place=locality.

+1 (natürlich... ;) )

Zur Not lässt sich das ganze natürlich auch ohne Relationen - also nur
mit tags - lösen, was aber die Zuordnung weiterer Eigenschaften
erschweren würde (wie internationale Namen).

Wenn man sich die von Ulf verlinkte Karte anschaut, erkennt man aber
auch, daß es wohl einer Möglichkeit der Hierarchiebildung und eine
Zuordnung der Art des geografischen Raumes gäbe (Gebirge, Landschaft,
Region? Kennt sich jemand mit den Begriffen wirklich aus?).

Gruß,

Martin

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

Re: [Talk-de] Maxspeed und highway=residential (War: maxspeed)

[Martin Simon]

Am 18. Januar 2011 14:26 schrieb Fabian Schmidt
fschm...@informatik.uni-leipzig.de:

 Meinetwegen. Mir geht es auch nur darum, dass für residentials ein
 default-Wert angenommen werden kann. Allerdings sehe ich gerade in der
 maxspeed-Map, dass der default eine Illusion ist und zumindest in
 Großstädten und in neuen Siedlungen sich die 30 durchsetzt.

Das Problem mit den Defaults ist meines erachtens nicht, daß man sie
nicht annehmen könnte oder dürfte, sondern, daß man sie _bei der
Auswertung_ annehmen sollte, nicht schon in der OSM-Datenbank.

Ich nehme bei meiner Garmin-Karte auch einen großen Haufen Defaults
an, angefangen bei der Oberfläche, über Geschwindigkeiten bis hin zu
Dingen wie Kostenpflichtigkeit von Fähren.

Das funktioniert ziemlich gut, da es aber doch nur geraten ist
möchte ich _in der Haupt-Datenbank_ trotzdem lieber explizite Werte
sehen.

Gruß,

Martin

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

Re: [Talk-de] Hausnummern bei Wohnblocks

[Martin Simon]

Am 7. Januar 2011 09:41 schrieb Andreas Perstinger andreas.perstin...@gmx.net:
 On 2011-01-07 08:47, Raimond Spekking wrote:

 Nodes in die Hausumrisse, wo sich die Eingänge befinden. Und diese Nodes
 mit den Adressinformationen versehen, so wie hier:
 http://osm.org/go/0g...@7yc--

...wobei man sich darüber im klaren sein sollte, daß ein node mit
Adressinformation keinerlei Aussage über das vorhandensein eines
Eingangs tätigt.

Wo immer es möglich ist, trenne ich Häuser in geschlossener Bauweise
auf und gebe die komplette Adressinformation an das building-Polygon.

 So habe ich es bis jetzt auch gemacht (am Node building=entrance + komplette
 Adressinformation).

 PS: Ich habe in Deinem Beispiel auch gesehen, dass Du bei barrier=bollard
 zusätzlich foot=yes und bicycles=yes setzt. Laut Wiki
 (http://wiki.openstreetmap.org/wiki/DE:Tag:barrier%3Dbollard) sind diese
 Werte jedoch schon impliziert und deshalb auch nicht notwendig, oder?

foot=yes und bicycle=yes sind bei barrier=bollard eigentlich unsinnig,
da ein bollard allein durch seine Bauart breitere Verkehrsteilnehmer
physisch aussperrt, mit einer Erlaubnis für bestimmte Verkehrsarten
hat das in der Regel nichts zu tun.

Gruß,

Martin

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

Re: [Talk-de] JOSM und Luftbilder

[Martin Simon]

Wie wäre es ganz simpel mit 'Bildmaterial' oder 'Vorlagen'?

Gruß,

Martin

Am 07.01.11 schrieb Markus liste12a4...@gmx.de:
 Hallo Christian,

 WMS/TMS (warum heisst das Ding nicht Luftbilder?!)
 Weil die per WMS/TMS bereitgestellten Bilder nicht unbedingt Luftbilder
 sein
 müssen. Es gehen ja auch eingescannte Karten, Höhenlinien oder so wie
 googles
 Gelände.

 Bei der Wahl von Begriffen für Menü-Punkte ist wichtig, dass sie
 *von möglichst vielen intuitiv verstanden* werden.

 Luftbilder beispielsweise versteht jeder.
 WMS/TMS findet man nicht mal in unserem Wiki.

 Klar, es gibt auch noch gescannte Karten etc.
 Aber ich vermute, dass die Zahl der Benutzer im Promillebereich liegt.
 Diejenigen wissen, dass sie diese unter Luftbilder eintragen können.

 Die meisten benutzen Yahoo und neuerdings Bing, und ein paar wenige
 benutzen die Bilder aus Lauf, Dortmund oder anderswo.

 Gruss, Markus

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


-- 
Gesendet von meinem Mobilgerät

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

Re: [Talk-de] JOSM und Luftbilder

[Martin Simon]

Am 7. Januar 2011 17:35 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com:

 +1, Vorlagen ist wohl schon für die Presets verwendet, aber

Ja, stimmt, ist mir erst nach dem schreiben aufgefallen ;)

 Bildmaterial wäre ungefähr die Übersetzung von imagery. Man könnte
 auch Raster oder Rasterbilder nehmen, weil Vektorbilder damit
 AFAIK nicht eingebunden werden können.

Wobei ich mir bei Raster auch nicht sicher wäre, ob die Zielgruppe,
die mit WMS nichts anfangen kann, sich darunter mehr vorstellen
könnte.

Gruß,

Martin

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

Re: [Talk-de] Wolferstetten / Külsheim [was: Re : White spots RELOADED]

[Martin Simon]

Am 4. Dezember 2010 14:35 schrieb Bernd Wurst be...@bwurst.org:
 Ich bin dabei grade auf Wolferstetten (Gemeinde Külsheim) in der Nähe von
 TBB gestoßen.

 Hat jemand eine Ahnung, was da los ist:
 http://maps.google.de/maps?ll=49.645486,9.525876spn=0.021175,0.055747t=kz=15

 In deR Mitte sieht es aus als wollte jemand ne Autobahn bauen, aber das macht
 keinen Sinn. Die Zahl der Wege ist auch etwas kurios. Kommt jemand aus der
 Ecke und hat da was mit bekommen?

Bin nicht aus der Ecke, aber das ist das typische Erscheinungsbild
eines Truppenübungsplatzes. :-)

Vergleiche: 
http://sautter.com/map/?zoom=14lat=50.34568lon=7.65987layers=00B000TTFF

Gruß,

Martin

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

Re: [Talk-de] Bundeswehr mappen?

[Martin Simon]

Am 3. Dezember 2010 13:00 schrieb Latze latz...@gmx.net:
 Hallo Liste,

 hat schon jemand Erfahrungen mit der Bundeswehr gemacht? Ich könnte hier mit
 Bing-Bildern die Gebäude und Straßen von einem Luftwaffenstützpunkt mappen.
 Ich frag mich, ob ich das einfach so machen soll oder ob ich lieber erst mit
 der Bundeswehr, der Lustwaffe oder dem Stützpunkt Kontakt aufnehmen soll.
 Ist ja immer wieder die Frage, wie die auf sowas reagieren.

Moin!

Ich würd's einfach machen. solange du nicht bei denen einbrichst und
nur Quellen nutzt, die öffentlich verfügbar sind, kann eigentlich
niemand etwas sagen. In meiner Gegend sind das BMVg, einige Kasernen
und ein großes Munitionsdepot gemappt, zudem habe ich auch schon
gps-Spuren innerhalb solcher Gelände gesehen, es scheint also auch den
ein oder anderen mappenden Soldaten oder BW-Angestellten zu geben.

Zudem kann die Information über eingezäunte oder nicht eingezäunte,
aber dennoch gesperrte militärische Gebiete auf der Karte sehr
nützlich sein, wenn man draußen unterwegs ist. Auf meiner Garmin-Karte
stelle ich z.B. Kasernengelände, Übungsplätze und dergleichen mit
einer roten Schraffur dar und kann mich so rechtzeitig darauf
einstellen, das Gebiet zu meiden. :-)
(wie im übrigen auch Kläranlagen, Bahngelände, Flugplatzgelände etc
sowie explizit als gesperrt getaggte Gebiete)

Gruß,

Martin

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

Re: [Talk-de] news von steve coast

[Martin Simon]

Am 30. November 2010 20:32 schrieb Daniel van Gerpen d...@jccnet.de:
 On Tue, 30 Nov 2010 20:14:57 +0100

 #osm titelt:

  OpenStreetMap | You can now use Bing imagery in Potlatch 2!
   http://post.ly/1GqQo http://bit.ly/gCiHyZ | JOSM coming soon, please
   be patient http://bit.ly/hIVoX2 | FAQ: http://url.ie/z4e;

 quote

  [..]
  SteveC woo woo http://opengeodata.org/microsoft-imagery-details
  [..]
  RichardF ladies and gentlemen, Bing imagery is now live in Potlatch 2

 /quote

Cool! Hier in Köln decken sich die Bilder sehr gut mit den vorhandenen
Daten und sind viel detailreicher als die von Yahoo!. :-)

Ich bin mal gespannt, ob sie in den umliegenden Gebieten zu einem
boom bei Gebäuden und Flächen führen werden...

Aber ich warte lieber auf das aktualisierte Josm-Slippymap-Plugin,
denn - als hätt' ichs geahnt - Potlach2 ignoriert noch immer jegliches
vorhandensein von highway=path, anstatt es einfach nur zu einem
inoffiziellen Weg zu umzubiegen wie noch Potlach 1...

Gruß,

Martin

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

Re: [Talk-de] news von steve coast

[Martin Simon]

Am 30. November 2010 21:12 schrieb Frederik Ramm frede...@remote.org:
 Hallo Martin,

 Was meinst DU mit ignoriert? Bei mir ist das deutlich sichtbar. Wenn Du
 mit der Art der Darstellung unzufrieden bist, kannst Du sogar einen eigenen
 Style erzeugen und von Potlatch laden lassen (muss derzeit auf einem Server
 irgendwo sein, lokal von der Platte geht nicht).

Moin Frederik,

Ich meine, daß es dazu im normalen Modus weder eine Bezeichnung noch
die (bei den anderen Wegtypen schön umgesetzten) Auswahlmöglichkeiten
zur Wegbeschaffenheit sowie Berechtigungen etc. gibt.
(Sehen kann man die Linien natürlich, aber das geht mit allen anderen
Wegen mit unbekannten Tags ja auch)

Damit erscheint es vor allem für die weniger versierten Mapper, für
die dieser Modus wohl (hauptsächlich) gedacht ist, als handle es sich
um einen ungültigen Wert, oder ein inoffizielles tag.

Dabei ist gerade Potlach2 mit diesen sehr schön integrierten
Schaltflächen für Zusatztags ein Tool, daß es einfacher ermöglichen
könnte, das path-Schema anzuwenden und sich nicht auf wenn's quakt
wie eine Ente...-Prinzipien verlassen zu müssen. ;-)

Gruß,

Martin

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

Re: [Talk-de] JOSM: Zoom auf durch Validate bemäng elte Elemente

[Martin Simon]

Am 30. November 2010 21:49 schrieb Jan Tappenbeck o...@tappenbeck.net:

 Schaltflächen sind schon erfunden oder ?

Ja, Ansicht, direkt neben Bearbeiten.

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

Re: [Talk-de] Karte die Verwaltungskategorie der Stra ßen darstellt?

[Martin Simon]

Am 26. November 2010 13:52 schrieb André Riedel riedel.an...@gmail.com:

 Ich würde analaog zu admin_level bei Grenzen einen neuen Schlüssel für
 die Straßeneinordnung vorschlagen, welche von Land zu Land gepfelgt
 werden kann.

 highway_class, road_level, ...

+1!

Nur wenn wir seperate Tags für Verwaltungsebene/Trägerschaft und
Verbindungsstufe haben (Ausbauzustand haben wir ja schon), können wir
den unsäglichen Mischmasch irgendwann überwinden und beginnen, auf
Basis dieser Informationen zu rendern und zu routen.

Gruß,

Martin

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

Re: [Talk-de] Karte die Verwaltungskategorie der Stra ßen darstellt?

[Martin Simon]

Am 26. November 2010 15:49 schrieb Heiko Jacobs heiko.jac...@gmx.de:

 Was soll ein Routen und Rendern nach Verwaltungsebene/Trägerschaft?
 Dann würde in Karlsruhe der internaionale Ost-West-Schwerverkehr
 Rotterdam-Balkan über eine Bundesstraße mit je einer Spur pro Richtung
 im Mischverkehr mit einer Straßenbahn geroutet statt über eine
 autobahnähnliche Kreisstraße?

Du hast das Anliegen nicht verstanden.
Es geht darum, die Informationen zu entheddern, so daß die Leute, die
Verwaltungsgeschichte visualisieren wollen dies können, ohne diese
Information ins Highway-tag zu pressen, was die Mehrheit tatsächlich
ablehnt.

Die Pseudoinformation in ref hilft dabei nicht wirklich, vor allem,
wenn man nicht nur das kleine Gallische Dorf Deutschland betrachten
will.

 Wer die Straße bezahlt, interessiert niemand im realen Straßenverkehr.
 Deswegen habe ich schon bunte Wechsel zwischen primary/Bundesstraße und
 secondary/Landesstraße auf ein- und derselben Verbindung
 (Bundesstraßeneubau nur abschnittsweise fertig) auf primary
 vereinheitlicht...

Natürlich interessiert es verschiedene Leute, ob es sich um eine
Landes- oder Bundesstraße handelt. man kann durchaus Ausbauzustand,
Verbindungsstufe o.ä. darstellen und *gleichzeitig* die
Verwaltungsebene.
Aber nur, wenn diese Informationen auch da sind und nicht entweder
teilweise unterdrückt werden oder mit anderem in einem tag vermengt
sind.

Den Rest haben auch schon andere gesagt.

Gruß,

Martin

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

Re: [Talk-de] news von steve coast

[Martin Simon]

Am 23. November 2010 22:27 schrieb SteveC st...@asklater.com:
 wow


Hey, stop google-translate-ing our list!

We can only succesfully conspire against you, OSMF, ODBL and
whoever-you-happen-to-work-for-atm when it's kept secret!

Please respect that!

Thank you sir.

-Martin



;-)

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

Re: [Talk-de] Panzersperren des Westwall

[Martin Simon]

Am 24. November 2010 16:09 schrieb Falk Zscheile falk.zsche...@googlemail.com:
 Und ich setze noch eins oben drauf, man könnte auch an
 historic=archaeological_site, site_type=fortification[1],
 fortification=tank_trap für ehemalige Panzersperren denken -- nur so
 als Vorschlag.

Ah, alles, was älter als 2 Generationen ist, ist eine archäologische
Ausgrabungsstätte? ;-)

Ich wäre für barrier. Das sind die nunmal, damals wie heute - frag'
mal die Bauern.
Wer es gebaut, wer benutzt und gegen wen es gerichtet war oder ist,
kann auch in einen Subtag. (das Militär hat heute keine Gewalt mehr
über die Dinger)

Mir ist jedenfalls noch nicht in den Sinn gekommen, die Tore des
Bundesverteidigungsministeium hier um die Ecke als military=gate und
die Zufahrten als military=service zu taggen, nur wiel sie zu den
gefleckten gehören... ;-)

Gruß,

Martin

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

Re: [Talk-de] Panzersperren des Westwall

[Martin Simon]

Am 24. November 2010 18:24 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com:
 Am 24. November 2010 16:47 schrieb Martin Simon grenzde...@gmail.com:

 Mir ist jedenfalls noch nicht in den Sinn gekommen, die Tore des
 Bundesverteidigungsministeium hier um die Ecke als military=gate und
 die Zufahrten als military=service zu taggen, nur wiel sie zu den
 gefleckten gehören... ;-)


 das wiederum sollte man überlegen, wenn man sich die obige Definition
 ansieht. Das BMfVerteidigung besteht z.T. durchaus aus Militärs, von
 daher wäre es angebracht.


Mit military=service meinte ich einen Ersatz für highway=service, geht
eventuell unter, wenn man den Ausdruck military service kennt ;-)

Ich halte den Key military nur für übergeordnete Objekte für
sinnvoll - die einzelnen Ausstattungsmerkmale einer Kaserne sind ja
ganz gewöhnlicher Kram: Tore, Schranken, Zäune, Sporthallen,
Parkplätze etc.
Wenn wir all diese Objekte jeweils für den Key military klonen,
können wir es auch gleich mit healthcare, railway, education etc
machen. ;-)

Da würde ich den Zusammenhang zwischen dem Tor des BMVg und dem Objekt
BMVg (das natürlich den Key military trägt) lieber über eine
Site-Relation herstellen.

Gruß,

Martin

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

Re: [Talk-de] Gebäude-Mapping

[Martin Simon]

Hallo Johannes, Hallo Martin,

Ich fürchte ich habe den Thread damit ein wenig gekapert; bei meiner
Antwort ging es gar nicht so sehr um die Fragestellung mit den Seilen
des Funkmastes, sondern um dieses allgemeine Konzept für gestückelte
Gebäude, das ich mal in den Raum stellen wollte.

(wie wär's mit man_made=cable, cable=suspension als Mitglied in einer
Building-Relation zusammen mit dem Mast und den Widerlagern?)


Am 5. November 2010 13:22 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com:
 Hm, wenn du Martin in dieser Frage beipflichtest, heißt die Lösung für
 deine Seile wohl building=yes. :-p


 building=rope wäre das analog. Im Bsp. Sony Center war das mit
 building=roof getaggt, nicht yes. Dieser Unterschied ist m.E. nicht
 unbedeutend.

OK, habe ich unterschlagen. ;-)
Ja, nicht unbedeutend, nur tritt es leider damit immer noch als
eigenständiges Gebäude auf.

 ja, volle Zustimmung. Das bräuchten wir eigentlich. Sobald wir ins
 2,5D gehen wollen (mit Höhen) kann es gar nicht ausbleiben, einen
 Umriss für jeden unterschiedlich hohen bzw. mit eigenem Dach
 ausgestatteten Baukörper zu haben. Man könnte den Kirchturm vom Schiff
 trennen, etc.

Ja, schön illustriert werden diese Möglichkeiten ja bereits z.B. bei
www.osm-3d.org .
Beispiele für Gebäude, die unterschiedliche Stockwerkszahlen haben und
bei denen ich damit unzufrieden bin, daß sie derzeit nach dem 'alten'
Schema als Sammlung einzelner Gebäude getaggt sind, befinden sich z.B.
auf diesem Campus (das Hauptgebäude mit Mensa und das Gebäude der
Fakultät 06 im Norden): http://osm.org/go/0...@ggdra-?layers=o

Vielleicht kriegen wir da etwas auf die Beine gestellt, das durchdacht
ist und Akzeptanz unter den Mappern und Renderern finden kann... :)

Gruß,

Martin

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

Re: [Talk-de] AIO - Routing über Fähren

[Martin Simon]

Am 4. November 2010 20:39 schrieb Garry garr...@gmx.de:

 Davon abgesehen waren die Freunde der Flughäfen in OSM schon sehr früh sehr
 fleissig und haben die Landebahnen
 schon vor Jahren vielfach auch mit Rollwegen eingetragen so dass es
 diesbezüglich kaum noch etwas zu mappen gibt.

Einer war sogar so fleißig, Landebahnen zu taggen, die nur in seinem
Kopf existieren - nämlich solche auf Modellfluggeländen, die schlicht
eine Rasenfläche ohne Markierung und jeglichen linearen Charakter...

...denn es wird ja bereits so schön gerendert...

Zum eigentlichen Thema:

Wenn eine wichtige Verkehrsverbindung über ein Fährterminal und eine
Fähre führt, sollten die dort eingeschlossenen Wege selbstverständlich
die Klassen beibehalten, unabhänging von Geschwindigkeit (das
berücksichtigen selbst simple Router schon separat) und Breite.


Auch Ortsdurchfahrten von Bundesstraßen (immer überregionale
Verbindungen) werden heutzutage aus Gründen der Sichertheit und des
Komforts für Fußgänger und Radfahrer schmaler (breitere Bürgersteige)
und langsamer ausgebildet, als es möglich wäre und früher praktiziert
wurde, wenn die beengten Platzverhältnisse dazu Anlass geben.
Die paar dm  und km/h weniger ärgern vielleicht den Autofahrer, ändern
aber nichts an der Verbindungsfunktion. Daher gehen wir dort auch
nicht auf secondary, tertiary oder residential herunter.

Gruß,

Martin

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

Re: [Talk-de] Gebäude-Mapping

[Martin Simon]

Am 5. November 2010 22:29 schrieb Johannes Huesing johan...@huesing.name:

 Keine Ursache, der Titel des Threads erfasst Deine Ausführungen genauso,
 aber alle, die mit uns auf Kaperfahrt gehn, müssen Männer mit Bärten sein.

[x] check! ;-)

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

Re: [Talk-de] Gebäude-Mapping

[Martin Simon]

Am 5. November 2010 18:36 schrieb Peter Wendorff wendo...@uni-paderborn.de:
 Am Unicampus Paderborn habe ich dazu ein Schema [1] verwendet und auch mit
 Komzpa (Entwickler von Kothic) abgestimmt.

 Bin bisher nicht dazu gekommen, das komplett fertigzumachen und in 'nen
 Proposal-Prozess einzubringen, aber hier passt das vielleicht rein,
 und auch wenn das noch auf meiner User-Seite liegt: Kommentare sind herzlich
 willkommen.

Hallo Peter!

Das Schema war mir noch gar nicht über den Weg gelaufen. Vielleicht
kann man die Vorteile aus allen Ansätzen kombinieren. :-)

Du schneidest dabei deine Gebäude horizontal, ich hatte eher eine
vertikale Unterteilung im Sinn (bei deinem Beispiel(von links nach
rechts): A: [7 Stockwerke], B: [5 Stockwerke, beginnend mit dem 3.],
A: [7 Stockwerke]).
Damit könnte man alles in einem Abwasch erledigen und sowohl solche
Durchlässe als auch unterschiedliche Dachhöhen darstellen. Hat das
horizontale schneiden einen Vorteil dem gegenüber, den ich übersehe?

Gruß,

Martin

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

Re: [Talk-de] Gebäude-Mapping

[Martin Simon]

Am 4. November 2010 20:21 schrieb Johannes Huesing johan...@huesing.name:

 Sehe ich anders. Die Realität wird m.E. ziemlich gut wiedergegeben,

 *beipflicht*

 Da wir gerade bei ger nicht so kleinen Details sind. Kürzlich war ich beim
 Sender Donebach spazieren. Wäre meine Frau nicht dabeigewesen (so fangen
 glaube ich viele Mapper ihre Sätze an), wäre ich durchaus versucht gewesen,
 die Betonanker der Spannseile und die Seile selbst zu mappen. Wie aber
 würde man Seile mit statischem Zweck eintragen, etwa auch bei Hängebrücken?
 Line hat sich glaube ich nur als Wert zum Schlüssel power eingebürgert.

Hm, wenn du Martin in dieser Frage beipflichtest, heißt die Lösung für
deine Seile wohl building=yes. :-p

SCNR...


Im Ernst: ich denke um die Problematik der information dies ist *ein*
Gebäude zu umgehen, die es auch immer gibt, wenn Mapper z.B.
unterschiedlich hohe Gebäudeteile als separate (wenn auch
verbundene) Polygone mit building=yes taggen, wäre es angebracht,
Gebäude und Gebäude*teile* zu trennen - nennen wir es einmal
buildingpart=*.
Das Dach des Sony Centers wäre z.B. buildingpart=roof (Dach ohne
darunter liegendes massives Gebäude, also nicht zur Aufstandsfläche
beitragend), die restlichen Bestandteile vielleicht erst einmal
buildingpart=yes.
Das ganze wird dann mit einer Simplen Relation vom typ building
zusammengefasst, die auch das alte building=* Tag enthält für den
Gebäudetyp.

Das hätte mehrere Vorteile: man könnte Gebäude genauer modellieren und
z.B. einzelnen Bauteilen unterschiedliche Basis- und Scheitelhöhen
geben (Dach des Sony Centers), ohne daß die falsche Information
aufkommt, es handle sich um eine Sammlung einzelner Gebäude. Dasselbe
gilt für unterschiedliche Stockwerkszahlen, Dachformen, etc.

Renderer, die sich dafür nicht interessieren, können buildingpart
einfach genauso zeichnen wie building - oder und verlieren dabei im
vergleich zu heute nichts. Die building-Relation würde es zudem
erlauben, auch unterteilten Gebäuden Funktionen aus dem Spektrum von
amenity=*, shop=* etc zuzuweisen.

Dieser Gedanke ist mir jetzt schon ein paar mal gekommen, mich würde
interessieren, ob ich der einzige bin, der hierin einen Nutzen sieht.

Gruß,

Martin

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