Re: [Talk-at] OSM Nominatim Adress Suche in Wien

[wolfbert]

Seitens Nominatim gibt es einen ersten Kommentar 
 :

· There will be no parsing of addr:housenumber for unit numbers. Any 
support for unit numbers on the Nominatim side will only rely on a separate tag 
addr:unit. Don't hack them into housenumber just to tag for a broken Nomiantim.

· Nominatim can (and already does) take missing address parts from a 
surrounding building polygon. So a node with only addr:unit inside a building 
with a full address is just fine.

 

Das bedeutet noch nicht, dass sich etwas ändert, aber es gibt mal die Richtung 
vor.

 

LG

Wolfgang

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

Re: [Talk-at] OSM Nominatim Adress Suche in Wien

[wolfbert]

https://trac.openstreetmap.org/ticket/4886
https://github.com/openstreetmap/Nominatim/issues/587

LG
Wolfgang

-Ursprüngliche Nachricht-
Von: Robert Kaiser [mailto:ka...@kairo.at] 
Gesendet: Sonntag, 18. Februar 2018 23:00
An: OpenStreetMap AT
Betreff: Re: [Talk-at] OSM Nominatim Adress Suche in Wien

Johann Haag schrieb:
> OSM Nominativ löst unit nicht auf.

Kannst du mir bitte einen Link schicken zu dem Issue/Bug-Report, den du dazu 
bei Nominatim sicher schon angelegt hast?

KaiRo


___
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-at] OSM Nominatim Adress Suche in Wien

[wolfbert]

Johann, das ist exakt, worauf ich in meinem vorigen Post hinaus wollte: es ist 
** irrelevant ** was die Adress-Suche liefert, das ist ein Problem von 
Nominatim (es würde schon reichen, wenn es  zusätzlich zur Allerweltssuche eine 
strukturierte Maske nebst Indizes gäbe, dann wäre das alles kein Thema). 

 

Unsere Aufgabe ist es, die Daten möglichst strukturiert und auswertbar bereit 
zu stellen. Befindet sich auf einem Punkt address:unit, dann kann man zur Suche 
z.B. wie folgt vorgehen (hierarchisch vom Spezifischen zum Allgemeineren, und 
in Kombination; gemappt wird umgekehrt):

 

· (Prio 3) Man beachte die weiteren Adressdaten auf diesem Punkt,

· (Prio 2) die Adressdaten des Gebäudes auf dem Umriss,

· (Prio 1) die Adressdaten in Relationen und umgebenden Polygonen, (-> 
Anlage)

· (Prio 4) an nahen Adresspunkten innerhalb des Umrisses,

· (Prio 5) ev. noch interpolierte Adressen / anliegende Straßen,

· ev. Ergänzung noch fehlender Bestandteile (z.B. aus PLZ-Relationen, 
nahen Straßen, etc.)

 

Lautet die Hausnummer auf „*/*“ dann legt man addr:unit eben implizit an.

Wenn das alles noch nicht reicht, und es tatsächlich zwei Adressen auf gleicher 
Ebene gibt, dann bliebe noch Friederichs Vorschlag mit den Identadressen. In 
der Suche können alle diese Adresskombinationen gefunden werden. 

 

Zur Veranschaulichung siehe z.B. die Adresse Vorgartenstraße 158-170/11 
(https://osm.org/go/0JrJmG1KX)

Mit obigem Verfahren ergibt sich:

 

· Vorgartenstraße 158-170/11 (die offizielle Adresse)

· Vorgartenstraße 164/11 (alternativ/halb-offiziell und genauer für den 
Zusteller)

· Jungstraße 9/11 (auch damit kommt man hin)

 

Was mich dazu bringt, dass komplexe Anlagen mit Ortskenntnis und manuell 
modelliert werden sollten, und nach einem Schema (das aber verschiedene Wege 
zulässt). Überspezifikation (also z.B. komplette Adresse auf allen Stiegen) ist 
unschön, aber kein Hindernis (der Renderer z.B. hat es aber ungleich schwerer, 
weil er ermitteln müsste, was denn nun die „gemeinsame“ Adresse ist, um dann 
die redundanten Bestandteile weg zu lassen – in obigem Beispiel gibt es 158-170 
ja auch mehrfach, weil die Anlage implizit in der gemeinsamen Hausnummer 
steckt).

 

So, das wurde wieder viel zu lang, LG

Wolfgang

 

 

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

Re: [Talk-at] OSM Nominatim Adress Suche in Wien

[wolfbert]

Hallo,

 

nachdem ich dieser unterhaltsamen Diskussion jetzt eine Zeit lang gefolgt bin – 
und langsam den Überblick verliere – erlaube ich mir dazu auch meine Meinung 
kund zu tun. (Ich bekenne mich freimütig zu zweifelhafter Vergangenheit und 
fragwürdiger Intention und trage Socken.)

 

a) Wir mappen nicht für . Jeder Aspekt der vorgeschlagenen Lösung, der 
nur dazu dient, Nominatim auf die Sprünge zu helfen, ist verzichtbar. 
Entsprechende Wünsche  bitte an Nominatim zu richten.

 

b) Bitte auch keine künstlichen Redundanzen, lokale Metaregeln, Abgleiche etc., 
die schon in verwalteten Umgebungen problematisch sind. In einer gewollt 
dynamischen und teils chaotischen Umgebung mit wechselnden Mitarbeitern und 
Tagging-Stilen vergrößert das nur noch das Durcheinander. Unklarheiten, 
Edit-Wars, ungewollte Seiteneffekte, Rückwirkungen auf  Tools etc. können 
daraus folgen.

 

c) Insofern das vorhandene Instrumentarium nicht ausreicht, Objekten Adressen 
direkt oder indirekt zuzuordnen, diese maschinell zu rekonstruieren und samt 
Verortung auszuwerten, kann man das diskutieren. Ich wohne selbst in einer 
Wohnhausanlage (https://osm.org/go/0JrJmF9hP) mit Stiegen und mehreren 
Adressen, und da gibt es ev. noch den einen oder anderen Punkt (z.B. die 
Gruppierung von Gebäuden), aber soweit ich das verstehe, alles (auf mehreren 
Wegen) lösbar.

 

In diesem Sinne bitte vor Änderungen im großen Stil um eine kurze 
Zusammenfassung welches Problem damit genau gelöst wird, was sich ändert und 
wie das gemacht wird (einschließlich Umgang mit bestehenden und neu 
hinzukommenden Daten). 

 

Grüße

Wolfgang Schreiter

http://hdyc.neis-one.org/?wolfbert

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

Re: [Talk-at] GPX-Daten glätten

[wolfbert]

> Gibt's für Linux einen GPX-Filter für die Kommandozeile, der ähnlich gute 
> Qualität bietet?

Hallo Christian,

laut Home Page verwendet gpsvisualizer GPSBabel, und das gibt es für Linux 
auch. Wenn es nicht Kommandozeile sein muss, lohnt vielleicht ein Blick auf 
GpsPrune.

LG
Wolfgang


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

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

[wolfbert]

On 2017-04-02 14:12, grubernd wrote:

> Lieber Friedrich, wenn es dein Ziel ist, aktive und produktive 
> Mitglieder der Community und ihre Arbeit auf zutiefst persönlicher und 
> unsachlicher Ebene zu beleidigen, dann bist du meiner Meinung nach auf 
> einem sehr guten Weg.

Ich fühle mich nicht beleidigt. Wir investieren alle eine Menge Zeit und 
Herzblut in die Sache, da kann es passieren, dass man mal empfindlich reagiert 
(auch wenn's einem nachher vielleicht leid tut). Mein ursprüngliches Posting 
war ja wirklich anonym. Kommunikation gelingt halt nicht immer optimal. 
Versuchen wir's weiter ;-)

LG
Wolfgang 


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

[Talk-at] Abschluss Datenbereinigungsaktion plan.at

[wolfbert]

Hallo alle,

 

die Löschaktion der plan.at Tags ist – soweit es den (halb-)automatischen
Teil angeht – abgeschlossen. 

 

Insgesamt wurden 155.643 Linien (und ein paar Punkte) bearbeitet. Die
verbliebenen Reste müssen manuell bearbeitet werden, siehe dazu bei checkAT
(http://geotools.ipax.at/) unter „plan.at: Probleme“. 

 

Einige Mapper werden sicher noch einige Zeit lang addr:* Tags an highways
verwenden, hier ist Aufklärungsarbeit nötig. Insbesondere Postleitzahlen
brauchen generell nicht an highways angebracht zu werden.

 

Der data_at User setzt sich damit vorerst zur Ruhe. Falls weitere Vorschläge
für größere Aktionen entstehen, poste ich wieder.

 

LG

Wolfgang

 

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

Re: [Talk-at] Datenbereinigung für plan.at

[wolfbert]

Hallo,

nur zur allgemeinen Information, ab sofort läuft die Bereinigung an. 

Im ersten Durchgang werden nur eindeutige plan.at highways (fixme+source
angegeben) bearbeitet, wobei Tags nur gelöscht, nicht aber hinzugefügt oder
verändert werden. Dabei konzentriere ich mich auf at:maxspeed (ca. 18.000 
Stück).

Den Fortschritt könnt Ihr ja auf Tagwatch oder bei osmi verfolgen, die Details
stehen im Wiki. Wird ein paar Tage dauern...

LG
Wolfgang


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

Re: [Talk-at] Datenbereinigung für plan.at

[wolfbert]

Hallo Hannes,

sorry, hab' die Doku noch nicht nachgezogen... Mache ich gleich.

Du musst da gar nichts beheben, das würde bei der Bereinigung miterledigt.
Wenn Du aber gerne möchtest: die Auswertung zeigt, wie viele aus plan.at
stammende (und IMHO unnötige) Tags da sind, die gelöscht werden könnten. Die
Tag-Liste steht im Wiki (siehe voriges Posting). Allenfalls könntest Du
'plan.at' zum source-Tag hinzufügen, falls noch nicht da.

Ein häufiger Fall ist z.B. addr:postcode=* an highways (wurde zugegebenermaßen
auch von einigen Mappern gesetzt), sollte aber an den Häusern stehen, da Straßen
ja keine PLZ bzw. Adresse haben (die PLZ steht auch noch in den place-Knoten).

Hannes Brandstätter-Müller osm@... writes:

 plan.at: Ways ohne 'check import' (1 Key) gibt's da einige, nur ist
 mir nicht ganz klar was da nicht passt. Wie behebe ich die?
 

LG
Wolfgang



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

Re: [Talk-at] Datenbereinigung für plan.at

[wolfbert]

Flaimo flaimo@... writes:

 1) es bläht die datenbank auf. die daten müssen auch jedes mal
 runtergeladen werden wenn man irgendwas damit machen will.

Die Gefahr besteht, zumal bei bearbeiteten Objekten auch nicht mehr sicher ist,
was denn nun genau source war.

 2) der nächste der was an den ways editiert, hat vielleicht als source
 ganz was anderes (zB bing oder geoimage).

Das kann er dann aber ergänzen.

 aus meiner sicht ist es viel besser den source tag, genauso wie
 comment und created by, auf das changeset zu setzen. damit ist dem
 quellennachweis ebenfalls rechenschaft getragen. wer die source infos
 explizit braucht, lädt sich die changeset-infos runter.

Beim Editieren sieht halt nicht jeder im Changeset nach, und source ist ganz gut
akzeptiert, denke ich.

Insgesamt bin ich da auch noch etwas unschlüssig, daher bearbeite ich erst
einmal Ways, wo source schon gesetzt ist. Das gibt uns noch etwas Zeit zum
Nachdenken.

LG
Wolfgang




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

[Talk-at] Datenbereinigung für plan.at

[wolfbert]

Hallo alle,

 

bei der SotM dieses Wochenende haben sich einige Mapper-Veteranen versammelt
und über eine (automatische) Bereinigung von plan.at-Tags diskutiert. Fazit
ist, wir möchten das angehen. 

 

Eine Beschreibung des Sachstandes und den Status findet Ihr hier:
http://wiki.openstreetmap.org/wiki/WikiProject_Austria/plan.at/Abschluss#Aut
omatische_Bereinigung_von_Tags

 

Wesentliche Fortschritte und Änderungsläufe (noch ist es nicht soweit) werde
ich auch auf dieser Liste posten. Für alle, dies sich im Detail für
datenbezogene Themen interessieren, hat Andreas eine neue Mailingliste
eingerichtet: https://openstreetmap.at/mailman/listinfo/data

 

Liebe Grüße

Wolfgang

 

 

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

Re: [Talk-at] Finanzamt ist verschwunden

[wolfbert]

Ja, da gab es einen Unfall. Ich habe gestern (da war das FA schon weg)
einige mehrere 100m lange Häuser wieder geschrumpft, und den verbliebenen
(ungenauen) Innenhof des FA gelöscht. Man könnte die Changesets rückgängig
machen, aber ich denke es ist unkomplizierter, das Gebäude wieder zu
ergänzen. Ich mache mich mal dran.

LG
Wolfgang 

-Ursprüngliche Nachricht-
Von: Bernhard Zwischenbrugger [mailto:b...@datenkueche.com] 
Gesendet: Mittwoch, 25. Mai 2011 20:12
An: OpenStreetMap AT
Betreff: [Talk-at] Finanzamt ist verschwunden

Hallo ihr Lieben

Das Finanzamt im 8. Wiener Gemeindebezirk ist verschwunden.
Will sich da jemand die Steuern sparen?

Hier dürfte etwas schief gegangen sein:
http://www.openstreetmap.org/browse/changeset/8233232

lg, Bernhard

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


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

Re: [Talk-at] Hilfe wegen OSM

[wolfbert]

Hallo,

 

ohne mit dem Thema Erfahrung zu haben (das hat aber wohl schon jemand gelöst, 
google bietet sich an), einfach ein paar  Ideen. Frage ist natürlich, wie groß 
die zu untersuchende Fläche ist, wieviele highways da sind, wie genau es sein 
soll, und wieviel Entwicklungszeit resp. Rechenkapazität/zeit zur Verfügung 
stehen. 

 

Von den Punktmengen (ev. auch nur Mittelpunkt, ev. gewichtet mit Straßenlänge) 
der (residential) highways ausgehen und per Cluster-Algorithmus (DBSCAN o.ä.) 
Gebiete höherer Dichte identifizieren, dann ev. Straßenlänge/Fläche der Hülle. 

 

Ausgehend von einem residential highway alle anderen erreichbaren residentials 
innerhalb einer gewissen (Straßen)Distanz rekursiv suchen (wäre natürlich 
einfacher, wenn ein Graph schon zur Verfügung stünde), dann Straßenlänge/Fläche 
der Hülle.

 

Straßenlänge pro Fläche zu berechnen würde z.B. bedeuten, Straßenlänge pro 
Gridquadrat zu berechnen, und die vollsten Quadrate zu suchen (dabei könnte man 
aber Orte verlieren, die in mehrere Quadrate fallen).  Das verursacht 
jedenfalls eine Menge Schnittoperationen (auch wenn die Schnittmenge leer ist).

 

Zur Berechnung wäre eine Kopie der DB fein (hoffentlich nicht wirklich der 
ganzen Welt ;-), PostGIS hat eine Menge praktische Funktionen (konvexe Hülle, 
Schwerpunkt, Fläche, Längenberechnung, bounding box/index-unterstützte 
Geometrieoperatoren), darüber hinaus könnte man die Verarbeitung 
abschnittsweise auch außerhalb der Datenbank durchführen.

 

Just my 2 cents…

Wolfgang 

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

Re: [Talk-at] Hilfe wegen OSM

[wolfbert]

Hallo Janine,

was hast Du denn für Vorkenntnisse, wieviel von osm willst Du untersuchen,
und was passiert mit dem Ergebnis?

Wie kann das eig funktionieren?

Kenntnisse in Programmentwurf und Programmierung (inkl. relationale
Datenbank/GIS-Erweiterungen) solltest Du schon haben oder Dir erarbeiten.
Was den Algorithmus angeht, ich schätze das ist die Aufgabe ;-)

LG
Wolfgang





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

Re: [Talk-at] Plan.at Statistik

[wolfbert]

Hallo,

note und at:maxspeed braucht Du nicht auswerten, die bedeuten nichts (können
summarisch gelöscht werden, zahlt sich nicht aus, die extra zu bearbeiten).

Am wichtigsten finde ich die 845 Geister-highways und 10 Geister-waterways,
die könnten wir nämlich in kurzer Zeit schaffen und aktivieren. Die fixmes
brauchen noch lange, aber die sind auch nicht störender als alle anderen
fixmes (es gibt jede Menge Ways die nicht aus plan.at stammen/kein fixme
haben und qualitativ auch nicht besser sind).

LG
Wolfgang



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

Re: [Talk-at] landuse-pletschn über linz

[wolfbert]

Boris Cornet borisC@... writes:

 Braucht man bei zweiterem area=yes?  Und was sagen dann die
 dogmatiker, die landuse + area als schlimmsten anzunehmenden 
 Fehler ansehen?
 

Ich vermute mal, dass sich das auf mich bezieht... Was Dogmatiker angeht, das
können wir in einem anderen Thread abhandeln, zu den anderen Punkten: 

- lt. Wiki (ich weiss, ich wiederhole mich) ist place=suburb auch für Flächen
gedacht (ist ja naheliegend), area=yes daher IMHO redundant. Soweit ich sehen
kann gibt, gibt es in Mapnik aber ein Rendering-Problem mit Namen (der Name wird
nicht mittig zur Fläche, sondern irgendwo am way angebracht), in Kombination mit
landuse scheint es aber wieder zu funktionieren. Das sollte dann aber in Mapnik
behoben werden.

- schlimmster anzunehmender Fehler - nein, nur wirkungslos bzw. redundant, und
das halte ich nicht für erstrebenswert

LG
Wolfgang

 


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

Re: [Talk-at] Donauradweg

[wolfbert]

Hallo,

 

die verschiedenen Möglichkeiten zum Kennzeichnen eines Radweges
(Verkehrszeichen, bauliche Gegebenheiten, Radfahrerseiten im Wiki,
Tagkombinationen) hast Du Dir ja sicher angesehen. Dann würde ich sagen,
mappe das, was Du vor Ort siehst (im Zweifel kannst Du ja auch kurz den
ursprünglichen Autor anmailen).

 

Nach meiner Beobachtung ist auch andernorts die Begeisterung mit manchem
Radler durchgegangen, und es wurde alles erst mal als separater Radweg
gemappt, bloß weil man da fahren kann und ev. eine Route durchgeht
(ungeachtet der Tatsache, dass es sich real um Güterwege, Fusswege,
Straßen/Spuren etc. handelt). 

 

Es gibt natürlich Graubereiche. Z.B. Treppelweg (zumindest teilweise track)
oder Donauinsel (cycleways): beide asphaltiert und Kfz-befahrbar, aber
primär als Fuss- und Radweg genützt/beschildert. Da highway=cycleway ==
highway=path + bicycle=designated müsste eigentlich in beiden Fällen track
verwendet werden (weil path eher einspurig und track zweispurig). Aber das
ist wohl schon Geschmackssache und hat vielleicht auch mit der
landwirtschaftlichen Bedeutung von track zu tun.

 

LG

Wolfgang

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

Re: [Talk-at] Talk-at Nachrichtensammlung, Band 30, Eintrag 12

[wolfbert]

Flaimo flaimo@... writes:
 
  Date: Wed, 13 Apr 2011 21:26:42 + (UTC)
  From: wolfbert geowolfat@...
 
  - Bitte verwendet landuse wie beschrieben - als vorwiegende 
  Gebietsnutzung, nicht pro Grundstücksparzelle. 
 
 nur nur weil es wo im wiki steht, heißt es nicht, dass es auch noch
 korrekt ist. 

Dann ist es anzupassen (wie definierst Du korrekt?), aber bis zu einem neuen
Proposal ist das die einzige Richtlinie, die wir haben. Und ohne halbwegs
gemeinsames Verständnis von Tags und Features klappt's nun mal nicht.  

 ich sehe nicht ein mich an eine definition anno 2008
 halten zu müssen, die aus zeiten stammt wo es kaum sat-bilder zur
 genauen auswertung gegeben hat.

landuse geht wahrscheinlich auf die kartografische Generalisierung oder
Flächenwidmung zurück. Das kann man im Zusammenhang mit digitalen Karten
hinterfragen und andere Modelle entwickeln. 
Die meisten Gebiete in Österreich sind von Katastergenauigkeit aber Lichtjahre
entfernt und landuse ist derzeit völlig ausreichend. Ob und wie Grundstücke
eingetragen werden sollen, sollte man in Ruhe erarbeiten. Zu den Open
was-auch-immer-Daten hat IMHO noch niemand ein Konzept (wie importieren,
regelmäßig abgleichen, vor Änderung schützen,...).

 wenn nunmal an der einen ecke ein hofer ist und daneben gleich ein
 einfamilienhaus ... werde ich nicht
 das eine oder andere einem bestimmten landuse unterordnen.

Diese Dinge werden bereits jetzt über den landuse gelegt, also der landuse ist
untergeordnet.

Ich bin nicht grundsätzlich gegen das Eintragen von Grundstücksgrenzen (hab's
auch schon probiert), aber es hat für mich keine Priorität und ist noch nicht
ausreichend überlegt.

LG
Wolfgang


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

Re: [Talk-at] Hilfe, meine Häuser sind schief!

[wolfbert]

Hallo michi,

überprüfe doch mal in JOSM unter Einstellungen (F12) im dritten Reiter von
oben die Projektionsmethode. Da sollte Merkator stehen. Mit WGS84 kann ich
Deine Häuser rechtwinkelig sehen.

Liebe Grüße
Wolfgang




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

Re: [Talk-at] Hilfe, meine Häuser sind schief!

[wolfbert]

Hallo michi,

hab' mich schlecht ausgedrückt: die Projektion soll auf Merkator stehen.
WGS84 ist nicht ok.

Grüße
Wolfgang

-Ursprüngliche Nachricht-
Von: Familie Geramb [mailto:michael.ger...@aon.at] 
Gesendet: Dienstag, 12. April 2011 20:18
An: talk-at@openstreetmap.org
Betreff: Re: [Talk-at] Hilfe, meine Häuser sind schief!


Hallo Wolfgang,

danke für die rasche Antwort, aber die Projektion steht auf WGS84. Sie sind
im JOSM optisch auch rechtwinkelig, jedoch nicht parallel zur Straße. Das
sieht aber auch auf den Sat-Bildern im JOSM so aus, nicht jedoch auf der
GIS-Seite. Und in der Online-Ansicht sind sie dann nicht nur nicht parallel,
sondern auch in keinster Weise rechtwinkelig. So eine starke Verzerrung habe
ich bei anderen Häusern in der Online-Ansicht noch nie gesehen.

Grüße,
michi!


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


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

[Talk-at] at:maxspeed=Ortsgebiet auf bot-Korrekturliste setzen?

[wolfbert]

Hallo alle,

automatische Änderungen sind ein heikles Thema, dennoch möchte ich zur
Diskussion stellen, dieses Tag aus plan.at zur Löschung durch einen Bot zu
nominieren.

at:maxspeed=Ortsgebiet aus dem plan.at Import liefert keine für Mapper
nützliche bzw. zuverlässige Information und verleitet allenfalls zur Verwendung
ungebräuchlicher Tags (maxspeed=Ortsgebiet, at:maxspeed=50 etc.) bzw. zum Setzen
einer ungeprüften Höchstgeschwindigkeit. Die gängige Praxis scheint mir ohnehin
die manuelle Löschung zu sein.

Alle anderen at:maxspeed=* habe ich schon manuell zu maxspeed=* geändert.

xybot (http://wiki.openstreetmap.org/wiki/User:Xybot) läuft sowieso schon und
könnte das eventuell mit erledigen.

Andere Tags, die eventuell auch in Frage kämen, wären :acad-id=*, acad_id=*,
plan_at:acad_id=* sowie die zum plan.at gehörenden note und uploaded_by 
Tags. 

Liebe Grüße
Wolfgang


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

Re: [Talk-at] (kein Betreff)

[wolfbert]

Hallo Boris und Andreas,

sorry, von der Diskussion wusste ich nicht.

Aber, um Missverständnisse zu vermeiden: ich will nicht die plan.at
Kennzeichnung (fixme, source) oder inhaltliche Tags entfernen, der plan.at-Layer
bei osmi würde also weiterhin funktionieren. Ich dachte jetzt primär an das
at:maxspeed, das nun völlig unnötig ist.

Weiters geht es mir auch nicht darum, einen Anti-plan.at-Feldzug zu starten. Der
Import hatte seine Berechtigung, und es ist müßig, über verschüttete Milch zu
diskutieren. Man kann aber das Aufräumen unterstützen.

Ad Andreas: die große Lösung ist verlockend, aber ich halte das nicht wirklich
für realistisch. Einerseits gibt's schon eine Vermischung von plan.at und Edits,
da ist sehr viel Vorsicht nötig, dann sind nicht alle plan.at-Daten Müll, bloß
weil sie noch niemand bearbeitet hat, und manuelles Aufräumen ist sehr aufwändig
(wenn nicht nur gelöscht wird).

Ich bin eher ein Freund der Salami-Taktik - lasst uns fokussiert einfache Dinge
tun, deren Auswirkungen sich abschätzen lassen. Wir könnten die plan.at Seite im
Wiki für die Sammlung/Diskussion von Maßnahmen nutzen, und ein paar alte Hasen
(einschließlich W.W.) für die kritische Prüfung gewinnen. Bin jedenfalls gerne
dabei.

LG
Wolfgang


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

Re: [Talk-at] plan.at die X-te

[wolfbert]

Hallo,

also, vielleicht klappt's ja diesmal...

Ich habe unter
http://wiki.openstreetmap.org/wiki/WikiProject_Austria/plan.at/Abschluss alles
zusammengetragen, was mir derzeit so einfällt. Bitte sammelt alles relevante
Material dort.

In ein paar Tagen werde ich auch meinen keepRight-Klon wiederbelebt haben,
dann kann ich entsprechende Auswertungen kurzfristig online stellen.

Inzwischen ist natürlich niemand aufgehalten, weiter individuell an der
plan.at-Bereinigung zu arbeiten.

LG
Wolfgang


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

Re: [Talk-at] Schrittgeschwindigkeit 5 km/h

[wolfbert]

Hallo Boris,

Boris Cornet borisC@... writes:

 Und IMHO finde ich die maxspeed-Diskussion für Wohnstraßen obsolet.

Zugegeben eine Nebenfront, aber sie illustriert recht schön das Problem.

 livingstreet impliziert Schrittgeschwindigkeit, Punkt. 

Und residential impliziert 50... Was nicht in der Datenbank - explizit oder als
Default - hinterlegt ist, kann beliebig interpretiert werden. 

 Als (GIS-)Datenbankler sind mir Redundanzen zutiefst zuwider!

Was machst Du als (GIS-)Datenbankler bei osm? osm hat Redundanz und Verzicht auf
Datenmodellierung praktisch erfunden ;-) 
 
 Aber wenn schon, dann als maxspeed=walk oder so, wir sind doch weder
 Richter, die das auszulegen haben 

Tun wir auch nicht. Das macht der OGH. maxspeed=walk verschiebt das Problem nur
auf die Tabelle. Womit wir auch wieder bei zone:* und source:* wären...

LG
Wolfgang 





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

[Talk-at] Schrittgeschwindigkeit 5 km/h

[wolfbert]

Hallo alle,

Friedrich Volkmann hat im maxspeed-Thread darauf hingewiesen, dass
Schrittgeschwindigkeit 5 km/h sein sollte (derzeit im Wiki mit 7 km/h
eingetragen).

Die 7 km/h stammen vermutlich aus DE, wo es dazu Rechtssprechung gibt. In
Österreich tendieren die Gerichte, soweit am Internet ersichtlich, 
zu 5 km/h.

Ich schlage daher Folgendes vor und ersuche ggf. um Gegenstimmen (sonst 
setze ich das demnächst um):

- Eintrag in Default-Tabelle für Routing von 7 auf 5 ändern
- ev. Hinweis in How to map A 
- wenn source:maxspeed=(AT:)walk und maxspeed  5 - auf 5 ändern
- wenn highway=living_street und maxspeed  5 - Autor anschreiben

(falls maxspeed nicht getagged, dann wird auch nicht ergänzt)

LG
Wolfgang




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

Re: [Talk-at] source:maxspeed=AT:zone

[wolfbert]

Friedrich Volkmann bsd@... writes:

 
 On 06.03.2011 14:02, wolfbert wrote:
  Wieso AT:zone:
 
  a) weil die source:maxspeed Tags mit Ausnahme von sign so aufgebaut sind
 
 Bei denen hat das AT aber den Grund, dass urban bzw. rural je nach Land 
 verschieden sind. Gibt man in einem Tag jedoch eine 30er-Zone an, dann ist 
 das AT zwecklos, weil eine 30er-Zone in AT genau das gleiche ist wie eine 
 30er-Zone in Djibouti.

Stimmt natürlich. Solange es keine landesspezifischen Zonen gibt, kann es
meinetwegen auch zone30 o.ä. heissen. Hab' mich ans Wiki gehalten.

 
  b) im Grunde fände ich AT:zone:30 besser, wenn das mehr Anklang findet, 
  können wir das auch tauschen (sonst ist der 30er implizit)
 
 Den 30er in 2 verschiedene Tags hineinzuschreiben (maxspeed, 
 source:maxspeed) fände ich grundsätzlich nicht gut.

Siehe Diskussion im anderen Thread zu (source:)maxspeed. Klar braucht's nur
eines, aber das ist nicht der Stand der Dinge.

 
 Aber wahrscheinlich ist es trotzdem nötig, um verschachtelte Zonen abbilden 
 zu können. Beispiel: Fast ganz Wien ist eine 50er-Zone. Darin gibt es 
 30er-Zonen. Man kann nun z.B. source:maxspeed=zone:50;zone:30 setzen. Dabei 
 muss man sich nur um die Reihenfolge einig werden (innere Zonen voran oder 
 am Ende).

Was ist der Unterschied zwischen Ortsgebiet und 50er-Zone in Wien?
Verschachtelte Zonen kann es nicht geben, entweder es gilt 30 oder 50. 

LG
Wolfgang



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

[Talk-at] maxspeed, source:maxspeed etc.

[wolfbert]

Hallo alle,

ich habe mir die Verwendung von maxspeed in Österreich in Tagwatch angesehen.
Die einschlägige Diskussion ist verwirrend bis widersprüchlich, daher hier ein
Versuch einer Zusammenfassung/Interpretation. 

Vielleicht hilft es ja dem einen oder anderen. Verbesserungsvorschläge sind
natürlich willkommen. Falls Ihr das als nützlich anseht, habe ich noch ein paar
andere Themen auf Lager.

a) maxspeed=*

Enthält die normalerweise (d.h. für PKW) erlaubte Höchstgeschwindigkeit in
km/h (ohne Einheit), oder maxspeed=signals für elektronische Signalanlagen.
Anzuwenden in erster Linie für highway=motorway bis highway=unclassified
(darunter würde ich es allenfalls bei expliziter Beschilderung tun).

Anmerkung: maxspeed=country-code:* wird auch verwendet, ist aber a) mit
weniger Software kompatibel und wird b) durch source:maxspeed abgedeckt.

b) source:maxspeed=*

Enthält die Art der Bekanntmachung für den Autofahrer, besonders in Hinblick auf
implizite Limits. Folgende Werte sind bei uns gebräuchlich:

source:maxspeed=sign (+ maxspeed=*) bei Angabe durch Verkehrszeichen
source:maxspeed=AT:motorway (+ maxspeed=130) auf Autobahnen
source:maxspeed=AT:rural (+ maxspeed=100) auf Freilandstraßen
source:maxspeed=AT:urban (+ maxspeed=50) im Ortsgebiet
source:maxspeed=AT:walk (+ maxspeed=7) in Wohnstraßen und bei
Schrittgeschwindigkeit (ist Auslegungssache und liegt zwischen 4 und 7 km/h)
source:maxspeed=AT:zone:* (+ maxspeed=*) für Zone (z.B. 30er)

Generelle Defaults basierend auf Straßentyp/Land/Verkehrszone/Fahrzeugtyp sind
noch in Diskussion, eine Abbildung/Migration dahin ist aber so möglich.
Zusammengefasst: source:maxspeed sollte immer getagt werden, maxspeed immer wenn
source:maxspeed=sign, und bis auf weiteres sowieso immer weil die meisten
Programme das verstehen und es allgemein akzeptierte Defaultregeln noch nicht 
gibt.

c) Beschilderte Ausnahmen

Hier gibt es ein Proposal in Erweiterung zu access, d.h. (source:)maxspeed für
die normale Höchstgeschwindigkeit, sowie zusätzlich 

maxspeed:Einschränkung=* (z.B. maxspeed:wet=70, maxspeed:hgv=50)


Verglichen mit dieser Darstellung haben wir folgende Situation:

- 3.000 highways mit maxspeed und source:maxspeed
- 29.600 highways mit maxspeed ohne source:maxspeed 
- 250.000 highways ganz ohne (source:)maxspeed 
Mit Default-Regeln müssten zumindest die Ausnahmen getagt werden.

- 366 x maxspeed=AT:urban (besser maxspeed=50, source:maxspeed=AT:urban)
- 40 x maxspeed=Ortsgebiet (siehe oben)
- 31 x maxspeed=10 + highway=living_street (besser mit maxspeed=7 und
source:maxspeed=AT:walk, außer explizit so angegeben)
- ein paar kleinere Dinge, die mit fixme oder individuell zu lösen sind

- außerdem noch aus plan.at 58.500 at:maxspeed=* (zu löschen, sobald
(source:)maxspeed getagt)

LG
Wolfgang

Quellen:
Tagwatch - http://tagwatch.stoecker.eu/Austria/De/tags.html
How to map A - http://wiki.openstreetmap.org/wiki/DE:Howto_Map_A#G
Wiki maxspeed - http://wiki.openstreetmap.org/wiki/DE:Key:maxspeed
Wiki source:maxspeed - http://wiki.openstreetmap.org/wiki/Key:source:maxspeed
Proposal access tags - http://wiki.openstreetmap.org/wiki/Proposed_features/
Extended_conditions_for_access_tags
Limits je Land - 
http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed
Proposal traffic zones -
http://wiki.openstreetmap.org/wiki/Proposed_features/trafficzone



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

Re: [Talk-at] source:maxspeed=AT:zone

[wolfbert]

Hallo Norbert, 

da das Tag bisher praktisch ausschließlich von mir verwendet wird (daneben
gibt's noch 12x source:maxspeed=zone), eine kurze Erklärung:

Warum 30er-Zone extra: 

a) damit sich's ggf. mal ändern lässt (auch wenn's unwahrscheinlich ist)
b) damit andere Mapper (und ev. auch Programme) wissen, dass hier Schilder nur
an Ein- und Ausfahrt stehen
c) zur Prüfung auf Vollständigkeit - Zonen sind i.A. zusammenhängend, Ausnahmen
müssen explizit mit source:maxspeed=sign angegeben werden

Wieso AT:zone:

a) weil die source:maxspeed Tags mit Ausnahme von sign so aufgebaut sind 
b) im Grunde fände ich AT:zone:30 besser, wenn das mehr Anklang findet, können
wir das auch tauschen (sonst ist der 30er implizit)
c) es gibt dazu einige nicht abschließende Beiträge und Beispiele (siehe Wiki zu
maxspeed, source:maxspeed und traffic:zone)

Ich denke, es macht ungefähr soviel Sinn wie source:maxspeed ingesamt, also
besser gleich mit erfassen, als nachher rätseln.

LG
Wolfgang






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

Re: [Talk-at] Tiefgaragen und car sharing

[wolfbert]

Boris Cornet borisC@... writes:

 
 Hallo!
 
 IMHO ist es übertrieben, Fahrspuren einer Tiefgarage einzuzeichnen.


Hallo Boris, das war auch nicht mein Vorschlag, die Garage ist ja bloß ein
node. Was es aber ohnehin schon gibt, sind die Zufahrten.

 reservierten Abstellplätze punktgenau eingetragen sind - schaffst du
 das eigentlich mit den Angaben der Stellplatzliste?

Ich denke, so einigermaßen. Es werden ein paar Punkte bleiben, wo ich nur nach
der Adresse gehen kann, das muss dann jemand vor Ort vielleicht noch genauer
platzieren.

 Ich denke aber, dass es ausreicht, einigermaßen nahe an das Ziel
 herangeführt zu werden, die Tiefgarageneinfahrt findet man dann schon
 selbst (noch dazu, wo man die Tiefgarage ja schon kennt, schließlich
 ist man ja von dort losgefahren).

Leider nicht ganz. Die Einfahrt kann ganz anders zu erreichen sein als die
Ausfahrt, ev. nur über Nebenstraßen und Einbahnen (leidvolle Erfahrung...). Man
muss schon genau die Garageneinfahrt treffen (gilt natürlich nur, wenn's ein
ungewohnter Standplatz ist). Erschwerend kommt noch hinzu, dass die offiziellen
Adressen der Standplätze manchmal nicht bei den Einfahrten sind, und die Zugänge
ev. wieder woanders...

Relation würde mir auch gefallen, aber gerade auf einer Karte, die wie osm viel
mit Mobilität zu tun hat (ÖPNV, Routing) sollten die Verbindungen zu PR,
Mietwagen etc. explizit sein. Und es sollte möglichst gleich funktionieren.

Ich habe mal die schweizer Kollegen angeschrieben, die haben jenseits von 1000
Standplätzen... 

LG
Wolfgang



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

Re: [Talk-at] Tiefgaragen und car sharing

[wolfbert]

Andreas Labres list@... writes:

 
 Ich finde dieses Verbinden nicht optimal. 

Ich auch nicht.

 Vielleicht sollte man sich aber über die Platzierung des Garagen-Nodes 
 Gedanken
 machen. Den Zielpunkt bei der Hausnummer findet der Router durch eine Normale
 auf die Straße. Bei der Garage wird das aber schwierig, wenn die Abfahrt 
 früher
 aufhört. 

Parkplätze sind Verkehrsflächen und sollten IMHO immer mit einem highway
verbunden sein (Ausnahme: wenn nur als node dargestellt und nicht Tiefgarage).

Die Normale auf die Straße kann funktionieren, wenn der Router auch
highway=service einbezieht und der node nahe genug platziert ist.

Ich werde das vorläufig so versuchen (Beispiel siehe 1010 Morzinplatz oder 1010
Marriott Parkring).

Liebe Grüße
Wolfgang





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

Re: [Talk-at] Tiefgaragen und car sharing

[wolfbert]

Im Karlsruhe Schema habe ich auch noch die Relation roadAccess für Zufahrten
gefunden, nicht sehr verbreitet zwar, aber die nehme ich jedenfalls auch.

LG
Wolfgang


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

[Talk-at] Tiefgaragen und car sharing

[wolfbert]

Hallo,

zwei Fragen zu o.g. Themen:

a) In Österreich gibt es 356 nodes mit amenity=parking,parking=underground,
aber nur 22 ways. Ich nehme das als Bestätigung, dass es sinnvoll und üblich
ist, Tiefgaragen mit einem entsprechenden node (an der Einfahrt) zu taggen und
nicht flächig.

- Autofahrer suchen i.A. nach der Einfahrt
- das Ausmaß der Tiefgarage ist ohnehin schwierig festzustellen und weniger
relevant als die Oberfläche darüber

b) Ich habe das ok, die CarSharing Standplätze lt. offizieller Liste
einzutragen, was ich jetzt auch tue. In Wien liegen viele dieser Standplätze
aber in Tiefgaragen. Nun möchte ich sowohl einen node dazu haben (gerendert,
POI) wie auch eine direkte routbare Straßenverbindung (gerade für
Gelegenheitsnutzer ist es wichtig, wieder zum Standplatz zu finden). 

Da die Tiefgarage aber nur ein node ist, klappt das naturgemäß nicht sauber.
Daher folgender Lösungsvorschlag: der node der Garage wird mit einem kurzen
highway=service (ev. tunnel) an den car_sharing node angebunden, das erfüllt
beide Forderungen oben, auch wenn man an der Einfahrt die beiden Knoten ggf. so
anordnen muss, dass sie sich nicht gegenseitig überdecken. Ein Kompromiss halt.

Relationen scheiden aus, weil weder darstellbar noch routbar.

Ist das aus Eurer Sicht so ok?

Grüße
Wolfgang


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

Re: [Talk-at] XML, SQL...

[wolfbert]

Hallo Thomas,

es gibt natürlich verschiedene Wege, und ohne etwas experimentieren und
intensiverer Beschäftigung mit osm und der Technik wird's nicht gehen. 
Ich versuche es mal (und hoffe, der technische Slang ist Dir geläufig; mit 
ArcSDE habe ich keine Erfahrung):

- die Objekte nach denen Du suchst sind ways (Linien) mit den tags
highway=motorway,  highway=primary, highway=secondary, highway=tertiary
und den Verbindungen dazwischen 
(siehe http://wiki.openstreetmap.org/wiki/DE:Map_Features#Wege), nach aktuellem 
Stand mehr als 50.000 Liniensegmente

-teilweise sind die Straßensegmente auch in osm-Relationen zusammengefasst(also
alle Teile einer Straße in einer Liste)

- bzgl. Straßenklassifizierung wirf einen Blick auf die tags ref=, die die A,
B und L Nummern enthalten (siehe auch
http://wiki.openstreetmap.org/wiki/WikiProject_Austria); 

- zum Experimentieren installiere Dir Postgres/PostGIS (eine freie
SQL-Datenbank), das Datenimport-Werkzeug osmosis
(http://wiki.openstreetmap.org/wiki/DE:Osmosis) und lade die Österreich-Daten
von hier: http://download.geofabrik.de/osm/europe/ (.pbf); in Tabelle 'ways'
(bzw. 'relations' und 'relation_members') ist dann alles was Du brauchst
(geometry-Erweiterungen bbox und linestring im Schema gleich mit installieren);
osmosis kann auch gleich die Objekte vorfiltern (Optionen tag_filter und 
used_nodes)

- die Daten liegen auch als SHP oder XML vor (aber für die Analyse ist SQL wohl
flexibler); siehe auch http://wiki.openstreetmap.org/wiki/DE:Export (kleine
Gebiete kannst Du direkt aus der Hauptkarte exportieren, Reiter 'Export')

- bzgl. Update: wenn Du die Daten nur alle paar Tage erneuern willst (soviel
ändert sich da ja auch nicht), ist es am einfachsten, den ganzen
Österreich-Datensatz herunter zu laden und dann (möglichst ohne Umweg über SQL)
entsprechend zu filtern (osmosis + XML-basierte Vorverarbeitung, z.B.). Hängt
aber auch davon ab, was ArcSDE verdauen kann.

Ich hoffe, Du hast bis hierher durchgehalten... Es gibt sicher auch noch andere
Wege, mit diesem habe ich eben Erfahrung.

Alles Gute
Wolfgang 





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