Re: [Talk-ee] Jõgede sidumine järvedel

[Joosep-Georg Järvemaa]

Kontakt Mihkel Oviir () kirjutas kuupäeval R,
4. detsember 2020 kell 12:19:
>
> Mis see OSMi praktika on jõgede/ojade suubumisel järvedesse. Lisan 
> Peipsiveere LK, ja näen, et kõik ojad ja jõed lõpetatakse Peipsi piiril ära 
> ja siis sealt läheb edasi nimetu jõe joon kuhugi keset Peipsit. Ilmselt siis 
> lähevad kõik suubuvad jõed kokku ja see siis omakorda Narva jõe algusesse? 
> Kas selline praktika nii suurte järvede puhul on normaalne? Ma saab aru, kui 
> vooluveekogu läbib väiksemaid järvi.

Kas see küsimus jäigi vastuseta?

-- 
Joosep-Georg

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

Re: [Talk-de] Gewichtung der Straßen im Routing

[Georg Feddern]

Moin,

Am 29.04.2020 um 13:11 schrieb Volker Schmidt:

Ich halte das mit maxspeed:practical fuer eine ziemliche Kruecke.


+1 - leider, weil s.u.


Ich kann mir nicht vorstellen,
dass eine 4m breite Strasse in DE nicht Geschwindigkeits-begrenzt ist.


Oh, ich kann Dir diverse Beispiele nennen.

Diese 4 m breiten Straßen sind die ganz üblichen ländlichen und 
verkehrsschwachen Gemeindeverbindungsstraßen mit 90° Kurven und immer 
dem Bullen-Pi$$ ;-) nach am Feldrand lang gebaut.
Da lohnen sich keine Geschwindigkeitsbegrenzungsschilder - wer die 
Strecke nicht kennt, fährt da eh 'angemessen' vorsichtig und nutzt 
höchstens die Sichtweite aus - nur das junge Landvolk übertreibt es 
manchmal, weil 'gestern kam auch keiner'.


Damit gilt nun mal die offizielle rural maxspeed von 100, die nach 
allgemeiner Auffassung getaggt werden darf.
Ein Router mag noch die width berücksichtigen können - aber die 
geschwindigkeitsentscheidende Sichtweite kann er nichteinmal aus der 
Geometrie erschließen, weil sie auch vom Hoch und Runter sowie dem 
Rand-/Feldbewuchs abhängt.


Grüße
Georg

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

Re: [Talk-de] Darstellung auf Karte Re: mit Bauzaun Strassenbereich sperren?

[Georg Feddern]

Moin,

Am 20.01.2020 um 09:49 schrieb Ludwig Baumgart:


Mein eigentliches Problem ist aber ungelöst: die Darstellung auf der 
Hauptkarte bekomme ich nicht so hin, wie es die Wirklichkeit ist, 
nämlich dass der Bauzaun einen Teil der Bus-platform (mit 
highway=platform wie z.B. am ZOB Freuburger Bahnhof) und der 
August-Ruf-Strasse absperrt. Diese Absperrungen sind nicht sichtbar in 
der Karte. Die Karte pinselt die highways über die Bauzäune!





Wer hat eine Idee, was ich falsch mache?



Prinzipiell nicht, nur:
"Der" Renderer (der Hauptkarte) ist auf so etwas nicht ausgelegt / 
eingerichtet - und wird das wahrscheinlich auch nicht so schnell.


Wenn man das unbedingt will - und entsprechend _dauerhaft_ und absolut 
zeitnah begleitet, kann man nur quasi "Tagging für den Renderer" betreiben.
Dafür muss man berücksichtigen, das dieser Renderer highways immer 
zuletzt in der Karte "malt".
Innerhalb der Baustelle / des Bauzauns hat man daher nur folgende 
Möglichkeiten:
- Straßen (unclassified und höher) als highway=construction taggen, 
immerhin sind sie Teil der Baustelle.
- bei highway=service(?), track und Wegen bleibt nur, sie per access=no 
für den Router zu taggen oder - vorübergehend - zu entfernen.
- um den Bauzaun "sehen" zu können, muss man highway=* beim Bauzaun 
deutlich unterbrechen.
- beim Haltestellenbereich muss man den Baustellenteil dem 
landuse=construction zuschlagen, also nicht als platform taggen.


Den Zorn der Gemeinde nehme ich jetzt mal in Kauf - in der Hoffnung, 
dass Du wirklich am Geschehen dran bleibst!


Grüße
Georg

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

Re: [Talk-de] Daten über Restriktionen und Vorrangrouten für den Schwerlastverkehr in NRW

[Georg Verweyen]

Hallo zusammen,

Erst einmal Danke an Tom, dass er die erste einleitenden Worte zur Einordnung 
gebracht hat.

Als ich die Mail von von Herrn Spitzley gelesen habe, habe ich nur gedacht „Was 
für eine riesige Aufgabe“. Und ich bin mir tatsächlich immer noch nicht im 
klaren, ob wir die Erwartungshaltungen in Deckung bringen können. Deshalb habe 
ich es gerade auf die Themenliste für den Dezember OSM Stammtisch von Bonn 
gesetzt 
(https://wiki.openstreetmap.org/wiki/Bonn/Stammtisch#124._Treffen_am_17._Dezember_2019
 
<https://wiki.openstreetmap.org/wiki/Bonn/Stammtisch#124._Treffen_am_17._Dezember_2019>).

Was mich bewegt, wie können wir denn Fehlerquellen (Differenzen im 
Datenbestand) möglichst automatisiert finden und aufbereitet, sodass die 
Community bereit ist (nicht nur nach dem St. Florian Prinzip) die Daten 
einzutragen. Das ist aber stark von der Form der angebotenen Daten abhängig. 
Ein erster Aufsatz wäre ein Vergleich von Router Ergebnisse (wie fahre ich von 
A nach B wenn ich Gefahrgut transportiere). Dies ist aus meiner Sicht aber 
suboptimal, denn hier müssten wir erstmal einen Experten für Routeranpassungen 
haben (meines Wissen nach gibt es „nur" eine Garminanpassung für LKWs) . 
Was ich mir vorstellen könnte, wäre erstmal ein Teilthema, das für den VRS 
besonders wichtig ist, über eine Overpass-Turbo-Abfrage grafisch darzustellen 
und die Sachlagen zu vergleichen. Weitere Entwicklungsschritte wäre damit 
besser planbar.

Was erwartet mich eigentlich hinter dem Benutzerbereich von Sevas 
(https://sevas.nrw.de/index.php?id=64 <https://sevas.nrw.de/index.php?id=64>)? 
Werden dort nur Routingdaten angeboten oder kann man sich dort auch an 
technische Informationen und Datenextrakte?

Mit morgendlichen Grüßen.   Georg V. (OSM=user_5359)
P.S.: Herr Spitzley> Sie sind herzlich eingeladen zum Bonner Stammtisch zu 
kommen, ist aber definitiv keine Pflicht. Das soll auch nicht den 
Informationsfluss bis dahin stoppen.
 

> Am 26.11.2019 um 13:00 schriebTom Pfeifer  <mailto:t.pfei...@computer.org>>
> 
> Hallo Herr Spitzley,
> es wird sich bestimmt noch jemand aus NRW zu Wort melden, ich mache mal den 
> Anfang zu den 
> allgemeinen Fragen.
> 
> On 21.11.2019 11:30, Spitzley, Bennedikt wrote:
> 
>> Kommunen in NRW tragen auf der web-basierten Plattform SEVAS auf OSM 
>> Kartenwerk zum einen Lkw-Vorrangrouten ein. 
> 
> Die Nutzung von OSM-Material, z.B. als Hintergrundkarte, ist grundsätzlich 
> ohne Einschränkung 
> möglich. Einzige Voraussetzung ist die korrekte Attributierung, wie sie hier 
> beschrieben ist:
> https://www.openstreetmap.org/copyright 
> <https://www.openstreetmap.org/copyright>
> 
>> Zum anderen erfassen sie Lkw relevante Restriktionen: Lkw Durchfahrtsverbot 
>> (basierend auf Verkehrszeichen 253), Verbot für Gefahrgut (VZ 261), 
>> Beschränkungen in der Masse (VZ 262), Achslast (VZ 263) Breite (VZ 264, Höhe 
>> (VZ 265), Länge (VZ 266) und Verbot für wassergefährdende Ladung (VZ 269).
>> Diese Daten werden auf dem Mobilitätsdatenmarktplatz MDM bereitgestellt, wo 
>> Sie von Navigationskartenherstellern heruntergeladen werden können und so 
>> ihren Weg zunächst in die Navigationskarten und dadurch dann in die 
>> Lkw-Navigationsgeräte finden. Auch der Download über WFS- und WMS-Server ist 
>> möglich.
>> Gerne möchten wir diese Daten auch auf OSM veröffentlichen. Ob und wie dies 
>> möglich ist, möchte ich gerne hier diskutieren.
> 
> Das Einpflegen dieser Restriktionen in OSM ist grundsätzlich erwünscht, und 
> in vielen Fällen auch 
> schon durch die Community entsprechend der Ausschilderung vor Ort erfasst.
> 
> Es existieren folgende etablierte Attribute:
> 
> - hgv=no  Lkw Durchfahrtsverbot,
>   https://wiki.openstreetmap.org/wiki/DE:Key:hgv 
> <https://wiki.openstreetmap.org/wiki/DE:Key:hgv>
> 
> - hazmat=no  Einschränkung für Gefahrguttransporte,
>   https://wiki.openstreetmap.org/wiki/DE:Key:hazmat 
> <https://wiki.openstreetmap.org/wiki/DE:Key:hazmat>
> 
> - hazmat:water=no Verbot für Fahrzeuge mit wassergefährdender Ladung
>   s.o.
> 
> - maxweight=* juristische Gewichtsgrenze für die Benutzung der Wege
>   * in Tonnen wenn ohne Einheit angegeben
>   https://wiki.openstreetmap.org/wiki/DE:Key:maxweight 
> <https://wiki.openstreetmap.org/wiki/DE:Key:maxweight>
> 
> - maxaxleload=* beschreibt die maximal zulässige Achslast in Tonnen.
>   https://wiki.openstreetmap.org/wiki/DE:Key:maxaxleload 
> <https://wiki.openstreetmap.org/wiki/DE:Key:maxaxleload>
> 
> - maxwidth=* maximal zulässigen Breite eines Fahrzeuges, in Metern
>   https://wiki.openstreetmap.org/wiki/DE:Key:maxwidth 
> <https://wiki.openstreetmap.org/wiki/DE:Key:maxwidth>
> 
> - maxheight=* Beschränkung der Durch

Re: [Talk-de] Postalische Eigenständigkeit / admin boundarys

[Georg Feddern]

Moin,

Am 17.10.2019 um 12:53 schrieb Florian Lohoff:

ich mache so einiges an Adress QA und u.a. überprüfe ich ob das
addr:city zu dem name (und name:suffix) auf dem admin_boundary mit dem
admin level 6 bzw 8 passt.

Das geht auch in 99% der Fälle gut und funktioniert.


Aber nur, weil Äpfel und Birnen (in diesem Fall Verwaltungszugehörigkeit 
und postalische Adresse) genetisch arg eng verwandt sind. ;-)

Es kommt aber eben zu diversen Mutationen.


Es gibt aber einige Gemeinden die im Zuge von Eingemeindungen ihre
postalische Eigenständigkeit erkämpft haben.


Eben - und das ist der wesentliche Unterschied - verwaltungsrechtliche 
und postalische Adress-Zugehörigkeit sind nun mal nicht als identisch zu 
betrachten

.

Z.b. ist hier 33428 Marienfeld genannt (gehört zu 33428 Harsewinkel)

Marienfeld ist eigentlich "nur" ein Stadtteil von Harsewinkel.

https://osm.zz.de/dbview/?db=addresses-nrw=addresserror#51.95246,8.28361,14z

Jetzt suche ich irgendeinen weg wie man das erkennen kann oder halt
entsprechend taggen.

D.h. auf dem admin_boundary mit dem admin_level 10 von Marienfeld
ein addr:city=Marienfeld hinterlassen z.b.

https://www.openstreetmap.org/relation/9609627

Jemand ne andere schöne idee.


Weder andere noch schöne - eher ein Gegenargument:
Denn dieses Zusatztagging hilft vielleicht bei solch eindeutigen 
Sonderfällen - aber es bleiben eben immer noch die 0,8 % der anderen 
Sonderfälle, wo Randerscheinungen einfach dem postalischen 
Zustellbereich der Nachbargemeinde zugeordnet werden, die sich nicht so 
leicht kennzeichnen lassen.

Lohnt sich dann für diese 20%-Erfolgsrate solch eine Sonderlocke?
Und wenn, dann bin ich voll bei Dir: Für reines QA-Tagging bitte einen 
qa: Namensraum statt allgemeiner keys bitte!


PS: Kann man das nicht durch einen zusätzlichen QA-Check gegen die 
PLZ-Relation (mit postal_code und name) erkennen/prüfen/false-positiven?


Grüße
Georg

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

Re: [Talk-at] minderwertige Importe

[Georg Haefele]

Hallo,

also ich finde die Arbeit von Johann sehr wertvoll. Er hat zumindest in meiner 
Heimatgemeinde in Vorarlberg gute Arbeit geleistet und dadurch die restlichen 
Korrekturen wesentlich erleichtert. Vernichtet wurde durch seine Arbeit 
zumindest in diesem Gebiet nichts.

Zudem hat er - im Gegensatz zu vielen anderen Mappern -  berücksichtigt, dass 
es dort keine Straßennamen gibt und korrekterweise addr:place verwendet.

Gruß
Georg


 

-Original Message-
From: Rudolf Mayer  
Sent: Sunday, June 9, 2019 2:41 PM
To: talk-at@openstreetmap.org
Subject: Re: [Talk-at] minderwertige Importe

Hallo,

ich bin zwar grundsätzlich nicht erfreut, wenn Arbeit zu nichte gemacht wird, 
auch nicht die von Johann - aber genauso macht er auch viel Arbeit von anderen 
zunichte, bzw. halst den anderen viel Arbeit auf.

Seine Vorgehensweise ist ja wirklich einfach nur arrogant - ich importiere mal, 
und als changeset Kommentar bitte ich dann die anderen, die Fehler zu 
beseitigen. Das ist einfach nur ignorant.

Auch seine Rechtfertigung, dass man ja jede Adresse dann persönlich 
verifizieren müsste zeigt, dass er einfach ein Sofa-Mapper der wirklich 
schlechten Art ist (ich habe grundsätzlich keine Abneigung gegen solche, viele 
tragen sehr wertvolles bei, wenn aus Satellitenbildern oder von Mapillary 
Informationen übertragen werden).


Grundsätzlich stellt sich mir hier nicht nur die Frage wie man die bisherigen 
Edits behandelt, sondern auch, wie man in Zukunft verhindert, dass er das 
wieder einfach weiter so macht. Diskussion mit ihm ist ja so ähnlich, wie wenn 
man mit einer Mauer redet.
Er sieht sich halt irgendwie als der Missverstandene, und alle anderen in der 
Community, auch wenn sie geschlossen anderer Meinung sind, liegen einfach 
falsch. Das passt halt überhaupt nicht zu OSM...

Eine 7-Tage Sperre wird hier vielleicht nicht viel helfen. Auch hat er ja 
gezeigt, dass er schnell einfach mal einen neuen account macht (und er hat auch 
momentan viele die er zugibt, wie man hier sieht: 
https://www.openstreetmap.org/user/addresshistory*org)


Alles in allem wäre ich dafür, zumindest einen Teil seiner Edits rückgängig zu 
machen. Vor allem dort, wo es ja von der lokalen Community nicht gut 
aufgenommen wurde (das ist imho zumindest in Wien der Fall).


Lg
Rudi

On 08/06/2019 12:03, Frederik Ramm wrote:
> Hallo,
> 
> nach wiederholten Beschwerden über die Importe von addresshistory*org 
> habe ich hier eine Accountsperre verhängt
> 
> https://www.openstreetmap.org/user_blocks/2839
> 
> und den User aufgefordert, jeden einzelnen Import vorher an dieser 
> Stelle hier zu diskutieren, insbesondere was die Datenquelle und die 
> Methodik anbetrifft, damit Fehler künftig *vorher* gefunden werden 
> können, statt dass zigtausende Nodes erst importiert, dann gelöscht, 
> dann wieder neu importiert werden und so weiter. Das ist einfach 
> schlampige Arbeit und macht uns allen mehr Arbeit als es nützt.
> 
> Ich bin auch sehr gern bereit, von der DWG aus großzügig alle Edits 
> der letzten Monate/Jahre dieses Accounts zu revertieren, wenn in der 
> österreichischen Community ein grober Konsens bestehen sollte, dass 
> der Schaden insgesamt größer als der Nutzen ist.
> 
> Viele Grüße
> Frederik
> 


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

Re: [Talk-de] Erreichbarkeit von Adressen

[Georg Feddern]

Moin,

Am 04.05.2019 um 18:32 schrieb Florian Lohoff:

On Sat, May 04, 2019 at 11:29:58AM +0200, chris66 wrote:

Am 03.05.2019 um 12:58 schrieb Florian Lohoff:


Ein access=private/access=no ist gar nicht zu benutzen.

bzgl access=no stimme ich zu. access=private sollte IMO als
destination gewertet werden, ansonsten können Anwohner sich
nicht von/zu ihrem eigenen Haus routen lassen.

Korrekt - das ist bei allen gängigen Routern so. Wenn wir access=private
überall wie access=destination werten können wir das auch gleich
abschaffen und ein service/driveway immer wie ein
motor_vehicle=destination bewerten.


einerseits mag ich Dir recht geben - für's Routing ist es dasselbe.
Andererseits besteht zwischen einer öffentlichen Straße (Widmung) mit 
Einschränkung auf Anlieger und einem Privatweg schon noch ein Unterschied.

Permissive ist für mich auch nicht dasselbe.

Beim Routing würde ich
- private - wie destination - immer nur auf der letzten Meile
- permissive auch im Transit
akzeptieren.

Grüße
Georg

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

Re: [Talk-de] Erreichbarkeit von Adressen

[Georg Feddern]

Moin,

Am 03.05.2019 um 09:48 schrieb Florian Lohoff:

On Fri, May 03, 2019 at 02:57:14AM +0200, Martin Koppenhoefer wrote:

sent from a phone


On 2. May 2019, at 23:46, Florian Lohoff  wrote:

Egal - Hier sind die Daten für NRW - Vielleicht findet die ja jemand
anderes auch Spannend.

spannender wären die überhaupt nicht erschlossenen (in OSM). Soweit
ich deine Ausführungen verstanden habe sind hier alle enthalten, die
weiter als 75m von einer allgemein mit dem Kfz befahrbaren Straße
liegen, also auch alle die über längere Privatzufahrten erschlossen
sind oder in Fußgängerzonen liegen, usw.


das sehe ich wie Martin.


Für mich ist "gar nicht erschlossen" dasselbe wie "track" oder
"access=no/private" auf einem service/driveway.


Also meiner Meinung nach macht ein Router - wie auch ein Anwender - 
einen Fehler, wenn er private = no wertet.
destination wäre m. M. n. richtiger - und zielführender im wahrsten 
Sinne des Wortes.

Zu track siehe unten.



Ich habe zuhause ein ähnliches Problem. Unbefestigter Waldweg vor
der Tür. Ist klar ein Service bzw ein unclassified weil öffentlich.
Trägt aber ein motor_vehicle=destination und ich bin der einzige
Anlieger. Drumherum gibt es reichlich Forstwirtschaftliche Wege.
Wenn ich mit OSMAnd versuche nach hause zu navigieren dann werde ich
Kreuz und quer durch den Wald geschickt weil die kosten für eine
unclassified mit motor_vehicle=destination höher sind als die
eines tracks.


Ich sehe da aber den Fehler bei OSMAnd und seiner Wertung.


Defakto "verweigern" die gängigen Routingengines Autos auf Tracks
(Meiner Meinung nach zu recht) so das hier diverse Höfe und
ländliche Gebäude routingtechnisch nicht wirklich "erreichbar" sind.



Was denn nun bei den tracks?
Verweigern oder über unclassified+destination stellen und bevorzugen?
Tracks (im Sinne von schmalen Fahrwegen) sollen "nach Möglichkeit"
vermieden werden, ja - aber die letzte Meile bietet nun mal keine
andere Möglichkeit.
Wo ist also das Problem den Malus sehr hoch zu setzen?


Auch eine Hofzufahrt mit "Privatweg"
als access=private zu taggen halte ich für falsch. Postbote,
Lieferdienst, Schulbus, Müllabfuhr fahren da mitunter rein.


Richtig - ihnen wird das private Recht der Benutzung eingeräumt.
Trotzdem gelten dort private Nutzungsrechte.
Schulbus bis auf den Hof? Nett, kenne ich so nicht ...


Das sind eben die letzten 2-3% Adressen die mit aktuellen Tags und
Software nicht lösbar sind.


Sehe ich eben ganz anders - durchaus lösbar mit den aktuellen Tags und 
Software.



Und die ganze nach Gefühl gemappten access=private/no auf jeder Hauszufahrt
machen eben die navigation für diese Adressen kaputt. Wenn das im
Wohngebiet nur die 10m Hauszufahrt sind - geschenkt. Wenn aber
das Haus/Hof 800m neben der Straße im Wald oder Tal/Berg liegt und ich
das nicht einmal sehe bzw der nächstgelegenene Punkt auf einer Öffentliche
Straße auf einer Straße ist von der keine Zufahrt möglich ist das halt
ziemlich suboptimal. Dann ist OSM für diesen Anwendungsfall auf dieser
Adresse einfach kaputt.


Ne - nicht OSM, sondern der Auswerter (sofern eine Zuwegung bis zum Haus 
in OSM existiert).


Grüße
Georg

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

Re: [Talk-de] fire_hydrant:pipe_diameter

[Georg Feddern]

Moin,

Am 03.04.2019 um 21:28 schrieb Martin Scholtes:

Ein Nachtrag noch. Die Anzahl auf Taginfo zeigt nach overpass-abfrage
nur Node´s in DE und 3 in AT an. Somit ein lokal und durch i-was
verursachtes Problem. "Urheber" dieses Key scheinen auch Fw-Acc´s zu sein.


alles nicht verwunderlich - führt doch eine simple Suche sofort zu
https://wiki.openstreetmap.org/wiki/DE:OpenFireMap-HowTo

Grüße, Georg

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

Re: [Talk-de] Korrektes Tagging eines Feriengebiets

[Georg Feddern]

Moin,

Am 25.03.2019 um 00:02 schrieb Martin Koppenhoefer:



Am 24.03.2019 um 23:43 schrieb Garry :

Worin siehst Du das Problem?

Es sind ja eigentlich alle Eigenschaften da die ein Wohngebiet machen -
die Bewohner wechseln zwar etwas öfter und die Leerstände sind etwas
häufiger und synchronisierter, aber muss man das unbedingt durch einen
eigenen landuse ausdrücken?

ein offensichtlicher Unterschied ist, dass das Übernachten hier business ist.


Also "commercial_residential"? ;-)
Dann hätten wir endlich auch unser Mischnutzungsgebiet ... ;-)

Grüße, Georg

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

Re: [Talk-de] Behindertenparkplätze und fee=*

[Georg Feddern]

Moin,

Am 26.02.2019 um 22:35 schrieb Richard:

Solle man solche Fälle mit fee=yes+fee:disabled=no bzw mit der conditional 
Variante
 fee:conditional=yes + fee:conditional=no @ disabled;
mappen?


Es geht nicht um Behindertenparkplätze sondern um 'normale' Parkplätze 
für Behinderte mit Park- (blau) bzw. Parkerleichterungsausweis (orange).
Somit ist diese Besonderheit für alle Betroffenen bereits bekannt - und 
für die Öffentlichkeit ist das eher uninteressant.
Zudem ist das ein default-Wert, der für alle öffentlichen Parkplätze / 
-häuser gilt - man muss also nicht extra danach suchen.
Dies ist somit nur bei privaten, nicht-öffentlichen Parkplätzen / 
-häusern von Interesse - und da sollte man solche Besonderheiten sowieso 
grundsätzlich erfassen.


Grüße, Georg

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

Re: [Talk-de] Etwas NICHT anlegen, wie schaut es mit Copyright aus?

[Georg Feddern]

Moin,

Am 10.02.2019 um 10:13 schrieb MonkZ:

Nun der Knackpunkt: Ist das NICHT-Anlegen auch schon ein
Copyrightverstoß? Ist die Feststellung von "Nichtexistenz eines
Gebäudes" = Datenerhebung?


Kennt jemand ein sicheres Land ohne Auslieferungsvertrag?
Bei meinen ganzen Copyright-Verstößen ...
Wie soll ich je beweisen, das meine Nichterfassungen nur auf 
Unwissenheit oder Faulheit beruhen!


Grüße
Georg

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

Re: [Talk-de] Radverkehrsinfrastruktur / Lübecker Modell

[Georg Feddern]

Moin,

nun ja - jeder benutzungspflichtige Radweg muss ja "designated"(*) sein 
- sonst wär er ja nicht benutzungspflichtig.
Andererseits sind ja nicht alle "designated" auch tatsächlich 
benutzungspflichtig - siehe Querfeldein-Wege.

(Hier war die frühere StVO eigentlich besser formuliert m.M.n.)

Die Benutzungspflicht ergibt sich ja erst aus der Nähe/Begleitung einer 
Straße - und kann im Wesentlichen durch "use_sidepath=yes" an der Straße 
abgebildet.
Hierdurch soll ja genau das Wesentliche - nämlich die Vermeidung der 
Straßenbenutzung beim Routing - erreicht werden.
Ein benutzungspflichtiger Radweg kann dann noch durch "is_sidepath=yes" 
hervorgehoben werden.


M. M. n. sind damit eigentlich genügend Daten für eine möglichst 
richtige Routenbevorzugung gegeben.


(*) Im deutschen Sinne läuft das ja auf den blauen Lolli hinaus.

Grüße
Georg

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

Re: [Talk-de] Attribut für die Europachausee in Halle (Saale)

[Georg Feddern]

Moin,

Am 08.01.2019 um 19:46 schrieb Heinz-Jürgen Oertel:

Am Dienstag, 8. Januar 2019, 19:13:43 CET schrieb Martin Koppenhoefer:

Am Di., 8. Jan. 2019 um 16:00 Uhr schrieb Heinz-Jürgen Oertel <

hj.oer...@t-online.de>:

Dass ein trunk am Anfang und Ende zur secondary wird, halte ich
aber auch für komisch, vielleicht primary?

primary: "Hauptverbindungsstraße unter zentraler Verwaltung , meist mit
besonderer Kennzeichnung (D: Nummer oberhalb der Vorfahrtsschilder), die
meist
größere Städte verbindet und dem überregionalen Verkehr dient."
trifft es auch nicht.

Ein Punkt am südlichen Beginn:
https://www.openstreetmap.org/node/1231139671

doch, das könnte es schon treffen, das südliche Stück bis zur B91 könnte
man primary setzen, und wahrscheinlich auch im Norden bis zur B100 hier:
https://www.openstreetmap.org/way/275346451

Gruß,
Martin

Martin, aber: "Hauptverbindungsstraße unter zentraler Verwaltung..:"
es ist eine städtische Straße.
Danke Allen für Hinweise.
Ich werde die gesamte Umgehung mal auf highway=trunk setzen.
Falls noch eindeutige Argumente für oder wider kommen, ist ja schnell
geändert. Jedenfalls denke ich, sollte der gesamte Verlauf einheitlich sein.


Hier sehe ich es wie Martin:
Ein Mischmasch macht auf diesen doch relativ kurzen 3 Teilstücken keinen 
rechten Sinn, erst recht nicht als secondary und trunk.
Aber sowohl nördlicher wie südlicher Teil enthalten viel zuviele 
Kreuzungen und Ampeln, als dass man sie als trunk taggen könnte, für 
trunk ist kreuzungs- und ampelfrei m. E. eine Voraussetzung.
Der mittlere Teil ist dann wiederum so kurz und ohne wirkliche 
Netz-Anbindung , dass sich dafür m. E. kein trunk mehr lohnt.
Ich würde daher die gesamte Strecke als primary taggen, dadurch ist sie 
ausreichend hoch eingestuft, um als Umgehung von/zur A 14 genutzt zu werden.


Grüße, Georg

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

Re: [Talk-de] Fwd: Path / Pfade / Mehrzweckwege

[Georg Feddern]

Am 17.12.2018 um 11:47 schrieb Martin Koppenhoefer:

Am Mo., 17. Dez. 2018 um 11:34 Uhr schrieb :


Wasserfest meint nicht zwangsläufig versiegelt. Außerdem der falsche
Begriff. Wassergebunden wäre richtiger und dort gibts auch ne prima
Erklärung für


Eben deshalb habe ich den vermeintlich 'falschen' Begriff verwendet.
Eine wassergebundene Decke (wie auch grober Schotter) ist eben nicht 
versiegelt, aber traktionsmäßig noch 'wasserfest'.
Asphalt und Beton sind versiegelt, aber eben nicht wassergebunden - aber 
wasserfest.



=> https://de.wikipedia.org/wiki/Wassergebundene_Decke

und zugegebenermaßen wird grade=1 bei korrekter Anwendung kaum und
grade=2 eher selten Verwendung finden.


Wassergebundene (compacted) lasse ich mit unter grade2 laufen - insofern 
nicht ganz so selten.
grade1 ist eher im Süden der Republik anzutreffen, im Norden konnten sie 
sich sowas nie leisten. ;)



Wassergebunden ist das Gegenteil von wasserdicht, es bedeutet, dass der Weg
ohne Bindemittel "zusammenhält", "wasserfest" meint vermutlich, dass Wasser
ausgehalten wird (eine Zeitlang, auf Dauer erodiert Wasser selbst massive
Berge).


So war es gemeint.

Grüße, Georg

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

Re: [Talk-de] Relation für Gebäude

[Georg Feddern]

Moin,

Am 18.09.2018 um 23:54 schrieb Martin Koppenhoefer:

Am 18. September 2018 um 15:30 schrieb Benedikt Bastin <
b.bast...@googlemail.com>:


Hallo zusammen!

Ich arbeite gerade an Indoor-Karten und bin jetzt am Problem dran, ein
gesamtes Gebäude herunterzuladen. Das Gebäude besteht aus einem
Multipolygon für den Umriss und natürlich den diversen Räumen und POIs im
Inneren. Das über eine Flächenabfrage mit Overpass oder über die einzelnen
Knoten abzufragen ist, gelinde gesagt, hässlich und sehr fehleranfällig
(beispielsweise U-Bahnen, Stromleitungen, Zäune an der Hauswand, etc.).




d.h. Du schlägst vor, U-Bahnen und Stromleitungen und Zäune an der Hauswand
in die Gebäuderelation einzufügen?
Ehrlich gesagt habe ich den Verdacht, du brauchst vielleicht einfach ein
größeres Polygon als nur ein oder mehrere Gebäude, vielleicht das komplette
Gelände / den Standort, dann sollte es einfach sein, alles benötigte über
eine räumliche Abfrage zu erhalten.


Falsch herum gedacht (weil es genau das Gegenteil heißt):
Eine größere Flächenabfrage enthält nur noch mehr Stromlinien über oder 
U-Bahnen unter bzw. Zäune am Gebäude -resp. dann ja neben - innerhalb 
des 2-dimensionalen Overpass-Abfrage-Polygons - die aber allesamt gar 
nicht zum Gebäude gehören. ;-)


Gruß
Georg

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

Re: [Talk-de] Gemeindegrenzen finden

[Georg Feddern]

Am 27.08.2018 um 22:32 schrieb Markus:

Mittelfranken: 250

Aber wieso funktioniert das nicht mit Franken
Und wie finde ich die Relations-Nr von z.B. Franken?


Z. Z. gar nicht - bzw. erst, wenn Franken als Relation erfasst werden würde.
Franken ist aber nur eine Region, keine administrative Einheit wie 
Ober-, Unter, Mittelfranken.

Und mit Regionen hat es sich in OSM ja nicht so.

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

Re: [Talk-ee] lennujaama nimes typo

[Joosep-Georg Järvemaa]

Redigeerida-parandada saab igaüks.

Aga tegin paranduse ära.

Kuupäeval 16. juuli 2018 10:08 kirjutas Aleksander Kamenik
:
> Mulle tundub, et kaardil on Tallinna lennujaama nimes typo, mis karjub
> silma. Peaks olema Lennart, mitte Lennard.
>
> https://www.openstreetmap.org/#map=19/59.41638/24.80057
>
> Keegi oskaja/vahenditega võiks ära lappida. Aitäh.
>
> --
> Aleksander Kamenik
>
> ___
> Talk-ee mailing list
> Talk-ee@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ee



-- 
Joosep-Georg Järvemaa

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

Re: [Talk-de] Maxspeededitor: Wie speichern?

[Georg Feddern]

Moin,

Am 29.12.2017 um 19:41 schrieb markus schnalke:

heute habe ich den Maxspeededitor <http://maxspeededitor.qrcaching.de>
entdeckt. Der war mir hilfreich, um vergessene Strassen in grossen
30er-Zonen zu finden ... und hinzufuegen kann man die Tempolimits auch
... scheinbar, denn die Frage ist wie man dort speichert?


in solchen Situationen mag er hilfreich sein - wenn er denn mal 
funktioniert.
Ortskenntnis ist aber unbedingt erforderlich - denn solange er keine 
richtungsabhängen maxspeed erkennt und global überschreiben will, sollte 
man ihn mit Vorsicht genießen.


Grüße, Georg
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-us] (New) Request for support when reverting the changeset 54846601

[Georg Verweyen]

I have discovered a marked shift in a point that leads the road through houses 
and other streets. Unfortunately, the JOSM plugin reverter doesn't always work 
on my laptop , so I have to ask for support. For details please refer to the 
mentioned changeset 
http://www.openstreetmap.org/changeset/54846601#map=15/40.6934/-73.9771

With thanks and best wishes Georg V. (OSM=user_5359)
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Request for support when reverting the changeset 54721716

[Georg Verweyen]

I have discovered a marked shift in a point that leads the road through houses 
and other streets. Unfortunately, the JOSM plugin reverter doesn't always work 
on my laptop , so I have to ask for support. For details please refer to the 
mentioned changeset http://www.openstreetmap.org/changeset/54721716 
<http://www.openstreetmap.org/changeset/54721716> .

With thanks and best wishes Georg V. (OSM=user_5359)___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-de] Fehler mit Nominatim

[Georg Feddern]

Moin,

Am 01.11.2017 um 00:36 schrieb Martin Koppenhoefer:



On 31. Oct 2017, at 19:59, Walter Nordmann <wnordm...@gmx.de> wrote:

Damit sollte klar sein, dass der Begriff "Mitte" durchaus in Daun 
verwendet wird - auch wenn es kein selbstständiger Ortsteil laut 
Satzung ist. Somit sollte die Fläche in OSM behalten werden.


admin Gebiete sollten offizielle Namen haben, diese stehen im 
Gesetz/Ordnung/Verfassung etc.


um es mal weiter zu verkomplizieren ;-):

Die Stadt Daun verwendet den Begriff "Kernstadt" selbst, wenn sie z.B. 
bei der Zusammensetzung von Gremien zu den Ortsbezirken unterscheiden muss.


Grüße, Georg
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Rettungsleitstellen

[Georg Feddern]

Moin,

Am 09.04.2017 um 20:35 schrieb chris66:

Am 09.04.2017 um 13:44 schrieb Walter Nordmann:


Moin,  ich habe /emergency=control_centre/ mal in die Emergency Map 2.2
https://wambachers-osm.website/emergency integriert.


Cool, damit ist das Tag quasi abgesegnet. ;-) 


hoffentlich nicht - ich sehe das wie Peilscheibe, dass
emergency=coordination_centre
der bessere Ausdruck wäre.
Die kontrollieren nämlich nichts, sondern koordinieren.

OK - jetzt mit Digital-Funk und GPS-Rückmeldungen haben sie etwas mehr 
Kontrolle. ;-)


Grüße, Georg

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

Re: [Talk-de] Mechanisches Umtaggen, Vorschlag zur vereinheitlichung von 30er Zonen tagging

[Georg Feddern]

Moin,

Am 30.03.2017 um 14:18 schrieb Martin Koppenhoefer:

Wie wärs, wenn wir zumindest

source:maxspeed=DE:zone30 und
source:maxspeed=DE:zone:30

vereinheitlichen würden


das halte ich für sinnvoll, da die beiden Werte keine unterschiedlichen 
Inhalte ausdrücken.


Allerdings drücken

zone:maxspeed=*
und
source:maxspeed=*

ja durchaus unterschiedliche Inhalte aus.
Denn zone:* beinhaltet ja die weiteren Zonen-Information, während 
source:maxspeed sich nur rein auf die Geschwindigkeit beziehen _darf_.

Insofern wäre per zone=DE:urban und zone=DE:rural auch die Unterscheidung 
zwischen innerorts und außerorts möglich,
während source:maxspeed=DE:rural nur die Quelle für die Geschwindigkeit angeben 
_kann_.

Da aber auf mehrspurigen Straßen zwar zone=DE:rural gilt, aber bei maxspeed=100 
eben _nicht_ source:maxspeed=DE:rural,
muss/sollte man diese Information grundsätzlich über getrennte Tags führen - 
auch wenn es auf den ersten Blick doppeltgemoppelt wirkt.

zone:maxspeed=* liegt eigentlich immer innerhalb zone=DE:urban und könnte 
theoretisch mit einem tag ausgedrückt werden - andererseits gibt es aber auch 
noch ganz andere Spezial-Zonen, die evtl. irgendwann mal getaggt werden wollen.

Verquere Tatsachen kann man leider nun mal nicht mit einfachem Tagging 
ausdrücken.

Grüße, Georg


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

Re: [Talk-de] Ankündigung der Entfernung von landuse =farm im Standardstil

[Georg Feddern]

Moin,

Am 24.03.2017 um 10:04 schrieb Stefan Martinek:

Habe jetzt auf leisure=horse_riding geändert. Ich glaub das passt.

Am 24.03.2017 09:41 schrieb "Harald Hartmann" <osm-talk...@haraldhartmann.de


ist es denn eine reiner Pferdehof, der alles fremd bezieht?
Das Eine (leisure=horse_riding) schließt das Andere (landuse=farmyard) 
ja nicht grundsätzlich aus.

1. Welchen landuse hat dann ein Pferdehof - mal ganz grundsätzlich gefragt?
2. Ist ein Pferdehof nicht ganz grundsätzlich auch ein 
landwirtschaftlicher Betrieb?


Vergleiche auch 
https://wiki.openstreetmap.org/wiki/DE:Tag:landuse%3Dfarmyard


Zumindest kenne ich einige Pferdehöfe, die aus einem ursprünglich 
anderen landwirtschaftlichen Betrieb entstanden sind und kommerzielle 
Landwirtschaft parallel oder zumindest zum Eigenbedarf betreiben.

Diese zumindest tagge ich durchaus auch entsprechend parallel.

Grüße, Georg

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

Re: [Talk-us] Talk-us Digest, Vol 108, Issue 10

[Georg Verweyen]

Hello,

did you discuss this on on the list impo...@openstreetmap.org 
<mailto:impo...@openstreetmap.org> ?

I checked the csv data:
there isn’t any geo coordinates
the column "Adress Line 1" has value of addr:housenumber and addr:street
the column „Main Phone“ has the wrong format (xxx) xxx- instead 
+1-xxx-xxx-
the column „Sunday hours“ to „Saturday hours“ has also a wrong format (must be 
changed to 24h format)
the column „Sunday hours“ to „Saturday hours“ must be calculated to one key 
„opening_hours“.
A short search(*) for „lancastergeneralhealth.org 
<http://lancastergeneralhealth.org/>“ shows only a building with this URL 
(https://www.openstreetmap.org/way/18231 
<https://www.openstreetmap.org/way/18231>). This object is part of the list 
(okay: you must change the street name to "West 2nd Avenue“) to find this with 
Nominatim. But see three object with the same address (line 55, 58, 60 with 52 
Peters Road in 175543 Lititz). Can’t find these address in Lititz :( .

Regards

Georg V. (OSM=user_5359)
(*) with over-turbo.eu <http://over-turbo.eu/> : http://overpass-turbo.eu/s/k3e 
<http://overpass-turbo.eu/s/k3e> 
> Am 14.11.2016 um 17:53 schrieb talk-us-requ...@openstreetmap.org:
> 
> Message: 1
> Date: Mon, 14 Nov 2016 11:50:05 -0500
> From: Justin Mosebach <jus...@ydop.com <mailto:jus...@ydop.com>>
> To: impo...@openstreetmap.org <mailto:impo...@openstreetmap.org>, 
> talk-us@openstreetmap.org <mailto:talk-us@openstreetmap.org>
> Subject: [Talk-us] Bulk import for large healthcare system in central
>   PA
> Message-ID:
>   <caof2gh9dzc6xs_pk+-3co1pckpdbc9rb9oc5rado25nauz2...@mail.gmail.com 
> <mailto:caof2gh9dzc6xs_pk+-3co1pckpdbc9rb9oc5rado25nauz2...@mail.gmail.com>>
> Content-Type: text/plain; charset="utf-8"
> 
> Hello,
> 
> We're working with Lancaster General Health which has 105 physical
> locations (not doctors, etc) in Lancaster and Chester counties in
> Pennsylvania.
> 
> I have updated data for all of the locations directly from them, which I've
> attached to this email as a CSV. This data includes the names, addresses,
> phone numbers, URLs, hours, and even descriptions of each location.
> 
> I've never done a bulk import with OSM before, but am excited to learn.
> 
> Can someone let me know what the next step is?
> 
> Thanks!
> 
> Justin Mosebach, *Director of Local Search*

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

Re: [Talk-de] Linksseitiger Radweg / Straßenbegleitend als oneway?

[Georg Feddern]

Am 10.08.2016 um 12:09 schrieb Florian Lohoff:


Du hast das problem mit den Queerungen - Es kann dir passieren das du
zur Kreuzung vor - auf der gegenrichtung zurück an der nächsten Kreuzung
wieder nen U Turn machst damit du 1 Haus weiter links landest.

Die legale Lösung wäre ja "Straße queeren - 20m links - Straße
queeren" um beim linken Nachbarhaus zu landen.

Da aber die getrennt gemappten Radwege eben nicht darstellen ob eine
queerung jederzeit möglich ist und auf welchen Weg kommen dann
halt routing stilblüten bei raus.


Da bleibt nur eins - Auffahrten mappen! ;-) 


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

Re: [Talk-de] place=square

[Georg Feddern]

Moin,

Am 30.06.2016 um 20:02 schrieb Martin Koppenhoefer:
Il giorno 30 giu 2016, alle ore 19:05, Georg Feddern 
<o...@bavarianmallet.de> ha scritto:

Wenn man die Historie betrachtet, war meist der Platz zuerst da, während sich 
die Straßen (Verkehrswege) erst in der 'Neuzeit' herausdominierten - aber 
praktisch immer noch Teil des Platzes sind. Verwaltungsmäßig wird das also eher 
der place sein.

ganz so will ich das nicht stehenlassen, historisch gab es auch durchaus 
Straßen, nicht erst in der Neuzeit. Die bedeutendsten Plätze sind oft dort, wo 
sich 2 oder mehr wichtige Straßen treffen.

vielleicht mißverstanden.
Ich meinte, dass früher die Verkehrswege über den Platz liefen, ohne 
sich allzu deutlich vom Platz abzuheben - der Platz also als Einheit 
dominierte.

Während heute eher die "Straßen" dominieren und der Platz zergliedert ist.

Grüße, Georg

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

Re: [Talk-de] place=square

[Georg Feddern]

Am 29.06.2016 um 13:22 schrieb Tom Pfeifer:


> Und was ist wenn es eine Straße und ein Place gibt die gleich heissen?

Ja, was empfehlen wir insbesondere wenn es den Schlossplatz gibt, der
auch von einem highway=* durchzogen wird, der auch mit Schlossplatz
beschildert ist?

addr:place oder addr:street an die Häuser?

(Als konkretes Beispiel hätte ich den Molkenmarkt in Berlin zu bieten.) 


Technisch gesehen ist das egal, was man dann verwendet.
Wenn man die Historie betrachtet, war meist der Platz zuerst da, während 
sich die Straßen (Verkehrswege) erst in der 'Neuzeit' herausdominierten 
- aber praktisch immer noch Teil des Platzes sind. Verwaltungsmäßig wird 
das also eher der place sein.


Aber ich würde da auch eher pragmatisch nach der Anordnung / dem 
Sichtbaren gehen:
Sind die Häuser um den Platz angeordnet, während die Straße eher im 
'Abseits' liegt => place

Sind die Häuser eher an der Straße angeordnet => street.

Grüße, Georg

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

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

[Georg Feddern]

Am 01.06.2016 um 11:42 schrieb Florian Lohoff:


Das kommt ganz schwer auf das tag an ... Ich komme immer wieder an
service oder unclassifieds vorbei die ein tracktype= tragen. Hat mal
ein Stadtkind als Track eingezeichnet (Weil alles was hinter dem
Ortsschild ist muss ja ein Track sein) und dann hat jemand das mal
korrigiert von track zu unclassified etc und das tracktype= nicht
entfernt. Es gibt tag kombinationen die absolut unsinnig sind die es zu
entfernen gilt und es gibt welche die nur redundant sind.


Es ist nicht ganz eindeutig zu entnehmen, welche Kombinationen Du nun 
für entfernenswürdig hältst - ich vermute aber mal den tracktype bei 
service und unclassified.


Nun, abgesehen davon, das tracktype zeit seines Lebens und aktuell immer 
noch im englischen Wiki als Universaltag beschrieben ist - und die 
Eingrenzung auf track mal wieder ein deutscher Alleingang ist:
Genauso, wie manche track mit grade1 in die Planung einbezogen werden 
können, ist es durchaus sinnvoll, manche service/unclassified wegen 
grade2 oder grade3 auszuschließen - und ja, auch da gibt es so einige 
hier in unserem Lande.
Klar, surface gilt als Allheilmittel - nur hat es leider eine in alle 
Richtungen offene Werteskala ...


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

Re: [Talk-de] Wahlbezirksgrenzen als boundary/administrative

[Georg Feddern]

Am 17.04.2016 um 08:25 schrieb Martin Koppenhoefer:

Il giorno 16 apr 2016, alle ore 16:35, Florian Lohoff  ha scritto:

Dazu sind noch die Wahlbezirke die falsch als boundary=administrative
getagged waren aufgefallen.


ist das überhaupt falsch? Sind Wahlbezirke keine Verwaltungsgrenzen? Ich bin 
mir da überhaupt nicht sicher, tendiere eher dahin dass sie es sind.


Sie haben einen politischen Einfluss auf die Zusammensetzung der 
Verwaltung - sind aber keine Grenzen der Verwaltung (außer sie fallen 
mit diesen zufällig zusammen).
Von daher halte ich - wie Walter - eine Trennung zu political ff. für 
sinnvoll.


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

Re: [Talk-de] admin_level = 8 Stadt, Dorf oder Markt?

[Georg Feddern]

Am 16.04.2016 um 21:35 schrieb Tobias:

ob es sich
bei einem Polygon mit admin_level = 8 um eine Stadt, ein Dorf oder einen
Markt handelt.

Gibt es hierfür in osm einen speziellen key?


Darauf gibt es ein klares Nein - einen eindeutigen key für diese 
wirtschaftliche Unterscheidung gibt es nicht.


Der key place gibt zwar eine gewisse Richtung an - in Deutschland wird 
versucht, die regionale Bedeutung eines place (Markt, Unterzentrum, 
Mittelzentrum) über die abstufung village, town, city herzustellen - 
weicht aber dadurch von der sonst europäischen Einteilung des place nach 
population ab.
Außerdem greift das nur, wenn über die Namensgleichheit eine Zuordnung 
zwischen der Relation und dem place möglich ist  - ist aber eben nicht 
immer mit der admin-Relation in Übereinstimmung zu bringen - und kennt 
keinen Markt.
Ein Markt lässt sich manchmal aus dem Namen herausziehen - aber eben 
auch nicht immer.




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

Re: [Talk-de] 1000-Augen-Prinzip

[Georg Feddern]

Ob 4-Augen oder 1000-Augen - der Begriff bedeutet ja, dass alle die 
_selben_ Daten überprüfen.
Und da bezweifle ich bei aller Euphorie, dass OSM über einen relativ 
niedrigen zweistelligen Wert hinauskommt.


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

Re: [Talk-de] Hartnäckiger JOSM Konflikt durch Relation

[Georg Feddern]

Moin,

Am 10.11.2015 um 19:54 schrieb ratrun:
Wer kann mir erklären wie man die beiden übereinanderliegende Knoten 
www.openstreetmap.org/node/3812945398 und 
www.openstreetmap.org/node/29901243 mit JOSM Version 8969 verbindet?
Ich schaffe es nicht den Konfiktdialog durch die dranhängenden 
Relationen zu überwinden.


äh - sorry - ich war jetzt im Halbschlaf evtl. zu voreilig und habe sie 
mit JOSM 8800 verbunden und hochgeladen.

Falls als Testfall noch vonnöten - einfach reverten.

Das Problem dürfte aber das "wer bleibt erhalten" gewesen sein.
3812945398 musste mit 29901243 verschmolzen werden, damit 29901243 (der 
mit den Relationen) erhalten bleibt.
Umgekehrt klappt es nicht, da ja dann 29901243 verschwindet, 3812945398 
aber nicht automatisch in die Relationen eingebaut werden kann.


Markiert man beide gleichzeitig, versucht JOSM - glaube ich - den 
neueren zu erhalten - also muss einzeln in der richtigen Reihenfolge 
ausgewählt werden.


Gruß
Georg

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

Re: [Talk-de] Mapnik: Dächer über area=yes werden nicht dargestellt.

[Georg Feddern]

Moin,

Am 25.10.2015 um 16:32 schrieb Frank J.:

Am 25.10.2015 um 14:56 schrieb huey212:

Hallo,
ich habe hier mehrere Stellen, an denen Dächer oder Gebäudeteile, die
sich über Plätzen (highway=service oder pedestrian + area=yes) befinden
nicht dargestellt werden.

Hallo,
das war mir auch mal aufgefallen, aber nicht nur "-teile".
Die "Marktkirche" im folgenden Ausschnitt steht eigentlich *auf* dem
Marktplatz. Dann wird sie aber unsichtbar.

Ich habe den "Marktplatz" daher an der Kirche ausgespart.



das haben die Erbauer in der Realität auch getan. ;-)

Anders als bei einem Dach.
Schon mal mit einem "covered=yes" am highway-Bereich versucht? Dafür 
muss man den Bereich natürlich auch explizit abtrennen.


Gruß, Georg

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

Re: [Talk-de] ÖPNV-Karte / Darstellung historischer Bahnstrecke

[Georg Feddern]

Moin,

als Hinweis:
Diese ist als route-Relation mit den (hier wesentlichen) Eigenschaften
- route=tram
- historic=yes
erfasst.

Das ist der Typus "Ich bin eine - aber eigentlich doch nicht".
Da müsste man ansetzen - aber wie, mögen bitte Diejenigen entscheiden, 
die sich damit im Detail auskennen und beschäftigen (aktuell und 
historisch).

Möglich wäre u. a. "route=historic:tram"

Gruß
Georg


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

Re: [Talk-de] Abgerissene Gebäude

[Georg Feddern]

Moin,

Am 03.09.2015 um 11:54 schrieb Martin Koppenhoefer:

Am 31.08.2015 um 07:14 schrieb Michael Reichert <naka...@gmx.net>:

Da building=* aber eine unbeschränkte Vielfalt an
Values hat [1], kann er nie alle Values unterstützen, ohne einige zu
vergessen. Deshalb tun viele Datennutzer auch einfach alles rendern, was
building=* als Key hat.


Technisch gesehen können sie das ja auch - sie müssen ja nur =no als 
(einmalige) Ausnahme berücksichtigen, aber ...




irgendwas=no ist Standard in osm, ich finde das OK um zu sagen: kein building


Als Eigenschaft eines Objektes - also als Subtag - ja, da ist es Standard.
Aber als Objekt selbst, also als Haupttag?

Zumal es doch wohl ganz einfach ist, das building=no durch ein 
note=<Begründung> zu ersetzen.
Jeder Mapper sollte doch sehen, wenn da bereits ein way vorhanden ist - 
und nicht mehr blindlings umtaggen.


Gruß
Georg

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

Re: [Talk-de] highway=trunk - Höhenfreie zweistreifige Straße

[Georg Feddern]

Moin,

Am 19.05.2015 um 00:08 schrieb 715371:


Am 15.05.2015 um 18:34 schrieb Florian Lohoff:

On Thu, May 14, 2015 at 07:28:19PM +0200, 715371 wrote:


So wie ich dich verstehe, möchtest du da Überholmöglichkeiten sehen,
ohne dass man in den Gegegenverkehr fährt, oder?

Nicht zwangsläufig - Es gibt in meinen Augen auch 2 Spurige Trunks -
Lange z.b. die B50 bei Simmern. Die müsste mittlerweile auch 4 Spurig
sein.

Und diese?
https://www.openstreetmap.org/way/46988406/history#map=18/52.49357/7.32926


ich hätte die gesamte Strecke als primary belassen.
Mir fehlt da die (verkehrsrechtliche) Trennung des Gegenverkehrs - und 
eine übergeordnete Bedeutung über andere primary ist in dem Bereich auch 
nicht gegeben.



D.h. 2+1 wäre OK, aber komplett höhen-/kreuzungsfrei alleine würde dir
nicht reichen. Also eine Mittellinie, die nicht durchgezogen ist, ist
für highway=trunk nicht OK.

Oder soll das ganze auf so etwas hinauslaufen, dass man sich anschaut,
ob noch mehr Sachen erfüllt sind und dann eher aus dem Bauch, aber
relativ frei entscheiden?

Relativ frei würde ich nicht sagen. Aber sowas wie

- Kreuzungsfrei
- Mehrspurig je Fahrtrichtung
- Mittelleitplanke/Doppelte Mittellinie
- Kraftfahrtstraße

Wenn 3 von 4 Kriterien erfüllt sind ist es ein Trunk - so mal ins
unreine Gedacht.

IMO: Eine durchgezogene Mittellinie wäre statt doppelter auch OK.
Allerdings wäre dann die Frage, ob man weitere Kriterien brauch wie
mindestens zwei Anschlussstellen.

Für das 2+1-System würde man Mehrspurig je Fahrtrichtung auch bereits
ein wenig aufweichen. Eingeschränkt auf Deutschland würde derzeit
kreuzungsfrei die wichtigste Eigenschaft sein.


Nicht nur die wichtigste - für mich ist sie zwingend erforderlich.
Von daher gehören für mich zusätzlich 2 der 3 anderen Kriterien erfüllt und


trunks wie diese

http://www.openstreetmap.org/#map=19/52.61961/8.36607

sind in Deutschland ja zur Zeit die Ausnahme.


und für mich ein No-Go.

Georg

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

Re: [Talk-de] highway=trunk - Höhenfreie zweistreifige Straße

[Georg Feddern]

Moin,

Am 19.05.2015 um 13:56 schrieb 715371:

Am 19.05.2015 um 08:37 schrieb Georg Feddern:

eine übergeordnete Bedeutung über andere primary ist in dem Bereich auch
nicht gegeben.

Die Straße ist schon ziemlich gut ausgebaut. Was ist an der Straße
gegenüber z.B. dieser hier

https://www.openstreetmap.org/way/246885609

nicht übergeordnet?


Dass die beiden Strecken 88 km auseinanderliegen ...
Siehe 
https://www.openstreetmap.org/way/46988406/history#map=18/52.49357/7.32926


In diesem Bereich meint ganz konkret von Anfang bis Ende der als trunk 
getaggten Strecke und ihren regionalen Bezug in der Verkehrsführung.
Ein überregionaler Bezug ist ja eh nicht gegeben, da die Strecke 
überregional ja eh nur mit primary angebunden ist.
Nur dann wurde ich diese Strecke ausnahmsweise mal als trunk statt als 
primary taggen trotz in meinen Augen nicht ausreichender Kriterien.
Das sehe ich dort in der Region aber nicht gegeben - primary reicht 
absolut als übergeordnete Einstufung.



Relativ frei würde ich nicht sagen. Aber sowas wie

- Kreuzungsfrei
- Mehrspurig je Fahrtrichtung
- Mittelleitplanke/Doppelte Mittellinie
- Kraftfahrtstraße


IMO: Eine durchgezogene Mittellinie wäre statt doppelter auch OK.
[...]
Eingeschränkt auf Deutschland würde derzeit
kreuzungsfrei die wichtigste Eigenschaft sein.

Nicht nur die wichtigste - für mich ist sie zwingend erforderlich.

+1 Das wäre für Deutschland aus meiner Sicht eine sinnvolle Regelung.


Von daher gehören für mich zusätzlich 2 der 3 anderen Kriterien erfüllt und

Weil Doppellinien laut VwV-StVO nur bei mehr als lanes=2 genutzt werden,
müsste man die Liste oben bereinigen, weil prinzipiell sonst nur 1 oder
3 Kriterien erfüllt werden können.

(siehe
http://www.verwaltungsvorschriften-im-internet.de/bsvwvbund_26012001_S3236420014.htm
zu Zeichen 295)

Gibt es denn ansonsten einen Unterschied zwischen doppelter und
einfacher Linie? Die doppelte scheint ja genauso wie die einfache unter
Zeichen 295 erfasst zu sein.



Ich kenne als Unterschied nur die Regelung, dass die Doppellinie von 
keinem Fahrzeugteil (z. B. Rückspiegel) überragt werden darf.
Insofern hatte ich das IMO: Eine durchgezogene Mittellinie wäre statt 
doppelter auch OK gedanklich bereits mit einbezogen.


Gruß
Georg

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

Re: [Talk-de] nominatim ortsangaben

[Georg Feddern]

Moin,

Am 09.05.2015 um 19:24 schrieb Sarah Hoffmann:

In OSM wäre es schön wenn wir uns auf ein einheitliches Tagging
für solche Eingemeindungnen einigen könnten. Ich habe schon
alles gesehen für das Tagging der place-Nodes: village, hamlet,
suburg, isolated_dwelling. Das macht es schwierig, einigermassen
allgemeingültige Regeln für die Berechnung der Adressen aufzustellen.


das Problem ergibt sich aber aus der Realität:
(Getrennte) Siedlungsplätze sind nunmal unterschiedlich in der Größe 
(village, hamlet, isolated_dwelling) und sollen ja auch entsprechend 
ihrer Größe / Population getaggt werden. Und sie können nunmal allesamt 
Ortsteile einer Gemeinde sein - ob nun seit jeher oder eben durch 
Eingemeindung.


suburb wiederum ist ja keine Größenangabe sondern eher eine 
Zugehörigkeitsangabe - und ist laut Wiki ja eigentlich für 
ineinanderübergehende Bebauung gedacht.



Langfristig ist die Definition von Flächen auf jeden Fall die
bessere Lösung, weil die Auswertung der Nodes immer ungenau ist.
Ich persönlich beführtworte da ein doppeltes Tagging: Relationen
für die Stadtfläche und einen place-Node für die Markierung des
Ortskerns. Aber es gibt auch Gegner, die das als Redundanz ansehen.


Ich zumindest nicht. ;-)
Relationen sind aber bei vielen kleineren Siedlungsplätzen ziemlich 
schwere Geschütze, zumal oft keine echten Grenzlinien existieren.
Willkürliche place-Polygone würden oft ausreichen - und für die 
Plazierung des Labels bei diesen kleinen Flächen auch oft genügen.


Andererseits sollte man vielleicht die derzeitige Wiki-Empfehlung, dass 
suburb am besten durch einen node getaggt wird, mal überdenken - und 
überarbeiten?



Ausserdem gibt es stimmen, die sagen, dass addr:*-Tags
nicht an die Strasse gehören, weil Strassen keine Adressen haben.


Hier allerdings +1.
Zudem soll es Straßen geben, die links und rechts unterschiedliche 
Ortsteile haben (Hörensagen ohne konkretes Beispiel).


Gruß
Georg

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

Re: [Talk-de] OSRM Routing Problem

[Georg Feddern]

Moin,

Am 03.05.2015 um 15:01 schrieb Bernhard Weiskopf:

Wenn ich die Trunk Ausfahrt Mannheim-Vogelstang/Viernheim West nehmen will,
schickt mich OSRM einen Umweg durch die schmale Anliegerstraße Waldeckweg,
statt über die kurze trunk_link.

Bei https://www.openstreetmap.org/ habe ich über den Pfeil zur
Routenberechnung folgende Strecke eingegeben:

von: Viernheimer Kreuz
nach: Kamenzer Straße 1, Mannheim
mittels: Auto (OSRM)

Ich vermute, dass OSRM die Abbiegerelation „nur geradeaus“ am Treffpunkt der
beiden Einbahn-trunk-links zu einer gemeinsamen
http://osm.org/go/0DwWW5DT7?m= falsch interpretiert.



Genau diagonal gegenüber (Ausfahrt Havellandstraße) verhält es sich anders:
Dort routet OSRM über so eine only-straight-on-restriction hinaus auf 
das gemeiname trunk-Stück.


ABER:
Setzt man dort das Ziel über die nächste Fahrspur-Trennung hinaus auf 
die Einbahn-trunk-Auffahrt zur Magdeburger Straße,
will OSRM sogar den großen Umweg (hintere Ausfahrt zur Kreuzung 
Birkenauer Straße), wieder zurück und dann Hart rechts gegen die 
Einbahn-Auffahrt zurück routen.


Gruß
Georg

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

Re: [Talk-de] Schreibfehler in deutschem Copyright-Text

[Georg Feddern]

Moin,

da wir ja alle vier immer von der gleichen Seite

www.openstreetmap.org/copyright

reden:
Kann es sein, dass je nach Browsereinstellung/-sprache bei Dir der 
englische Text angezeigt wird?


Gruß
Georg

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

Re: [Talk-de] Schreibfehler in deutschem Copyright-Text

[Georg Feddern]

Am 15.04.2015 um 19:24 schrieb Volker Schmidt:

Der Fehler hat sich auch schön verbreitet: auf Anhieb 275 Ergebnisse bei
Google.

Auf welcher Seite ist der Original-Fehler?
(Du hast die Ziel-Seite angegeben, nicht die mit dem fehlerhaften link)


Wie Mark es korrekt schreibt:
Die Zielseite enthält den Schreibfehler im _Text_ :

Zitat:
Du kannst dies tun, indem du auf www.openstretmap.org/copyright 
http://www.openstreetmap.org/copyright verlinkst.


Der dahinterliegende Link ist allerdings korrekt.

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

Re: [Talk-de] Umfrageplattform freigegeben

[Georg Feddern]

Hallo Harald,

habe gerade eben mal testweise an einer Umfrage teilgenommen.
Bei der Anzeige der Antwort-Charts fällt mir auf, das die beiden Charts 
die Farben unterschiedlich verwenden / beschriften.


Test: maxspeed-Umfrage von Chenshi

Auswertung pro Antwort: ja=grau, nein=grün, Enthaltung=blau
Absolute Zahl pro Mapperty: ja=blau, nein=grün, Enthaltung=grau

Das irritiert zumindest mich - oder ist es evtl. auch verwurschtelt?

Gruß
Georg


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

Re: [Talk-de] information=guidepost auf eine kreuzungsnode

[Georg Feddern]

Am 20.03.2015 um 12:10 schrieb Kurt Waldhans:
Es gibt wohl keine Chance, hier auf cycling=yes in Analogie zu 
hiking=yes auszuweichen?


+1
Ansonsten müsste man das guidepost:* konsequent auch dort anwenden.

Georg

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

Re: [Talk-de] information=guidepost auf eine kreuzungsnode

[Georg Feddern]

Am 20.03.2015 um 12:24 schrieb Martin Koppenhoefer:

Am 20. März 2015 um 12:10 schrieb Kurt Waldhans k...@waldhans.com:


Es gibt wohl keine Chance, hier auf cycling=yes in Analogie zu
hiking=yes auszuweichen?

mit dem guidepost: prefix hätte man halt den Vorteil, dass wirklich klar
ist, worauf sich der tag bezieht. cycling und bicycle nimmt sich da
nicht viel.


+1 - und ich ziehe meine voreilige gegenteilige Zustimmung zurück - es 
gibt ja auch noch foot=* ...


Georg

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

Re: [Talk-de] Strittige Adressen / Gemeindegrenzen

[Georg Feddern]

Moin,

neugierig wie ich nun mal bin, hab ich mir die aktuelle Situation aus 
der Ferne angeschaut:


Mit Datenstand heute 10:56 Uhr sind doch beide Informationen immer noch 
da - die offizielle Adresse am Gebäude und die inoffizielle Adresse am 
node auf der Grenze.

Diesen Stand halte ich auch für eine gelungene Lösung.

Gruß
Georg


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

Re: [Talk-de] Wehr - Schleuse

[Georg Feddern]

Am 05.01.2015 um 22:33 schrieb Helmut Kauer:

Griaß eich,
schon länger suche ich nach einer Möglichkeit, Schleusen an Mühlbächen zu
mappen. Also keine Schleusen für Schiffe, sondern die Schieber zum
Wasserstand regulieren, also die Abflussmenge in einem Mühlbach / Kanal.
Habt Ihr da einen Tip?

Gruß Helmut



Moin,

siehe http://wiki.openstreetmap.org/wiki/Tag:waterway%3Dweir

Gruß
Georg

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

Re: [Talk-de] Suche Ansprechpartner und Lösungsvorschlag (elotse)

[Georg Verweyen]

Hallo,

Ich habe mit den Kollege -wie berichtet- ebenfalls schon Kontakt und habe 
bereits am 26.10 einen Ansatz in Richtung meshing of databases vorgeschlagen. 
 Ich stelle Joachim den Mailwechsel zur Verfügung, denn von dem 
Network-Vorschlag  halte ich persönlich für nicht optimal (Änderung eines 
Verwendungszweckes eines Tag's, müsste auch erst ausführlich diskutiert werden).

Aber es ist doch erstaunlich, welche Emotionen entstehen. Bitte lasst uns bei 
einer sachlichen Diskussion bleiben! 

Übrigens ist meines Erachten der Meshing Ansatz langsam reif, produktiv 
getestet zu werden. Die Toolkette wie overpass-API läßt inzwischen eine 
zeitnahe Kontrolle des Datenbestandes zu, ohne das man 2GB komprimierte Daten 
für das Gebiet Deutschland von der Geofabrik runterladen muss. Aber das wäre 
ein separater Diskussionsstrang.

Mit freundlichen Grüßen 

Georg V. (OSM=user_5359)
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Suche Ansprechpartner und Lösungsvorschlag (elotse)

[Georg Verweyen]

Hallo,

Ich habe den User CornyJoe schon wegen den ebusiness-Lotse Tags angeschrieben 
und ihn auf die prinzipiellen Problematiken hingewiesen. Die Kollegen scheinen 
hier schon eine Webapplikation im Petto zu haben und wollen deshalb zu 
Demozwecken die Werte eintragen. Ich hätte mir sehr gewünscht, dass die 
Kollegen früher mit der Kommunity gesprochen hätten.

Mit freundlichen Grüßen Georg V. (OSM=user_5359)

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

Re: [Talk-de] addr:state massen remove in DE

[Georg Feddern]

Am 03.09.2014 17:03, schrieb Florian Lohoff:

On Wed, Sep 03, 2014 at 04:36:10PM +0200, Michael Reichert wrote:

[1] http://forum.openstreetmap.org/viewtopic.php?pid=447693#p447693

Ich bin für einen Revert der Changesets. Nur einen Tag Diskussion, bevor
man zur Tat schreitet, kann man IMHO mit einer fehlenden Diskussion
gleichsetzen, insbesondere wenn man sie auch noch in einem Thread
versteckt.

Mir gehts daraum das dort informationen drin sind die ja vielleicht fuer
MICH oder 80% der anderen nicht von bedeutung sind. Sie schaden aber nicht.
Entfernen ist Informationsverlust also lehne ich das erstmal ab.

Flo


mal ehrlich:
addr:state ist innerhalb Deutschlands so unsinnig wie ein Kropf.
Es wird postalisch in keinster Weise verwendet - und die vorhandene 
Information ließe sich m. W. jederzeit über addr:postcode oder (siehe 
GIS-Datenbank) über die Bundesland-Relation herleiten.


Solange er seine eigenen (massenweisen) Ergänzungen (in Berlin) 
massenweise entfernt, habe ich überhaupt kein Problem damit.
Warum er jetzt aber wieder gleich bundesweit zuschlägt ... nun gut, mich 
stört es ehrlich gesagt nicht sonderlich.
Das halte ich höchsten moralisch für revert-fähig - inhaltlich 
jedenfalls nicht.


Gruß
Georg


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

Re: [Talk-de] Wo Google besser ist als OSM

[Georg Feddern]

Moin,

Am 31.08.2014 23:54, schrieb Stephan Knauss:

On 31.08.2014 22:55, simson.gert...@gmail.com wrote:
http://compare.osm-tools.org/?zoom=15lat=50.79866lon=12.95761layers=BT00F 


An dieser Stelle sehe ich mehrere dicke rote Markierungen. Dies sind die
Gornauer Straße und die Jägerschlößchenstraße.  Bei diesem Vergleich
http://sautter.com/map/?zoom=16lat=50.79804lon=12.95035layers=B000TFFF 


sieht man, dass die Straßen von google und osm aber eigentlich sehr gut
übereinander liegen. Wo ist da der Wurm drin?


Es werden Hauptstraßen ausgewertet. Google denkt hier, dass es eine 
Hauptstraße sein sollte.


In OSM ist sie als Nebenstraße (highway=residential) gemappt.

Details zur Technik habe ich hier beschrieben:
http://www.technologyblog.de/2014/08/wo-fehlen-bei-openstreetmap-noch-daten/ 



Ich denke in Deutschland wirst du dich schwer tun noch fehlende 
Hauptstraßen zu finden.


das stimmt zwar - aber mir hilft es dabei, OSM-residentials zu finden,
die aufgrund ihrer (Überland-)Verbindungsfunktion besser als 
unclassified getaggt werden sollten.

Schönes Tool!

Georg

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

Re: [Talk-de] Wo Google besser ist als OSM

[Georg Feddern]

Moin,

Am 01.09.2014 15:45, schrieb Volker Schmidt:

das stimmt zwar - aber mir hilft es dabei, OSM-residentials zu finden,
die aufgrund ihrer (Überland-)Verbindungsfunktion besser als unclassified
getaggt werden sollten.


Ist das korrekt? Ich hatte das immer so verstanden (und auch so
angewendet), dass residential und unclassified die unterste
Strassenkategorie sind, wobei der einzige Unterschied ist, das residential
in Wohngebieten und unclassified ausserhalb verwendet wird.


de: highway=unclassified sollte möglichst bis zur nächsten 
höherklassigen Straße durchgezogen werden, auch innerorts.
en: In an urban context, unclassified roads may be [...]. They are 
commonly found in industrial, retail, or commercial areas, or linking to 
residential neighbourhoods.


Stichwort Durchgangsverkehr.

Gruß
Georg

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

Re: [Talk-de] Alltagsassistentin - Betreuungsdienst

[Georg Feddern]

Moin,

Am 05.06.2014 21:33, schrieb nicolaus1977:

Ich habe so recht gar keine Ahnung in welchen Bereich ich den
Betreuungsdienst stecken soll - healthcare?!?


Siehe Wiki:
social_facility (outreach)

Gruß
Georg

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

Re: [Talk-de] Steinfelder Waschkeller == Lavoir?

[Georg Feddern]

Moin,

wenn man einen französischen Begriff, der es zumindest nicht ins Oxford 
Dictionary geschafft hat und somit m. E. nicht in den englischen 
Sprachgebrauch übernommen wurde, als Wert verwenden möchte.
Ich halte historic=laundry für OSM-konformer - allerdings stimmt taginfo 
mit den Füßen anders ab ...


Gruß
Georg

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

Re: [Talk-de] Privat oder nicht von der öffentlichen Verwaltung benannte Wege, was: Wegenamen in Kleingärten

[Georg Feddern]

Moin,

Am 19.05.2014 18:05, schrieb Martin Koppenhoefer:

Am 19. Mai 2014 17:30 schrieb Florian Lohoff f...@zz.de:


Der Weg ist aber Privatgrund wie mir die Stadt bestätigt hat.



Gemeinschaftseigentum oder Grunddienstbarkeit oder Nießbrauch? Oder nochmal
anders?


also bei uns wurde die Straße ursprünglich als Gemeinde-/Wohnstraße geplant,
vom Gemeinderat benannt, dieser Name dem Amt mitgeteilt, entsprechende 
Adressen vergeben
- und anschließend durfte dann doch jeder Grundstücks-Eigentümer bzw. 
auch Eigentumwohnungsbesitzer seinen Anteil am Gemeinschaftseigentum 
dieser Sackgasse erwerben ...


Gruß
Georg

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

Re: [Talk-de] JOSM Tag-Template ??

[Georg Feddern]

Moin,

Am 12.05.2014 23:01, schrieb Johannes:

Keine Idee?


keine, die Dir vermutlich wirklich weiterhelfen wird ...

A) JOSM Sourcecode anpassen und compilieren - dann behält man die 
Vorbelegung mit den zuletzt eingegebenen Werten.
B) Eigenes Preset schreiben - dann hat man aber keine Vorbelegung mit 
den zuletzt eingegebenen Werten.
C) One-Click-Preset mit den verschiedenen leveln anlegen und in die 
Toolbar einhängen.


Gruß
Georg

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

Re: [Talk-de] Kann es sein, dass seit 1.Mai keine neuen Beitraege erstellt wurden?

[Georg Feddern]

Moin,

Am 05.05.2014 11:48, schrieb hike39:
Sorry, aber ich habe festgestellt, dass seit dem ersten Mai keine 
neuen Beitraege bei mir rein kommen. Das kann ich nicht glauben.


ja, meine ganze Verwandschaft hat sich auch gewundert - bis ich Ihnen 
die Zugänge auf SSL umgestellt habe, nachdem viele (alle?) 
Email-Provider es jetzt voraussetzen.


Gruß
Georg

PS: Hoffe Du liest das jetzt auch über einen anderen Weg (Archiv, GMANE 
o.ä.) ... und wartest nicht auf die Email ...


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

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

[Georg Feddern]

Moin,

Am 03.04.2014 09:47, schrieb Manuel Reimer:

Was mich daran stört: Ich hätte gerne die normale Straßenlinie erhalten.


prinzipiell gebe ich Dir recht - aber bei dieser einfachen 
langgestreckten Version macht das kaum einen Unterschied.



Ist highway=pedestrian auf die Fläche überhaupt korrekt?


Gemäß (text)googlen ist es eine Fußgängerzone - und die darf bei OSM 
auch als Fläche getaggt werden.



Darf die Fläche an die zuführenden Straßen angeschlossen sein?


Klar - wie soll man sonst darüber routen?


Kann ich den Wegverlauf
einfach als weiteres highway=pedestrian in Form einer Linie oben
drüberlegen?


Ist derzeit zumindest bei stark von der linearen Form abweichenden 
Flächen wohl geduldete Praxis.



  Wo gehört dann der name dran?


Ich würde ihn dann nur an die Linie setzen.

Gruß
Georg


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

Re: [Talk-de] Postalische Bezeichnung (addr:place -)

[Georg Feddern]

Moin,

Am 30.03.2014 16:16, schrieb fly:

On 30.03.2014 07:21, Georg Feddern wrote:

hmm, das sehe ich aus Deiner Beschreibung heraus eher anders - es ist
doch ein benannter Wohnplatz (place=isolated_dwelling), oder?

Nein, es gibt keinen place= mit dem Namen Außenbezirk. Es ist nur ein
postalischer Zusatz, der anstatt Straße verwendet wird. Eventuell haben
die Höfe auch noch einen eigenen Namen, welcher aber nicht in die
Adresse aufgenommen wurde.
Somit ist addr:place wohl eher fehl am Platz.


autsch - Außenbezirk ist wörtlich zu nehmen?
Ich dachte, es wäre ein Platzhalter - und so begab ich Esel mich aufs 
Glatteis ...


Sorry, bitte nicht persönlich nehmen - aber bei solch unglaublichen 
Adressen ist mein Mißtrauen und meine Neugierde geweckt.
Wo stammt die Information her, was sagen die Bewohner / Betreiber , kann 
man unbemerkt die Post filzen ;-) - oder den Postboten einfach mal 
freundlich fragen ...


Die spärlichen Internet-Hinweise zur Gaststätte sind ja ziemlich 
unterschiedlich, sowohl was Name (... am Elzwehr - veraltet und 
geändert?) wie Adress-Angabe (Oberes Grün 6 - wenn die überhaupt stimmt, 
ist das dann der Weg-Name oder evtl. eine Flur(place)-Bezeichnung ?) 
betrifft ...


Nichts für ungut, aber ich hätte - wenn überhaupt - trotzdem vorerst 
addr:place als Platzhalter genommen.

Straße ist es wohl mit Sicherheit nicht - und daher das kleinere Übel. ;-)

Gruß
Georg

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

Re: [Talk-de] maxheight=none

[Georg Feddern]

Moin,

Am 30.03.2014 16:53, schrieb fly:

Im Unterschied zu maxspeed=none finde ich bei maxheight den Wert none
nicht passend.
[...]
Wie seht Ihr das ?


muss man wohl im OSM-historischen Kontext sehen:
Damals im Forum kam das Problem auf, dass die Brummi-Karte Höhen braucht,
die maxheight-Karte das Taggen pushen wollte und zwar fehlende Angaben 
anmeckern kann - aber nicht zwischen kein Schild und unbekannt 
unterscheiden kann.


Es wurde also ein QS-Tag gesucht, damit die Mapper nicht immer wieder 
die gleichen Orte überprüfen müssen.
Damals habe ich selbst das von maxspeed bekannte none befürwortet - in 
der Intention kein Schild vorhanden ... und in Applikationen als 
String-define mehrfach verwendbar ...

none entspricht definitiv dem default.

Eine Zahlenangabe mit weiterem zuätzlichen 
Ist-gesetzlicher-default-Tag ist in meinen Augen eine doppelte 
Tote-Luft-Blähung:
Ein gesetzliches Fahrzeug braucht die Zahlenangabe nicht, ein höheres 
Fahrzeug interessiert sie _hier_ nicht.

(maxspeed dagegen findet direkte praktische Verwendung.)

Fazit:
default wäre zugegebenermaßen semantisch der bessere Begriff.
Da die Angabe in meinen Augen eh nur QS-Zwecken dient und sonst 
keinerlei _praktische_ Bedeutung hat, ist der Bezeichner mir zumindest 
wurscht.
Aber vermutlich sollte man es einmal durchziehen, damit das Murmeltier - 
das es gar nicht betrifft - nicht täglich grüßt ...


Gruß
Georg


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

Re: [Talk-de] Postalische Bezeichnung (addr:place -)

[Georg Feddern]

Moin,

Am 31.03.2014 12:42, schrieb Martin Koppenhoefer:

Wo wir schon beim Thema sind, hätte auch nochmal eine Frage zu
Adressvarianten, hier gibt es gelegentlich im Aussenbereich Adressen, die
zwar einen Straßennamen haben, aber keine Hausnummer sondern eine
km-Angabe, z.B: Strada Statale 7 (also in etwa B7 auf deutsch), km 12,200
Wo würdet Ihr diese km-Angabe reinnehmen, als Hausnummer oder in einen
eigenen tag, oder alles in addr:full?


mit oder ohne km ?
Aber das ist ja nur ein fixer Bestandteil - und wir kennen ja auch 
Buchstaben in Hausnummer.

Ansonsten ist es ja schon eine rechte Hausnummer - finde ich jedenfalls.
Und eindeutig zudem - halt, wie machen die das, wenn auf beiden Seiten 
... ;-)


Gruß
Georg

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

Re: [Talk-de] Postalische Bezeichnung (addr:place -)

[Georg Feddern]

Moin,

Am 28.03.2014 18:22, schrieb fly:

wie sieht das denn so auf dem Land und
im hohen Norden aus ? Errinnere mich, dass dort auch Aussiedlerhof und
ähnliches verwendet wird.


ja, hier gibt es auch Außensiedlungen zuhauf ohne Straßennamen.
Allerdings gibt es auch eine leichte Tendenz, dass Straßennamen und 
Hausnummern eingeführt werden.
Die alten Postboten sterben halt aus - und wie soll man mit dem Navi 
sonst das eine Haus von den verteilten fünf finden? ;-)


Schönes Beispiel ist in meinen Augen
http://www.openstreetmap.org/#map=18/54.30798/10.32640

Bis vor wenigen Jahren gab es dort weder Hausnummern noch Straßennamen, 
nur den Siedlungsplatz Neuenkrug.
Dann hat die nordöstliche Gemeinde Schlesen Straßennamen und Hausnummern 
eingeführt.
Bei der südwestlichen Gemeinde Dobersdorf ist es aber beim addr:place 
geblieben - dort ist es ja auch eindeutig, da nur ein Grundstück.



Vielleicht doch eher auf tagging@osm nach fragen.


Kann man machen - ich habe mich allerdings mit addr:place arrangiert.


Und es kann ja eh nur entweder addr:street oder addr:place angegeben
werden - beides gleichzeitig geht logisch nicht. (*)

Ich habe mal addr:street benutzt, da es ja kein place ist und noch am
nächsten kommt.


hmm, das sehe ich aus Deiner Beschreibung heraus eher anders - es ist 
doch ein benannter Wohnplatz (place=isolated_dwelling), oder?


Gruß
Georg

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

Re: [Talk-de] Postalische Bezeichnung (addr:place -)

[Georg Feddern]

Moin,

Am 27.03.2014 21:51, schrieb fly:

Habe hier mehrere Hof ohne Straßennamen anstelle wird Außenbezirk
verwendet. Welchen Tag soll ich nun für Außenbezirk verwenden ?

addr:street
addr:place

Die Adresse laute also:

Name
Außenbezirk Hausnummer
PLZ Ort


Eigentlich ist das ein hausgemachtes OSM-Problem,
denn eigentlich ist addr:* ja nur ein Platzhalter für ein Feld in der 
postalischen Adresse.

Hier: das Feld, wo bei Dir Außenbezirk steht und sonst Straße.

Das man bei OSM dafür _zwei_ Tags benötigt, resultiert doch nur aus der 
hausgemachten Verknüpfung Suche dazu eine passende Straße gleichen 
Namens in der Nähe.


Dabei passt das eh nur, wenn ein Router überhaupt eine passende Straße 
gleichen Namens findet.
Wird nämlich der place angegeben, kann er zwar den place suchen - muss 
aber trotzdem eh die nächstgelegene Straße beliebigen Namens oder 
namenlos zum Routen nutzen.


Somit hilft das praktisch gar nicht weiter - es befriedigt nur die 
menschliche Logik da steht addr:street, also muss es eine Straße sein.
Stünde da ein anderer, allgemeiner Adress-Platzhalter 
addr:street_or_place (wie es in der postalischen Adresse zur Anwendung 
kommt) gäbe es das Problem überhaupt gar nicht erst ...


Und es kann ja eh nur entweder addr:street oder addr:place angegeben 
werden - beides gleichzeitig geht logisch nicht. (*)


Gruß
Georg

(*) addr:place nicht mit Ortsteil (addr:suburb) verwechseln!
siehe
Name
Ortsteil
Straße Hausnummer
PLZ Gemeinde


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

Re: [Talk-de] Wo wird OSM in 3D regelmäßig gerendert?

[Georg Feddern]

Moin,

Am 07.03.2014 17:19, schrieb Manuel Reimer:

Hallo,

gibt es einen Dienst bei dem man OSM in 3D halbwegs regelmäßig 
aktualisiert betrachten kann?

[...]
Mir schwebt da sowas wie die Karte hier vor:
http://maps.osm2world.org/

Nur sollte regelmäßiger gerendert werden. Zum Beispiel tagesaktuell.


mit der lokalen Version von osm2world klappt das noch aktueller - 
sozusagen on demand.

Da kann man dann auch vor dem Hochladen prüfen, ob es überhaupt hinhaut.

http://osm2world.org/download/

Gruß
Georg

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

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

[Georg Feddern]

Am 28.02.2014 01:24, schrieb Martin Koppenhoefer:



Am 28/feb/2014 um 01:02 schrieb Frederik Ramm frede...@remote.org:

und das gilt im Kleinen auch in der Innenstadt - gehört die
Grasfläche jetzt noch zum Platz oder nicht, und so weiter.


und wenn sie dazugehört, wie taggt man das dann?

Ich habe bei innerstädtischen Plätzen eigentlich nie oder nur höchst selten ein 
Problem damit, die Grenzen zu erkennen [...] einen spezifischen Tag für diese 
Art Toponym haben wir aber bisher nicht entwickelt abseits von befestigten 
(Verkehrs-)Flächen, könnte man mal machen.


mal ganz dreist spekuliert:
Im Prinzip handelt es doch 'nur' um einen benannten Ort resp. ein 
benanntes Gebiet ...
Da einen spezifischen Tag für Platz zu finden, kann einfach 
(Definition) oder schwierig (Konsens) sein - je wie man will.


Stellt sich die Frage, ob man place=locality dafür verwenden will.
Ebenso wie place=neighbourhood für die Mannheimer Quadrate - so denn 
dieser Tag dort nicht bereits für übergreifende Gebiete verwendet wird.

Und ob man dann diese Tags auch entsprechend bei Mapnik rendern möchte

Was allerdings auch einer Flugverbotszone Tür und Tor öffnen würde. :-(

Georg

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

Re: [Talk-de] Access-Tags

[Georg Feddern]

Moin,

Am 27.02.2014 15:12, schrieb Martin Koppenhoefer:



Am 27/feb/2014 um 12:56 schrieb Fabian Schmidt 
fschm...@informatik.uni-leipzig.de:

Ich gehe davon aus, dass der Default gilt


echte Daten (d.h. vor Ort vom Mapper erhobene und dann eingetragene 
Informationen) sind besser als ein sich verlassen auf vermeintliche Defaults.


auch wenn ich selbst aufgrund der unterschiedlichen Sicht von defaults 
(siehe track) lieber explizite access-Werte eintrage,

so darf doch die Problematik nicht außer Acht gelassen werden:
Explizit gesetzte 'defaults' (also allgemeine gesetzliche Vorgaben) 
müssen auch explizit angepasst werden, falls sie mal geändert werden.
Insofern sind dort eigentlich auch zusätzliche source-Tags nötig, wie 
bei den default maxspeed.



  Klar, jeder kann eintragen was er will, aber Sachen rauszulöschen, die zwar 
stimmen aber vom einzelnen Mapper als redundant wg. defaults angesehen werden, 
ist m.E. dagegen nicht ok


Das ist zumindest ein Gebot der Höflichkeit, solange da keine echte 
Einigkeit aufgrund von 'Standards' besteht - und das wird ja oft genug 
kontrovers betrachtet.


Das Problem sind ja nicht default- Werte an sich (1) - sondern die 
kontroverse Sicht der Mapper und Anwender.


Georg

(1) Abgesehen von der Mapper-Erfassungproblematik: 'Fehlt hier noch was?'

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

Re: [Talk-de] Planetarium

[Georg Feddern]

Moin,

Am 23.02.2014 00:03, schrieb Wolfgang Hinsch:

Am Samstag, den 22.02.2014, 21:07 +0100 schrieb Martin Koppenhoefer:

ich finde nicht, dass Planetarium ins Museums-schema passt. Typologisch ist
das noch eher ein Kino oder gar ein Theater, als ein Museum, ich würde aber
für einen dedizierten tag plädieren.


  -1

tourism=museum
museum=planetarium

passt voll ins Museum. Theater dagegen überhaupt nicht. Planetarium ist
ein technisches Museum, in dem ganz überwiegend der Stand des Wissens
von kosmischen Zusammenhängen visualisiert wird.

Ich sehe da Parallelen z.B. zum Deutschen Museum in München. Sonst
müssten alle Museen mit Technik und/oder Multimedia eine andere
Kategorie bekommen.


und wenn sich meine Erinnerung (und Wikipedia) nicht irrt, dann hat 
genau das Deutsche Museum ein Planetarium.

Also ein Technik-Museum mit Planetarium.
Wie erfasst man das dann?
Mal wieder das Grundproblem: Ein Objekt mit mehreren Eigenschaften ...

Gruß
Georg

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

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

[Georg Feddern]

Moin,

Am 03.02.2014 18:52, schrieb Falk Zscheile:

Am 3. Februar 2014 18:34 schrieb Tobias Knerr o...@tobias-knerr.de:

Durch eine Abkürzung wird dem Mapper nichts einfacher gemacht. Denn
alles ausschreiben ist eine extrem einfache Regel - viel einfacher als
manches wird ausgeschrieben, manches nicht.


Eine (noch) einfachere Regel ist aber Ins name-Tag kommt es so, wie
es vor Ort steht.


Nur das es bei Tobias (und der bisherigen OSM-Regel) Variante immer ein 
eindeutiges Endergebnis gibt.
Während bei Deiner Interpretation bereits zwei unterschiedliche Schilder 
am Anfang und Ende der Straße sich nicht in einem Tag abbilden lassen ...




Es gibt aber auch (mit vertretbarem Aufwand) unauflösbare Abkürzungen im
normalen Sprachgebrauch.

Das kann man auch über long_name (eindeutig) abbilden. Damit erübrigt
sich der Streit über die richtige Schreibweise. Im name-Tag steht,
wie es vor Ort geschrieben wird und in long_name kommt die
ausgeschriebene Schreibweise.


Was dann halt bedeutet, das jedes Objekt auch zwingend einen long_name 
bekommt - denn wie sonst soll einem Auswerter der ausgeschriebene Name - 
in Deinem Sinne - eindeutig zur Verfügung gestellt werden ...


Gruß
Georg

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

Re: [Talk-de] Exportfunktion auf der OpenStreetMap.org Seite

[Georg Feddern]

Am 03.02.2014 00:20, schrieb Martin Koppenhoefer:

Am 2. Februar 2014 21:34 schrieb Thorsten Alge m...@thorsten-alge.de:


Das macht natürlich Sinn. Aber ein entsprechender Hinweis wäre trotzdem
schön.



Im Prinzip steht das da: Bild zeigt Standardebene bei  Wenn man weiss
wie's gemeint ist, ist es klar, aber sonst evtl. nicht ausreichend explizit.



Wäre es dann nicht evtl. sinnvoll, beim Aufruf von Teilen auch gleich 
auf die Standard-Ebene zu wechseln?


Georg

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

Re: [Talk-de] Spezialist für Satz und Druck gesucht

[Georg Verweyen]

Hallo Markus,

leider sind in der PDF-Datei noch einige fehlende Umbrüche (u.a. Kapitel 
3.2.1, 3.2.3) und in 3.2.2 sind die Anführungszeichen auf das Große E 
gerutscht (statt Ȅ wohl E). Außerdem muss auch der Text in 2.13 
angepasst werden, da der versteckte Link im HTML-Code natürlich im Text 
lesbar aufgeführt sein muss.
Wenn ich nochmal gegenlesen soll, dann wäre eine Bereitstellung der 
aktuellen Fassung sinnvoll. Gerne eine PM, da ich nur Zusammenfassung 
der Deutschen Mailingliste erhalte.


Mit freundlichen Grüßen

Georg V. (OSM=user_5359)

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

Re: [Talk-de] Spezialist für Satz und Druck gesucht

[Georg Verweyen]

Hallo Markus und Patrick,

hier meine Anmerkungen zu der aktuellen Fassung:
Seite 1 Kapitel 1.1 statt SD-Zugriff Zugriff“ eher SD-Zugriff“.
Seite 2 Kapitel 2.1 statt Zwei Pfeile auf der Oberen Fläche dienen dazu, „ 
eher Zwei Pfeile auf der oberen Fläche dienen dazu, „
Seite 3. Kapitel 2.2 statt Achte darauf, dass es kein gekreuztesKabel oder 
Cross-Kabelßum direkten Verbinden zweier Computer ist.“ besser Achte darauf, 
dass es kein „gekreuztes Kabel oder Cross-Kabel“ um direkten Verbinden zweier 
Computer ist. „ (zwei Fehler: fehlendes Leerzeichen nach dem ersten 
schließenden Anführungszeichen und ein ß statt dem zweiten schließenden 
Leerzeichen).

Anmerkung zu Seite 3, letzter Satz: Wenn die äußersten Drähte im durchsichtigen 
Stecker grün sind, hast du ein Kabel nach europäischer Norm (568A), wenn sie 
orange sind, ist es eines nach amerikanischer Norm (568B). Hier ist es sinnvoll 
zu erwähnen, dass die andere äußersten Drähte in beiden Varianten braun sind. 
(Gemeint sind die rechten Drähte wenn der Befestigungsclip des Steckers unten 
liegt und die offenen Drähte oben sind).

 Seite 4, Abbildung 1: Alternative Formulierung zu Markus statt Patch-Kabel 
nach amerikanischer Norm. Der äußerste Draht ist orange.“ besser Patch-Kabel 
nach amerikanischer Norm, da die beiden äußersten Drähte orange sind.“

Empfehlung zu Tabelle 1 und 2: 2. Spalte nur mit Paarnr. beschriften.
Empfehlung zu Tabelle 1: 3. Spalte nur Farbe (europäisches Kabel) beschriften 
 
Empfehlung zu Tabelle 2: 3. Spalte nur Farbe (amerikanisches Kabel) 
beschriften  
Empfehlung zu Tabelle 2: Beschriftung mit Belegungsplan Norm 568B (ATT 258A) 
Anmerkung zu Abbildung 3: diese Abbildung passt nicht mit dem Bild auf der 
Titelseite zusammen! Statt einem P steht dort das Wort Status. 

Anmerkung zu Abbildung 7: Ich bin verwirrt! Kurze Zeit später (Kapitel 2.11) 
wird behauptet, dass die Rot blinkende LED nicht bedeutet „Der Logger schreibt 
auf die SD-Karte“ sondern die Bedeutung „SD-Karte ist voll“ hat. Aber auch wenn 
der Inhalt richtig ist: der Satz müsste dann Der Logger ist aktiv und 
empfangsbereit, er schreibt auf die SD-Karte.“ lauten.

Seite 15: Anmerkung zu den Ursachen: Eventuell wäre es sinnvoll den 
Schreibschutzschalter einer SD Karte zu erwähnen. (also statt SD Karte ist 
nicht beschreibbar oder wird nicht erkannt. Bitte teste die Karte auf deinem 
PC.“ sowas wie SD Karte ist nicht beschreibbar (Schreibschutz?) oder wird 
nicht erkannt. Bitte teste die Karte auf deinem PC.“ 

Anmerkung zu Kapitel 2.14: Wenn man das Thema Partition aufnimmt, sollte man 
auch eine Mindestgröße der Partition (abhängig von der Speicherbedarf der 
Firmware) erwähnen. 

Seite 20, Kapitel 3.2.2 das E mit den Doppelten Punkten ist immer noch 
vorhanden. Ich bin kein Latex-Experte aber das liegt wohl daran, dass das 
Anführungszeichen und das E direkt nebeneinander stehen.

Seite 22: Kapitel 3.3 statt „2. Stecke die SD-Karte in den SD-Kartenslot.“ 
würde ich „2. Stecke die SD-Karte in den SD-Kartenslot des Rechners.“ empfehlen.

Seite 22, Kapitel 3.3 Frage zu Punkt 4: Bei „4. Falls du dasselbe Schiff wie 
beim letzten Mal hast, und falls an der Messeinrichtung nichts geändert wurde, 
kannst du einfach dein Schiff aus der Liste deiner Schiffe auswählen.“ ist da 
eventuell folgendes gemeint „4. Falls du dein Schiff bereits registriert hast, 
und an der Messeinrichtung nichts geändert wurde, kannst du einfach dein Schiff 
aus der Liste deiner Schiffe auswählen.“ In der Originalformulierung wäre immer 
nur ein Schiff sinnvoll nutzbar.

Am 05.01.2014 um 16:21 schrieb Patrick Beck pb...@yourse.de:

 Hallo,
 
 noch ein kurzer Zwischenbericht. Daten wurden aktualisiert. Tabellen und 
 Bilder sollten nun an ihrem Platz sein. Die einzigste Tabelle die nicht an 
 Ort und Stelle steht ist die Bedienanzeige-Tabelle - unter Bedienanzeigen 
 wird auf die Tabelle und die Seite verwiesen.
 
 Wichtig wäre noch, ob die Ränder so in Ordnung sind zum Drucken. Inhaltlich 
 wäre noch zu klären ob man beim Du bleibt (oder Sie, Abstrakt (man). Die 
 Überarbeitung wird aber wohl länger dauern, als bis heute abend. Wenn es 
 vorwiegend um eine Vorinformation geht und damit man durch den Zoll kommt, 
 wäre diese Lösung wohl meines erachtend schon in Ordnung.
 
 Grüße Patrick
 
 Am 05.01.2014 15:46, schrieb Patrick Beck:
 Hallo,
 
 so mal der letzte Stand, falls sich jemand zuschalten möchte.:
 
 http://yourse.de/tmp/logger_de.pdf
 http://yourse.de/tmp/openseamap_booklet.zip
 
 Ich habe die LaTeX-Vorlage ausgemistet und alles in eine Datei gepackt.
 Manche Formatierungen sind sicherlich nicht 100%. Was mir bisher
 aufgefallen ist, dass die Tabellen und Bilder noch frei positioniert
 werden (float-umgebung). Ist hier ein Problem und muss ich noch anpassen.
 
 Ansonsten habe ich noch nicht die Bilder für die Leitungen eingefügt.
 Was wäre noch wichtig?
 
 Grüße Patrick

___
Talk-de mailing list
Talk-de@openstreetmap.org

Re: [Talk-de] Adresstagging - Karlsruher Schema

[Georg Feddern]

Moin,

Am 26.12.2013 00:35, schrieb Walter Nordmann:

hab addr:city als Bestandteil der Postalischen Adresse wieder auf Kiel
gesetzt. So sollte es richtiger sein,

sorry
walter


ok, dann kann ich die Rute ja doch einmotten. ;-)

Ist halt nicht alles so Relations-konform, wie man es gerne hätte.
Generell könnte man den Datenbestand wohl reduzieren - aber mindestens 
für solche Sonderfälle braucht man halt die Überschreibmöglichkeit.

Und die Verarbeitung würde halt nicht einfacher im Sinne von Jedermann.

Wünsche noch frohe Rest-Weihnachten

Georg

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

Re: [Talk-de] Adresstagging - Karlsruher Schema

[Georg Feddern]

Moin,

Am 25.12.2013 09:32, schrieb Bernhard Kuisle:

ich möchte mich dafür aussprechen, beim Adresstagging nicht an den Bytes zu 
sparen und das Karlsruher Schema trotz der Redundanz beizubehalten.
Ich habe wirklich schon viele Adressen getaggt und hatte erst kürzlich den 
sonderbaren Fall, dass in einem Dorf ein Haus am Rand zu einer anderen Gemeinde 
mit anderer PLZ gehört!


ich kann mich dem nur anschließen.
Auch in Kiel gibt es solche Fälle, siehe
http://www.openstreetmap.org/way/136306277
http://www.openstreetmap.org/way/136306278

Gruß
Georg

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

Re: [Talk-de] How to map a....

[Georg Feddern]

Moin,

Am 11.12.2013 07:48, schrieb Markus:


Gibt es eigentlich eine Möglichkeit zu unterscheiden zwischen
- Form
- Funktion

Ein Gebäude ist [...]

Es wäre m.E. sinnvoll,
wenn wir für *Form* eine spezifische tag-Gruppe hätten
und für *Funktion* eine spezifische andere.

Gibt es dazu schon irgendwo Überlegungen?


m. W. gibt es bisher nicht nur die Überlegungen, sondern auch die 
Verwendung,

die Form über die spezifische tag-Gruppe building=* zu beschreiben
und die Funktion (POI) über mehrere spezifische andere tag-Gruppen 
(amenity, shop, office etc.).
Allerdings steckt die Funktion dann oft im übergeordneten Element 
(Fläche, site).


Gruß
Georg



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

Re: [Talk-de] Lane oder SharedLane?

[Georg Feddern]

Moin,

Am 05.12.2013 01:40, schrieb Masi Master:

Am 03.12.2013, 11:26 Uhr, schrieb Andreas Neumann andr-neum...@gmx.net:


Moin,

ich bin grad etwas verwirrt auf Grund der wiki-Seite zum cycleway:
http://wiki.openstreetmap.org/wiki/DE:Key:cycleway

Wir haben mehrere Straßen mit Fahrradschutzstreifen (sprich mit
Strichellinie abgesetzte Spur auf Straße, meist mit Piktogramm). Bisher
sind die alle mit cycleway=lane getaggt. Nun steht der Schutzstreifen
aber explizit bei shared_lane. Was genau ist der Unterschied? Kann man
diesen evtl. etwas besser auf der Seite hervorheben?



Öhm, sehe ich nicht so wie das wiki. shared_lane würde ich mal mit 
Fahrspur, die von verschiedenen Verkehrsarten genutzt wird 
übersetzen. Der Schutzsteifen ist allerdings eine Radspur (nicht 
verpflichtend und auch nicht ganz exklusiv), die nur im Bedarfsfall 
von KFZ befahren/benutzt werden darf, und auch nur wenn kein Radfahrer 
behindert wird.




hmm, die StVO bzw. deren Verwaltungsvorschrift sagt gerade, dass der 
Schutzstreifen keine eigenständige Fahrspur ist (im Gegensatz zum 
Radfahrstreifen) , sondern ein Teil der Kfz-Fahrspur/-bahn. Auch die 
ganze Formulierung zum Schutzstreifen lese ich gerade als Mehrfachnutzung.
Die Schutzstreifen, die ich im Umfeld so kenne, befinden sich auf 
normalbreiten Straßen, deren Breite keinen eigenen Radfahrstreifen 
erlauben, so dass die KFZ gezwungen sind, den Schutzstreifen bei 
Gegenverkehr zu benutzen. Die gilt z. B. auch innerorts für enge 
Landesstraßen mit entsprechendem KFZ-Verkehr.
Von daher sehe ich sowohl inhaltlich die shared_lane als auch gerade 
die Abgrenzung zum Radfahrstreifen als lane.



Aus meiner Sicht sind das eher Fahrradspuren (cycleway=lane), die mit 
den passenden access-tags versehen werden sollten (zur Abgrenzung zum 
Radfahrstreifen), also mit motor_vehicle=xxx. xxx:irgenwas 
schwächeres als yes, vielleicht permitted? Oder bin ich da etwas zu 
kleinlich?


Zum ersten Satz nein, zum zweiten ja. ;-)
Auch das shared_lane kann für die KFZ bereits als Warnhinweis gewertet 
werden.


Gruß
Georg

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

Re: [Talk-de] Pugi zu automatischen nachladen...

[Georg Feddern]

Moin,

Am 05.12.2013 15:57, schrieb Steffen Heinz:

Kann mir bitte mal wer helfen [...] ?


OK, wegen des Zauberworts hab ich mir für Dich mal eben kurz die 
Plugin-Liste (in JOSM oder im JOSM-Wiki) durchgelesen: continuosDownload.
Für Bing: Bei geladener Hintergrundebene Kontext-Menü aufrufen (Rechter 
Mausklick) und Haken setzen.


Gruß
Georg

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

Re: [Talk-de] Lane oder SharedLane?

[Georg Feddern]

Moin,

Am 03.12.2013 11:26, schrieb Andreas Neumann:

Moin,

ich bin grad etwas verwirrt auf Grund der wiki-Seite zum cycleway:
http://wiki.openstreetmap.org/wiki/DE:Key:cycleway

Wir haben mehrere Straßen mit Fahrradschutzstreifen (sprich mit
Strichellinie abgesetzte Spur auf Straße, meist mit Piktogramm). Bisher
sind die alle mit cycleway=lane getaggt. Nun steht der Schutzstreifen
aber explizit bei shared_lane. Was genau ist der Unterschied?


Der Unterschied ist der zwischen Fahrradstreifen und Schutzstreifen.
Siehe http://de.wikipedia.org/wiki/Radverkehrsanlage#Schutzstreifen
oder eben StVO.


  Kann man
diesen evtl. etwas besser auf der Seite hervorheben?


Kann man ohne Probleme, indem man bei cycleway=lane das falsche Bild 
eines Schutzstreifen durch das richtige Bild eines Radfahrstreifen 
ersetzt.
Auch die englische Seite bedürfte da einiger Überarbeitung bei den 
Bildunterschriften.


Da dies aber nur mein Allgemeinwissen als Autofahrer ist, halte ich mich 
da wohlweislich raus ...


Gruß
Georg

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

Re: [Talk-de] OpenStreetMap und Bürgerbus

[Georg Feddern]

Moin,

Am 27.11.2013 10:30, schrieb cracklinrain:

Wird das Rendering von stop_position und platform von Mapnik eigentlich
schon unterstützt? Vor einem halben Jahr etwa, funktionierte das noch
nicht. Wenn es nicht unterstützt wird, würde ich erst einmal
vorschlagen, dass man schließlich an alle public_transport=stop_position
zusätzlich den alten Tag highway=bus_stop tagt. Wenn man das am Ende
einmal macht, wäre das keine zusätzliche Arbeit.


hier gebe ich nur zu bedenken, dass das highway=bus_stop oft historisch 
bedingt aus Nutzer (Fahrgast)-Sicht (auch von mir) nicht auf der 
public_transport=stop_position sondern an der public_transport=platform 
(resp. Haltestellenschild) getaggt wurde (und wird), um die 
Richtungsinformation zu geben bzw. zu erhalten.


Gruß
Georg

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

Re: [Talk-de] Muster für Datenfreigabe/Lizenzvereinbarung

[Georg Feddern]

Moin,

Am 25.11.2013 15:36, schrieb Martin Koppenhoefer:

Am 24. November 2013 22:13 schrieb Michael Reichert naka...@gmx.net:


Hallo,

ich habe vor, kommende Woche die örtlichen Stadtwerke um Freigabe ihres
schematischen Liniennetzplans (Bus und Tram, abstrahierte Linien, kein
Stadtplan) zu bitten.


Das beste wäre es, die Daten als cc0 (bzw. PD) herauszugeben, so dass nicht
nur OSM sondern jeder Interessierte sie nach Belieben nutzen kann. Alles
andere (also unter Bedingungen freigegeben) schränkt die Nutzung ein,


Das ist zwar richtig - stellt aber oft genug für den LizenzGeber die 
größte Hürde dar.
(Zwar soll sie jeder Nutzer (Fahrgast) nutzen dürfen - aber das 
Produced work soll ja nicht jeder weiterverwursten dürfen.)


Andererseits würde eine schlichte Erlaubnis zur Übernahme der 
enthaltenen Informationen in die OSM-Datenbank a la Contributor terms 
doch völlig ausreichen.


Bing hat die Luftbilder doch wohl auch nicht als PD zur Verfügung 
gestellt. ;-)


Gruß
Georg

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

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

[Georg Feddern]

Moin,

Am 20.11.2013 11:16, schrieb Martin Vonwald:

Am 20. November 2013 10:58 schrieb Martin Koppenhoefer 
dieterdre...@gmail.com:


meine Vermutung ist, dass hier Landeier und Stadtmenschen ein bisschen
aneinander vorbei diskutieren. Klar, wenn man die Auswahl hat, wird man
sich nicht zuerst in einen Viehunterstand flüchten, aber wenn man in
abgelegenen Regionen unterwegs ist [...]


+1
Ein Unterstand ist ein Unterstand. Genauso wie eine Kuh sich in eine
überdachte Bushaltestelle (shelter_type=public_transport) stellen kann [1]
oder ein Reh in offene Schutzhütte (lean_to) kann sich ein Mensch in einen
Viehunterstand (field_shelter) stellen.
[...]
Wenn ich im Gebirge von einem Unwetter überrascht werde, ist es mir
herzlich egal ob das Dach über meinem Kopf auch explizit für mich gebaut
wurde oder nicht - Hauptsache trocken.


bedenkt bitte einmal die Auswirkungen, das zieht in meinen Augen viel zu 
weite Kreise:

Einen rock_shelter wird man nur vereinzelt im Gebirge finden.
Nur wo zieht man dann die Grenze _wo_ man einen _irgendwie_ gearteten 
Unterstand als amenity=shelter tagt?
Anhand der Shelter-Dichte? Wo genügend öffentliche, da die privaten 
dann doch nicht?

Ausgewählte, wo der Wanderer meint, den könnte man mal gebrauchen?

Im Ortsbereich z. B.
- Carports
- Holzlagerschuppen

Hier (sic!) im ländlichen Bereich
- Viehunterstand
- Maschinenunterstand
- Strohlager
- Feldscheunen

Bringt es wirklich Vorteile, diese privaten alle mit amenity=shelter, 
shelter_type=*, access=private zu versehen - statt bei den Anwendungen 
auf die entsprechenden building=* auszuwerten, wenn die Anwendung für 
entsprechende Zwecke gedacht ist und solche Ausweichmöglichkeiten 
benötigt werden?
Wozu braucht man für diesen Spezialfall Notunterstand 3 zusätzliche 
Tags, wenn das alles im Grunde schon mit dem vorhandenen erschlagen ist?


Gruß
Georg

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

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

[Georg Feddern]

Moin,

Am 19.11.2013 22:49, schrieb Martin Simon:

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


+1
Als amenity=shelter würde ich wirklich nur öffentlich zugängliche 
Möglichkeiten taggen.
Bei Bedarf (Wanderreitkarte ;-) ) lassen sich auch 
building=field_shelter oder building=carport als Hilfs-Unterstand auswerten.



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


Wenn schon dann Egalité: amenity=shelter mit shelter_type=carport ... :-P

Gruß
Georg

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

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

[Georg Feddern]

Moin,

Am 19.11.2013 20:13, schrieb NopMap:


Das war auch mein erster Gedanke, aber bei näherem Hinsehen sehe ich da kein
Problem.

Die alten Shelter unterscheiden sich bereits deutlich voneinander,
Grillpavillion, Picknickplatz oder Schutzhütte machen einen großen
Unterschied. Von daher ist es jetzt schon nötig, für eine sinnvolle
Auswertung den Typ zu berücksichtigen.

Wenn es Dir egal ist ob es eine Berghütte oder ein Bushäuschen ist und es
Dir nur um ein Dach geht, dann ist Dir auch mit einem solchen Unterstand
gedient.


wenn es danach geht, kann man fast jedes building als shelter nutzen.
Irgendwo/wie bietet es immer Schutz und sei es nur durch Dachüberstand 
oder abgewandte Wetterseite.
Statt jetzt aber jedes building als amenity=shelter zu taggen, würde ich 
eher geeignete building=* als Shelter _auswerten_ .


Gruß
Georg

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

Re: [Talk-de] innerorts oder außerorts - WAS: Datenmodell für straßenbegleitende Wege

[Georg Feddern]

Moin,

Am 06.11.2013 23:56, schrieb Masi Master:


Relevant u.a. für Mofafahrer. Sowas wie innerort=yes ist ja ganz 
praktisch, allerdings denke ich nach wie vor, das es nur mit einem 
großen Polygon funktionieren kann. (Bei Umweltzonen ist es ja genauso.)


woher nimmst Du diese absolute Gewissheit?
Natürlich _kann_ es auch mit einem Polygon und entsprechender 
Vorverarbeitung (übertragen der Information auf den way) funktionieren.

Aber praktische Erfahrungen belegen derzeit eher das Gegenteil:
Während solch eine programmtechnische Vorverarbeitung noch in den 
Sternen steht, funktioniert es bereits da, wo die Vorverarbeitung 
bereits vom Mapper vorgenommen wurde.
Ich sehe auch überhaupt kein Problem, diese Information direkt am way zu 
taggen - analog wie bei Adressen, wo addr:country, addr:city und 
addr:suburb auch aus den jeweiligen admin_level-Relationen 
vorverarbeitet werden _könnte_ .


Ja, hab mir extra ein JOSM-Preset gebastelt, das die source:maxspeed 
immer mit drangängt, weil ich vorher immer ein schlechtes Gewissen 
hatte, das zu unterschlagen.




eben: Ein Klick und fertig - genauso einfach ist's mit innerorts und 
außerorts. ;-)


Gruß
Georg


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

Re: [Talk-de] innerorts oder außerorts - WAS: Datenmodell für straßenbegleitende Wege

[Georg Feddern]

Moin,

Am 07.11.2013 13:11, schrieb fly:

Mit der Umweltzonen habe ich auch so mein Problem.
Kann mir irgendjemand sagen wie ich eine Umwelzone darstelle, welche
eine zerschneidende Hauptstraße nicht beinhaltet, aber kreuzenden
Brücken und die Straße mündet auch noch in einen Tunnel, wo darüber
Umwelzone ist, nur der Tunnel halt nicht.


klar:
Du musst nur das gleiche tag, wie es dann irgendwann bei der 
automatischen Auswertung erzeugt wird, mit =no an die auszuschließenden 
Straßen mappen, damit diese bei der automatischen Auswertung das tag 
nicht verpasst kriegen. :-P


Gruß
Georg

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

Re: [Talk-de] innerorts oder außerorts - WAS: Datenmodell für straßenbegleitende Wege

[Georg Feddern]

Moin,

Am 06.11.2013 14:48, schrieb Martin Koppenhoefer:

Am 6. November 2013 13:54 schrieb Masi Master masi-mas...@gmx.de:


Das source:maxspeed-Tag ist nicht so praktisch zur Kennzeichnung.
Denn wo liegt eine Straße, die mit source:maxspeed=sign + maxspeed=30 oder
70 getaggt ist?



wie relevant ist das? Im Prinzip hast Du Recht, beides zusammen
(Ortsschilder und source:maxspeed) sollten normalerweise ausreichen aber es
mag Ausnahmen geben. Wenn man es gern noch gründlicher machen will (weil
man z.B. auch in OSM die Info drin haben will, ob man rechts überholen darf
und das Rechtsfahrgebot aufgehoben ist, oder ob Parkleuchten beim Parken
ausreichen) kann man ja auch noch einen weiteren tag einführen
(innerort=yes) und promoten in der Hoffnung, dass das auch viele andere
Mapper für wichtig erachten.



vor Jahren (etwa 2010) wurde da mal der Vorschlag zone:traffic=DE:rural 
bzw. DE:urban gemacht, den ich seitdem verwende (dafür leider kein 
source:maxspeed ... aber irgendwas ist ja immer ...)

Ebenso zone:maxspeed=*, wenn es mit Zeichen 274.1 ausgeschildert ist.

Gruß
Georg

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

Re: [Talk-de] Datenmodell für straßenbegleitende Wege

[Georg Feddern]

Moin,

Am 05.11.2013 16:26, schrieb Martin Koppenhoefer:

Am 4. November 2013 20:19 schrieb Bernhard Weiskopf bweisk...@gmx.de:


Den Wortlaut Der
Radverkehr  darf  nicht  die  Fahrbahn,  sondern  muss den Radweg benutzen
finde ich klar formuliert.



das wäre so sicher klar formuliert, steht aber in der StVO überhaupt nicht
so drin, oder hast Du mal die passende Stelle?

http://www.gesetze-im-internet.de/stvo_2013/__2.html



Anlage 2 , Lfd. Nr. 16 siehe
http://www.gesetze-im-internet.de/stvo_2013/anlage_2_62.html

Gruß
Georg - der sich auch erst an die bebilderte Version gewöhnen muss ...

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

Re: [Talk-de] Telekommunikationskabel

[Georg Feddern]

Moin,

Am 30.10.2013 14:49, schrieb Florian Lohoff:

Soll ja kein oberirdisches sondern ein unterirdisches sein.

Ich habe jetzt ein communication=cable gesetzt aber am ende wäre
ja noch schön ob glasfaser und den operator des cables.

Bei mir liegen die jedoch im highway=

Ein einfacher operator wäre da - aeh - kaputt.

Und sowas

communication=line
communication:line=copper
communication:line:operator=dtag

ist vielleicht - aehm - auch kaputt.


da highway=* und communication=cable nun außer der zweidimensionalen 
Lage übereinander eigentlich gar nichts miteinander zu tun haben, ist 
evtl. auch das tag am highway-Objekt schon - aehm - kaputt.
Denn wenn das Kabel _im_ highway liegen würde - wäre es auch ganz 
schnell kaputt. ;-)
Sprich es sind zwei völlig unabhängige Objekte - sollten also auch in 
OSM als zwei unabhängige Objekte erfasst werden.
Wird vielleicht anschaulicher, wenn man mal hypotetisch auch noch Strom, 
Gas und Abwasser _unter_ der Straße - aber am gleichen highway-Objekt - 
zu erfassen versucht.


Gruß
Georg

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

Re: [Talk-de] Fahrradwege taggen, Lübecker Methode

[Georg Feddern]

Moin,

Am 29.10.2013 00:19, schrieb Wolfgang Hinsch:

Am Montag, den 28.10.2013, 13:29 +0100 schrieb Leo Koppelkamm:

Der ADFC Lübeck hat in Eigenarbeit eine neue Art Fahrradwege zu tagen
erfunden, die leider komplett inkompatibel mit dem bisherigen Model ist. (
http://wiki.openstreetmap.org/wiki/DE:Bicycle/Radverkehrsanlagen_kartieren_L%C3%BCbecker_Methode)

Statt cycleway=track benutzen sie jetzt cycleway=both;
cycleway:right=track, cycleway:left=track.

???

wiki.openstreetmap.org/wiki/DE:Key:cycleway

/Zusätzliche Fahrradwegtags für andere highway-Typen

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

cycleway=track ist unbrauchbar, da in ~50% der Fälle der Radweg nicht
auf beiden Seiten gleich ist.


Provokation
Na - cycleway=track bedeutet doch seit Jahren da ist irgendwo ein 
abgesetzter Fahrradweg - das kann man doch nicht unbrauchbar nennen!

/Provokation

Mit den cycleway:left=* und cycleway:right=* habt ihr das doch schon 
eindeutig und ausreichend präzisiert - da müsst ihr doch nicht mit 
cycleway=both das 'bisherige Model' versauen. ;-)


Provokation
cycleway=track müsste man dann sonst ja plötzlich als da sind beidseits 
abgesetzte Fahrradwege umdefinieren ... und alle früheren Werte 
plötzlich so auswerten ...

/Provokation

Gruß
Georg

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

Re: [Talk-de] Amtliche Daten

[Georg Feddern]

Moin,

Am 24.10.2013 18:43, schrieb cracklinrain:

Wie gebt ihr Namen oder Hausnummern in die OSM ein, wenn sie nicht mit
der Schreibweise der entsprechenden amtlichen Liste übereinstimmen?


Generell gilt:
Auch amtliche Listen werden nur von Menschen gepflegt - und können 
Schreibfehler enthalten.

Und werden hin und wieder auch mal wieder geändert.



Hintergrund ist: Ich habe in den letzten Tagen die
Straßenvergleichsliste in Bremen
(http://regio-osm.de/listofstreets/wiki/index.php?title=Bremen) ein
wenig gepflegt und dabei die Einzelnen Fälle von Differenzen unterschieden.

Nun gibt es solche harten Abweichungen wie In'n Dörp (vor Ort) und In
n Dörp (amtliche Liste),


Blende z.B. mal die Spalte E ein - die gehen da auf Nummer Sicher.;-)


  oder Wurtmannplatz (vor Ort) und
Johann-Wurtmann-Platz (amtliche Liste).


Da solltest Du mal die aktuelle Liste neu abrufen - haben sie schon 
angepasst - ob nun der Widmung oder der Realität sei mal dahingestellt.



  Teilweise waren auch groß- und
Kleinschreibung anders.


Echt menschlich halt.

Aber zum Wesentlichen:
Auch ich halte Vor Ort  Liste - bzw. mit entsprechendem alt_name.
Kann man nach der evtl. Schilderänderung ja wieder anpassen. ;-)

Gruß
Georg



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

Re: [Talk-de] Fehler beim mappen

[Georg Feddern]

Moin,

Am 04.09.2013 21:19, schrieb Jan Kulhanek:

Ja, in dem Fall waren mutipolygone aus meiner Sicht besser, weil vieles 
aneinander grenzt.

Vorher waren dort viele einzelne Linien, das war aber so chaotisch das es mir 
nicht möglich war weitere Flächen einzuzeichnen.
Vorher, mit einzelnen Linien für jedes Gebäude wurde es seltsamer weise 
gerendert.

Keiner eine Idee wo jetzt das Problem liegt?


ich hab mir das mal angeschaut aund kann technisch keinen Fehler 
erkennen, es sollte also eigentlich gerendert werden.


Allerdings kann ich auch nicht Dein vermeintliches Chaos nachvollziehen.
Es handelt sich jetzt alles um einfache geometrische Objekte.
Bei allen jetzigen Multipolygonen besteht jeweils ein eigenständiger way 
(d.h. der nur in einem Multipolygon verwendet wird), den man ganz bequem 
zum Gesamtumriss erweitern - und sich die ganzen Multipolygone sparen 
könnte.
Und ich finde es gar nicht seltsam, das die Objekte mit einzelnen Linien 
gerendert wurden ... im Gegensatz dazu finde ich es chaotischer, jetzt 
nachzuvollziehen, ob alle Objekte auch wirklich geschlossen sind.


Nichtsdestotrotz habe ich mal ein /dirty auf die kleine Grenzkachel 
19/281670/171938 losgelassen - und plötzlich wurden die Gebäude komplett 
angezeigt.

Liegt es vielleicht doch nur am Browser-Cache?

Gruß
Georg

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

Re: [Talk-de] Hydrant oder Beregnungsanlage

[Georg Feddern]

Moin,

Am 14.08.2013 18:34, schrieb Volker Schmidt:

Fuer mich ist das ein Anschluss fuer eine moeglicherweise sogar private
Beregnungsanlage.


hmm - hast Du Dir die Lage mal auf Bing angeschaut ... ?
Wie ein geschickter Foto-Ausschnitt doch in die Irre führen kann!


2013/8/14 Andre mr.jo...@ewetel.net


Ist das in [1] ein Hydrant oder der Anschluss für eine Beregnunganlage?

Es handelt sich um diesen [2] Knoten. Der Punkt liegt also in einem
kleinen Dorf in der Nähe von Feldern.




eher direkt an einer Straßenkreuzung (Trinkwasserversorgung) und in der 
Nähe von Gebäuden ...

Die Felder liegen doch erst jenseits der bebauten Grundstücke.

Bestimmt gibt es an der Straße ein entsprechendes Hinweisschild - oder 
woher hast Du sonst den Leitungsdurchmesser 150?


Also: Hydrant.
Ich würde den node allerdings noch weiter auf das Grün Richtung Hecke 
verschieben und die Lage als fire_hydrant:position=green angeben.


Georg


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

Re: [Talk-de] Flächenstil wird nicht mehr gerendert nach Hinzufügen als inner zu Multipolygon

[Georg Feddern]

Moin,

Am 09.08.2013 09:08, schrieb tumsi:

Von: Georg Feddern o...@bavarianmallet.de

Andererseits gibt es dort noch einige umliegende Überlappungen:


Du spielst wahrscheinlich auf die Warnungen von JOSM an.


Nö, die habe ich gar nicht gesehen, da ich keine Prüfung durchgeführt habe.
Sie vielen mir nur auf, als ich die einzelnen ways ausgewählt hatte.

Was ist daran falsch, wenn sich die Umrisslinie eines Polygons und ein 
outer-Linienzug eines Multipolygons ein paar Punkte teilen?


Solange eines davon ein (in sich geschlossenes) Polygon ist - nichts.
Aber wenn sich zwei Teillinien zweier Multipolygone dennoch wieder in 
verschiedenen Bereichen überlagern, ist das irgendwie halbgar.


Ich kann doch jetzt nicht den Umriss jedes kleinen Fitzelpolygons 
auftrennen und es zu einem Multipolygon machen, nur damit JOSM 
zufrieden ist


Nein, beileibe nicht jedes (sonst geschlossene) Fitzelpolygon - so war 
das definitiv nicht gemeint.


Gruß
Georg

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

Re: [Talk-de] Flächenstil wird nicht mehr gerendert nach Hinzufügen als inner zu Multipolygon

[Georg Feddern]

Moin,

Am 08.08.2013 14:23, schrieb Wilhelm Spickermann:

Jetzt wird es richtig interessant. Es (Way 94507617) wird immer noch
nicht dargestellt, obwohl es ein einfaches Polygon ist. Kein Punkt ist
doppelt. Keine Selbstüberschneidungen. Keine lustigen Codes in den Tags.

eigentlich sollte das einfache Element gerendert werden.

Andererseits gibt es dort noch einige umliegende Überlappungen:

z. B. zwischen way 232577437 und way 232577436, sowohl im Süden wie im 
Norden.


Ich halte da meinen Mausfinger lieber raus ...

Gruß
Georg

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

Re: [Talk-de] Talk-de Nachrichtensammlung, Band 84, Eintrag 34

[Georg Verweyen]

Hallo Tracy,

bitte verwendet ref:ifopt ! In den selten Fällen wo mal ein ref_ vor kommt 
(siehe taginfo.openstreetmap.org) ist meistens keine Referenznummer gemeint.

MfGGeorg V: (OSM=user_5359)

Am 11.07.2013 um 14:00 schrieb kasperc...@mentzdv.de:

 Message: 6
 Date: Thu, 11 Jul 2013 12:21:45 +0200
 From: Tracy Kasperczyk kasperc...@mentzdv.de
 To: talk-de@openstreetmap.org
 Subject: [Talk-de] Einführung eines neuen Tags (globaleID)
 Message-ID:
   cajb3xkaepfqhpesq5_14gc52qhe_sptzr4buhgm9833ukqi...@mail.gmail.com
 Content-Type: text/plain; charset=ISO-8859-1
 
 :

 Wir nehmen die Anregung von Stephan Wolff auf und ändern den Namen in
 ref_ifopt
 :


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

Re: [Talk-de] Bauliche Trennung

[Georg Feddern]

Moin,

Am 03.07.2013 14:05, schrieb Masi Master:
Die StVO hat zwar eine andere Definition von Baulicher Trennung als 
wir bei OSM.


gibt es für diesen (Fehl-)Satz eigentlich auch ein Hamburger 
Gerichtsurteil, dass er sich so sehr in den Köpfen festgesetzt hat?


Die StVO definiert nirgends eine bauliche Trennung - und sie verwendet 
den Begriff auch  nicht anders als OSM.


Sie verwendet lediglich die Formulierung
durch Mittelstreifen oder sonstige bauliche Einrichtungen getrennt = 
bauliche Trennung wie bei OSM

und grenzt ausdrücklich davon ab
durch Fahrstreifenbegrenzung(Zeichen 295) oder durch Leitlinien 
(Zeichen 340) markiert.


Gruß
Georg

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

Re: [Talk-de] Bauliche Trennung

[Georg Feddern]

Moin,

Am 04.07.2013 11:05, schrieb Martin Koppenhoefer:

Am 4. Juli 2013 10:56 schrieb Georg Feddern o...@bavarianmallet.de:

Sie verwendet lediglich die Formulierung
durch Mittelstreifen oder sonstige bauliche Einrichtungen getrennt =

bauliche Trennung wie bei OSM

und grenzt ausdrücklich davon ab
durch Fahrstreifenbegrenzung(Zeichen 295) oder durch Leitlinien (Zeichen

340) markiert.



in § 3 Abs 3, 2c StVO steht: ...Sie gilt ferner nicht auf Straßen, die
mindestens zwei durch Fahrstreifenbegrenzung (Zeichen 295) oder durch
Leitlinien (Zeichen 340) markierte Fahrstreifen für jede Richtung haben

2xZ295 ist eine doppelte Mittellinie
http://dejure.org/gesetze/StVO/3.html


hmm, stimmts Du mir jetzt zu oder hältst Du dagegen? Ist nicht so ganz 
eindeutig ...

Aber genau darauf beziehe ich mich.

OK, ich hätte die Quelle nochmal explizit angeben können, bin aber der 
Meinung StVO ist bereits eindeutig und die Fundstelle als Einzige ebenfalls:


In § 3 Abs 3, 2c StVO findet sich folgender zusammenhängender Textblock:

Diese Geschwindigkeitsbeschränkung gilt nicht auf Autobahnen (Zeichen 
330.1) sowie auf anderen
Straßen mit Fahrbahnen für eine Richtung, die durch Mittelstreifen oder 
sonstige bauliche Einrichtungen
getrennt sind. Sie gilt ferner nicht auf Straßen, die mindestens zwei 
durch Fahrstreifenbegrenzung
(Zeichen 295) oder durch Leitlinien (Zeichen 340) markierte Fahrstreifen 
für jede Richtung haben.


Somit ist die doppelte Mittellinie eindeutig weder ein Mittelstreifen 
noch eine sonstige bauliche Einrichtung, sondern eben eine Markierung.
Und somit hat die StVO kein anderes Verständnis einer baulichen Trennung 
als OSM.


Gruß
Georg


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

Re: [Talk-de] Export der Postleitzahlen-Gebiete

[Georg Feddern]

Moin,

Am 23.05.2013 08:19, schrieb Christoph Fröhlich:

1) Weiß jemand, ob z.B. die 22767 nicht erfasst ist, oder ob ich sie nur nicht 
finde? Weil die 22767 so einen zentralen Bereich in Hamburg abdeckt, könnte ich 
mir vorstellen, dass die Relation irgendwo in OSM existiert aber anders 
getagged ist.


ein paar weiße Flecken gibt es wohl noch.
Siehe auch:

http://www.flosm.de/html/Verwaltungsgrenzen.html

Gruß
Georg

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

Re: [Talk-de] Stadtteilfuckup in Nominatim

[Georg Feddern]

Moin,

Am 09.05.2013 00:55, schrieb Ruben Kelevra:

Nun, wie ich bereits sagte nimmt Nominatim den Stadtteil außerhalb des
Stadtgebiets der definitiv NICHT zu einer Straße im Stadtgebiet
gehört. Ich wüsste aber nicht wie ich den Stadtkern selbst taggen
soll. Das ist das primäre Problem.

Hat jemand dafür einen Vorschlag?


Ich kenne keine Gemeinde/Stadt, die aus Ortsteilen/Stadtteilen besteht, 
wo das Kerngebiet nicht auch ein Ortsteil/Stadtteil ist.
Also wird es wohl auch dort für den 'Stadtkern' eine administrative 
Struktur samt Namen geben - ich tippe mal auf Wermelskirchen. ;-)



Den Rest werde ich mal so probieren wie hier vorgeschlagen, entweder
ein Shape oder nur die Straße selbst taggen.


Shape / Grenze - selbst in geschätzter Lage - ist der bessere Weg.
Selbst ein place-Node 'Stadtkern' hilft nicht weiter, wenn halt der 
äußere Stadtteil-Node immer noch dichter dran liegt ...


Gruß
Georg


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

[Talk-dk] Søges: Foredrag om Openstreetmap i Aalborg

[Georg Sluyterman]

Hej

Hackerspacet i Aalborg (HAL9k) holder åbent hus og foredragsdag i anledningen 
af NJLUG ophører ( det skal slutted af med en lille fejring), lørdag d. 1. 
juni. 

Er der nogen her på listen der mon har tid og lyst til at holde et oplæg om 
OSM, hvordan det fungerer, hvordan folk bidrag mv. Tekniske detaljer i 
foredraget er velkomment. 

På forhånd tak!

-- 
Venlig hilsen
Georg Sluyterman
Tlf. 50830119
___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk