Re: [Talk-at] PLZ und Ortsvorwahlen von Österreich

[andreas wecer]

Am Do., 10. Dez. 2020 um 06:35 Uhr schrieb Johann Haag :

> Du hast sicher bemerkt dass ich in Wien nun in OpenStreetMap, die
> Telefonvorwahl eingetragen habe, auch Eine Region in Vorarlberg ist bereits
> erfasst.
>

 "onk" ist übrigens kein korrekter Tag, wenn dann onkz
https://wiki.openstreetmap.org/wiki/DE:Key:onkz
Das wird auch nur in Deutschland verwendet, aber zumindest nennt die RTR
die Ortsnetzkennzahl auch so und mir ist kein internationaler Tag dazu
bekannt

Andreas Labres hatte offenbar auch einmal einige "ref:vorwahl" verteilt
https://taginfo.openstreetmap.org/keys/ref:vorwahl

ref=https://wordpress.com/post/openstreetmap.home.blog/438
ergibt überhaupt keinen Sinn
https://www.openstreetmap.org/relation/7872644
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] PLZ und Ortsvorwahlen von Österreich

[andreas wecer]

Die Suche nach Ortsnamen sollte besser nicht case-sensitive sein. Um
einiges interessanter ist allerdings sowieso die umgekehrte Suche nach
PLZ/Vorwahl.

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

Re: [Talk-at] Hausnummern in Puch bei Hallein

[andreas wecer]

Am Do., 19. Nov. 2020 um 14:26 Uhr schrieb Friedrich Volkmann :

> On 19.11.20 12:07, andreas wecer wrote:
> > Im konkreten Fall sind die alten Adressen aber zum Teil gar keine
> > Konskriptionsnummern und gab es diese vor der Neuadressierung auch schon
> wo
> > anders
> > Halleiner Landesstraße 44 war früher hier:
> > https://www.openstreetmap.org/node/5574660523
> > und ist jetzt hier: https://www.openstreetmap.org/node/5543882614
>
> Wenn das keine Konskriptionsnummer war, wo war dann Konskriptionsnummer 44?
>

44 dürfte es laut PDF nur einmal geben, aber es gibt bpsw. auch

Bachweg 73
Urstein Nord 73
Vollererhofstraße 73

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

Re: [Talk-at] Hausnummern in Puch bei Hallein

[andreas wecer]

Am Do., 19. Nov. 2020 um 10:38 Uhr schrieb Rudolf Mayer <
rudolf.ma...@gmail.com>:

> ich würde die alten Adressen schon in irgendeiner Form beibehalten - es
> gibt sicher noch massig Verweise auf die alten Adressen, im Web oder
> gedruckt, und ich glaube es wäre schon nicht schlecht, wenn man das in
> OSM noch irgendwie auflösen kann.
>
> Welche tag dazu am besten geeignet ist kann ich nicht sagen, hängt wohl
> (leider) von Nomatim ab, was dort ausgewertet wird, das ist schließlich
> wohl die Variante, über die meistens gesucht wird.
>

conscriptionnumber wird von Nominatim ausgewertet, es wird aber meines
Wissens nirgends gerendert, was so wie im folgenden Fall, wo die alten als
Konskriptionsnummern gelassen wurden, durchaus praktisch ist, da zwar beide
Adressen (die für sich auch eindeutig sind) gefunden werden, die
Darstellung aber nicht völlig chaotisch aussieht:
https://www.openstreetmap.org/search?query=Zemling%2093
https://www.openstreetmap.org/search?query=Manhartsbergstraße%2034%2C%20Zemling


Im konkreten Fall sind die alten Adressen aber zum Teil gar keine
Konskriptionsnummern und gab es diese vor der Neuadressierung auch schon wo
anders
Halleiner Landesstraße 44 war früher hier:
https://www.openstreetmap.org/node/5574660523
und ist jetzt hier: https://www.openstreetmap.org/node/5543882614
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Hausnummern in Puch bei Hallein

[andreas wecer]

Am Mi., 18. Nov. 2020 um 21:08 Uhr schrieb Friedrich Volkmann :

> On 18.11.20 20:37, scubbx wrote:
> > Ist die alte Adresse noch am Gebäude sichtbar? Wenn nicht, hat die
> > eigentlich keine Bedeutung mehr, weil ja nicht mehr existent.
> >
> >
> > Am 18.11.20 um 20:04 schrieb feneks via Talk-at:
> >> Das heißt, man könnte die momentan in OSM gespeicherten Adressen nach
> >> "addr:conscriptionnumber" verschieben?
>
> Erfahrungsgemäß bleiben die Konskriptionsnummerntafeln oft Jahrzehnte lang
> hängen, und auch in Kundendatenbanken usw. spuken sie noch viele Jahre
> herum.
>
> addr:conscriptionnumber ist für Konskriptionsnummern passend, aber
> unabhängig davon empfehle ich, die alten Adressen ins addr2:* Schema zu
> verschieben, damit es zu keinen Konflikten bzw. Fehlerinterpretationen
> kommt.


Das Erhalten der Konskriptionsnummern ist mMn. bei Ortschaften sinnvoll, wo
davor noch keine Straßennamen existiert haben und es keine Kollisionen mit
den neuen Adressen gibt.
Davon abgesehen haben aber, so wie ich das PDF oder die aktuelle Karte
interpretiere, auch schon vorher bei manchen Straßen Orientierungsnummern
existiert
https://www.openstreetmap.org/#map=19/47.70947/13.08754
https://www.openstreetmap.org/#map=19/47.70080/13.09815
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] ALS-Daten frei zugänglich

[andreas wecer]

Am So., 15. Nov. 2020 um 18:33 Uhr schrieb Florian Kratochwil <
flor...@kratochwil.at>:

> In JOSM ist das Geländemodell verfügbar unter Hintergrund -> Höhenkarte
> -> Basemap.at Gelände. Dieser Layer ist super hilfreich in Kombination
> von GPS-Spuren zur exakten Kartierung von Waldwegen, die man im Luftbild
> wegen den Bäumen nicht sieht
>

Ja, dafür (oder erst recht für Bachverläufe) ist es super und wird auch
verwendet, wie man an den Changesets der letzten Wochen mit source "
basemap.at Terrain" sieht:
https://tinyurl.com/yxdssosv

Im iD-Editor ist der Layer anscheinend standardmäßig nicht vorhanden. Ich
hatte eigentlich irgendwo im Hinterkopf, dass die dafür die gleiche Quelle
verwenden?
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Meinungen zu Access-Tagging

[andreas wecer]

Am Mo., 9. Nov. 2020 um 12:20 Uhr schrieb Rudolf Mayer <
rudolf.ma...@gmail.com>:

> finde auch, dass es viel sinnvoller ist, einen expliziten Tag zu
> verwenden der genau das abbildet, was Sache ist (Autofahren verboten),
> anstatt generell kein access mit allen möglichen Ausnahmen zu taggen.
>
> So hartnäckig fkv auch gerne manchmal über etwas diskutiert, wo evtl.
> nur er der Meinung ist - hier passt das auf jeden Fall!


Sehe ich auch so.  Ich habe aber auch das Gefühl, dass zum Teil auch der
iD-Editor an dieser Praxis mit Schuld ist.
vehicle wird dort im Standard-Formular nicht angeboten, im Gegensatz zu:

Alle
Fußgänger
Motorfahrzeuge
Fahrräder
Pferde

und ich sehe es auch öfter bei Neulingen, dass dann eben auch genau diese
Werte alle explizit angegeben werden, egal wie sinnvoll das oder auch die
gewählte Kombination für den entsprechenden Weg ist.

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

Re: [Talk-at] landuse: line oder multipolygon?

[andreas wecer]

Am Di., 28. Juli 2020 um 22:12 Uhr schrieb Stephan Bösch-Plepelits <
sk...@xover.mud.at>:

> Ganz einfach: Tools -> Create Multipolygon (Ctrl-B)
>

Die inverse Funktion gibt es über das JOSM-Plugin  Relation Toolbox ->
"Polygon rekonstruieren"
Aber wie gesagt: bitte nicht einfach nur dafür verwenden, um überall in
"fremden" Gebieten alles von einer Variante auf die andere zu ändern.

Andere sinnvolle Funktionen für den Bereich gibt es im Plugin utilsplugin2,
wie bspw. Split Area:
https://wiki.openstreetmap.org/wiki/JOSM/Plugins/utilsplugin2
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Irreführendes Nominatim-Ergebnis

[andreas wecer]

Am Do., 18. Juni 2020 um 23:52 Uhr schrieb Friedrich Volkmann :

> Eine Alternative zu Nominatim würden sicher viele begrüßen.
>

Photon, der Geocoder von komoot, funktioniert damit übrigens anscheinend
problemlos, auch wenn der auch auf Nominatim-Daten aufbaut.
Wobei auf der Demoseite photon.komoot.de der gleiche Fehler auftaucht, auf
www.komoot.de dagegen nicht mehr und dort wird nicht nur die falsche
Schelleingasse 8 herausgefiltert, sondern auch die korrekte
Alois-Drasche-Park 8 gefunden.

https://github.com/komoot/photon
https://www.komoot.de/plan/tour/d11At9JDwD54Cw=FuYABMoBI2A=/@48.1865220,16.3714850,17z
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Irreführendes Nominatim-Ergebnis

[andreas wecer]

Hallo,

spontane Vermutung, ohne es mir im Detail angesehen zu haben:

Nominatim braucht für street/place ein konkretes OSM-Objekt mit diesem
Namen. Wenn kein Straßenname angegeben ist, wird die Hausnummer der
nächstgelegenen Straße zugewiesen. Möglicherweise passiert das auch, wenn
der angegebene Straßenname nicht gefunden wird, was vermutlich hier der
Fall ist.

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

Re: [Talk-at] PLZ Import

[andreas wecer]

"survey" ist jedenfalls eine tolle Quelle für einen österreichweiten
PLZ-Import und "POSTCODE" kein korrekter key

Am Mo., 27. Apr. 2020 um 17:41 Uhr schrieb Thomas Rupprecht <
rupprecht.tho...@gmail.com>:

> Hallo,
>
> geo_sch  hat heute einiges an
> PLZ Polygonen importiert. Der import sieht aber nicht sehr durchdacht aus.
> Ich hätte auch nichts von einer Diskussion über so einen Import mitbekommen.
>
> Kann sich das noch wer andere ansehen?
>
> Beispiel changelog: https://www.openstreetmap.org/changeset/84206322
>
> mfg Thomas Rupprecht
> ___
> 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] Kartenmaterial Mils

[andreas wecer]

Hallo Klara,

wenn du auf der Komoot-Website Strg+Alt gedrückt hältst und auf die Karte
clickst, öffnet sich der entsprechende Kartenausschnitt auf
openstreetmap.org
Dort kannst du über das Sprechblasen-Symbol einen entsprechenden Hinweis
hinterlassen. Am besten verlinkst du dabei auch gleich auf deine
Komoot-Tour und setzt diese auf public.

Mittlerweile gibt es auch direkt in der komoot-App einen Button um
Routenprobleme zu melden, aber keine Ahnung was dabei passiert, mir wären
zumindest noch keine entsprechenden öffentlichen OSM-Hinweise aufgefallen.

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

Re: [Talk-at] Stop area groups

[andreas wecer]

Am Sa., 7. März 2020 um 16:26 Uhr schrieb Stefan Tauner <
stefan.tau...@gmx.at>:

> Ist seither irgendetwas passiert (Reaktion von ihm, irgendwelche
> Reverts, ...)? AFAICS ist das noch alles kaputt (und ich bezeichne das
> mit voller Absicht so).
>

Zumindest in Wien wurde anscheinend kürzlich einiges von gnlpfth
(ehem. Filius Martii) zurückgesetzt
https://www.openstreetmap.org/changeset/82716025

Reaktion gab es anscheinend nur insofern, dass er seit der Frage keine
Änderungen mehr in Österreich gemacht hat.
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Fehler bei Altenmarkt im Pongau

[andreas wecer]

Am Di., 28. Jan. 2020 um 19:37 Uhr schrieb Kevin Kofler <
kevin.kof...@chello.at>:

> Daher aber eine Frage an die Mapper-Kollegen, die mit Wintersport mehr am
> Hut haben als ich: Gibt es einen sinnvollen Tag (nicht einfach
> highway=track
> für den Renderer, was außerhalb der Rodelsaison dann Unsinn ist), den man
> da
> setzen kann und der auch gerendert wird?


Es ist ja eh als piste:type=sled getaggt, nur wird das eben nur auf
(manchen) Winterkarten angezeigt:
https://slopes.waymarkedtrails.org/#route?id=146871383&type=wayset&map=17!47.3602!13.4321
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Stop area groups

[andreas wecer]

Am Sa., 4. Jan. 2020 um 12:34 Uhr schrieb Robin Däneke <
robin.daen...@live.at>:

> Man könnte den User der das macht aber auch mal fragen, warum. Und ob er
> es nicht vielleicht zumindest etwas geographischer angehen könnte.
>
> Falls es sich dabei um den User Diego Sanguinetti handelt, der scheint für
> diese MAPS.me subway Gruppe zu mappen. Die haben ja leider auch eine eigene
> Vorstellung wie die Daten aussehen sollen...
>

Ja, es handelt sich in beiden Fällen um diesen User und Kevin hat das schon
getan: https://www.openstreetmap.org/changeset/78848893
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Stop area groups

[andreas wecer]

Ich habe mich auch gerade über die Verschachtelung bei diesem Node hier
gewundert:
https://www.openstreetmap.org/node/5959356915

Der bus_stop "Baden Landesklinikum" ist Teil der stop_area Relation "Baden
Landesklinikum (bus)", die nur aus diesem Node besteht und wiederum wie die
direkt nebenan liegende Relation "Baden Landesklinikum (WLB)" zur
stop_area_group "Baden Landesklinikum" gehört.
Die Suffixe tauchen nur in den stop_area Relationen und nicht in den
konkreten Stop-Nodes auf, also ist die Struktur an sich schon
nachvollziehbar, aber ohne mich näher mit dem public_transport Thema
beschäftigt zu haben, würde ich erwarten, dass stop_area_group komplexe
Stationen übersichtlicher machen und nicht einfache komplexer machen sollte.
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

[Talk-at] Statutarstadt Grenzen (war: name:suffix & name:prefix (de))

[andreas wecer]

Am Sa., 9. Nov. 2019 um 03:39 Uhr schrieb Robert Kaiser :

> IMHO ist diese Relation sowieso falsch (und ev. alle Statutarstädte).
> [..]. Das sollten IMHO zwei relationen mit zwei verschiedenen Namen und
> admin_levels sein,
> aber mit gleichen members.


Die einzelne Relation würde dem steinzeitlichen Wiki-Artikel entsprechen

Für Statutarstädte gibt es keine Gemeinde-Grenzen, da diese mit dem Bezirk
> ident sind.


der sich allerdings auch selbst widerspricht

Die Summe der Flächen aller Einheiten einer Ebene sollte jeweils das ganze
> Staatsgebiet umfassen, also ist jeder Punkt in Österreich sowohl einer
> Katastralgemeinde, einer Gemeinde, einem Bezirk, einem Bundesland und dem
> Bund selber zuordenbar.


https://wiki.openstreetmap.org/wiki/WikiProject_Austria/Gebietskörperschaften

Ich habe jetzt die restlichen Statutarstädte durchgeschaut

Nur Bezirksgrenzen (admin_level=6) haben:
Eisenstadt
Rust
Steyr
Villach
Wels

Bezirksgrenze (6) und Katastralgemeinden (10):
Linz
Salzburg

Bezirksgrenze (6) und Stadtbezirke (9):
Graz
Innsbruck
Klagenfurt

Bezirksgrenze (6) und Gemeindegrenze (8):
Krems
St. Pölten
Waidhofen
Wr. Neustadt

Land (4), Stadtbezirke (9) und Katastralgemeinden (10):
Wien

Soweit ich das sehe müssten die 16 Unterbereiche von Linz statt admin_level
10 auch 9 bekommen:

> Seit 1. Jänner 2014 (Beschluss des Stadtsenates vom September 2013) ist
> die Stadt in 16 statistische Bezirke eingeteilt

[...] Etwas abweichend davon gliedert sich die Stadt grundbücherlich in 14
> Katastralgemeinden

 https://de.wikipedia.org/wiki/Linz#Stadtgliederung

Es existierten auch schon in allen Fällen zusätzliche Gemeindegrenzen
(evtl. mit Ausnahme Wien), die mit diesen Changesets wieder entfernt wurden:
OSMCha: https://tinyurl.com/yjmhbw3d
und https://www.openstreetmap.org/changeset/24423298

was nur in NÖ durch fkv rückgängig gemacht wurde, siehe:
https://forum.openstreetmap.org/viewtopic.php?id=59448
und
http://osm-talk-at.1116557.n5.nabble.com/Talk-at-Loschung-bzw-Anderungen-von-ca-240-Grenzen-in-AT-td1821.html

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

Re: [Talk-at] name:suffix & name:prefix (de)

[andreas wecer]

Am Sa., 9. Nov. 2019 um 15:16 Uhr schrieb Robert Kaiser :

> Der Name der Stadt und der Gemeinde ist "Steyr", das stimmt. Der Name
> des Bezirkes ist allerdings "Steyr-Stadt" (hauptsächlich, weil es
> daneben noch "Steyr-Land" gibt).
>

Nein, Statistik Austria führt den Bezirk als "Steyr(Stadt)", wobei der
Zusatz in der Klammer allerdings (im Gegensatz zu "Steyr-Land" z.B.) kein
Teil des Namens ist:

Bei gleich- bzw. ähnlich lautenden Politischen Bezirken wurden – um
> Verwechslungen zu vermeiden – in Klammer die Zusätze „Stadt“ bzw. „Land“
> angefügt. Diese Zusätze stellen jedoch keinen Bestandteil des offiziellen
> Namens dar.


https://www.statistik.at/web_de/klassifikationen/regionale_gliederungen/politische_bezirke/index.html


Anscheinend wurde das auch einfach generell bei allen Statutarstädten
hinzugefügt, auch wenn es nicht einmal gleich- oder ähnliche lautende
Bezirke gibt, wie etwa bei Rust.
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] name:suffix & name:prefix (de)

[andreas wecer]

Am Sa., 9. Nov. 2019 um 00:54 Uhr schrieb PPete :

> Erstere ist bisher durch den Tag "ref:at:gkz" erfasst, zweitere finde
> ich gar keine. Die Bezirke sind derzeit mit mit dem GKZ getaggt,
> erhalten aber zumindest die richtige Nummer.
>

Der Bezirk wird (wie auch das Land) vom GKZ abgeleitet und entspricht den
ersten drei Ziffern.
Laut verstaubtem Wiki soll das beim Bezirk entsprechend auch als
dreistelliges GKZ abgegeben werden. Statutarstädte sind bzgl. GKZ nicht
explizit angegeben, aber nachdem das auch Gemeinden sind, würde ich es auch
fünfstellig für die Gemeinde angeben.
https://wiki.openstreetmap.org/wiki/WikiProject_Austria/Gebietsk%C3%B6rperschaften

Am Sa., 9. Nov. 2019 um 03:39 Uhr schrieb Robert Kaiser :

> IMHO ist diese Relation sowieso falsch (und ev. alle Statutarstädte).
> Der Bezirk heißt "Steyr-Stadt", die Gemeinde heißt "Steyr".


 Laut Wikipedia ist der Name "Steyr". Bei manchen Statutarstädten wie St.
Pölten und Wiener Neustadt gibt es nicht einmal (mehr) die Unterscheidung
mit "-Land/Umgebung", d.h. ohne die Präzisierung mit "Bezirk" oder anderen
Zusatzinformationen bzw. Abweichung vom offiziellen Namen sind die nicht
einmal unterscheidbar.
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Radweg R2 südlich von Graz...

[andreas wecer]

Am Sa., 2. Nov. 2019 um 22:53 Uhr schrieb Robert Grübler <
robgrueb...@gmail.com>:

> Sodala, die Restrukturierung des Murradweges ist fertig.


Danke. Die erfasste Länge von 725 km, nachdem alles doppelt gezählt wird,
finde ich etwas komisch, aber gut, dafür passt dann wieder die Länge für
linkes/rechtes Ufer und die Routen sind durchgängig.

Die groben km-Angaben hatte ich bei meinen Vorschlägen nur zur Orientierung
für die Einteilung, im Namen haben sie mMn. nichts verloren. Du könntest
sie allerdings als distance angeben, damit gröbere Abweichungen leichter
auffallen.
https://wiki.openstreetmap.org/wiki/Key:distance

"Sankt Michael" als Etappen-Ziel/Start ist nicht ganz eindeutig, da die
Route durch mehrere Sankt Michael verläuft.


> Was mir noch aufgefallen ist: Der Murradweg ist eigentlich eine
> internationale Route, obwohl es keine einheitliche Beschilderung gibt. Der
> Beleg dafür ist das Startschild:
> https://mehrlicht.keuk.de/2017/08/18/murradweg-2017-teil-1/ (2. Bild)
> "Legrad 456km"! Eine Fortsetzung bis nach Legrad wäre doch nett, oder?


Ich hatte ursprünglich angeregt den Murradweg von damals rcn auf ncn zu
erhöhen bzw. diese Kategorie überhaupt zu nutzen:
http://osm-talk-at.1116557.n5.nabble.com/Talk-at-Murradweg-quot-nationale-quot-Radwege-td1404.html

Das war auch das, wie die slowenischen/kroatischen Abschnitte damals noch
erfasst waren, mittlerweile wurden die wiederum auf icn erhöht, was im
Grunde ja auch passt, wenn es mittlerweile schon bei der Sticklerhütte
angeschrieben steht. Ich bin vor ~10 Jahren im Rahmen der Tour de Mur bis
Legrad gefahren, da war der kroatische Teil noch nicht mehr als eine Idee
ohne jegliche Markierung oder dezidierter Radwege.

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

Re: [Talk-at] name:suffix & name:prefix (de)

[andreas wecer]

Am Mo., 28. Okt. 2019 um 11:33 Uhr schrieb Florian Lohoff :

> Ich habe da überhaupt kein problem mit :suffix und :prefix - Wenn es
> eine Bildungsregel gibt wie man zum offiziellen Namen kommt.


Selbst wenn es die gäbe, kommst du damit nicht immer zum offiziellen Namen,
da sich der ja vom "common default name" unterscheiden kann, siehe
"Zwettl-Niederösterreich" oder das von dir angesprochenen "Werther
(Westf.)", das natürlich bei anderen Kartenanbietern sinnvollerweise auch
als "Werther (Westfalen)" aufscheint.
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] name:suffix & name:prefix (de)

[andreas wecer]

Am Mo., 28. Okt. 2019 um 09:48 Uhr schrieb Thomas Rupprecht <
rupprecht.tho...@gmail.com>:

> Was haltet ihr von diesen Varianten?:
>
> official_name=Marktgemeinde XYZ
> name=XYZ
>
> oder
>
> name=Marktgemeinde XYZ
> short_name=XYZ
>

Das wurde schon hier vorgeschlagen und ist das aktuelle im Osten
verbreitete Schema:
http://osm-talk-at.1116557.n5.nabble.com/Re-Talk-at-Grenzen-td270.html#a337

Im übrigen löst das auch das von Florian angesprochene Problem, dass
name:suffix/prefix weder vernünftig dokumentiert ist, noch nicht einmal in
Nachbargemeinden des selben Kreises konsistent verwendet wird und Auswerter
dann daraus wieder irgendwie einen offiziellen Namen basteln wollen, obwohl
es genau dafür schon einen Tag mit official_name gibt.

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

Re: [Talk-at] Radweg R2 südlich von Graz...

[andreas wecer]

Wofür es EINE Superroute braucht, ist mir schon klar, nur eine zusätzliche
Superroute, die wiederum 2 nahezu identische Superrouten enthält, halte ich
für unnötig.
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Radweg R2 südlich von Graz...

[andreas wecer]

Am Fr., 11. Okt. 2019 um 00:58 Uhr schrieb Robert Grübler <
robgrueb...@gmail.com>:

> Die Idee dahinter ist, dass beide Hauptrouten gleichwertig sind und dass
> beide lückenlos geordnet werden können. Somit sind die Längenangaben
> sinnvoll.
> Um den Wartungsaufwand zu verringern würde ich aus den gemeinsam genutzten
> Teilabschnitten ebenfalls Routen machen.
>
> Den Namen würde ich sichtbar künstlich erweitern. Etwa so:
>Murradweg ({HR; HL; Gx; Rx; Lx})
> damit das Sortieren der Teilrouten leichter fällt. Muss aber nicht sein.


Was die Namenserweiterung angeht, würde ich keine kryptischen Kürzel
verwenden, sondern die entsprechenden Etappen, evtl. auch mit Nummerierung
ähnlich der Abschnitte beim österreichischen EV6 (
https://cycling.waymarkedtrails.org/#route?id=2764556 )

Abs. 1 (Sticklerhütte - Judenburg) ~130km
Abs. 2 (Judenburg - Frohnleiten) ~100km
Abs. 3 Ostufer (Frohnleiten - Kalsdorf)
Abs. 3 Westufer (Frohnleiten - Kalsdorf) jeweils ~50km
Abs. 4 (Kalsdorf - Bad Radkersburg) ~70km
Verbindungsrouten

Die Vorteile der zusätzlichen Superroute-Ebene mit 2 durchgehenden Routen,
obwohl der überwiegende Teil völlig ident ist, überzeugen mich noch nicht
wirklich.
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Änderung von Bezirks- und Gemeindenamen in Tirol und Vorarlberg

[andreas wecer]

Am Do., 10. Okt. 2019 um 07:27 Uhr schrieb Johann Haag :

> Bereits seit mehreren Tagen beschäftigt mich eine Instabilität von OSM
> Nominatim. Beispiel Bizauer Straße 25a in der Gemeinde Bizau.
> Ich vermute nun, dass es zwischen diesen Problemen, und den von mir
> hinzugefügten Präfixen möglicherweise einen Zusammenhang gibt. Ich bin mir
> hierbei aber noch nicht ganz sicher. Bisher konnte ich folgende Logik
> feststellen. Ein Haus Nr. 25 wird gefunden
> https://www.openstreetmap.org/search?query=Bizauer%20Straße%2025#map=19/47.36808/9.93703
> 
>  ein
> Haus 25a hingegen nicht.
> Grüße Johann Haag
>

"Bizauer Straße" entspricht schon einmal gar nicht der von dir angegebenen
Adresse, denn die lautet "Oberdorf 25a, 6874 Bizau". Das wird von Nominatim
allerdings genauso nicht gefunden, weil es keinen Ort "Oberdorf" in der
Nähe gibt, aber bspw. von komoot oder magic earth.
Der Straßenname funktioniert bei Nominatim wohl nur eher zufällig weil
offenbar trotz angegebenen addr:place (oder weil eben dieser nicht gefunden
wird) auch die nächstgelegene Straße zugewiesen wird und die ist bei der
25a eben nicht die Bizauer Straße, sondern "Winkel", entsprechend findet
Nominatim auch ein "Winkel 25a, Bizau"
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Radweg R2 südlich von Graz...

[andreas wecer]

Es sollte wieder alles vorhanden sein. Jetzt könnte man das mit der
Superroute noch sinnvoller strukturieren, wobei ich eine Segmentierung in
kürzere Abschnitte gar nicht schlecht fände, denn die ursprüngliche
Relation hat mittlerweile über 1000 Änderungen und da nachzuvollziehen, wie
diese zustande gekommen sind und wo auf den ~400 Kilometern sich was
geändert hat oder ob das für die Radroute überhaupt irgendwie relevant ist,
ist etwas mühsam.

Am Di., 8. Okt. 2019 um 23:46 Uhr schrieb Robert Grübler <
robgrueb...@gmail.com>:

> Am Dienstag, 8. Oktober 2019 22:47 schrieb andreas wecer [mailto:
> andreas.we...@gmail.com]
>
> >Anscheinend ist der Radweg aber nicht durch die Restrukturierung von
> Roland5
> >Ende Juli verschwunden, auch wenn die dennoch etwas eigenartig ist.
> >Der Großteil der ursprünglichen Radroute ist bei  dieser nämlich offenbar
> >in der Relation 9708043 gelandet, die aber anscheinend als einzige der
> neuen
> >Relationen nicht in die Superrelation aufgenommen wurde.
>
> >cgu66 wollte dann vermutlich vor 5 Tagen diese Relation für den lokalen
> Radweg
> >"Mitterbergrunde"  kopieren, der großteils über den R2 verläuft, hat aber
> stattdessen
> >das Original geändert und dort das meiste davon entfernt.
>
> >Hier ist diese Relation vor: http://overpass-turbo.eu/s/MXb
> >und nach dieser Änderung: http://overpass-turbo.eu/s/MXc
>
> DANKE für das Overpass Muster! Super!
>
> Hmm, die Superroute enthält die R2 "Alternativrouten", die Relation
> 9708043 die "Hauptroute". Beides zusammen ergibt den ganzen R2.
> Die Aufteilung erscheint mir willkürlich, ich kenne keine "Hauptroute". Es
> ist weder ausgeschildert, noch vom Betreiber (Land Steiermark) so
> klassifiziert.
> Die Alternativen in eine Superroute zu sammeln ist auch merkwürdig.
> Ein seltsames Konzept von Roland5. Bin auf seine Argumente gespannt.
>
> LG Robert (robhubi)
>
>
>
> ___
> 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] Änderung von Bezirks- und Gemeindenamen in Tirol und Vorarlberg

[andreas wecer]

Am Do., 10. Okt. 2019 um 01:48 Uhr schrieb Robert Kaiser :

> Ich bin der Auffassung, dass in jeglichen
> OSM-Tags der Typ eines Objekts (oder einer Grenze) nichts im "name"-Tag
> verloren hat, sowas gehört immer in ein separates Tag, um Übersetzungen
> und automatisch verschiedene Darstellungsvarianten zu ermöglichen. Das
> trifft auch bei diesen Grenzrelationen zu
>

Bei den Iren steht "County" am Anfang, bei den Amis am Ende und auf
kroatisch ändert der Titel die Basisform. Das ist aber alles kein Problem,
wenn der "common default name" die gebräuchliche Bezeichnung incl. Titel
enthält und official_name die offizielle Bezeichnung.
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Radweg R2 südlich von Graz...

[andreas wecer]

Am Di., 8. Okt. 2019 um 21:49 Uhr schrieb Robert Grübler <
robgrueb...@gmail.com>:

> Danke für die Anleitung, ich konnte es lokal nachvollziehen. Und ja, es
> schaut gut aus. Einige kleine Lücken existieren, aber die lassen sich ohne
> Aufwand wieder schließen.
> Ich habe einen Kommentar zu CS-71449494   erstellt:
> https://www.openstreetmap.org/changeset/71449494#map=8/47.047/14.710
>
> Die R2-Relation war sicher nicht optimal aufgebaut, aber so kann es nicht
> laufen. Ohne vorherige Diskussion, mit einem fragwürdigen Ergebnis ...
> Ich bin für einen Revert, falls keine überzeugende Argumente von Roland5
> kommen.
>

Anscheinend ist der Radweg aber nicht durch die Restrukturierung von
Roland5 Ende Juli verschwunden, auch wenn die dennoch etwas eigenartig ist.
Der Großteil der ursprünglichen Radroute ist bei dieser nämlich offenbar in
der Relation 9708043 gelandet, die aber anscheinend als einzige der neuen
Relationen nicht in die Superrelation aufgenommen wurde.
cgu66 wollte dann vermutlich vor 5 Tagen diese Relation für den lokalen
Radweg "Mitterbergrunde"  kopieren, der großteils über den R2 verläuft, hat
aber stattdessen das Original geändert und dort das meiste davon entfernt.

Hier ist diese Relation vor: http://overpass-turbo.eu/s/MXb
und nach dieser Änderung: http://overpass-turbo.eu/s/MXc
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Radweg R2 südlich von Graz...

[andreas wecer]

Dieses Changeset sieht auch etwas auffällig aus:
https://www.openstreetmap.org/changeset/75258723

Mit Erstellung der Superroute hat Roland5 u.a. die Relation 9708043
angelegt, mit dem Namen "Murradweg", Note "main / west branch" und einer
Boundingbox in OSMCha, die so ziemlich den gesamten Bereich des
österreichischen R2 abdecken sollte.
Mit dem oben angeführten Changeset wurde das plötzlich mit Version 22 von
cgu66 auf "Mitterbergrunde", lcn, ref=MR umbenannt?


Am Di., 8. Okt. 2019 um 17:34 Uhr schrieb andreas wecer <
andreas.we...@gmail.com>:

> Am Di., 8. Okt. 2019 um 09:58 Uhr schrieb Lars Schimmer <
> l.schim...@cgv.tugraz.at>:
>
>> ist mir aufgefallen, das der R2 östlich
>> der bei Fernitz jetzt direkt an der Mur entlang geht und nimmer durch
>> Fernitz.
>> Wer hat denn das geändert?
>>
>
> Die Änderung bei Fernitz dürfte das hier gewesen sein:
> https://www.openstreetmap.org/changeset/71039876
>
> Aber viel wichtiger, es fehlt anscheinend fast der komplette Radweg
> https://cycling.waymarkedtrails.org/#route?id=31617&map=10!47.1006!15.2955
>
> Am Di., 8. Okt. 2019 um 16:26 Uhr schrieb PPete :
>
>> Ich weiß aber leider nicht wie man sich die Ways einer alten Version
>> einer Relation graphisch auf einer Karte oder im JOSM darstellen lassen
>> kann, hat da einer eine Idee? z.b. Version #1036 der Relation 31617. Das
>> war der Stand vor dem Erstellen der Superrelation.
>
>
> Daran, die Historie solcher Relationen nachzuvollziehen, bin ich auch
> schon öfter gescheitert.
> Was ich jetzt einmal lokal versucht habe: das Changeset 71449494 mit JOSM
> rückgängig machen, dann die Relation 31617 laden und alle Elemente herunter
> laden - das schaut dann auf den ersten Blick wieder vollständig aus
>
>
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Radweg R2 südlich von Graz...

[andreas wecer]

Am Di., 8. Okt. 2019 um 09:58 Uhr schrieb Lars Schimmer <
l.schim...@cgv.tugraz.at>:

> ist mir aufgefallen, das der R2 östlich
> der bei Fernitz jetzt direkt an der Mur entlang geht und nimmer durch
> Fernitz.
> Wer hat denn das geändert?
>

Die Änderung bei Fernitz dürfte das hier gewesen sein:
https://www.openstreetmap.org/changeset/71039876

Aber viel wichtiger, es fehlt anscheinend fast der komplette Radweg
https://cycling.waymarkedtrails.org/#route?id=31617&map=10!47.1006!15.2955

Am Di., 8. Okt. 2019 um 16:26 Uhr schrieb PPete :

> Ich weiß aber leider nicht wie man sich die Ways einer alten Version
> einer Relation graphisch auf einer Karte oder im JOSM darstellen lassen
> kann, hat da einer eine Idee? z.b. Version #1036 der Relation 31617. Das
> war der Stand vor dem Erstellen der Superrelation.


Daran, die Historie solcher Relationen nachzuvollziehen, bin ich auch schon
öfter gescheitert.
Was ich jetzt einmal lokal versucht habe: das Changeset 71449494 mit JOSM
rückgängig machen, dann die Relation 31617 laden und alle Elemente herunter
laden - das schaut dann auf den ersten Blick wieder vollständig aus
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Änderung von Bezirks- und Gemeindenamen in Tirol und Vorarlberg

[andreas wecer]

Am Do., 3. Okt. 2019 um 22:16 Uhr schrieb Friedrich Volkmann :

> > und die letzten Jahre hat es doch auch kein Problem damit gegeben
>
> Wenn du persönlich kein Problem damit hast, heißt das noch lang nicht,
> dass
> es keines gibt. Ich z.B. habe immer wieder Probleme damit, wenn ich für
> den
> Höhlenkataster den Gemeindenamen angeben muss und in der Karte die
> Gemeinden
> nicht von den Bezirken unterscheidbar sind. Wenn ich nicht mal als lokaler
> Mapper mit so einem Sauhaufen arbeiten kann, wie sollen gewöhnliche
> Anwender
> es dann erst können?
>

Nebenbei sollte man auch die Frage stellen, welches Problem durch die
Trennung eigentlich gelöst wird? Ich bin auch der Meinung, dass man es für
Gemeinden weglassen kann, aber beim Bezirk ist das dann ein entscheidendes
Unterscheidungsmerkmal. Darum heißen die ja auch in Deutschland "Landkreis"
oder in englischsprachigen Ländern "county" und wo stellt das ein Problem
dar, das durch die etablierten Tags official_name bzw. short_name nicht
sowieso schon gelöst ist?
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Änderung von Bezirks- und Gemeindenamen in Tirol und Vorarlberg

[andreas wecer]

Sehe ich das eigentlich richtig? Ein einzelner User hat vor 5 Jahren in
ganz Österreich alle möglichen Bezirke auf "name:prefix:at" umgetaggt,
wovon er nach einiger Zeit offenbar selbst nicht mehr überzeugt war
http://osm-talk-at.1116557.n5.nabble.com/Re-Talk-at-Grenzen-tt270.html#a382
http://osm-talk-at.1116557.n5.nabble.com/Talk-at-Gemeinde-Relationen-in-Osterreich-Abweichende-Schreibweisen-tp1288p1290.html

Es konnte anscheinend bis jetzt noch niemand erklären, was das ":at"
überhaupt soll, sondern es wurde mehrfach von verschiedenen Leuten darauf
hingewiesen, dass das überhaupt keinen Sinn ergibt
http://osm-talk-at.1116557.n5.nabble.com/Re-Talk-at-Grenzen-tp270p372.html
http://osm-talk-at.1116557.n5.nabble.com/Re-Talk-at-Grenzen-tp270p379.html
http://osm-talk-at.1116557.n5.nabble.com/Re-Talk-at-Grenzen-tp270p384.html
http://osm-talk-at.1116557.n5.nabble.com/Re-Talk-at-Grenzen-tp270p386.html
https://forum.openstreetmap.org/viewtopic.php?pid=732637#p732637

Dennoch wird es immer noch weiter verwendet und kommt mittlerweile 2429 mal
vor (während es bspw. gerade einmal 70 name:prefix:de gibt), weil die
Alternativen auch alle irgendjemand nicht passen, weil es mittlerweile
schon immer so war und weil von den Varianten mit der getrennten
Speicherung sowieso keine irgendwo unterstützt wird?
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Änderung von Bezirks- und Gemeindenamen in Tirol und Vorarlberg

[andreas wecer]

Am Mi., 2. Okt. 2019 um 03:00 Uhr schrieb eest9 :

> Doch es ist Redundanz, denn es kommt bereits in "name:prefix:at" vor.
>

Welche Anwendung soll "name:prefix:at" auswerten? Was soll das "at" hier
überhaupt?

Bekommen jetzt all diese Burgen auch ein "name:prefix:at"="Burg"?
http://overpass-turbo.eu/s/MMi

Oder diese Counties ein "name:prefix:ie"="County"?
http://overpass-turbo.eu/s/MMk

und diese ein "name:suffix:us"="County"?
http://overpass-turbo.eu/s/MMh

Am Mi., 2. Okt. 2019 um 00:29 Uhr schrieb Andreas :

> Funktioniert ja in Deutschland anscheinend doch, muss man immer eigene
> Süppchen kochen?


Mein Eindruck ist eher, dass Deutschland da sein eigenes Süppchen kocht und
das nicht durchgängig:
http://overpass-turbo.eu/s/MMm
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Fwd: Mittersill: gelöschte Schule wiederherstellen

[andreas wecer]

Am Mi., 18. Sept. 2019 um 07:45 Uhr schrieb :

> Wie kann man in der History eines Ausschnittes sehen was gelöscht wurde?
> Bzw. wie kann man gelöschte Objekte wieder herstellen?


Wenn man genau weiß, wo und was man sucht, ist das einfachste, was ich
kenne, immer noch Potlatch 1:
https://help.openstreetmap.org/questions/23631/how-do-i-find-and-recover-a-deleted-way

Du kannst es auch über Tools wie https://osmcha.mapbox.com/ oder
https://overpass-api.de/achavi/ finden und in JOSM per Datei->Objekt
wiederherstellen, wenn du die ID des Objekts kennst

Die Schule wurde offenbar durch dieses Changeset (oder eines der anderen
des Users) gelöscht: https://www.openstreetmap.org/changeset/68139322

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

[Talk-at] zahlreiche motorway_link auf motorway geändert

[andreas wecer]

Hallo,

ein User hat letztes Monat zahlreiche Autobahn-Auffahrten/-Rampen
von motorway_link auf motorway geändert (motorways die zuletzt von diesem
geändert wurden: http://overpass-turbo.eu/s/MgG ).
Auf Kommentare anderer User wurde bisher - wie schon in der Vergangenheit
beim Umtaggen diverser primary auf trunk (
https://www.openstreetmap.org/changeset/72233572 ) - nicht reagiert
https://www.openstreetmap.org/changeset/73700683
https://www.openstreetmap.org/changeset/73699392
https://www.openstreetmap.org/changeset/73699677

Mmn. sollten alle Changesets dieses Users, wo motorway_link geändert wurde,
rückgängig gemacht werden, falls jemand ein passendes Script dazu hat. Das
erste diesbezügliche dürfte das hier gewesen sein:
https://www.openstreetmap.org/changeset/72852700

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

Re: [Talk-at] Österreichs Hausnummern in OpenStreetMap unvollständig

[andreas wecer]

Am Fr., 16. Aug. 2019 um 11:16 Uhr schrieb Andreas via Talk-at <
talk-at@openstreetmap.org>:

> Ich habe zb.: diese Woche einen neuen Kreisverkehr zwischen Laxenburg
> und Münchendorf angelegt, den wirst du weder bei google, here oder
> basemap.at finden.
>

Tatsächlich gibt es den schon auf Google, was mich auch sehr überrascht
hat, nachdem dort immer noch Baustelle ist.
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Relationschaos nach Landesstraßenanpassung (Kreisverkehr Erstellung)

[andreas wecer]

Am Mo., 12. Aug. 2019 um 10:34 Uhr schrieb Kevin Kofler <
kevin.kof...@chello.at>:

> Und wenn du Ways neu erstellst (nicht durch Teilen bestehender Ways), mußt
> du sie natürlich ohnehin manuell zu den entsprechenden Relationen
> hinzufügen, egal mit welchem Editor du arbeitest. Hellsehen können die
> natürlich alle nicht. ;-)
>

Ja, aber es muss dabei auch öfter die gleiche Änderung mehrfach gemacht
werden, also ersetze Sequenz A durch Sequenz B für alle betroffenen
Relationen. Nachdem solche Änderungen bei mir aber dennoch noch nicht so
häufig vorgekommen sind, habe ich mich dann trotzdem nicht länger damit
beschäftigt, ob das nicht effizienter geht.
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Relationschaos nach Landesstraßenanpassung (Kreisverkehr Erstellung)

[andreas wecer]

Hallo,

Am So., 11. Aug. 2019 um 12:56 Uhr schrieb Andreas via Talk-at <
talk-at@openstreetmap.org>:

> Gibt es dazu einen leichteren Weg, oder ist es einfach mit den
> Relationen so kompliziert?


die Frage habe ich mir auch schon gestellt.

Was das Auftrennen des Kreisverkehres betrifft, bin ich auch erst später
draufgekommen, dass das - insbesondere bei kleinere Kreisverkehren - nicht
unbedingt zwingend notwendig ist und man diesen auch abstrakter als ein
geschlossenes Objekt ansehen kann. In der JOSM-Relationsansicht erscheint
er dann auch als Kreisverkehr-Symbol und bei Routen, die in beide
Richtungen befahren werden (was eher Radrouten als Busrelationen betrifft),
entstehen damit auch keine Lücken in der Relation. Spätestens wenn man die
Ein- und Ausfahrten aber als getrennte Ways erfassen möchte, steht man
wieder vor dem gleichen Problem.
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Zweiter Benutzer von addresshistory*org mit edits?

[andreas wecer]

Am Di., 16. Juli 2019 um 12:22 Uhr schrieb Frederik Ramm <
frede...@remote.org>:

> Sollte es ein "multi" von addresshistory*org sein, der damit in perfider
> Weise versucht, unser Aufräumen zu torpedieren, wäre das natürlich ein
> Grund, sämtliche Accounts erstmal für längere Zeit auf Eis zu legen,
> aber ich glaube jetzt mal an das Gute im Menschen und gehe davon aus,
> dass "Landeskarte" jemand anders ist.
>

Ja natürlich ist er das, was er hier nur mit "Nein! Doch! O..."
kommentiert hat:
https://www.openstreetmap.org/changeset/71951271

Das Verschleiern der Nodes dürfte er erst im letzten Changeset gemacht
haben, wobei "verschleiern" ja der falsche Ausdruck ist, es ist mehr ein
trotziges Trollen und Erschweren der Aufräumarbeiten.

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

Re: [Talk-at] minderwertige Importe

[andreas wecer]

Kann mir mal jemand beim (partiellen) Revert dieses Changesets behilflich
sein?
https://www.openstreetmap.org/changeset/71043071

Hier hat er existierende Adressen gelöscht, die kein addr:street oder
addr:place hatten, u.a. auch 200 vollständig angegebene Adressen, die nur
addr:hamlet statt addr:place hatten, wie diese hier:
https://www.openstreetmap.org/relation/2666001/history

Neben diesen hat er allerdings auch noch seine eigenen Duplikate gelöscht,
wobei er die aus irgendeinem Grund in diesem Changeset nicht direkt
gelöscht hat, sondern nur die Tags entfernt hat und die leeren Nodes
anschließend in einem anderen Changeset gelöscht hat
https://www.openstreetmap.org/node/6533111972/history
https://www.openstreetmap.org/changeset/71043190

Wenn ich jetzt #71043071 mit dem JOSM Reverter rückgängig machen möchte,
bekomme ich damit haufenweise Konflikte, weil es davon schon wieder die v3
gibt, wo sie im separaten Changeset gelöscht wurden. Ich könnte jetzt
annehmen, dass die Konflikte immer diese Fälle betreffen und daher einfach
alle Konflikte auf die Server-Version auflösen, aber so ganz wohl ist mir
dabei auch nicht.

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

Re: [Talk-at] minderwertige Importe

[andreas wecer]

Am Do., 11. Juli 2019 um 22:21 Uhr schrieb Michael Reichert <
osm...@michreichert.de>:

> Das Kriterium ist auf den ersten Blick machbar. Ich habe mir die
> Änderungssätze bislang noch nicht angeschaut, daher die etwas dumme
> Rückfrage meinerseits: Was tun, wenn ein v1-Node Mitglied eines
> hochgeladenen Ways ist, der geändert worden ist (also jetzt v > 1), oder
> später für einen Way verwendet worden ist?
>

Wenn die Daten inzwischen von jemand anderem bearbeitet wurden, kann das
meiner Meinung nach in den meisten Fällen als "kontrolliert" oder
"korrigiert" gewertet werden. Im allerschlimmsten Fall hat es sich
zumindest einmal jemand angesehen, solange nicht jemand anderes mit einem
großflächigen, mechanischen Edit darüber gefahren ist, aber davon ist
nichts bekannt.

> * Changesets mit dem Beginn "Fehlende oder neue Adressen*"
>
> Ab wann (Zeitpunkt) ist dieses Kriterium anzuwenden?


Das dürfte das erste Changeset außerhalb seiner Kernregion sein, ab wo er
nur noch großflächig importiert hat:
https://www.openstreetmap.org/changeset/70645289

also im Grunde geht es um diese Nodes:
node["at_bev:addr_date"="2019-04-01"](user:"addresshistory*org")(newer:"2019-05-27T00:00:00Z");out;

Die Changesets, wo er existierende Daten bearbeitet und großflächig
Adressen gelöscht hat, sind großteils schon wieder rückgängig gemacht.

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

Re: [Talk-at] minderwertige Importe

[andreas wecer via Talk-at]

Am Do., 11. Juli 2019 um 16:02 Uhr schrieb Andreas :

> Hättest du eine Validierung der Adressdaten vorgenommen, dann wäre dir
> das Attribut "BESTIMMUNGSART" aufgefallen und da kann man auf "Z"
> filtern und vola sind die Zähladressen weg.
>

Quelladresse und Bestimmungsart hatte ich mir schon einmal kurz angesehen,
aber sie sind nicht dazu geeignet seine Problemfälle zu identifizieren. Andere
Tests  sind da zwar
tlw. erfolgreicher, allerdings frage ich mich auch, ob es nicht wie schon
vorgeschlagen sinnvoller wäre alle Nodes mit v1 ab dem angesprochenen
Salzburg-Changeset zu löschen. Er halst nur allen anderen Ärger und Aufwand
auf, macht keinerlei Anstalten irgendetwas an den Problemen zu beseitigen
(ehrlich gesagt weiß ich allerdings auch nicht, ob wir das bei seiner
Vorgangsweise wirklich wollen - zumindest wurden im Moment noch wenig
existierende Daten geändert), feiert sich trotz aller Kritik und Probleme
weiterhin selbst für diesen Import und wenn sich lokale Mapper völlig
zurecht beschweren, weil in der zuvor vollständig erfassten Ortschaft
plötzlich alle Adressen verschwunden sind, können sie sich als Antwort auch
noch irgendwelche Vorwürfe bzgl. großer Lücken anhören
https://www.openstreetmap.org/changeset/71043800

Warum soll so ein Import nur in Zukunft nicht mehr vorkommen und dieser
hier toleriert werden, wo er innerhalb weniger Tage völlig unkontrolliert
hunderttausende Nodes importiert hat, ohne sich überhaupt irgendwelche
Gedanken zu machen, außer wie er die Limitierung beseitigen kann, dass die
Daten gesperrt und auf Straßenebene segmentiert sind? Und das obwohl ihm,
wie JM82 im Forum
 richtig
bemerkt hat, seit mind. 3-4 Jahren immer wieder erklärt wird, dass diese
Daten auch fehlerhaft sind und er sie nicht einfach in Gegenden, zu denen
er überhaupt keinen Bezug hat, völlig unreflektiert übernehmen soll.
Und jetzt sitzt ihm schon wieder ein Floh im Ohr, dass sein Vorgehen
eigentlich völlig ok war und nur eine minimale Änderung an den Daten
notwendig wäre.

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

Re: [Talk-at] Österreich Open Data Adresslisten des Bundesamt für Eich und Vermessungswesen, gejammt.

[andreas wecer]

Am Mi., 26. Juni 2019 um 16:35 Uhr schrieb Johann Haag :

> Daten des BEV sind über jeden Zweifel erhaben
>

ja eh, darum importierst du überall solche Sachen:

https://i.imgur.com/mSwVihv.png
101 übereinander gestapelte Adressen mitten im Schilfgürtel

https://i.imgur.com/LsxtHiu.png
jede Adresse hat irgendeine andere der Straßen um den See zugewiesen,
vereinzelt gibt es die Straße dort überhaupt gar nicht und auch die
Hausnummern alleine sind großteils nur irgendetwas und haben nichts mit der
Realität zu tun. Ich habe keine Ahnung, wie es zu einem derartigen Blödsinn
in der Form kommen kann. Wenn man absichtlich Fehler einbaut, um
Lizenzverstöße zu finden, würde das ja deutlich subtiler aussehen als so,
wo sofort etliche unterschiedliche Plausabilitätsprüfungen anspringen
können. Die Verortung muss dort wohl nach dem Prinzip, "dort sind noch
nicht viele Punkterl", erfolgen.

https://i.imgur.com/kzH9GaY.png
und nochmal 150 übereinander gestapelte Adressen in der Mitte der Siedlung,
was sicher ein viel besseres Ergebnis liefert, als wenn man einfach zu
einer der Straßen routet...

Aber hey: regio-osm ist schön gelb und bei den zu hunderten übereinander
liegenden Adressen hast du ein fixme gesetzt, nachdem sich JOSM darüber
beschwert 🙄

Warum glaubst du, wurden die Daten bisher von allen anderen nur
kontrolliert zur Unterstützung und zum Vergleich verwendet und nicht schon
vor langem in einem Rutsch importiert, was hier zahlreiche Leute deutlich
sauberer hinbekommen hätten? Wie schon Frederik sagte, sind die Nodes
alleine ohne Kontrolle, ohne andere Daten und ohne Mapper, welche die Daten
pflegen und originäre hinzufügen wertlos und können genauso direkt extern
eingebunden werden.

Pseudoadressen sind an einer Neubaustraße entlang vergebene Zähladressen.
> Eine Besonderheit im Osten von Österreich, im Westen unbekannt.


Ich muss zugeben, ich verstehe es auch immer noch nicht ganz, aber auf der
anscheinend grünen Wiese verstreute Adressen gibt es in Tirol zumindest
genügend
https://www.openstreetmap.org/node/6445735318
https://www.openstreetmap.org/node/6445735089
https://www.openstreetmap.org/node/6467554894
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] minderwertige Importe

[andreas wecer]

Hallo,

Am Sa., 8. Juni 2019 um 12:03 Uhr schrieb Frederik Ramm :

> 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.


Auch wenn er oft mit dem Holzhammer daher kommt, sollten wir nicht aus
Reflex ebenfalls zu diesem greifen und ohne zu schauen, was dabei überhaupt
geändert wurde, Monate oder gar Jahre von Changesets zurücksetzen, die dann
auch zahlreiche andere User betreffen (schlussendlich alle), welche
angenommen hatten, dass Gewisse Daten in einer Gegend schon vorhanden /
korrekt waren.

Ich habe einmal für die Bezirke Baden und Bruck an der Leitha versucht die
meisten Problemfälle tlw. automatisiert zu beseitigen
.

Wenn ich das richtig sehe, haben die großflächigen "Fehlende oder neue
Adressen..." Changesets außerhalb seiner Kernregion aber sowieso erst vor
etwa 2 Wochen in Salzburg begonnen:
https://www.openstreetmap.org/changeset/70646116
bzw. die ersten in Vorarlberg vor ca. einem Monat:
https://www.openstreetmap.org/changeset/70248289

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

Re: [Talk-at] Postleitzahlen

[andreas wecer]

Ich habe mal interessehalber den Zusammenhang Gemeinden - PLZ mit den
BEV-Daten ausgewertet. Ehrlich gesagt hätte ich eine größere
Übereinstimmung erwartet, es gibt:

2096 Gemeinden, davon 1014 mit mehr als einer PLZ

2221 Postleitzahlen, wovon 1059 über mehr als eine Gemeinde gehen (wiederum
30 davon enthalten nur vollständige Gemeinden und benötigen somit keine
zusätzlichen Grenzen)

In 597 Fällen stimmen Gemeinde- und PLZ-Grenzen - zumindest basierend auf
den aktuellen existierenden Adressen - exakt überein

csv-Dateien dazu:
https://drive.google.com/drive/folders/1Jsq6TyG-orJlS1TmntummRTa1iWco6ou

Teilweise läuft es auch entlang von Katastralgemeindegrenzen, aber das
lässt sich aus diesen Daten alleine nicht beurteilen und die fehlen sowieso
ebenso oft in den OSM-Daten, wären aber von manchen Ländern als OGD
erhältlich.

Grüße
Andreas
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Werde Teil der OpenStreeetMap Familie

[andreas wecer]

On Mon, Nov 5, 2018 at 1:30 PM  wrote:

>
> Am 05.11.18 um 12:52 schrieb Friedrich Volkmann:
>
>
> Das kann ich nicht empfehlen, solang es mit Wochennotiz und anderem
> Offtopic-Spam zugespammt ist und keiner der Moderatoren etwas dagegen
> unternimmt.
>
> Wochennotiz = Offtopic-Spam? Schäm dich.
>

Auch wenn ich sie inhaltlich schätze, kann ich dem Zuspammen dennoch
zustimmen, denn warum jede Ausgabe einen eigenen "Thread" in mehreren Foren
braucht, und warum nicht ein Sammelthread dafür reicht, verstehe ich auch
nicht. Meistens besteht der "Thread" sowieso nur aus der Ankündigung, wobei
Kommentare und Diskussionen dazu IMHO ohnehin direkt beim Blog-Eintrag
selbst besser aufgehoben sind. Das Schweiz-Forum mag man jetzt als tot
bezeichnen, aber dort ist überhaupt praktisch nichts anderes mehr zu sehen.
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Quantität vor Qualität beim BEV-Adressimport?

[andreas wecer]

On Tue, Aug 28, 2018 at 7:33 AM  wrote:

> Meiner Erinnerung nach wollte geocodec in Wien ein eigenwilliges
> Adressschema einfuehren, hier scheint es sich jetzt um einzelne
> Mappingfehler zu handeln - die ich schon zu Hauf von anderen Usern gesehen
> habe.
>

Dass es einen Unterschied zu Wien gibt und ein Massenrevert hier überzogen
und kontraproduktiv wäre sehe ich aktuell auch so, das unabgesprochene
Drüberfahren mit dem persönlich bevorzugten Schema gibt es hier aber auch,
wenn auch weniger drastisch in seiner Auswirkung: alleine in dem einen
Changeset wurden bei 200 Gebäuden die vorhandenen Adressen bei den Gebäuden
gelöscht und stattdessen ein Node gesetzt. Kann man jetzt argumentieren
beim Mergen von Adressnodes mit Gebäuden macht man das gleiche nur
umgekehrt und das könnte auch irgendjemand nicht passen, aber das kommt
halt auch auf die lokalen Konventionen an. Großflächiges Umtaggen, ohne das
vorher besprochen zu haben, oder einem klaren Konsens, dass eine Variante
eindeutig besser/schlechter ist, halte ich jedenfalls für eine ziemliche
Unart.

Die Aussage, "Was dem amtlichen BEV genügt, sollte einstweilen auch für OSM
ausreichend sein", finde ich einigermaßen originell, nachdem er an anderer
Stelle auch schon selbst festgestellt hat, dass die BEV-Daten in manchen
Gegenden auch oft ungenau und falsch sein können und während man das beim
Eintragen zum Teil noch ganz gut entdecken kann, würde ich ja gerne wissen,
wie er diese Nadeln dann noch zu finden gedenkt, "sobald er mit seinem
Heuhaufen fertig ist".

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

Re: [Talk-at] Vervollständigung der Wiener Adressen

[andreas wecer]

On Wed, May 30, 2018 at 12:11 AM Markus Straub 
wrote:

> Als OGD sind unter
> https://www.data.gv.at/katalog/dataset/1d5c2411-9719-4c8f-b99d-57a5f4a4ae41
> insgesamt etwa 286.000 Adressen enthalten, allerdings sind hier z.B.
> Albertplatz 7/1 und Albertplatz 7/2 jeweils gesonderte Einträge - reine
> Hausnummern sind es weniger.


Mit dem BEV-Datensatz vom April komm ich auf ca. 149.000 reine Hausnummern
für die Gemeinde Wien und 127.000 Subadressen. Letzteres bzw. das
Verhältnis erschien mir etwas viel, allerdings werden auch die durch
Identadressen mehrfach gezählt (v.a. die Parzellen der Kleingartenanlagen
werden dadurch tlw. bis zu 10x gezählt), also wenn man diese nur mehr
einmal für die Hauptadresse zählt, halbiert sich das schon auf 66.000, was
man dann noch auf die größten Prefix-Gruppen aufgliedern kann:
30.000 "/"
13.000 "Haus"
13.000 "Parz."

Direkt vergleichbar macht es das aber natürlich genauso wenig, weil bei den
OSM-Daten genauso Subadressen dabei sind (oder je nach Mapping-Stil sein
können), oder auch mehrere POIs die gleiche Hausnummer haben können.
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Vervollständigung der Wiener Adressen

[andreas wecer]

Ich habe in den letzten Tagen ein paar Adressen in Favoriten ergänzt, wobei
auch in meiner unmittelbareren Umgebung im südlichen Speckgürtel
diesbezüglich noch genügend zu tun wäre.
An Tools verwende ich die regio-osm Hausnummernauswertung:
http://regio-osm.de/hausnummerauswertung/auswertung_auswahlort
Wie bei allen Hilfsmitteln ist auch dieses mit Vorsicht zu genießen. Es ist
bspw. sehr penibel bei der Schreibweise, matcht dabei auch nur den Namen
und nicht auch official_name (ich gehe davon aus, alt_name auch nicht) und
neben Identadressen an Straßenecken, von denen die Hausbesitzer gar nichts
wissen, kenne ich in meinem Heimatort auch Adressen, die gar nicht
existieren, weil an der Stelle neue Straßen eingezogen wurden. Also es ist
ein tolles Hilfsmittel, aber die Prozentanzahl sollte man wie immer bei so
etwas nicht als die reine Wahrheit ansehen.

Ansonsten sind natürlich der schon erwähnte Address Helper und auch der
JOSM-Stil Coloured Streets empfehlenswert

On Sat, Feb 24, 2018 at 7:12 PM Markus Straub 
wrote:

> Abseits der Stiegendiskussion gibt es ja noch
> genügend klare Fälle von Einfamilienhäusern in der Peripherie


Dort gibt es dann dafür mehrere Reihenhäuser an einer Adresse ;p
Im Übrigen formatiert die Suche beim Wiener Stadtplan diese nicht immer nur
mit "/1", sondern auch schon mal als "(HAUS 1)", wie es auch vor Ort oft
angeschrieben ist.
https://www.wien.gv.at/stadtplan/grafik.aspx?lang=de-AT&bookmark=ebeKRtT-cmEVwDc1D1rNGQ-a5Rphlnqnnkur2pH4Oprw-b-b&bmadr=10458379

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

Re: [Talk-at] "geocodec/Socke/Johann Haag" stummschalten

[andreas wecer]

Wenn ich kompetenztechnisch inhaltlich noch etwas zur nicht
funktionierenden Suche anmerken darf: das eigentliche Problem sehe ich
darin, dass Nominatim öfter gar kein Ergebnis findet und es nicht schafft,
ein weniger spezifisches zu liefern, also bpsw. "Davidgasse 76-80" statt
"Davidgasse 76-80/14/10" - und eigenartigerweise funktioniert genau dieses
Beispiel jetzt bei Nominatim, während Volkis Nachbarn dagegen schon wieder
nicht mehr so viel Glück haben. Photon (die Such-Engine von komoot) wirkt
da bspw. nicht so erratisch.
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] "geocodec/Socke/Johann Haag" stummschalten

[andreas wecer]

On Tue, Feb 20, 2018 at 9:55 AM  wrote:

> Ich spreche mich gegen ein "stummschalten" aus, weil geocodec immer noch
> ein Mitglied der Community ist, das viel (auch kontroversielles)
> beigetragen hat. Die Vorwuerfe und Anschuldigungen sind entbehrlich, aber
> gehen aus meiner Sicht nicht so weit, dass man jetzt gleich die
> Konversation abdrehen muss!
>

Ich habe nicht das Gefühl, dass die Konversation irgendwo hinführt, außer
zu weiteren absurden Vorwürfen und Anschuldigungen, aber stimmt schon,
komplett stumm schalten ist auch keine Lösung.

On Tue, Feb 20, 2018 at 7:57 AM Johann Haag  wrote:

> unser Vorbild basemap  https://i.imgur.com/E47uhmj.png und Stadtplan
> Wien
> https://www.wien.gv.at/stadtplan/grafik.aspx?lang=de-AT&bookmark=nzA-cRnepO0ZPJ9FDUA9dQ-a5Rphlnqnnkur2pH4Oprw-b-b


auch da wird keinen privaten Grundstücken aufgrund des jeweiligen
Untergrunds die Eigenschaft als Wohngebiet abgesprochen und auch in deinem
zitierten Proposal steht fett "area:highway is NOT a kind of landuse"

On Tue, Feb 20, 2018 at 6:54 AM Johann Haag  wrote:

> Seltsamerweise sind genau jene Elemente welche Karten für Menschen smart
> und nützlich machen (z.b. eine funktionierende Adress Suche) dem osm
> Projekt entsagt

die funktionierende Suche ist ein Problem der Software und nicht der Daten.
Du magst die Daten in manchen Fällen so hinbiegen können, dass Nominatim
damit etwas besser klar kommt, aber dann haben wir schlechtere Daten und
noch immer keine funktionierende Suche - siehe mein Bsp., siehe Peters
Mail, siehe Volkis Mail, siehe Bugtracker, oder verwende einfach Nominatim
und dann sag mir, dass du bis auf Untereinheiten von Adressen, die
eigentlich schon ein vglw. nebensächlicher Spezialfall sind, alles
einwandfrei finden kannst.

On Sun, Feb 18, 2018 at 10:29 PM Johann Haag  wrote:

> Die adresse Velmerstraße 1a, gibt es aufgrund der Anwendung von Unit
> Adresse doppelt,
> OSM Nominativ löst unit nicht auf.
> Du kannst das mittels:
> [...]
> addr:housenumber=1a/1
> lösen.

Die Erklärung ergibt keinen Sinn, nachdem es ja gefunden wird, wenn der
Suchbegriff um "Gemeinde" erweitert wird. Wenn dich das immer noch nicht
überzeugt, kannst du das Spielchen auch mit jeder anderen Hausnummer in der
Straße machen, die keine units hat. Mit "1a/1" hättest du dann genau das
gleiche Problem.
Das Erfassen neuer Adressen finde ich grundsätzlich begrüßenswert, egal ob
erst einmal mit Appendix oder mit Unit, wenn sie sonst passen (einige hier
werden das anders sehen, aber mit dem plan.at-Chaos ist das dennoch nicht
vergleichbar), aber ein Auflösen von vorhandenen Units sehe ich als
Vandalismus an. Du verweist selbst immer wieder auf den Wiener Stadtplan
und nennst es sogar als "Vorbild", aber dieser schafft es Adressen und
Stiegen unterschiedlich und übersichtlich darzustellen - wenn du das
ebenfalls erreichen möchtest, musst du die Daten auch entsprechend erfassen.

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

Re: [Talk-at] "geocodec/Socke/Johann Haag" stummschalten

[andreas wecer]

On Sun, Feb 18, 2018 at 8:27 PM Johann Haag  wrote:

> Zur Beruhigung Deines Gemütes [...]
> micromapping mapping exempel:
> https://www.openstreetmap.org/#map=19/47.52588/12.39863
>

Nicht auch noch zur "Beruhigung des Gemüts" dein eigenwilliges
Löcherschneiden in Residentials, nachdem asphaltierte Teile eines
Grundstücks kein Wohngebiet sein sollen und von dem du genau weißt, dass
dir dabei noch jedes Mal von allen widersprochen wurde. Wie bei allen
anderen Themen interessiert dich die allgemeine Meinung aber herzlich
wenig, während du allen anderen die wildesten Motive und
Verschwörungstheorien unterstellst. Besonders amüsant ist ja deine
Vorstellung der "Allianzen", als würdest du es mit deiner Art nicht ganz
von selbst schaffen, jedem furchtbar auf die Nerven zu gehen. Ich werde
deine Nachrichten jetzt auch filtern und versuchen zu ignorieren, das ist
sinnlos, führt zu nichts und regt nur auf.
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

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

[andreas wecer]

On Sun, Feb 18, 2018 at 11:13 PM snupo  wrote:

> Die Klederinger Straße 70
> 
> könnte der Renderer in der Tat schöner zeichnen. Einiger Aufwand ist schon
> nötig, wir erwähnt wurde muss erst die implizite Gesamteinheit erkannt
> werden (eine Berechnung die dann für jede(!) Hausnummer zu machen wäre, bei
> der es irgendwo Units gibt), um dann dahinter nur noch die Units zu
> zeichnen. Das alternativ vorgeschlagene Gesamtpolygon für die gesamte
> Anlage würde das vereinfachen und die Hierarchie stärker modellieren, aber
> so wie es jetzt ist, das Polygon würde aber vermutlich neue Probleme
> aufwerfen.


Ja, ich fände das Gesamtpolygon auch die schönere Lösung, aber leider
herrscht ja bei OSM die Stimmung, Relationen sind böse und sollten
möglichst vermieden werden, wenn es irgendwie anders geht.  Das
beschriebene Problem mit der Inkonsistenz Gußriegelstraße vs.
Gussriegelstraße würde ja mit associatedStreet nicht existieren. Meiner
Meinung nach ist das mehr ein Problem der Editoren, aber vielleicht habe
ich auch nur die anderen Nachteile noch nicht gesehen.
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

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

[andreas wecer]

On Sun, Feb 18, 2018 at 8:19 PM Robert Kaiser  wrote:

> Gleiches gilt für Nominatim, wobei der im gesamten wohl auch gröbere
> Änderungen als nur diese eine braucht.
>

Ja, da gibts gröbere Probleme. Es ist mir bspw. ein wenig ein Rätsel, warum
"Velmerstraße 1a, Münchendorf" keine Adresse liefert, "Velmerstraße 1a,
Gemeinde Münchendorf" dagegen schon...
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

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

[andreas wecer]

>
> addr:housenumber=76-80/1
> addr:postcode=1100
> addr:street=Davidgasse
> addr:unit=1


Ich verstehe noch immer nicht, was du mit dem doppelten Angeben der Stiege
bezwecken möchtest  - das bewirkt ja nur, dass eine Software, die addr:unit
unterstützt, es wie osm.org doppelt als "76-80/1 1" darstellt?

Generell bin ich der Meinung, dass das eine 100% richtige und immer
anzuwendende Schema zwar wünschenswert wäre, ein wenig Pragmatismus aka
mappen für  aber in geringem Umfang tolerierbar ist. Wenn ich mir
z.B. die Klederinger Straße 79-81 ansehe:
https://www.openstreetmap.org/#map=19/48.13101/16.42383

fkv steigt ob der vielen Redundanzen in den OSM-Daten zwar zurecht die
Grausbirn auf, es ist aber wegen seiner Einfachheit die etablierte Form bei
OSM. 93% aller addr:unit haben auch ein addr:housenumber angegeben und auch
wenn es im Wiki nicht so eindeutig beschrieben ist und man den Abschnitt,
"Further address tags are optional, since they can usually be determined
from the boundary relations (if present and valid)", auch equivalent für
Hausnummern zu Units interpretieren könnte, ist es beim Proposal für
addr:unit auch nur mit voller Adresse vorgestellt.
Insofern halte ich das erst einmal für die logisch korrekte Form, die ich
verwende - das Problem dabei ist allerdings, bei der aktuellen
Unterstützung für addr:unit vereint es auf osm.org (und mir ist kein
Produkt bekannt, wo es aktuell groß anders wäre) im Moment nur die
Nachteile: es ist bei den kleinen, eng beieinander liegenden Einheiten
extrem unübersichtlich, wenn bei jedem "79-81 25" gerendert wird und
gleichzeitig kann auch nicht danach gesucht werden.
Nachdem es sowieso nur einen gemeinsamen Zugang gibt, hätte ich also in dem
Fall dort einen Node mit "79-81" angelegt (alternativ ein Mulitpolygon über
alle Gebäude) und die Units ohne Hausnummer gelassen.
Bei Fällen wie der Davidgasse dagegen, wo die Stiegen weiter auseinander
liegen und sich die Zufahrt dadurch ändert, finde ich es als Workaround
auch ok, die Stiege direkt zur Hausnummer zu schreiben und als eigene
Hausnummer anzusehen, solange addr:unit so schlecht unterstützt ist.

Aber wie schon erwähnt, ist das sowieso Jammer auf hohem Niveau und wenn
ich mich nicht täusche, sind die Stiegen auch nicht in der BEV-Liste und
bspw. Google findet genauso wenig die Davidgasse 76-80/15 und kann sie auch
nicht anzeigen. Entscheidend sollten noch nicht vorhandene Adressen und
keine Untereinheiten sein, wobei das mit den Ident-Adressen und so riesigen
Blöcken mit mehreren Gebäuden, wie beim Anna-Boschek-Hof, ohne lokalem
Wissen im Detail wohl nicht so einfach ist.

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

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

[andreas wecer]

On Fri, Feb 16, 2018 at 11:22 PM Robert Kaiser  wrote:

> Dass es einige gute Beispiele gibt, wo OSM-Daten verwendet werden,
> bezweifle ich nicht. Dass es in der Masse angekommen ist, aber sehr
> stark. Ich sehe kaum irgendwo in den Karten, die auf Webseiten und in
> Apps auftauchen, dass OSM verwendet wird - überwiegend ist es GMaps.


Sport-Apps setzen eigentlich recht häufig auf OSM wie bspw. Strava, Komoot
oder Bergfex. Bei Strava war der Wechsel von Google zu OSM etwas
kontrovers, weil v.a. nichteuropäische Rennradler Streetview vermisst
haben, aber für Fuß- und Radwege abseits der Straße sind die OSM-Daten
einfach deutlich besser.
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

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

[andreas wecer]

On Fri, Feb 16, 2018 at 4:23 PM Johann Haag  wrote:

> es spricht ja auch nichts gegen addr:unit, zum vermeiden von doppelten
> Adressen dient zusätzlich auf der Hausnummer der Appendix  „/treppe“
>

Wenn du die Stiege doppelt unter housenumber und unit angibst, wird sie
u.a. bei carto, also dem Standardstil auf osm.org, auch doppelt angezeigt.
Im Moment wird addr:unit öfter - wie beim mittlerweile
weltberühmten Anna-Boschek-Hof - ohne Hausnummer angegeben. Das sieht auf
der Karte hübsch aus, dafür ist nicht unmittelbar eindeutig klar, zu
welcher Adresse diese gehören. Umgekehrt sieht es schnell sehr hässlich
aus, wenn die Hausnummer bei jeder Unit gerendert wird und die
Unterstützung von anderer Software sieht meines Wissens auch nicht besser
aus (Maps.me zeigt anscheinend addr:flats aber nicht addr:units an, scheint
aber nach keinem davon suchen zu können). Der Appendix bei der Hausnummer
ist aktuell der pragmatische Ansatz, der bei vielen Units auf engem Raum
genauso hässlich aussieht, aber zumindest ohne Anpassung gleich überall
funktioniert.
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

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

[andreas wecer]

On Fri, Feb 16, 2018 at 12:52 AM Johann Haag  wrote:

> Wenn also OGD-Wien https://www.wien.gv.at/advadrwebapp/public/ die
> Adresse so formatiert, der Stadtplan Wien
> https://www.wien.gv.at/stadtplan/  die Adresse  Davidgasse 76-80/2 auch
> so wieder findet. OSM Nominatim die Adresse in diesem Format ebenso
> auflöst, warum sollen wir dann bitte die Adresse in OSM nicht auch genau so
> eintragen.
>

Ja, es FORMATIERT die Adresse so, das Suchformular hat aber genauso ein
Feld "Stiege", was unserem addr:unit entspricht. Das strukturiert und
getrennt zu speichern ist jetzt kein so außergewöhnlicher, neuer, oder
destruktiver Gedanke, es wird halt im Moment nicht von Nominatim unterstützt
https://github.com/openstreetmap/Nominatim/issues/587

Ich bin da auch gar nicht dogmatisch, habe vermutlich schon beide Varianten
selbst verwendet und würde vorhandene Adressen nicht ohne Grund umtaggen
(v.a. solange ich keine Software kenne, die daraus einen Vorteil generiert,
wie Zusammenfassen beim Rendern oder bei der Adress-Suche), aber deine
andauernden Vorwürfe, Unterstellungen und Untergangsmeldungen machen das
Lesen von Mailingliste und Forum etwas mühsam.

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

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

[andreas wecer]

On Thu, Feb 15, 2018 at 11:32 AM Friedrich Volkmann  wrote:

> > Das System schafft es auch mit mehreren Punktadressen auf einem
> > Gebäude.
>
> Gegenbeispiele wurden schon genannt.
>

Weil du schon öfter POI-Nodes genannt hast, die sich ohne addrN nicht
abbilden lassen - gibt es dafür konkrete Beispiele? Ich kann mir eigentlich
nicht vorstellen, dass ein Geschäft, oder was auch immer, beide theoretisch
möglichen Adressen (oder mehr) tatsächlich in Verwendung hat.

Davon abgesehen ist mir jetzt allerdings ein Fall untergekommen, wo ich
auch einmal addr2 gesetzt habe und zwar gibt es beim Dürrsee in Münchendorf
laut Adressregister die wunderhübschen Straßennamen "Dürrsee-N",
"Dürrsee-O", "Dürrsee-W", "Dürrsee-S" und - ganz toll - "Dürrsee-S A" (was
an der gleichen Straße wie Dürrsee-S liegt, nur an der dem See abgewandten
Seite). Das schreibt und erst recht sagt natürlich keiner so, entsprechend
habe ich die Adressen als "Dürrsee Süd" eingetragen und "Dürrsee-S" als
official_name der Straße, dann werden auch beide Varianten von Nominatim
gefunden.
Im Fall von "Dürrsee-S A 1" funktioniert das allerdings nicht. Soweit ich
das in Erinnerung und damals so aufgenommen habe, sind die Adressen vor Ort
als "Dürrsee Süd 1a" angegeben, also habe ich jetzt die hässliche, aber
anscheinend offizielle Adresse der Vollständigkeit halber für die 8 Häuser
als addr2 hinzugefügt. Ja ich weiß, es wird dann aktuell immer noch nicht
gefunden, aber zumindest ist einmal beides vorhanden und beruhigt
vielleicht jemand, der diese Bezeichnung in irgendeiner Liste findet.
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Es geht alles gegen null

[Andreas Wecer]

Am 2017-09-14 um 13:48 schrieb Gabriel:
> Im uebrigen habe ich vor kurzem im ID Editor gesehen das es beim
> speichern eines Changes die Option gibt die Aenderung ueberpruefen zu
> lassen, ist ein kleines Haekchen unter der Kommentarbox. Keine Ahnung
> wie lange das schon da ist.

Gibt es offenbar seit ca. einem Monat, deshalb habe ich bisher auch erst
ein Tool gesehen, dass das auch auswertet, und das ist nicht gerade
praktikabel
http://neis-one.org/2017/09/review-requests-osm/



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

[Talk-at] EuroVelos und OpenCycleMap

[Andreas Wecer]

Hallo,

Am 2017-04-04 um 21:28 schrieb andreas wecer:
> ich habe die Relation "EV9 - part Austria" von ncn auf icn gesetzt, wie
> das auch schon jemand beim tschechischen und slowenischen Teil getan hat
> und wie es auch im Wiki zu Superrelationen steht:
>
> The superroute has the same characteristics as the routes regarding
> route=*, ref=*, network=*, name=*, …
>
>
> Eine Unterscheidung ergibt Sinn, wenn es eine eigene nationale
> Bezeichnung gibt, die über die gleiche Route verläuft, wie beim
> Donauradweg R1, aber es gibt nur einen EV9

Ich wurde darauf aufmerksam gemacht, dass der Grund für das vorherige
Tagging wohl war, dass OpenCycleMap icn nicht rendert. Es hat lange
gedauert, bis die Tiles aktualisiert wurden, aber mittlerweile ist der
EV9 auch wirklich von der Karte verschwunden. Nachdem es ein 4 Jahre
altes Ticket dazu gibt, wird sich so bald wohl auch nichts daran ändern.
https://trac.openstreetmap.org/ticket/4737

http://www.openstreetmap.org/#map=12/47.9054/16.1892&layers=C
https://cycling.waymarkedtrails.org/#route?id=2766147&map=12!47.9054!16.1892


Ich finde den OCM-Stil zwar generell nicht so toll (welche Ortsnamen auf
welchen Zoomstufen angezeigt oder nicht angezeigt werden, wirkt bspw.
oft recht eigenartig), aber nachdem es die Standard-Radfahrerkarte ist,
sollte die Änderung wohl besser wieder rückgängig gemacht werden? Mit
der gesetzten Ref würde dann diese zumindest jetzt auch angezeigt
werden, was vorher auch nicht der Fall war.

EV7 und EV6 (bzw. die entspr. Unterrelationen) sind auch als icn getaggt
und scheinen demnach ebenfalls nicht auf OCM auf, bei letzterem ist es
allerdings nicht ganz so tragisch, nachdem die Route ident mit dem ncn
R1 ist

LG
  Andreas



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

[Talk-at] EuroVelo 9 - Bernsteinroute Österreich

[andreas wecer]

Hallo,

es gibt hier einen kleinen Abschnitt des EV9 der als "Bernsteinroute
Österreich" benannt ist und auch in der Superrelation des EV9 enthalten ist:
https://www.openstreetmap.org/relation/5162779

mMn. kann diese Relation gelöscht werden, da der Abschnitt auch schon in
dem Teilabschnitt des EV9 enthalten ist, der ganz Österreich abdeckt:
https://www.openstreetmap.org/relation/2766147

Wie mit dem Namen "Bernsteinroute" verfahren werden soll, weiß ich
allerdings nicht? Der Name scheint auf der deutschen eurovelo-Website noch
auf, die Superrelation hieß ursprünglich auch so, wurde aber 2013 auf
"Ostsee-Adria" geändert (die alte Alternativroute EV9a heißt auch immer
noch "Bernsteinroute Österreich (alternativ)")
http://www.eurovelo.com/de/eurovelos/eurovelo-9

alt_name:de=Bernstein-Route?


Zusätzliche Anmerkung:
ich habe die Relation "EV9 - part Austria" von ncn auf icn gesetzt, wie das
auch schon jemand beim tschechischen und slowenischen Teil getan hat und
wie es auch im Wiki zu Superrelationen steht:

> The superroute has the same characteristics as the routes regarding
> route=*, ref=*, network=*, name=*, …


Eine Unterscheidung ergibt Sinn, wenn es eine eigene nationale Bezeichnung
gibt, die über die gleiche Route verläuft, wie beim Donauradweg R1, aber es
gibt nur einen EV9

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

[Talk-at] Murradweg / "nationale" Radwege

[Andreas Wecer]

Hallo,

ich bin gerade etwas unzufrieden mit der Kategorisierung der Radrouten
in Österreich

Der Murradweg R2 wird in Österreich (Salzburg/Steiermark) als
"regionaler Radweg" rcn getagged, in Slowenien/Kroatien bis zur Mündung
in die Drau dagegen als "nationaler Radweg" ncn (durchgehend gleiche
Bezeichnung "R2"). Meiner Meinung nach sollte alles als ncn getagged
werden (auch wenn er durch mehrere Länder geht).
http://cycling.waymarkedtrails.org/#route?id=31617&map=9!46.8977!15.6033
http://cycling.waymarkedtrails.org/#route?id=2021264&map=10!46.5277!16.8942

aktuelle Regelung:
> http://wiki.openstreetmap.org/wiki/WikiProject_Austria/Radwege#Radwege_in_der_Steiermark
> Die Landesradwege (R1, R2, etc.) werden als Relationen mit network=rcn
> und die Bezirksradwege (GU1, LB8, etc.) mit network=lcn gemappt.
> 'Nationale' Radwege (network=ncn) gibt in der Steiermark nicht
> (angeblich sind einige der Landesradwege aber Teile Europäischer
> Fernradwege).

Die Kategorisierung im Wiki hat zwar ihre Logik und erleichtert die
Einteilung, ignoriert allerdings völlig die Länge und Bedeutung der
Radroute, was zur Folge hat, dass ein 320km langer Radweg genauso
angezeigt wird, wie bspw. ein 4km langer
(http://openstreetmap.org/relation/38237 )

Die Kategorie ncn wird im Moment in Österreich so gut wie gar nicht
verwendet (bzw. hauptsächlich dort, wo sowieso auch ein internationaler
EuroVelo verläuft) und ich denke es ist durchaus argumentierbar, dass
Radrouten mit mehr als (Hausnummer) 100km von "nationalem" Interesse
sind. In den meisten Bundesländern kommen dafür eh nur 1-2 in Frage und
dann hat auch rcn wieder mehr Aussagekraft, als nur welche Bezeichnung
am Schild steht.
Es ist ein wenig so, als würde man auf highway=primary völlig verzichten
und es gäbe nichts zw. Autobahn und Landstraße.

LG
  Andreas


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

Re: [Talk-at] in Austria, good experience - thank you!

[andreas wecer]

On Mon Nov 10 2014 at 16:45:17 Stefan Tiran 
wrote:

> [1] I assume, it is mostly people who see the world only through the
> front shield of their car.


 I think this argument goes both ways, it all comes down to the level of
abstraction you are going to apply. We usually also don't map every lane as
single way, we consider them all as part of the street as well as a
sidewalk is part of the street - I'm walking down Favoritenstraße and not a
footway that happens to be next to Favoritenstraße (and to use it for
routing some sort of preprocessing is needed any way).
Having said that, I'm with you that deleting them is still vandalism.
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] in Austria, good experience - thank you!

[Andreas Wecer]

Am 2014-10-30 um 19:36 schrieb Michael Maier:
> If the sidewalks are correctly mapped, and the kerbs are mapped too (as
> they are in one of the examples Carles provided, with kerb=lowered), it
> is clearly an loss if information if the ways are deleted.

as far as I can see, there isn't any additional information in this
example, which couldn't be mapped with sidewalk tags on the streets and
kerb tags on the crossings

> I'm absolutely with you, that footway=sidewalk shouldn't be rendered (at
> least on z<18) - but we're not mapping for the renderer here, or are we?^^

In fact, I _do_ consider this example as mapping for the renderer,
because that's the main difference in this case, there isn't anything
that makes wheelchair routing easier, quite the contrary



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

Re: [Talk-at] in Austria, good experience - thank you!

[Andreas Wecer]

Am 2014-10-30 um 01:30 schrieb Carles Pina i Estany:

there seems to be footpaths on a "normal" street. I'm not an OSM expert
but this seems unusual?


Hi,

micromapping of sidewalks is a controversial subject, personally I don't 
think it's a good idea, but I guess you will not find a consensus on 
this topic any time soon


best regards
  Andreas

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

Re: [Talk-at] Mappen von Gehsteigen

[Andreas Wecer]

Am 26.02.2014 08:21, schrieb Michael Maier:
> Also ich finde die getrennte Variante übersichtlicher und für Anfänger
> leichter zu verstehen.

Sorry, aber das Anfänger-Argument halte ich für ziemlich konstruiert.
Ich bezweifle, dass es für die meisten soviel intuitiver ist, bei einem
Gehsteig, der nur durch die Gehsteigkante von der Fahrbahn getrennt ist,
diesen nicht als Teil der Straße anzusehen, sondern lauter unabhängige,
parallele Wege anzulegen. Ohne eine entsprechende Unterstützung der
Editoren ist keine der beiden Varianten so besonders
einsteigerfreundlich und soweit ich das sehe, ist in der Simple-Ansicht
des ID-Editors nur das sidewalk-Attribut dafür vorgesehen.
Ich habe auch schon solche separaten Gehsteige korrigiert (nicht
gelöscht), die bspw. parallel zu einer Straße angelegt wurden, ohne
Verbindung zum Zebrastreifen auf der Straße daneben bzw. ohne
Schnittpunkt mit kreuzenden Straßen - solche Fehler wären gar nicht
möglich gewesen, hätte derjenige einfach nur das Attribut gesetzt, also
erscheint mir das die anfängerfreundlichere Variante zu sein.



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

Re: [Talk-at] Mappen von Gehsteigen

[Andreas Wecer]

Am 25.02.2014 09:56, schrieb Martin Raifer:
> 1. Es ist einfach intuitiver jeden getrennten Verkehrsweg extra zu
> mappen: Es benötigt keine Einlese-Arbeit im Wiki (seinen wir mal
> ehrlich, kein Mensch liest sich das Wiki durch bevor man anfängt zu
> mappen). KISS [1]
> 2. Man erhält akkuratere Geometrien. Sehr viele Kreuzungen lassen sich
> mit den jeweiligen Fußgängerkreuzungsmöglichkeiten gar nicht anders
> erfassen.


Nach meiner Beobachtung erhält man eher komplexere Graphen, die aber im
Detail dann auch nicht korrekt sind, weil das detaillierte Erfassen
aller Verbindungen und Kreuzungspunkte dann doch auch nicht mehr so
simple stupid intuitiv ist



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

Re: [Talk-at] OGD NÖ

[Andreas Wecer]

Am Sa 20 Apr 2013 10:51:11 CEST schrieb Andreas Labres:
> Ich hab das dort jetzt mal so etwa hingeschätzt.

sehr schön, danke. Ich habe die restliche Grenze auch noch korrigiert. 
Besonders gut ist sie zwar auf der 1:50.000 austrianmap.at nicht 
erkennbar, aber nachdem man eh weiß, wo man schauen muss, reicht es zur 
Orientierung.

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

Re: [Talk-at] OGD NÖ

[Andreas Wecer]

  
  

  
Hallo, 

Am 13. April 2013 01:18 schrieb Soldier Boy :

 
Grenzen wirken sehr ungenau. Sollte man
  mal checken was die echten Grenzen sind. Denke aber die Daten
  sind auch eher nutzlos.
es handelt sich dabei um generalisierte Daten für den
Maßstab 1:200.000, die für uns ziemlich unbrauchbar sind, siehe
dazu auch die unten zitierten Mails. 
 
Wie dort auch zu lesen ist, war der Grund, warum ich mich
überhaupt für die Daten interessiert habe, diese Gemeindegrenze
zw. Münchendorf und Velm: 
http://www.openstreetmap.org/?lat=48.03395&lon=16.41704&zoom=16&layers=M
Nachdem ich den genauen Grenzverlauf nicht kenne, aber zumindest
weiß, dass der Dürrsee komplett auf Münchendorfer und die
Kienerseen auf Velmer Gebiet liegen sollten, soll ich zumindest
das einmal irgendwie hinschätzen, was dann wohl immer noch eher
korrekt ist, als die jetzige Grenze? Ich vermute, dass es beim
Seedörfl an der Grenze zu Laxenburg ähnlich sein wird.
 
  LG 
    Andreas 
  


  

 
Am 17.04.2013
  07:32, schrieb Andreas Wecer:
  
Sehr geehrte Damen und Herren,

Ich würde gerne wissen, wie oft die von Ihnen angebotenen Daten zu den
Verwaltungsgrenzen
(http://data.noe.gv.at/Land-Zukunft/Open-Government-Data/Geographie-und-Planung/Verwaltungsgrenzen_politische_Gemeinden.html)
aktualisiert werden? Konkret interessiert mich die Gemeinde- und
Bezirksgrenze zw. Münchendorf und Velm, die ich gerne in Openstreetmap
aktualisieren würde:

http://www.openstreetmap.org/?lat=48.03395&lon=16.41704&zoom=16&layers=M

Laut Münchendorfer Chronik müsste sich hier der Grenzverlauf 2007
geändert haben, sodass die Grenze nicht mehr durch den Dürrsee verläuft,
sondern dieser komplett auf Münchendorfer Gebiet liegt, was in dem von
Ihnen angebotenen Shapefile allerdings noch nicht der Fall ist.

Vielen Dank
  Andreas Wecer


  
  Am 18.04.2013 15:56, schrieb GIS-Support (BD3):
  

  Sehr geehrter Herr Wecer,
   
  Wie in den Metainformationen zu diesem Datensatz
ersichtlich wurden diese Gemeindegrenzpolygone 2005
erstmalig erstellt und werden in den darauffolgenden
Jahren "bei Bedarf" aktualisiert.
   
  VORSICHT: Ebenfalls ersichtlich ist, dass es sich
hierbei um auf den Maßstab 1:200.000
 !!!GENERALISIERTE!!! Polygone handelt. D.h. diese
wurden von Ihrer Stützpunktanzahl derart vereinfacht,
dass sie für Karten im Maßstab 1:200.000 (etwa
Niederösterreichübersichten im Papierformat A0) geeignet
sind. Würde man in solchen Kartenmaßstäben die exakten
Grenzverläufe verwenden, wäre das Darstellungsergebnis
nicht zufriedenstellend, deshalb ist es für
kartografisch hochwertige Produkte notwendig zu
generalisieren.
   
  Da wir die Urheberschaft für diesen generalisierten
Datensatz halten ist es uns möglich diese im Rahmen von
OGD zur freien Verwendung anzubieten. Allerdings
bezweifle ich, dass die Openstreetmap Community daran
interessiert ist, generalisierte Grenzverläufe in Ihrer
Plattform vorzuhalten, da dies für Webkartendienste in
der Regel nicht sinnvoll ist.
   
  Die Urheberschaft für katasterscharfe
Verwaltungsgrenzen liegt bei den österreichischen
Vermessungsämtern, bzw. in weiterer Folge beim Bundesamt
für Eich- und Vermessungswesen, da diese Grenzverläufe
in der Regel direkt aus dem Grundstückskataster
abgeleitet wird.
   
  Um Ihnen den Unterschied zu verdeutlichen kann ich
Ihnen folgenden Screenshot beilegen auf dem Sie die
Grundstücksparzellen des fraglichen Ausschnitts in
Münchendorf sehen können. Die rote Linie zeigt dabei den
katasterscharfen Grenzverlauf der Gemeindegrenze,
während unser Generalisierungsalgorithmus diese
„Schikane“ geradlinig durchläuft (schwarze Linie). Der
Informationsgehalt im Maßstab 1:200.00 wird durch diese
Vereinfachung eben nicht oder kaum beeinflusst, das
Darstellungsergebnis aber entsprechend verbessert.
  
  Ich würde also dringend davon abraten die
generalisierten Gemeindegrenzen generell in
 

Re: [Talk-at] Redaction Bot in AT

[Andreas Wecer]

Wieso löscht er eigentlich Tags aus dem plan.at-Import raus? Ich habe
mir diesen Way angesehen:
http://www.openstreetmap.org/browse/way/30570185

und neben der Zerstörung der Verbindungen/Positionen wurden eben auch
einige Tags wie dieses "uploaded_by W." od. "fixme=check import" etc.
raus gelöscht. Nicht, dass mir jetzt konkret diese abgehen würden, ich
wundere mich nur, nachdem der plan.at-Import ja bei den Zustimmern ist
http://odbl.de/austria.html

LG
  Andreas



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

[Talk-at] Wohnblock Adresse(n)

[Andreas Wecer]

Hallo,

ich habe hier einen Wohnblock mit Adresse "10-12", dazu einigen
Reihenhäusern "RH1-RH18", sowie den Stiegen "Stg.1-Stg.8". Wie gebe ich
da jetzt am sinnvollsten die Adresse an? "10-12/1" funktioniert nicht,
da das Reihenhaus oder Stiege sein könnte. Bei Unit sieht es ähnlich aus
und man müsste als Unit explizit "RH 1" od. "Stg.1" angeben. Und gibt es
überhaupt eine Software, die Unit auswertet? Sonst ist der Mehrwert
etwas fraglich, wenn damit dann in erster Linie 25x nebeneinander
"10-12" gerendert wird (bzw. eine Navi-Software das nicht zusammen fasst
und 25 um ein paar Meter versetzte Einträge mit gleicher Adresse
auflistet). Daher gleich gar nicht so detailliert erfassen und einen
einzelnen Address-Node "10-12" setzen?

http://www.openstreetmap.org/?lat=48.03364&lon=16.38372&zoom=17&layers=M



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

Re: [Talk-at] Übereinander liegende Straßen Bus 566

[andreas wecer]

Am 28. März 2012 08:08 schrieb Martin Vonwald :
>
> Es ist mir selbst schon unzählige Male passiert - vor allem bei Wegen mit
> langen Relationen wie z.B. Buslinien - dass JOSM beim Hochladen einen
> Konflikt meldet. Völlig egal, wie man diesen Konflikt dann löst, in gefühlt
> mehr als der Hälfte aller Fälle hat man nachher ein oder mehrere Wege
> doppelt.
>
 Die meisten dieser Verdopplungen habe ich selber gleich wieder (mühsam)
> korrigiert


hmm, das klingt jetzt nicht so spannend. Gibt es keine einfacheren
Möglichkeiten, so etwas aufzulösen?
___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

[Talk-at] Übereinander liegende Straßen Bus 566

[Andreas Wecer]

Hallo,

kann mir jemand erklären, warum es plötzlich bspw. von der B16 2
übereinander liegende Straßen gibt, von denen eine nicht mit dem Rest
der Karte verbunden ist?
http://www.openstreetmap.org/?lat=47.98927&lon=16.38529&zoom=17&layers=M

hier das entsprechende Changeset:
http://www.openstreetmap.org/browse/changeset/0837

Grüße
  Andreas



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