subject:"\[Talk\-de\] Überarbeitung OSM Inspector Adress\-Layer \/ OSM Inspector Address Layer revamp"

Hi Peter,

Am Mittwoch, den 02.10.2013, 23:53 +0200 schrieb Peter:
Am 01.10.2013 20:56, schrieb Peter Wendorff:
Am 01.10.2013 17:10, schrieb tumsi:

Dazu fänd ich ein missing post-code noch gut (oder seh ich das nicht?).

[...]
Deshalb schadet Redundanz hier nicht.

Ich widerspreche vehement.

Man darf die Eigenheiten der Menschen nicht vernachlässigen.
Gerade die der deutschen (genau, korrekt, Fehler werden ausgemerzt :-):
[...]
Am Ende haben wir nicht redundante Daten sondern das Gegenteil:
Die addr:postcode passen 100% zu den PLZ-Polygonen und alles
sieht toll aus. Nur das die addr: 'falsch' sind da nicht vor
Ort geprüft, oder aus unabhängiger Quelle. Am ende scheinen
sich die Daten gegenseitig zu 'beweisen', obwohl sie falsch sind.

+100

Als Auswerter / Nutzer reicht durchaus ein Wert. Bei zwei Werten ist es
durchaus ein Problem automatisch zu entscheiden welcher Wert richtig
ist. Daher ist die GK-PLZ in addr:postcode außerhalb der PLZ-Relation
ungünstig. Mein Vorschlag dazu wäre addr:letter_postcode.

PLZ gehören IMHO daher nur in die entsprechende Relation und nicht an
die Nodes / Ways.

Laut [3] gibt es in Deutschland ca. 19.000.000 Wohngebäude. Wenn alle
Gebäude ein addr:postcode - Tag hätten wäre das allein für Deutschland
(14+6) * 19.000.000 ~ 380MByte an Daten die eingespart werden könnten.

[...]
Hierzu: wie kann man denn eine verlässliche Datenquelle für
die PLZ Gebiete bekommen?
Eigentlich gar nicht, da sich zumindest alle 3 Monate einiges geändert
wird. [1]

Oder warten wir einfach bis die Post angekrochen kommt und
uns die Daten anbietet. Irgendwann werden sie es tun, denn
es kann nur eine [2] geben.
Hat dort schon mal jemand nachgefragt? Und wenn ja mit welchem Ergebnis?

Und so schlimm kann es mit der Fehlerrate bei den PLZ-Relationen nicht
sein. Hier steht ziemlich viel auf 100% [2].

Wobei sich mir gerade die Frage aufdrängt warum Sendungen mit falscher
PLZ trotzdem zugestellt werden.

Schönen Sonntag noch

Jörg

[1]
http://www.deutschepost.de/dpag?tab=1skin=hicheck=yeslang=de_DExmlFile=1010980

[2]
http://wiki.openstreetmap.org/wiki/Import/Catalogue/Postleitzahlen_Deutschland_2010/Todo

[3]
https://www.destatis.de/DE/PresseService/Presse/Pressekonferenzen/2013/Zensus2011/gwz_zensus2011.pdf?__blob=publicationFile

--
Jörg Frings-Fürst
OSM privat
D-54526 Landscheid
GPG Fingerprint: 13E3 4D4A 3228 D138 8511 EA5A 08AC AF02 3C6D 750A
Full GPG key: hkp://pool.sks-keyservers.net
CAcert Serialnr.: 0D:9A:23
SHA1-Fingerprint: CA:36:4D:44:D1:71:4A:78:C8:6C:C2:CC:94:F3:6E:42:38:BA:CE:4E
http://cacert.org

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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

2013-10-03 Diskussionsfäden Martin Koppenhoefer

Am 3. Oktober 2013 14:03 schrieb Jörg Frings-Fürst o...@jff-webhosting.net:

 Am Mittwoch, den 02.10.2013, 23:53 +0200 schrieb Peter:
  Am 01.10.2013 20:56, schrieb Peter Wendorff:
   Am 01.10.2013 17:10, schrieb tumsi:
   Deshalb schadet Redundanz hier nicht.
  Ich widerspreche vehement.

 +1



-1



 Als Auswerter / Nutzer reicht durchaus ein Wert. Bei zwei Werten ist es
 durchaus ein Problem automatisch zu entscheiden welcher Wert richtig
 ist. Daher ist die GK-PLZ in addr:postcode außerhalb der PLZ-Relation
 ungünstig. Mein Vorschlag dazu wäre addr:letter_postcode.
 PLZ gehören IMHO daher nur in die entsprechende Relation und nicht an
 die Nodes / Ways.



gerade weil man es nicht automatisch entscheiden kann, und weil relationen
prinzipiell komplexer sind als tags on nodes, würde ich tendenziell eher
einer PLZ an einem Node trauen als einer Relation. Alle PLZ die ich an
Nodes gehangen habe, kommen von Dingen wie Kassenzetteln oder in anderer
Weise von dem jeweiligen Nutzer (Internetseiten etc.). Klar kann man da
auch Fehler nicht ausschließen, von daher sollte nichts automatisch
gemacht werden, sondern diese Diskrepanzen durch Recherche aufgeklärt
werden. Wenn man aber rein auf Relationen setzt entgehen einem sicherlich
viele solcher Fehler und schlummern potentiell sehr lange in der db.

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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

Hallo Martin,


Am Donnerstag, den 03.10.2013, 14:51 +0200 schrieb Martin Koppenhoefer:
 Am 3. Oktober 2013 14:03 schrieb Jörg Frings-Fürst o...@jff-webhosting.net:
 
[...]
 
  Als Auswerter / Nutzer reicht durchaus ein Wert. Bei zwei Werten ist es
  durchaus ein Problem automatisch zu entscheiden welcher Wert richtig
  ist. Daher ist die GK-PLZ in addr:postcode außerhalb der PLZ-Relation
  ungünstig. Mein Vorschlag dazu wäre addr:letter_postcode.
  PLZ gehören IMHO daher nur in die entsprechende Relation und nicht an
  die Nodes / Ways.
 
 
 
 gerade weil man es nicht automatisch entscheiden kann, und weil relationen
 prinzipiell komplexer sind als tags on nodes, würde ich tendenziell eher
 einer PLZ an einem Node trauen als einer Relation. Alle PLZ die ich an
 Nodes gehangen habe, kommen von Dingen wie Kassenzetteln oder in anderer
 Weise von dem jeweiligen Nutzer (Internetseiten etc.). Klar kann man da
 auch Fehler nicht ausschließen, von daher sollte nichts automatisch
 gemacht werden, sondern diese Diskrepanzen durch Recherche aufgeklärt
 werden. Wenn man aber rein auf Relationen setzt entgehen einem sicherlich
 viele solcher Fehler und schlummern potentiell sehr lange in der db.


Also irgendwie verstehe ich die Logik dahinter nicht. 

Aber mal von Anfang an:

PLZ ist ein Merkmal eines geografischen Zustellgebietes. Und sie ist in
diesem Gebiet für alle Grundstücke gültig. 
Damit gibt es eine eindeutige Zuordnung PLZ -- Grundstück.

Jetzt sagst Du das Du den PLZ an Nodes / Gebäuden / Ways mehr traust.
Gut. Nur was heißt das? Die vorhandenen Daten sind nicht brauchbar, da
nur mit Ortskenntnis oder mit 3. Mitteln die Korrektheit überprüft
werden kann. Hier drängt sich die Frage auf: Warum werden potentiell
falsche Daten erfasst?

Ich denke mal hier sollte wie bei is_in die Relationen korrigieren und
dann die addr:postcode Tags an den Nodes auslaufen lassen.


Dafür spricht auch die leichtere Überprüfbarkeit, schnellere Korrektur
und das verringerte Datenvolumen. 


Gruß

Jörg


-- 
Jörg Frings-Fürst
OSM privat
D-54526 Landscheid
GPG Fingerprint: 13E3 4D4A 3228 D138 8511 EA5A 08AC AF02 3C6D 750A
Full GPG key: hkp://pool.sks-keyservers.net
CAcert Serialnr.: 0D:9A:23
SHA1-Fingerprint: CA:36:4D:44:D1:71:4A:78:C8:6C:C2:CC:94:F3:6E:42:38:BA:CE:4E
http://cacert.org



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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp


Hola,

On Wed, Oct 02, 2013 at 11:53:18PM +0200, Peter wrote:
 Wenn da in OSMI ein Layer auftaucht mit fehlenden PLZ an Adressen,
 so finden sich sicher ein paar Mapper die durch die Lande ziehen,
 also nie vor Ort waren, und die Korrigieren/Nachtragen. Und zwar
 gut gemeint aus den PLZ-Polygonen. [1]
 Da verwette ich meinen * drauf.
 Da werden Leute hingehen und mit Josm und filtern ganzen
 Stadtteilen PLZ verpassen, nach den ungenauen/falschen Polygonen.

Na - ein Hirn brauch man definitiv wenn man Josm startet.

 Walters plz Karte ist so wie sie ist doch gut für die PLZ.
 Vielleicht sollten wir damit erstmal die PLZ Gebiete hier
 vervollständigen/korrigieren und dann später mit einem
 OSMI Layer die echten Fehler aufzeigen.
 
 Hierzu: wie kann man denn eine verlässliche Datenquelle für
 die PLZ Gebiete bekommen?

Es gibt keine - Ich glaube nicht das die Deutsche Post stand
heute Polygone hat. Ich glaube auch nicht das irgendjemand
wirklich mit den Polygonen arbeitet um absolut korrekte informationen
zu erarbeiten.

Das was die Post da in der Abfrage rauswirft a la

Straße A 1-399 PLZ XYZ
Straße A 400-1200 PLZ ABC

sind die korrekten Daten. Andere haben da vielleicht mal
mit hilfe eine geocoders polygone draus gemacht. Die sind
aber so ungenau wie die WLAN Ortung im Android.

 Und die Gutmapper werden durch die Lande ziehen und jedem
 $Dings country/postcode verpassen.
 Ich halte addr:postcode/county an jedem $Dings eher für
 was wie Spam.

Sehe ich nicht so - addr: objekte sollten immer VOLLSTÄNDIGE
Adressinformationen beinhalten und nicht irgendwelchen
verkrüppelte Daten wo die andere hälfte basierend auf irgendwelchen
geographischen ratespielchen dazuergänzt werden muss.

Wenn man das weiter treibt sind demnächst nur noch Housenumbers
dran solange man die Straße zuordnen kann a la - die naechste Straße.
Und der nächste Schritt ist das man nur noch auf dem ersten Gebäude
die 1 macht - den anderen krams kann man ja durchzählen oder?

Die Argumentation das man alles weglässt was man anders ermitteln kann
ist demnach beliebig ad absurdum zu führen.

Flo
-- 
Florian Lohoff f...@zz.de


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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

On Thu, Oct 03, 2013 at 02:03:18PM +0200, Jörg Frings-Fürst wrote:
 die Nodes / Ways. 
 
 
 Laut [3] gibt es in Deutschland ca. 19.000.000 Wohngebäude. Wenn alle
 Gebäude ein addr:postcode - Tag hätten wäre das allein für Deutschland 
 (14+6) * 19.000.000 ~ 380MByte an Daten die eingespart werden könnten.

Kompression? Und 380MByte geht vielleicht nicht mehr auf meine Amiga DD
Floppy von 1986, stellt aber mittlerweile eine lächerlich kleine
Datenmenge dar.

CDs als FLAC rippen und hier auf 380MByte hinweisen *ROFL*

Flo
-- 
Florian Lohoff f...@zz.de


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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

On Thu, Oct 03, 2013 at 04:46:53PM +0200, Jörg Frings-Fürst wrote:
 Aber mal von Anfang an:
 
 PLZ ist ein Merkmal eines geografischen Zustellgebietes. Und sie ist in
 diesem Gebiet für alle Grundstücke gültig. 
 Damit gibt es eine eindeutige Zuordnung PLZ -- Grundstück.

Das alleine bestreite ich schon. Eine Postleitzahl ist ein Technisches
Hilfsmittel der Deutschen Post um Gruppen von Adressen zu bilden. Diese
hat den Zweck der einfachen überregionalen Logistik.

Diese Gruppen wurden zum einen basierend auf der Geographischen
lage aber eben auch nach anderen Kriterien erzeugt. So hat man 
gerne vollständige Straßenzüge genommen auch wenn diese eigentlich in 
andere PLZ Bereiche reichen. Teilweise sind Postleitzahlen auch nur
Inseln die von anderen Postleitzahlen vollständig umschlossen werden.

Die Polygone die wir derzeit haben berücksichtigen die vollständigkeit
der Straßenzüge nicht, sondern sind lediglich grobe richtwerte welche
Masse von Adressen zu einer PLZ gehören.

D.h. teilweise muss das PLZ Polygon angepasst werden, teilweise die
Adressen.

Aber das ist wie mit maxspeeds. Um die wirklich sauber hinzubekommen 
mappe ich mittlerweile die Schilder der Geschwindigkeitsbeschränkungen,
anders sind Asymmetrische maxspeeds nicht in den Griff zu bekommen.

Selbiges gilt für die PLZ Polygone. Diese wird man nur sehr mühsam
korrigiert bekommen wenn man nicht nach und nach die Adressen
richtig einträgt und dann nach und nach das anpasst.

Flo
-- 
Florian Lohoff f...@zz.de


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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

2013-10-03 Diskussionsfäden Martin Koppenhoefer

Am 3. Oktober 2013 17:12 schrieb Florian Lohoff f...@zz.de:

  PLZ ist ein Merkmal eines geografischen Zustellgebietes. Und sie ist in
  diesem Gebiet für alle Grundstücke gültig.
  Damit gibt es eine eindeutige Zuordnung PLZ -- Grundstück.

 Das alleine bestreite ich schon. Eine Postleitzahl ist ein Technisches
 Hilfsmittel der Deutschen Post um Gruppen von Adressen zu bilden. Diese
 hat den Zweck der einfachen überregionalen Logistik.

 Diese Gruppen wurden zum einen basierend auf der Geographischen
 lage aber eben auch nach anderen Kriterien erzeugt.



+1, grundsätzlich gibt es zwar schon zusammenhängende Bereiche, aber es
gibt halt auch viele Ausnahmen.


Aber das ist wie mit maxspeeds. Um die wirklich sauber hinzubekommen

 mappe ich mittlerweile die Schilder der Geschwindigkeitsbeschränkungen,
 anders sind Asymmetrische maxspeeds nicht in den Griff zu bekommen.



+1, den JOSM-Style für das Anzeigen der Schilder kennst Du vermutlich?
Ausser für asymmetrische Limits hilft das Mappen der einzelnen Schilder
auch zur Bestätigung bei  unlogischen Limits, d.h. wenn in sehr kurzer
Zeit das Limit sich ohne weiteren Grund mehrmals ändert (kommt in
Deutschland so eher nicht vor), und es verhindert halbwegs, dass
Straßenknoten an Stellen, wo sich das Limit ändert, aus Unachtsamkeit
verschoben werden.


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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

On Thu, Oct 03, 2013 at 05:37:52PM +0200, Martin Koppenhoefer wrote:
 +1, den JOSM-Style für das Anzeigen der Schilder kennst Du vermutlich?

Ja

 Ausser für asymmetrische Limits hilft das Mappen der einzelnen Schilder
 auch zur Bestätigung bei  unlogischen Limits, d.h. wenn in sehr kurzer
 Zeit das Limit sich ohne weiteren Grund mehrmals ändert (kommt in
 Deutschland so eher nicht vor), und es verhindert halbwegs, dass
 Straßenknoten an Stellen, wo sich das Limit ändert, aus Unachtsamkeit
 verschoben werden.

Ich kriege das auch ansonsten selber im Kopf nicht zusammen. Ich fahre
ja oft nur teilbereiche irgendwelcher Straßen. Morgens hin - abends
zurück. Abends kann ich micht nicht mehr Erinnern wo die Schilder in
gegenrichtung Standen. 

Flo
-- 
Florian Lohoff f...@zz.de


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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

Am Donnerstag, den 03.10.2013, 16:46 +0200 schrieb Jörg Frings-Fürst:
[...]
Ironie an

Hallo, 

ich musste doch wieder einmal feststellen das ich immer noch dazu lerne:

1.) Eine Zuordnung PLZ -- Grundstück wird bestritten.

2.) Bis heute war ich der Meinung ein optimaler Weg Daten zu verarbeiten
wäre das Vorhalten in einer Datenbank. Jetzt scheint es besser zu sein
Daten auszulagern und zu komprimieren. 



zu 1.) Jetzt stellt sich für mich die Frage warum gibt es dann überhaupt
PLZen? Und wie finden die Postsendungen den Empfänger?

zu 2.) Ein Planet auf Disketten ist auch eine Möglichkeit. Nur wie lange
würde das extrahieren nur von Deutschland dann dauern? Aber man könnte
daraus einen neuen Beruf machen - Disk-Jockey ;)

Ironie aus

Hinweis an
Die obrigen Punkte haben mich per PM erreicht, daher keine Möglichkeit
zu zitieren.
Hinweis aus

Ich bleibe trotzdem der Meinung das die PLZ-Polygone nach Korrektur der
bessere Weg sind PLZ zu erfassen. 

Und 19.000.000 Datensätze müssen in der Datenbank gespeichert, indiziert
und verarbeitet werden. Und das kostet Zeit und Platz.


Gute Nacht

Jörg


PS. Ich frage mich warum ich mir darüber Gedanken mache. Wo doch noch
nicht einmal die administrativen Grenzen in Ordnung sind.

Jörg



-- 
Jörg Frings-Fürst
OSM privat
D-54526 Landscheid
GPG Fingerprint: 13E3 4D4A 3228 D138 8511 EA5A 08AC AF02 3C6D 750A
Full GPG key: hkp://pool.sks-keyservers.net
CAcert Serialnr.: 0D:9A:23
SHA1-Fingerprint: CA:36:4D:44:D1:71:4A:78:C8:6C:C2:CC:94:F3:6E:42:38:BA:CE:4E
http://cacert.org



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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

On Thu, Oct 03, 2013 at 09:26:12PM +0200, Jörg Frings-Fürst wrote:
 1.) Eine Zuordnung PLZ -- Grundstück wird bestritten.

Meine mail ging auch an die Liste wie du vielleicht feststellen
konntest.

Hier der Kontext:

   Jörg Frings-Fürst wrote
   PLZ ist ein Merkmal eines geografischen Zustellgebietes. Und sie ist in
   diesem Gebiet für alle Grundstücke gültig.
   Damit gibt es eine eindeutige Zuordnung PLZ -- Grundstück.
  
  Das alleine bestreite ich schon. Eine Postleitzahl ist ein Technisches
  Hilfsmittel der Deutschen Post um Gruppen von Adressen zu bilden. Diese
  hat den Zweck der einfachen überregionalen Logistik.

Guck dir einfach mal die PLZ Polygone an und geh mal an den Rändern durch
und such die Postleitzahlen mal auf der Webseite der Deutschen Post
raus. Du wirst einige überraschungen erleben wo das gefundene so einfach
mit Polygonen NICHT abbildbar ist es sein wir fangen jetzt auch 
mit en und exklaven an.

Die Post benutzt keine Polygone sondern Adresslisten zur zuordnung
der PLZ. Das das in kleinen Dörfern oft auf ein schönes einfach Polygon
hinausläuft bestreite ich nicht. Das geht aber Orten mit mehr
als einer PLZ schief. Dort hat man keine Polygone mehr sondern wenn
es gut laeuft sieht das am ende aus wie ein Tintenfisch vielleicht
aber auch eher wie Dalmatiner.

Und ich habe schon diverses an PLZ polygonen versucht so hinzubiegen das
das passt und an einigen stellen habe ich das einfach aufgegeben.

 2.) Bis heute war ich der Meinung ein optimaler Weg Daten zu verarbeiten
 wäre das Vorhalten in einer Datenbank. Jetzt scheint es besser zu sein
 Daten auszulagern und zu komprimieren. 

Du hast damit argumentiert das es 380MByte sind die Postcode in Deutschland
zusaetzlich zu erfassen.

Ich habe gesagt das es sogar mehr ist - und wenn man es kompremiert auch
gerne mal nur 18MByte. 

Nicht jedes byte im Planet muss und wird exakt so in der Datenbank stehen - Wir
betreiben ja keinen geocoder auf dem planet als XML file sondern daten werden
vorverarbeitet und dann nur extrakte die fuer diese aufgabe noetig sind
in die Datenbank geschrieben.

Wenn es nicht um OSM Daten gehen würde würde man sogar die Postleitzahlen
in einer - und die Adressen in einer anderen tabelle halten - Relationales
datenmodell und so ...

 Und 19.000.000 Datensätze müssen in der Datenbank gespeichert, indiziert
 und verarbeitet werden. Und das kostet Zeit und Platz.

Diese aussage ist auch mal wieder spannend. Das hat doch ganz schwer
was mit dem Schema zu tun.

In einer mit osm2pgsql erzeugten datenbank stehen die GAR NICHT
drin. Bei dem snapshot schema von osmosis sind sie nur ein attribut
an einem node oder way in einem hstore. Damit sind sie kein eigenständiger
Datensatz sondern vielleicht eine spalte wobei das bei hstore nichtmal
eine eigenständige spalte ist.

Wenn wir auf Nominatim eingehen berechnet dieser die Hierarchie ja vorab,
d.h. selbst wenn ich keine PLZ eingebe ist die doch in der Datenbank.

Und jetzt koennen wir nochmal die CPU und DiskIO kosten ausrechnen 
ob es sinn macht in einem varchar index zu suchen oder eben alle
adressen via gist index der geometrien in der Datenbank gegen ein
Multipolygon zu matchen.

In dem einen Fall suche ich in einem index nach der Postleitzahl,
im anderen Fall suche ich den gist index der Gebäudeumrisse bzw Nodes
ob diese mit ST_Intersect via bounding box auf das extent eines Polygon 
matched. Den rest mache ich dann zu Fuß ohne Index.

Ich tippe mal drauf das letzteres etwa 4-8 mal so viel CPU zeit braucht
und vermutlich von der IO last faktor 2.
Der IO Faktor könnte noch deutlich höher legen je nachdem
welche geometrien alle in dem index stehen. 

Um es noch mal klar zu machen:

Vorberechnen - Kein platzgewinn in der Datenbank
So speichern - CPU intensiver bei der Abfrage.

D.h. das einzige ueber was wir hier so reden sind die 18MByte die zusaetzlich
im Planet file stehen.

Der letzte Planet war 30GByte (http://planet.openstreetmap.org/planet/)
bz2 XML. Wenn wir es dann mal schaffen alle PLZ in D
zu erfassen haben wir da 18MByte mehr. Das sind 0.05% oder 0.5 Promille
bei dem Planet von heute.

Bis dahin wird der Planet vermutlich aber auch 100-200GByte haben und
die paar Postleitzahlen sind - ähm - lächerlich.

Flo
PS: Ich propose highway demnaechst als hwy zu schreiben. Spart pro way
in der Datenbank 4 byte - Macht bei 199406145 ways derzeit einen Gewinn
von 760MByte - Oder nur h= - dann wären es 1.3GByte. building muesste
dann b= sein - landuse ist l= - waterway ist w= --- Läuft.
-- 
Florian Lohoff f...@zz.de


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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

2013-10-01 Diskussionsfäden christian.pietz...@googlemail.com

Moin, 

Am Donnerstag, den 03.10.2013, 17:02 +0200 schrieb Florian Lohoff:
 Hola,
 
  
[...]
  Hierzu: wie kann man denn eine verlässliche Datenquelle für
  die PLZ Gebiete bekommen?
 
 Es gibt keine - Ich glaube nicht das die Deutsche Post stand
 heute Polygone hat. Ich glaube auch nicht das irgendjemand
 wirklich mit den Polygonen arbeitet um absolut korrekte informationen
 zu erarbeiten.

ZitatGeocodierte Flächen weisen die Postleitzahlgebiete in Deutschland
sowie die Leitregionen und Leitzonen aus /Zitat [1]

Gruß

Jörg


[1]
http://www.deutschepost.de/dpag?tab=1skin=hicheck=yeslang=de_DExmlFile=link1020331_1020325



-- 
Jörg Frings-Fürst
OSM privat
D-54526 Landscheid
GPG Fingerprint: 13E3 4D4A 3228 D138 8511 EA5A 08AC AF02 3C6D 750A
Full GPG key: hkp://pool.sks-keyservers.net
CAcert Serialnr.: 0D:9A:23
SHA1-Fingerprint: CA:36:4D:44:D1:71:4A:78:C8:6C:C2:CC:94:F3:6E:42:38:BA:CE:4E
http://cacert.org



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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

2013-10-02 Diskussionsfäden Stefan Keller

Hoi Tobias

Interessante Diskussion und gut dass du gefragt hast :-)

Du hast geschrieben:
 - Ein Voronoi-Diagramm mit Postleitzahlen.

Voronoi ist m.E. bereits lösungsbezogen. Da gibt es ev. treffendere
Begriffe und vielleicht gibt es ja bessere Ansätze:
Bei Voronoi wird jede Region wird durch genau ein Zentrum bestimmt.
Was hier doch gesucht ist, das ist die Abgrenzung zwischen Punktwolken,
bzw. Gebäudegruppen, wobei es auch Ausreisser haben kann, seien es korrekte
(weil der Pöstler mal schnell den anderen Briefkasten bedient, daher ja de
Name Post-Leit-Zahl) oder sei es weil es ein Fehler in den Daten ist.
Ich würde von Flächen-Segmentations-Algorithmus sprechen und als
Lösungsansatz z.B. Clustering-Algorithmen anschauen, z.B. [1]

LG, Stefan

[1] http://pointclouds.org/documentation/tutorials/cluster_extraction.php



Am 2. Oktober 2013 07:43 schrieb Toggenburger Lukas 
lukas.toggenbur...@htwchur.ch:

 Ich versuche mal eine Zusammenfassung vom bisher gesagten zu machen.
 Folgende neue Wünsche habe ich herausgelesen:

 - Häuser als adressiert anerkennen, wenn ein oder mehrere Hausnummern auf
 den Eingängen (bzw. auf dem Gebäude) getaggt sind.

 - Glaubwürdigkeitsklassen: Anzahl anderer Strassen zählen, die eine
 Verbindungslinie Haus-Zugehörige Strasse kreuzt (bzw. Anzahl Strassen
 zählen, die näher liegen, als die in der Adresse eingetragene Strasse)

 - Ausgabe von nicht-getaggten Häusern als GPX, damit man diese unterwegs
 anvisieren kann. Und/oder: Link generieren, der mittels Overpass das
 ausgibt, was auch im OSMI sichtbar ist.

 - GUI: Shortcut um alle Fehler-Arten anzuzeigen (in der bisherigen
 Version: no addr:street tag, street not found, interpolation lines with
 errors) und evtl. andere Angaben gleichzeitig ausblenden

 - Fehlende Postleitzahlen (evtl. auch fehlendes addr:city=, fehlendes
 addr:country=) markieren (evtl. nur dort, wo schon Adressangaben vorhanden
 sind)

 - Ein Voronoi-Diagramm mit Postleitzahlen. Ich nehme an, das gibt/gab es
 jedoch schon unter http://osm.wno-edv-service.de/plz .

 - Konfliktierende Adress-Angaben finden: Z.B. Postleitzahl aus
 addr:postcode - PLZ aus PLZ-Polygon

 Habe ich etwas übersehen?

 Bezüglich den Tagging-Schemata, ob und wie z.B. PLZ erfasst werden sollen,
 möchte ich niemandem Vorschriften machen. Es sollte jedoch erkannt werden,
 wenn es widersprüchliche Angaben hat, damit das jemand reparieren kann.

 Grüsse

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

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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

2013-10-02 Diskussionsfäden Peter


Am 01.10.2013 20:56, schrieb Peter Wendorff:

Am 01.10.2013 17:10, schrieb tumsi:



Dazu fänd ich ein missing post-code noch gut (oder seh ich das nicht?).



Hm, wozu benötige ich das noch an einzelnen Knoten, Umrisen oder
Straßen, wenn außen herum bereits ein post-code Polygon liegt? Ähnlich
sehe ich es z.B. auch bei addr:city und addr:country. Dieses sind alles
ableitbare Informationen, die so nur redundant in der Datenbank gehalten
werden.


Finde ich eigentlich auch.
Obwohl ich es bei POIs dazu nehme.
Bei Wohnhäusern nicht.

Ich hatte hier auch mal wen, der ergänzte den Kram massenweise,
wohl ein Sesselmapper von anderswoher, der brachte dann aber die
addr:street durcheinander. So was passiert leicht wenn man
halbmechanisch viel bearbeitet - Fehler sind halt unvermeidlich.
Leider hab' ich vergessen dem weiter nachzugehen.


Wenn die Postleitzahlengebiete so eindeutig und korrekt eingetragen wären...
Redundantes Eintragen erlaubt
1) Erkennen von offensichtlichen Fehlern, wenn es nicht zusammenpasst
2) einfaches Abfragen auch ohne Auswertung von Grenzen etc, z.B.
direktes abfragen einer vollständigen Adresse

Die Informationen sind ableitbar, das stimmt - aber nur, wenn die
PLZ-Grenze vollständig und korrekt ist. Eine Auswertung, wo die eben
nicht passt, ist ohne dieser redundanten Information nicht mehr möglich.

Abgesehen davon sind Postleitzahlengebiete nicht immer vollständig
anzunehmen, weil Großkunden etc. davon abweichende Postleitzahlen haben,
aus einer fehlenden Postleitzahl lässt sich also nicht alleine durch das
Postleitzahlengebiet korrekt auf eine Adresse schließen

Deshalb schadet Redundanz hier nicht.



Ich widerspreche vehement.

Man darf die Eigenheiten der Menschen nicht vernachlässigen.
Gerade die der deutschen (genau, korrekt, Fehler werden ausgemerzt :-):

Wenn da in OSMI ein Layer auftaucht mit fehlenden PLZ an Adressen,
so finden sich sicher ein paar Mapper die durch die Lande ziehen,
also nie vor Ort waren, und die Korrigieren/Nachtragen. Und zwar
gut gemeint aus den PLZ-Polygonen. [1]
Da verwette ich meinen * drauf.
Da werden Leute hingehen und mit Josm und filtern ganzen
Stadtteilen PLZ verpassen, nach den ungenauen/falschen Polygonen.


Am Ende haben wir nicht redundante Daten sondern das Gegenteil:
Die addr:postcode passen 100% zu den PLZ-Polygonen und alles
sieht toll aus. Nur das die addr: 'falsch' sind da nicht vor
Ort geprüft, oder aus unabhängiger Quelle. Am ende scheinen
sich die Daten gegenseitig zu 'beweisen', obwohl sie falsch sind.


Auch ein View addr:postcode passt nicht zu PLZ-polygon ist
problematisch da z.B. Großkunden-PLZ dann 'korrigiert' werden.
Wenn es da eine Liste/Verfahren gäbe diese nicht-gebiet-PLZ
an der Nummer zu erkennen könnte man das filtern.
So viele können das allerdings auch nicht sein, die hat
vielleicht schon mal wer zusammengetragen.
Wenn man so eine Liste nimmt muß sie zum filtern wohl nicht
odbl kompatibel sein?


Walters plz Karte ist so wie sie ist doch gut für die PLZ.
Vielleicht sollten wir damit erstmal die PLZ Gebiete hier
vervollständigen/korrigieren und dann später mit einem
OSMI Layer die echten Fehler aufzeigen.

Hierzu: wie kann man denn eine verlässliche Datenquelle für
die PLZ Gebiete bekommen?
Oder warten wir einfach bis die Post angekrochen kommt und
uns die Daten anbietet. Irgendwann werden sie es tun, denn
es kann nur eine [2] geben.


Außerdem denke man daran das de nicht die ganze Welt ist und
andere Länder das ganze anders sehen.

Peter

[1]
Und die Gutmapper werden durch die Lande ziehen und jedem
$Dings country/postcode verpassen.
Ich halte addr:postcode/county an jedem $Dings eher für
was wie Spam.


[2] map



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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

2013-10-02 Diskussionsfäden Peter


Am 01.10.2013 07:49, schrieb Toggenburger Lukas:


[...] werde ich die Adress-Ansicht vom OSM Inspector [...]überarbeiten.

[...]
soll die Performance erhöht werden, wodurch [...] die Ansicht auf die 
gesamte Welt zu erweitern.


Ich las letztens irgendwo im Forum/Liste einen Thread zu ausländischen
Adressen. In Japan gibt es wohl keine bis fast keine Straßennamen.
In ?Korea? ist das ähnlich, die führen das gerade erst ein.

Will damit sagen das, wie so oft bei OSM, die Welt nicht überall so
gestrickt ist wie in DACH. Das sollte man auf jeden Fall beachten
wenn man was auf die ganze Welt ausdehnt.

Also z.B. Schalter einbauen Features in bestimmten Ländern
deaktivieren zu können. Zumindest so architekten das man
es leicht so ändern kann.



Bereits angedacht sind folgende Ideen:
- Tagging mit addr:place=... bzw. mittels Relation berücksichtigen
- Aufspüren von Einträgen mit isolierter (also möglicherweise falsch getaggter) 
Postleitzahl


Zu PLZ schrieb ich gerade was ablehnendes:-)
Wobei es durchaus was hat, aber lies dort.


- Visualisieren von Lücken in den Hausnummer-Einträgen


Die sind allzu oft in der Realität so lückenhaft.
Da will ich keine false positiv sehen.


- Feststellen von Adress-Duplikaten


Gerade POI shop/amenity ... in größeren Gebäuden dürften absichtlich
mal doppelt sein. Hier könnte man bei den Objekten gucken ob die
Poiartig sind und dann das duplikat als ok ansehen. Also die
suche hier auf einfache (z.B. Wohngebäude) beschränken.

Ansonsten ok. Ich würde aber erst mal einen Test machen wie oft sowas
vorkommt. Bei 1-10 ppm: spar die Arbeit. Dazu ist ein OSMI Layer
der kaum ein Problem zeigt und dazu noch solch ein harmloses eher
schädlich: Informationsflut im GUI


Ach ja, da sind proposal unterwegs? die sowas wie Aufgang-Nr,
Appartment-Nr etc. ansprechen. Beim duplikats-vergleich also
generisch sein und z.Zt unbekannte addr:* auch vergleichen?
Wird sowas schon genutzt?
Wenn nicht: könnte man auch später in den Code einbauen.



- Visualisieren von Eingängen (entrance=...)


Hmm, wie ist das gemeint?


- Feststellen, wenn der exakt ausgeschriebene Strassenname nicht vorhanden ist, 
aber dafür einer mit

 ähnlicher Schreibweise

Das scheint interessant.
Auch wenn ich nicht weiß wie oft es vorkommt, würde ich aus Erfahrung
annehmen das das öfter auftaucht als doppelte Adressen.

Was ist 'ähnlich': bitte einen vernünftigen Algo.
Da gibt es welche die recht doof sind. Wobei das bei
Tipfehlern reichen könnte. Ich hatte mal was mit n-grammen
gemacht, war einfach und schien mir brauchbar.

Peter



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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

Hallo
es wäre schön, wenn der Adresslayer auch Häuser als addresiert anerkennt,
wenn ein oder mehrere Hausnummern auf den Eingängen getaggt sind.

mfg Christian (Hedaja)


Am 1. Oktober 2013 07:49 schrieb Toggenburger Lukas 
lukas.toggenbur...@htwchur.ch:

 English text see below...


 Hallo zusammen

 Im Rahmen einer Projektarbeit für mein Studium werde ich die
 Adress-Ansicht vom OSM Inspector ( http://tools.geofabrik.de/osmi/ )
 überarbeiten. Diese soll Mappern helfen, unvollständige oder fehlerhafte
 (Post-)Adress-Einträge zu finden und allenfalls zu korrigieren. Aus
 Performance-Gründen wird diese Ansicht derzeit nur für Europa berechnet.
 Durch eine Änderung der Architektur soll die Performance erhöht werden,
 wodurch es möglich sein sollte, die Ansicht auf die gesamte Welt zu
 erweitern.

 Gibt es aus eurer Sicht Dinge, die derzeit nicht richtig funktionieren
 oder Funktionen, die neu eingebaut werden sollten? Gerne nehme ich eure
 Vorschläge entgegen. (Allerdings muss ich aber auch gleich vorweg nehmen,
 dass die zur Verfügung stehende Zeit limitiert ist und ich wohl nicht alle
 Wünsche berücksichtigen kann.)

 Bereits angedacht sind folgende Ideen:
 - Tagging mit addr:place=... bzw. mittels Relation berücksichtigen
 - Aufspüren von Einträgen mit isolierter (also möglicherweise falsch
 getaggter) Postleitzahl
 - Visualisieren von Lücken in den Hausnummer-Einträgen
 - Feststellen von Adress-Duplikaten
 - Visualisieren von Eingängen (entrance=...)
 - Feststellen, wenn der exakt ausgeschriebene Strassenname nicht vorhanden
 ist, aber dafür einer mit ähnlicher Schreibweise

 Für Feedback zu andern Layern als dem Adress-Layer wendet ihr euch bitte
 an Frederik Ramm: frede...@remote.org

 Grüsse

 Lukas





 Hey there

 As a project thesis for my master studies I will overhaul the Address view
 of the OSM Inspector ( http://tools.geofabrik.de/osmi/ ). Its purpose is
 to support mappers in finding invalid or incomplete (postal) address
 entries. Due to performance reasons this view is currently Europe only. The
 goal of this thesis is to change the architecture to improve the
 performance and be able to provide a worldwide view.

 Is there anything in the current view that you would like to be changed or
 do you have suggestions for new functions? I'd like to hear your ideas. (At
 the same time I have to admit that I probably will not be able to implement
 all wishes.)

 We already thought about the following new things:
 - Respect address tagging with addr:place=... and relations.
 - Find addresses with isolated (and therefore potentially wrong) postal
 codes.
 - Find gaps in housenumbers
 - Find address duplicates
 - Visualize entries (entrance=...)
 - If mentioned street names can't be found, look for similar-named ones

 If you have feedback to layers other than the Address Layer, please
 contact Frederik Ramm: frede...@remote.org

 Best regards

 Lukas



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

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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

2013-10-01 Diskussionsfäden christian.pietz...@googlemail.com

On Tue, Oct 01, 2013 at 05:49:45AM +, Toggenburger Lukas wrote:
 Hallo zusammen
 
 Im Rahmen einer Projektarbeit für mein Studium werde ich die Adress-Ansicht 
 vom OSM Inspector ( http://tools.geofabrik.de/osmi/ ) überarbeiten. Diese 
 soll Mappern helfen, unvollständige oder fehlerhafte (Post-)Adress-Einträge 
 zu finden und allenfalls zu korrigieren. Aus Performance-Gründen wird diese 
 Ansicht derzeit nur für Europa berechnet. Durch eine Änderung der Architektur 
 soll die Performance erhöht werden, wodurch es möglich sein sollte, die 
 Ansicht auf die gesamte Welt zu erweitern.
 
 Gibt es aus eurer Sicht Dinge, die derzeit nicht richtig funktionieren oder 
 Funktionen, die neu eingebaut werden sollten? Gerne nehme ich eure Vorschläge 
 entgegen. (Allerdings muss ich aber auch gleich vorweg nehmen, dass die zur 
 Verfügung stehende Zeit limitiert ist und ich wohl nicht alle Wünsche 
 berücksichtigen kann.)
 
 Bereits angedacht sind folgende Ideen:
 - Tagging mit addr:place=... bzw. mittels Relation berücksichtigen
 - Aufspüren von Einträgen mit isolierter (also möglicherweise falsch 
 getaggter) Postleitzahl
 - Visualisieren von Lücken in den Hausnummer-Einträgen
 - Feststellen von Adress-Duplikaten
 - Visualisieren von Eingängen (entrance=...)
 - Feststellen, wenn der exakt ausgeschriebene Strassenname nicht vorhanden 
 ist, aber dafür einer mit ähnlicher Schreibweise

Feststellen wenn Straßennamen an den Adresseinträgen namen von weit
entfernten Straßen - also nicht der nächstgelegenen enthalten.

Ist schwierig - Ein Anhaltspunkt ist das die grüne linie der Zuordnung zur
Straße eine weitere Straße mit anderem Namen Kreuzt. Das kann eigentlich
nicht sein.

So Kontrolliere ich visuell ob die Straßennamen auf den Adressnodes
halbwegs passen können.

Flo
-- 
Florian Lohoff f...@zz.de


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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

Hallo,
Was mir gerade noch einfällt... Vielleicht wäre es ja möglich, dass man
sich auf der Karte die Gebäude markiert, welche noch keine Addresse
haben und dann per gpx Datein ausgeben lassen kann, um sie auf dem Handy zu
nutzen.
Ich habe in meinem Ort schon viele Adressen erfasst, sehe aber,
dass zwischen drin immer mal welche fehlen. Wenn man diese Fehlstellen
dann einfach mit dem Handy anvisieren könnte, würde es die Suche nach
dem richtigen Haus deutlich erleichtern.
mfg Christian


Am 1. Oktober 2013 11:37 schrieb christian.pietz...@googlemail.com 
christian.pietz...@gmail.com:

 Hallo
 es wäre schön, wenn der Adresslayer auch Häuser als addresiert
 anerkennt, wenn ein oder mehrere Hausnummern auf den Eingängen getaggt
 sind.

 mfg Christian (Hedaja)


 Am 1. Oktober 2013 07:49 schrieb Toggenburger Lukas 
 lukas.toggenbur...@htwchur.ch:

 English text see below...


 Hallo zusammen

 Im Rahmen einer Projektarbeit für mein Studium werde ich die
 Adress-Ansicht vom OSM Inspector ( http://tools.geofabrik.de/osmi/ )
 überarbeiten. Diese soll Mappern helfen, unvollständige oder fehlerhafte
 (Post-)Adress-Einträge zu finden und allenfalls zu korrigieren. Aus
 Performance-Gründen wird diese Ansicht derzeit nur für Europa berechnet.
 Durch eine Änderung der Architektur soll die Performance erhöht werden,
 wodurch es möglich sein sollte, die Ansicht auf die gesamte Welt zu
 erweitern.

 Gibt es aus eurer Sicht Dinge, die derzeit nicht richtig funktionieren
 oder Funktionen, die neu eingebaut werden sollten? Gerne nehme ich eure
 Vorschläge entgegen. (Allerdings muss ich aber auch gleich vorweg nehmen,
 dass die zur Verfügung stehende Zeit limitiert ist und ich wohl nicht alle
 Wünsche berücksichtigen kann.)

 Bereits angedacht sind folgende Ideen:
 - Tagging mit addr:place=... bzw. mittels Relation berücksichtigen
 - Aufspüren von Einträgen mit isolierter (also möglicherweise falsch
 getaggter) Postleitzahl
 - Visualisieren von Lücken in den Hausnummer-Einträgen
 - Feststellen von Adress-Duplikaten
 - Visualisieren von Eingängen (entrance=...)
 - Feststellen, wenn der exakt ausgeschriebene Strassenname nicht
 vorhanden ist, aber dafür einer mit ähnlicher Schreibweise

 Für Feedback zu andern Layern als dem Adress-Layer wendet ihr euch bitte
 an Frederik Ramm: frede...@remote.org

 Grüsse

 Lukas





 Hey there

 As a project thesis for my master studies I will overhaul the Address
 view of the OSM Inspector ( http://tools.geofabrik.de/osmi/ ). Its
 purpose is to support mappers in finding invalid or incomplete (postal)
 address entries. Due to performance reasons this view is currently Europe
 only. The goal of this thesis is to change the architecture to improve the
 performance and be able to provide a worldwide view.

 Is there anything in the current view that you would like to be changed
 or do you have suggestions for new functions? I'd like to hear your ideas.
 (At the same time I have to admit that I probably will not be able to
 implement all wishes.)

 We already thought about the following new things:
 - Respect address tagging with addr:place=... and relations.
 - Find addresses with isolated (and therefore potentially wrong) postal
 codes.
 - Find gaps in housenumbers
 - Find address duplicates
 - Visualize entries (entrance=...)
 - If mentioned street names can't be found, look for similar-named ones

 If you have feedback to layers other than the Address Layer, please
 contact Frederik Ramm: frede...@remote.org

 Best regards

 Lukas



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



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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

2013-10-01 Diskussionsfäden Peter Wendorff

Hallo Lukas,

fürs User-Interface - gar nicht mal den Layer selbst - wäre es nett,
wenn man gezielt alle Fehler des Layers auswählen könnte.
Momentan muss man einzeln aktivieren, aber wenn man genau das sehen
will, was noch fehlerhaft ist, wäre eine Abkürzung praktisch, die no
adddr:street tag, Street not found, interpolation lines/with errors
auswählt.

Dazu fänd ich ein missing post-code noch gut (oder seh ich das nicht?).

Gruß
Peter


Am 01.10.2013 07:49, schrieb Toggenburger Lukas:
 English text see below...
 
 
 Hallo zusammen
 
 Im Rahmen einer Projektarbeit für mein Studium werde ich die Adress-Ansicht 
 vom OSM Inspector ( http://tools.geofabrik.de/osmi/ ) überarbeiten. Diese 
 soll Mappern helfen, unvollständige oder fehlerhafte (Post-)Adress-Einträge 
 zu finden und allenfalls zu korrigieren. Aus Performance-Gründen wird diese 
 Ansicht derzeit nur für Europa berechnet. Durch eine Änderung der Architektur 
 soll die Performance erhöht werden, wodurch es möglich sein sollte, die 
 Ansicht auf die gesamte Welt zu erweitern.
 
 Gibt es aus eurer Sicht Dinge, die derzeit nicht richtig funktionieren oder 
 Funktionen, die neu eingebaut werden sollten? Gerne nehme ich eure Vorschläge 
 entgegen. (Allerdings muss ich aber auch gleich vorweg nehmen, dass die zur 
 Verfügung stehende Zeit limitiert ist und ich wohl nicht alle Wünsche 
 berücksichtigen kann.)
 
 Bereits angedacht sind folgende Ideen:
 - Tagging mit addr:place=... bzw. mittels Relation berücksichtigen
 - Aufspüren von Einträgen mit isolierter (also möglicherweise falsch 
 getaggter) Postleitzahl
 - Visualisieren von Lücken in den Hausnummer-Einträgen
 - Feststellen von Adress-Duplikaten
 - Visualisieren von Eingängen (entrance=...)
 - Feststellen, wenn der exakt ausgeschriebene Strassenname nicht vorhanden 
 ist, aber dafür einer mit ähnlicher Schreibweise
 
 Für Feedback zu andern Layern als dem Adress-Layer wendet ihr euch bitte an 
 Frederik Ramm: frede...@remote.org
 
 Grüsse
 
 Lukas
 
 
 
 
 
 Hey there
 
 As a project thesis for my master studies I will overhaul the Address view of 
 the OSM Inspector ( http://tools.geofabrik.de/osmi/ ). Its purpose is to 
 support mappers in finding invalid or incomplete (postal) address entries. 
 Due to performance reasons this view is currently Europe only. The goal of 
 this thesis is to change the architecture to improve the performance and be 
 able to provide a worldwide view.
 
 Is there anything in the current view that you would like to be changed or do 
 you have suggestions for new functions? I'd like to hear your ideas. (At the 
 same time I have to admit that I probably will not be able to implement all 
 wishes.)
 
 We already thought about the following new things:
 - Respect address tagging with addr:place=... and relations.
 - Find addresses with isolated (and therefore potentially wrong) postal codes.
 - Find gaps in housenumbers
 - Find address duplicates
 - Visualize entries (entrance=...)
 - If mentioned street names can't be found, look for similar-named ones
 
 If you have feedback to layers other than the Address Layer, please contact 
 Frederik Ramm: frede...@remote.org
 
 Best regards
 
 Lukas
 
 
 
 ___
 Talk-de mailing list
 Talk-de@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-de
 


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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

Hallo Christian

 es wäre schön, wenn der Adresslayer auch Häuser als addresiert anerkennt,
 wenn ein oder mehrere Hausnummern auf den Eingängen getaggt sind.

Das würde wohl Sinn machen. Hast du gerade ein Beispiel, bei dem das der Fall 
ist?

Es müssten ja gar nicht unbedingt Eingänge sein: Man könnte das Verfahren auch 
erweitern auf beliebige Adress-Punkte, die Teil eines Gebäude-Linienzuges sind. 
Dabei würde sich dann eventuell noch die Frage stellen, ob das dann überhaupt 
noch korrekt gemappt ist wenn ein beliebiger Punkt des Gebäudes die Adresse 
trägt und nicht das Gebäude selbst...

Es war auch noch angedacht, zu erkennen, wenn ein Adress-Punkt innerhalb eines 
Gebäudes liegt, dass das wohl die Adresse des entsprechenden Gebäudes sein 
muss. Das dürfte aber wieder etwas aufwändiger zu implementieren sein...

Gruss

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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

2013-10-01 Diskussionsfäden tumsi


Hallo zusammen,

 Original-Nachricht 
Betreff: Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM 
Inspector Address Layer revamp

Datum: Tue Oct 01 2013 12:05:39 GMT+0200
Von: Peter Wendorff wendo...@uni-paderborn.de
An: talk-de@openstreetmap.org


Dazu fänd ich ein missing post-code noch gut (oder seh ich das nicht?).


Hm, wozu benötige ich das noch an einzelnen Knoten, Umrisen oder 
Straßen, wenn außen herum bereits ein post-code Polygon liegt? Ähnlich 
sehe ich es z.B. auch bei addr:city und addr:country. Dieses sind alles 
ableitbare Informationen, die so nur redundant in der Datenbank gehalten 
werden.


Constanze

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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

Hallo Flo

 Feststellen wenn Straßennamen an den Adresseinträgen namen von weit
 entfernten Straßen - also nicht der nächstgelegenen enthalten.

Eine andere Formulierung: Es ist verdächtig, wenn ein Haus als Adresse eine 
Strasse beinhaltet, deren nächstes Segment so weit entfernt liegt, dass z.B. 
vier andere Strassen in kürzerer Distanz vom Haus aus erreicht werden könnten. 
So meinst du das?

Da könnte man ja sogar Qualitäts- bzw. Glaubwürdigkeits-Klassen erstellen: 
Nämlich die Anzahl Strassen, die gemäss obiger Beschreibung näher liegen als 
die getaggte.

Gruss

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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

Hallo Christian

 Vielleicht wäre es ja möglich, dass man sich auf der Karte die Gebäude
 markiert, welche noch keine Addresse haben und dann per gpx Datein
 ausgeben lassen kann, um sie auf dem Handy zu nutzen.

Das ist schon ein gutes Stück weit weg von unserem angedachten Workflow.

Eventuell wäre es einfacher, das mit einer Overpass-Anfrage zu machen? Als 
Beispiel hab ich mal schnell eine Query zusammengebastelt, die Gebäude ohne 
addr:street= ausgibt:

query type=way
  has-kv k=building/has-kv
  has-kv k=addr:street modv=not regv=./
  bbox-query {{bbox}}/
/query
union
  item/
  recurse type=down/
/union
print/

Zum Anzeigen auf http://overpass-turbo.eu/s/19F gehen, einen nicht zu grossen 
Ausschnitt wählen und im Menü Ausführen, bzw. Run klicken.

Die Vorteile davon wären, dass die Daten immer aktuell sind (so aktuell wie die 
Overpass-Daten) und kaum Overhead generiert wird.

Natürlich müsste die Suche nach keine Adresse vorhanden noch etwas verfeinert 
werden (z.B. auch Tagging mittels Relationen beachten, etc.)...

Gruss

Lukas


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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

2013-10-01 Diskussionsfäden fly

On 01.10.2013 17:10, tumsi wrote:
 Hallo zusammen,
 
  Original-Nachricht 
 Betreff: Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM
 Inspector Address Layer revamp
 Datum: Tue Oct 01 2013 12:05:39 GMT+0200
 Von: Peter Wendorff wendo...@uni-paderborn.de
 An: talk-de@openstreetmap.org
 
 Dazu fänd ich ein missing post-code noch gut (oder seh ich das nicht?).
 
 Hm, wozu benötige ich das noch an einzelnen Knoten, Umrisen oder
 Straßen, wenn außen herum bereits ein post-code Polygon liegt? Ähnlich
 sehe ich es z.B. auch bei addr:city und addr:country. Dieses sind alles
 ableitbare Informationen, die so nur redundant in der Datenbank gehalten
 werden.

+1

Leider verwendet selbst nominatum diese Grenzen bisher nicht und ich
bekomme häufig die PLZ des Regierungspräsifums gelieft.

Umgekehrt kann es allerdings durch aus Sinn machen, sobald eine
private PLZ existiert.

fly

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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

On Tue, Oct 01, 2013 at 03:12:32PM +, Toggenburger Lukas wrote:
 Hallo Flo
 
  Feststellen wenn Straßennamen an den Adresseinträgen namen von weit
  entfernten Straßen - also nicht der nächstgelegenen enthalten.
 
 Eine andere Formulierung: Es ist verdächtig, wenn ein Haus als Adresse
 eine Strasse beinhaltet, deren nächstes Segment so weit entfernt
 liegt, dass z.B. vier andere Strassen in kürzerer Distanz vom Haus aus
 erreicht werden könnten. So meinst du das?

Das koennte ja noch richtig sein. 

Falsch ist wenn die kürzeste Strecke zur Straße deren name im
addr:street tag ist straßen mit anderen namen Kreuzt.

So meinte ich:

http://zz.de/tmp/erklaerung-strassenkreuzung.png

Ich kenne gerade keinen weg wie das legal ginge.

Ich habe das aber selber oft als Fehler produziert. Mit josm einfach
immer nur Hausnummer +2 +2 +2 +2 +2 +2 von den Aufzeichnungen und
vergessen den Straßennamen mitzuziehen und mit einem mal solche
Fehler produziert.

 Da könnte man ja sogar Qualitäts- bzw. Glaubwürdigkeits-Klassen
 erstellen: Nämlich die Anzahl Strassen, die gemäss obiger Beschreibung
 näher liegen als die getaggte.

Flo
-- 
Florian Lohoff f...@zz.de


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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

2013-10-01 Diskussionsfäden christian.pietz...@googlemail.com

On Tue, Oct 01, 2013 at 05:10:58PM +0200, tumsi wrote:
 Hallo zusammen,

 Dazu fänd ich ein missing post-code noch gut (oder seh ich das nicht?).
 
 Hm, wozu benötige ich das noch an einzelnen Knoten, Umrisen oder
 Straßen, wenn außen herum bereits ein post-code Polygon liegt?
 Ähnlich sehe ich es z.B. auch bei addr:city und addr:country. Dieses
 sind alles ableitbare Informationen, die so nur redundant in der
 Datenbank gehalten werden.

Erster Satz der Nachrichtentechnik: Redundanz schafft Sicherheit :)

Das bischen an Daten macht den Kohl nicht fett und die PLZ Polygone
die wir derzeit haben sind - aehm - im detail reichlich kaputt.

Wenn ich die Adressen durchgehe und wirklich Orte mit mehreren
Postleitzahlen habe dann kontrolliere ich das auch mal durch und
defakto müssen unsere PLZ Polygone noch um einiges genauer werden,
teilweise auf Gebaeudegranularität.

Es gibt halt fälle wo eine Straße eine Grenze der PLZ Bereiche
darstellt und das so auch eingetragen ist. Leider gibt dann kleinere
Stichwege mit 4-6 Häusern die im moment fälschlicherweise
ausserhalb des Polygons liegen.

Mal davon abgesehen das ich diese scharfe suche nach Ortsnamen
oder PLZ anhand von Polygonen für falsch halte. Diese sind
leider im OSM Datenbestand oftmals ungenau so das gewisse dinge
dann nicht mehr auflösen.

Flo
-- 
Florian Lohoff f...@zz.de


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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

2013-10-01 Diskussionsfäden fly

On 01.10.2013 16:54, Toggenburger Lukas wrote:

Hey
 es wäre schön, wenn der Adresslayer auch Häuser als addresiert anerkennt,
 wenn ein oder mehrere Hausnummern auf den Eingängen getaggt sind.
 
 Das würde wohl Sinn machen. Hast du gerade ein Beispiel, bei dem das der Fall 
 ist?
 
 Es müssten ja gar nicht unbedingt Eingänge sein: Man könnte das Verfahren 
 auch erweitern auf beliebige Adress-Punkte, die Teil eines 
 Gebäude-Linienzuges sind. Dabei würde sich dann eventuell noch die Frage 
 stellen, ob das dann überhaupt noch korrekt gemappt ist wenn ein beliebiger 
 Punkt des Gebäudes die Adresse trägt und nicht das Gebäude selbst...

Jetzt wird es interessant, ist aber auch nicht mehr trivial. Drei Dinge
sind wichtig:

1. Struktur in OSM und die auswertende Software
2. Realität
3. völlständigkeit der Daten

zu 1.

Site Relationen mal außen vor gelassen, kannst Du auf jeden Fall mit
Gelände als Flächen/Multipolygone ohne building=* rechnen.
Weiter folgen Gebaude als Flächen/Multipolygone
Dann Gebäude mit einem oder mehreren Punkten sowohl innerhalb als auch
als Kindspunkte mit/ohne entrance=*.
Letztlich wohl noch einzele Punkte.

Gewünscht ist eigentlich, dass Adressinformation vererbt werden und
somit das größte Objekt nur die Informationen trägt. Leider kommen
damit nur wenige Programme klar, weshalb auch oft doppelte Hausnummern
vorkommen (Laden + Wohnhaus).

zu 2.
* Es gibt durch aus Häuser mit mehreren Hausnummern.
* Es gibt durch aus nicht vergebene Hausnummern
* Ich habe auch schon Gelände mit Hausnummer gesehen und dann doch noch
extra Nummern für einige Häuser auf dem Gelände.

zu 3.

Die Daten sind nicht immer vollständig, was sowohl einzelne Gebäude als
auch Hausnummern betrifft. Deshalb können hier nur schwer Annahmen
gemacht werden.

 Es war auch noch angedacht, zu erkennen, wenn ein Adress-Punkt innerhalb 
 eines Gebäudes liegt, dass das wohl die Adresse des entsprechenden Gebäudes 
 sein muss. Das dürfte aber wieder etwas aufwändiger zu implementieren sein...

Ist das nun eine von mehreren Nummern für das Gebäude oder wurde es
einfach nur nicht zusammengeführt ?

In solchen Fällen ist wohl eine Warnung angebracht.

Grüße fly

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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

2013-10-01 Diskussionsfäden fly

On 01.10.2013 18:10, Florian Lohoff wrote:
 On Tue, Oct 01, 2013 at 05:10:58PM +0200, tumsi wrote:
 Hallo zusammen,
 
 Dazu fänd ich ein missing post-code noch gut (oder seh ich das nicht?).

 Hm, wozu benötige ich das noch an einzelnen Knoten, Umrisen oder
 Straßen, wenn außen herum bereits ein post-code Polygon liegt?
 Ähnlich sehe ich es z.B. auch bei addr:city und addr:country. Dieses
 sind alles ableitbare Informationen, die so nur redundant in der
 Datenbank gehalten werden.
 
 Erster Satz der Nachrichtentechnik: Redundanz schafft Sicherheit :)
 
 Das bischen an Daten macht den Kohl nicht fett und die PLZ Polygone
 die wir derzeit haben sind - aehm - im detail reichlich kaputt.
 
 Wenn ich die Adressen durchgehe und wirklich Orte mit mehreren
 Postleitzahlen habe dann kontrolliere ich das auch mal durch und
 defakto müssen unsere PLZ Polygone noch um einiges genauer werden,
 teilweise auf Gebaeudegranularität.
 
 Es gibt halt fälle wo eine Straße eine Grenze der PLZ Bereiche
 darstellt und das so auch eingetragen ist. Leider gibt dann kleinere
 Stichwege mit 4-6 Häusern die im moment fälschlicherweise
 ausserhalb des Polygons liegen.
 
 Mal davon abgesehen das ich diese scharfe suche nach Ortsnamen
 oder PLZ anhand von Polygonen für falsch halte. Diese sind
 leider im OSM Datenbestand oftmals ungenau so das gewisse dinge
 dann nicht mehr auflösen.

Danke, dass motiviert mich ja jetzt richtig diese Grenzen zu verbessern.

Im Ernst, PLZ Grenzen sind doch leichter innerhalb der Daten zu warten
als administrative Grenzen. Bei mir sind diese durch mergen von Punkten
und verschieben, bzw auch durch Anpassung an verschobene Luftbilder
häufig sehr ungenau oder ein wildes Zickzack. Und ja, ich habe auch
schon die ein oder andere PLZ-Insel korrekt getaggt.

cu

fly

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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

Ich und viele andere
(Taginfohttp://taginfo.openstreetmap.org/keys/entrance#combinations)
mappen
Adressen für Wohnblocks oft mit dem Adress Tag auf den eingängen, da es
sich um ein gebäude mit mehreren Hausnummern handelt (oft ist auch nicht zu
erkennen, wo eine Trennung zu machen wäre.
Zum Beispiel so: http://www.openstreetmap.org/#map=19/51.01922/13.76985
Ich weiß, dass es da schon viele Diskussionen gab, aber ich persönlich
finde es so das beste System.

Adressen die einfach so innerhalb von Gebäuden rumliegen, sollten
auch erkannt (vllt seperat gekennzeichnet) werden. Das sieht man auch sehr
 häufig

mfg Christian



Am 1. Oktober 2013 16:54 schrieb Toggenburger Lukas 
lukas.toggenbur...@htwchur.ch:

 Hallo Christian

  es wäre schön, wenn der Adresslayer auch Häuser als addresiert
 anerkennt,
  wenn ein oder mehrere Hausnummern auf den Eingängen getaggt sind.

 Das würde wohl Sinn machen. Hast du gerade ein Beispiel, bei dem das der
 Fall ist?

 Es müssten ja gar nicht unbedingt Eingänge sein: Man könnte das Verfahren
 auch erweitern auf beliebige Adress-Punkte, die Teil eines
 Gebäude-Linienzuges sind. Dabei würde sich dann eventuell noch die Frage
 stellen, ob das dann überhaupt noch korrekt gemappt ist wenn ein
 beliebiger Punkt des Gebäudes die Adresse trägt und nicht das Gebäude
 selbst...

 Es war auch noch angedacht, zu erkennen, wenn ein Adress-Punkt innerhalb
 eines Gebäudes liegt, dass das wohl die Adresse des entsprechenden Gebäudes
 sein muss. Das dürfte aber wieder etwas aufwändiger zu implementieren
 sein...

 Gruss

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

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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

On Tue, Oct 01, 2013 at 06:34:04PM +0200, fly wrote:
 Danke, dass motiviert mich ja jetzt richtig diese Grenzen zu verbessern.
 
 Im Ernst, PLZ Grenzen sind doch leichter innerhalb der Daten zu warten
 als administrative Grenzen. Bei mir sind diese durch mergen von Punkten
 und verschieben, bzw auch durch Anpassung an verschobene Luftbilder
 häufig sehr ungenau oder ein wildes Zickzack. Und ja, ich habe auch
 schon die ein oder andere PLZ-Insel korrekt getaggt.

Es geht halt beides - PLZ Polygone anhand der addr:postcode bauen oder
den addr:postcode anhand der postcode boundarys ersetzen.

Ich bin dafür beides zu machen. Im moment ist beides unvollständig
und eines ergänzt das andere.

Und deshalb fragte ich nach der OSM PostCodeMap - dort konnte man schön
beides abgleichen - d.h. addr nodes/buildings mit den postcode
boundarys.

Es waren schnell abweichungen zu finden so das man entweder die boundary
oder die addr nodes fixen konnte.

Flo
-- 
Florian Lohoff f...@zz.de


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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

2013-10-01 Diskussionsfäden Peter Wendorff

Hi Lukas,

darf ich einen Kompromiss vorschlagen? wie wäre es, in osmi einen
overpass-Link entsprechend generiert einzufügen, der genau das ausgibt,
was angezeigt würde, die aktuelle Boundingbox eingeschlossen.

Ob das jetzt im Rahmen deiner Arbeit geschieht oder nicht sei
dahingestellt, aber es wär vielleicht gut, wenn es auf die Ideenliste so
käme.

Gruß
Peter

Am 01.10.2013 17:39, schrieb Toggenburger Lukas:
 Hallo Christian
 
 Vielleicht wäre es ja möglich, dass man sich auf der Karte die Gebäude
 markiert, welche noch keine Addresse haben und dann per gpx Datein
 ausgeben lassen kann, um sie auf dem Handy zu nutzen.
 
 Das ist schon ein gutes Stück weit weg von unserem angedachten Workflow.
 
 Eventuell wäre es einfacher, das mit einer Overpass-Anfrage zu machen? Als 
 Beispiel hab ich mal schnell eine Query zusammengebastelt, 
 die Gebäude ohne addr:street= ausgibt:
 
 query type=way
   has-kv k=building/has-kv
   has-kv k=addr:street modv=not regv=./
   bbox-query {{bbox}}/
 /query
 union
   item/
   recurse type=down/
 /union
 print/
 
 Zum Anzeigen auf http://overpass-turbo.eu/s/19F gehen, einen nicht zu grossen 
 Ausschnitt wählen und im Menü Ausführen, bzw. Run klicken.
 
 Die Vorteile davon wären, dass die Daten immer aktuell sind (so aktuell wie 
 die Overpass-Daten) und kaum Overhead generiert wird.
 
 Natürlich müsste die Suche nach keine Adresse vorhanden noch etwas 
 verfeinert werden (z.B. auch Tagging mittels Relationen beachten, etc.)...
 
 Gruss
 
 Lukas
 
 
 ___
 Talk-de mailing list
 Talk-de@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-de
 


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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

2013-10-01 Diskussionsfäden Bernhard Weiskopf

 Von: Peter Wendorff [mailto:wendo...@uni-paderborn.de]
 Gesendet: Dienstag, 1. Oktober 2013 20:57
 Wenn die Postleitzahlengebiete so eindeutig und korrekt eingetragen
 wären...

In meiner Umgebung sind die Postleitzahlengebiete relativ genau wie in der
früheren Karte der Post eingetragen. Die Gebiete stimmen aber nicht genau
mit den tatsächlichen Zustellbezirken und Postleitzahlen überein, auch
damals nicht. In der Regel stimmen die Angaben an den Gebäuden besser.

Aus dem Vergleich verspreche ich mir eine Korrekturmöglichkeit der
Gebietsrelationen und rate ebenfalls beides beizubehalten.

 Abgesehen davon sind Postleitzahlengebiete nicht immer vollständig
 anzunehmen, weil Großkunden etc. davon abweichende Postleitzahlen
 haben ...

Großkunden haben zwei (oder mehr) Postleitzahlen: Die örtliche (gilt nach
wie vor für Frachtzustellungen) und zusätzlich (meistens) eine
Großkundenpostleitzahl (für Briefe u. ä.). Die Großkundenpostleitzahl ist
nur eine Kurzform für die Postfachadresse. Unter addr:postcode trage ich
stets die örtliche Postleitzahl ein, die zur Straßenanschrift gehört.

Bernhard



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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

2013-10-01 Diskussionsfäden Martin Koppenhoefer

Am 1. Oktober 2013 16:54 schrieb Toggenburger Lukas 
lukas.toggenbur...@htwchur.ch:

 Dabei würde sich dann eventuell noch die Frage stellen, ob das dann
 überhaupt noch korrekt gemappt ist wenn ein beliebiger Punkt des Gebäudes
 die Adresse trägt und nicht das Gebäude selbst...



nach deutschem Recht sind es sowieso die Grundstücke und nicht die Gebäude,
die die Nummer bekommen (Im Übrigen gelten die landesrechtlichen
Vorschriften.), von daher ist korrekt relativ.
http://www.gesetze-im-internet.de/bbaug/__126.html
§126,(3)

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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

2013-10-01 Diskussionsfäden Martin Koppenhoefer

Am 1. Oktober 2013 20:16 schrieb christian.pietz...@googlemail.com 
christian.pietz...@gmail.com:

 Ich und viele andere
 (Taginfohttp://taginfo.openstreetmap.org/keys/entrance#combinations)
 mappen
 Adressen für Wohnblocks oft mit dem Adress Tag auf den eingängen, da es
 sich um ein gebäude mit mehreren Hausnummern handelt (oft ist auch nicht zu
 erkennen, wo eine Trennung zu machen wäre.
 Zum Beispiel so: http://www.openstreetmap.org/#map=19/51.01922/13.76985
 Ich weiß, dass es da schon viele Diskussionen gab, aber ich persönlich
 finde es so das beste System.




das ISTAT (italienische Statistikbehörde) hat vor ein paar Jahren mal
wieder eine Volkszählung gemacht. Die haben für Hausnummern 2 Objekte:
einmal den Eingang und Zuwegung von der Straße und dann den Bereich, für
den die Nummer gilt. Beides ist natürlich verknüpft.

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

Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp