Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.alt.comm.android > #52416 > unrolled thread

Adressen (maschinell) bereinigen?

Back to article view | Back to de.alt.comm.android

Contents

  Adressen (maschinell) bereinigen? Franklin Schiftan <fraschi_usenet@arcor.de> - 2026-06-21 09:09 +0200
    Re: Adressen (maschinell) bereinigen? Ralph Aichinger <ra@h5.or.at> - 2026-06-21 07:20 +0000
      Re: Adressen (maschinell) bereinigen? Franklin Schiftan <fraschi_usenet@arcor.de> - 2026-06-21 09:48 +0200
        Re: Adressen (maschinell) bereinigen? Ralph Aichinger <ra@h5.or.at> - 2026-06-21 08:14 +0000
          Re: Adressen (maschinell) bereinigen? Jörg Lorenz <hugybear@gmx.net> - 2026-06-21 10:21 +0200
            Re: Adressen (maschinell) bereinigen? Ralph Aichinger <ra@h5.or.at> - 2026-06-21 08:47 +0000
              Re: Adressen (maschinell) bereinigen? Franklin Schiftan <fraschi_usenet@arcor.de> - 2026-06-21 11:08 +0200
                Re: Adressen (maschinell) bereinigen? andreas quast <bu3ro.kratz@fr33n3t.de> - 2026-06-24 14:59 +0000
                  Re: Adressen (maschinell) bereinigen? Thomas Schade <toscha@rrr.de> - 2026-06-24 17:09 +0200
                    Re: Adressen (maschinell) bereinigen? Jörg Lorenz <hugybear@gmx.net> - 2026-06-24 18:51 +0200
                      Re: Adressen (maschinell) bereinigen? Thomas Schade <toscha@rrr.de> - 2026-06-24 19:39 +0200
                        Re: Adressen (maschinell) bereinigen? Jörg Lorenz <hugybear@gmx.net> - 2026-06-24 23:22 +0200
                          Re: Adressen (maschinell) bereinigen? Axel Berger <Spam@Berger-Odenthal.De> - 2026-06-24 23:47 +0200
                            Re: Adressen (maschinell) bereinigen? Jörg Lorenz <hugybear@gmx.net> - 2026-06-25 10:09 +0200
          Re: Adressen (maschinell) bereinigen? Franklin Schiftan <fraschi_usenet@arcor.de> - 2026-06-21 10:26 +0200
            Re: Adressen (maschinell) bereinigen? Ralph Aichinger <ra@h5.or.at> - 2026-06-21 09:05 +0000
              Re: Adressen (maschinell) bereinigen? Franklin Schiftan <fraschi_usenet@arcor.de> - 2026-06-21 11:16 +0200
              Re: Adressen (maschinell) bereinigen? Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-06-21 13:13 +0200
                Re: Adressen (maschinell) bereinigen? Heinz Schmitz <sch@example.invalid> - 2026-06-21 14:16 +0200
                Re: Adressen (maschinell) bereinigen? Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> - 2026-06-21 19:39 +0200
                  Re: Adressen (maschinell) bereinigen? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-21 18:14 +0000
                    Re: Adressen (maschinell) bereinigen? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-21 19:32 +0000
                      Re: Adressen (maschinell) bereinigen? Arno Welzel <usenet@arnowelzel.de> - 2026-06-21 22:29 +0200
                    Re: Adressen (maschinell) bereinigen? Ralph Aichinger <ra@h5.or.at> - 2026-06-21 19:36 +0000
                      Re: Adressen (maschinell) bereinigen? Axel Berger <Spam@Berger-Odenthal.De> - 2026-06-22 10:28 +0200
                        Re: Adressen (maschinell) bereinigen? Ralph Aichinger <ra@h5.or.at> - 2026-06-22 10:12 +0000
                    Re: Adressen (maschinell) bereinigen? Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> - 2026-06-22 13:48 +0200
                      Re: Adressen (maschinell) bereinigen? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-22 12:21 +0000
                        Re: Adressen (maschinell) bereinigen? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-22 12:25 +0000
                      Re: Adressen (maschinell) bereinigen? Ralph Aichinger <ra@h5.or.at> - 2026-06-22 15:02 +0000
                      Re: Adressen (maschinell) bereinigen? Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-06-22 17:24 +0200
                        Re: Adressen (maschinell) bereinigen? Thomas Dorner <daca260622.dorner@spamgourmet.com> - 2026-06-22 18:29 +0200
                        Re: Adressen (maschinell) bereinigen? Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> - 2026-06-23 07:24 +0200
                          Re: Adressen (maschinell) bereinigen? Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-06-23 08:40 +0200
                            Re: Adressen (maschinell) bereinigen? Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> - 2026-06-23 10:41 +0200
                              Re: Adressen (maschinell) bereinigen? Ralph Aichinger <ra@h5.or.at> - 2026-06-23 15:38 +0000
                          Re: Adressen (maschinell) bereinigen? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-23 07:54 +0000
                            Re: Adressen (maschinell) bereinigen? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-23 08:38 +0000
                            Re: Adressen (maschinell) bereinigen? Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> - 2026-06-23 10:46 +0200
                              Re: Adressen (maschinell) bereinigen? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-23 09:18 +0000
                          Re: Adressen (maschinell) bereinigen? Arno Welzel <usenet@arnowelzel.de> - 2026-06-24 13:14 +0200
                            Re: Adressen (maschinell) bereinigen? Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> - 2026-06-24 15:32 +0200
                              Re: Adressen (maschinell) bereinigen? Arno Welzel <usenet@arnowelzel.de> - 2026-06-24 20:06 +0200
                                Re: Adressen (maschinell) bereinigen? Heinz Schmitz <sch@example.invalid> - 2026-06-25 11:39 +0200
                      Re: Adressen (maschinell) bereinigen? Arno Welzel <usenet@arnowelzel.de> - 2026-06-22 22:26 +0200
                      Re: Adressen (maschinell) bereinigen? Walter Brill <WalterBrill@t-online.de> - 2026-06-25 15:13 +0200
                        Re: Adressen (maschinell) bereinigen? Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> - 2026-06-26 10:54 +0200
    Re: Adressen (maschinell) bereinigen? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-21 09:11 +0000
      Re: Adressen (maschinell) bereinigen? Franklin Schiftan <fraschi_usenet@arcor.de> - 2026-06-21 11:32 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#52437

Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> schrieb oder zitierte:
>Natürlich kann man das alles in das Straßenfeld packen. Aber wenn man
>Struktur haben will, hat man verloren

  Also, ich meine, daß man so etwas schon bewältigen kann.

  Zunächst einmal muß man den Kunden fragen, wofür er die Datensätze
  verwenden will. Nehmen wir zum Beispiel an, die Antwort lautet:
  1. für Briefanschriften
  2. zum Anrufen (Telephonnummer).

  Dann könnte man im Prinzip jeden Datensatz so aufbauen:

  0 - Identifikation (normalerweise der Name)
  1 - Rufnummer
  2 - Anschrift

  Das sollte dann mit allen Orten auf der ganzen Welt gehen,
  in denen es überhaupt so etwas wie international erreichbare
  Telephone und Postanschriften gibt.

[toc] | [prev] | [next] | [standalone]

#52440

ram@zedat.fu-berlin.de (Stefan Ram) schrieb oder zitierte:
>  0 - Identifikation (normalerweise der Name)
>  1 - Rufnummer
>  2 - Anschrift

  Chatbot:

| To handle global addresses without breaking in regions that lack
| traditional street names or house numbers, enterprise giants like
| Amazon, eBay, and Shopify discard hyper-specific fields like "Street
| Name" and "House Number" in favor of an abstract, multi-line container
| schema.
| 
| The industry standard for a globalized address database uses a
| flexible structure that relies heavily on "free-form" text fields
| combined with universal geographic identifiers.
| 
| The Core Global Address Schema
| 
| A production-ready database table for international e-commerce
| addresses generally uses the following universal fields:
| 
| Full Name / Recipient   The individual or business name.
| 
| Address Line 1   Used for the core structural address data (e.g.,
| house number and street, plot number, crossroads, or building name).
| 
| Address Line 2 (Optional)   Used for micro-locational data like
| apartment, suite, unit, floor, or local landmarks.
| 
| Address Line 3 / Line 4 (Optional)   Used in complex international
| regions (like parts of India, Japan, or rural areas) to list extended
| subdivisions, neighborhoods, or sub-localities.
| 
| Locality   The generic term for a City, Town, or Village.
| 
| Region / Administrative Area   The generic term for a State, Province,
| Territory, County, or Emirate (often mapped to ISO codes, such as US
| states or Canadian provinces).
| 
| Postal Code / ZIP Code   The alphanumeric routing code. This field is
| usually made optional because several countries (such as the UAE or
| Ireland prior to Eircodes) do not utilize traditional postal codes.
| 
| Country Code   A strict 2-letter or 3-letter ISO country code (e.g.,
| US, DE, JP). This functions as the ultimate database anchor.
| 
| Phone Number   A critical fallback identifier, especially in countries
| where delivery personnel rely on calling the customer to locate the
| exact drop-off point.
| 
| ----------------------------------------------------------------------
| 
| Why This Design Works Globally
| 
|   ---------------------------------------------------------------------
|   Region Challenge                   How the Database Handles It
|   ---------------------------------- ----------------------------------
|   No Street Names (e.g., Rural       The customer places their village
|   Ireland, parts of UAE)             name, house name, or plot
|                                      descriptor straight into Address
|                                      Line 1.
| 
|   Blocks & Grids (e.g., Japan, South Addresses go from largest entity
|   Korea)                             to smallest. The block, chome, and
|                                      building number are sequentially
|                                      written across the generic Address
|                                      Lines.
| 
|   Landmark-Based Routing (e.g.,      Directions like "Opposite the blue
|   Latin America, Africa)             gas station" or "Two blocks south
|                                      of the old church" are naturally
|                                      typed directly into Address Line
|                                      2.
| 
|   Military Addresses (e.g., APO/FPO) "APO" or "FPO" is mapped directly
|                                      into the Locality (City) field,
|                                      while the Region (State) uses
|                                      military designations like "AA" or
|                                      "AE".
|   ---------------------------------------------------------------------
| 
| ----------------------------------------------------------------------
| 
| UI Adaptation vs. Database Storage
| 
| A common misconception is that the database fields exactly match the
| text boxes you see on screen. Companies use an abstraction layer
| between the database and the customer:
| 
| 1.  Frontend Localization: When a user selects a country from a
|     dropdown menu (e.g., Germany vs. the United States), JavaScript
|     dynamically re-labels the frontend form fields. A user in Berlin
|     sees "Straße und Hausnummer," while a user in New York sees
|     "Street Address" and "Apt/Suite."
| 
| 2.  The Database Flattening: No matter what the frontend label says,
|     the database engine treats whatever text was typed into those
|     boxes as generic data points mapped directly to address_line_1,
|     address_line_2, and locality.
| 
| 3.  Geocoding Fallbacks: For logistics routing, companies pass these
|     abstract lines to cloud mapping engines like Amazon Location
|     Service or Google Maps API. These engines convert the free-form
|     text blocks into precise Latitude and Longitude coordinates for
|     the delivery driver’s GPS map, bypassing the need for a physical
|     street address entirely.

[toc] | [prev] | [next] | [standalone]

#52447

Stefan Ram, 2026-06-21 21:32:

> ram@zedat.fu-berlin.de (Stefan Ram) schrieb oder zitierte:
>>  0 - Identifikation (normalerweise der Name)
>>  1 - Rufnummer
>>  2 - Anschrift
> 
>   Chatbot:
[...]

Hört doch bitte auf, irgendwelche Antworten von Sprachmodellen zu
posten. Wer sowas wissen will, kann auch einfach selber da fragen und
kann sich die Frage hier sparen.

Weiterhin ist diese Newsgroup deutschsprachig. Nicht jeder kann so gut
Englisch, dass er solche Antworten problemlos versteht, auch wenn er
sich mit Software beschäftigt.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#52441

Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>   verwenden will. Nehmen wir zum Beispiel an, die Antwort lautet:
>   1. für Briefanschriften
>   2. zum Anrufen (Telephonnummer).
    3. um Koordinaten zu ermitteln (Punkte auf einer Karte)
    4. um für steuerliche Fragen in eine Gemeinde einzuordnen
    5. um etwas zuzustellen
    6. um Bonität einzuschätzen (eventuell illegal)

/ralph

[toc] | [prev] | [next] | [standalone]

#52451

Ralph Aichinger wrote:
>     6. um Bonität einzuschätzen (eventuell illegal)

Du meinst also die Vielzahl der Felder statt eines einzigen freien
Textfeldes, das den meisten vollkommen ausreicht, diene vor allem dem
Zweck, die Daten dem Großen Bruder mundgerecht anzuliefern? Nicht
unplausibel.


-- 
/¯\   No  |    Dipl.-Ing. F. Axel Berger    Tel: +49/ 221/ 7771 8067
\ /  HTML |    Roald-Amundsen-Straße 2a     Fax: +49/ 221/ 7771 8069
 X    in  |    D-50829 Köln-Ossendorf      http://berger-odenthal.de
/ \  Mail | -- No unannounced, large, binary attachments, please! --

[toc] | [prev] | [next] | [standalone]

#52452

Axel Berger <Spam@berger-odenthal.de> wrote:
> Ralph Aichinger wrote:
>>     6. um Bonität einzuschätzen (eventuell illegal)
> 
> Du meinst also die Vielzahl der Felder statt eines einzigen freien
> Textfeldes, das den meisten vollkommen ausreicht, diene vor allem dem
> Zweck, die Daten dem Großen Bruder mundgerecht anzuliefern? Nicht
> unplausibel.

Nein, ich meine: Wer spezifischere Anforderungen hat, der braucht
eventuell strukturiertere Daten. Für forward geocoding (geographische
Koordinaten aus Adressen) ist eventuell mehr Struktur sinnvoll. Aber
vielleicht auch nicht, wenn man irgendeinen Clouddienst nimmt, der
eh mit AI drübergeht und gängige Formate hablbwegs versteht.

/ralph

[toc] | [prev] | [next] | [standalone]

#52453

Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> schrieb oder zitierte:
>>Natürlich kann man das alles in das Straßenfeld packen. Aber wenn man
>>Struktur haben will, hat man verloren
>
>   Also, ich meine, daß man so etwas schon bewältigen kann.
>
>   Zunächst einmal muß man den Kunden fragen, wofür er die Datensätze
>   verwenden will. Nehmen wir zum Beispiel an, die Antwort lautet:
>   1. für Briefanschriften
>   2. zum Anrufen (Telephonnummer).
>
>   Dann könnte man im Prinzip jeden Datensatz so aufbauen:
>
>   0 - Identifikation (normalerweise der Name)
>   1 - Rufnummer
>   2 - Anschrift
>
>   Das sollte dann mit allen Orten auf der ganzen Welt gehen,
>   in denen es überhaupt so etwas wie international erreichbare
>   Telephone und Postanschriften gibt.

Exakt das sagte ich. Das geht immer.
Aber meine weitere Aussage war: wenn man MEHR STruktur braucht, hat man
international verloren. Grund: Anschrift ist international nicht
normbar.
>
>

[toc] | [prev] | [next] | [standalone]

#52454

Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> schrieb oder zitierte:
>>0 - Identifikation (normalerweise der Name)
>>1 - Rufnummer
>>2 - Anschrift
. . .
>Exakt das sagte ich. Das geht immer.
>Aber meine weitere Aussage war: wenn man MEHR STruktur braucht, hat man
>international verloren. Grund: Anschrift ist international nicht
>normbar.

  Ja. Aber man sollte dann einmal überdenken, ob man mit "mehr
  Struktur" nicht eigentlich teilweise "die in meiner Region
  der Welt übliche Struktur" meint.

  Wenn ja, ist es auch nicht schlimm. Man könnte diese Struktur
  dann für diejenigen Personen, bei denen sie gegeben (möglich)
  ist, in zusätzlichen Feldern erfassen, die bei anderen Personen 
  dann einen Null-Wert enthalten.

  Jetzt könnte jemand einwenden, daß bestimmte Teile der Daten
  dann doppelt erfaßt werden: einmal in einem universellen Feld
  und einmal in einem regionalen Feld (Redundanz). - Dann würde
  ich sagen, ok, diese Redundanz ist der Preis, den man zahlen
  muß, wenn man das so will.

  Man könnte auch zu einer Mischung aus Datenbank und XML
  greifen, um diese Redundanz zu vermeiden:

Name: <Vorname>Wolfgang</Vorname> <Nachname>Müller</Nachname>
Name: <Eigenname>Jón</Eigenname> <Patronym>Einarsson</Patronym>
Name: <Mononym>Suharto</Mononym>

  . Für den Zweck eines Namens kann man die Tags dann einfach
  löschen, aber wenn man mehr Informationen haben will, kann
  man sie erhalten.

  Aber anscheinend kommen viele international erfolgreichen
  Unternehmen gut ohne solche Details aus, wie der Chatbot
  ausführte. Diese Details tragen aber zur Komplexität des
  Projektes bei. Also sollte man sich überlegen, ob man sie
  wirklich benötigt.

[toc] | [prev] | [next] | [standalone]

#52455

ram@zedat.fu-berlin.de (Stefan Ram) schrieb oder zitierte:
>Jetzt könnte jemand einwenden, daß bestimmte Teile der Daten
>dann doppelt erfaßt werden: einmal in einem universellen Feld
>und einmal in einem regionalen Feld (Redundanz). - Dann würde
>ich sagen, ok, diese Redundanz ist der Preis, den man zahlen
>muß, wenn man das so will.

  PS: Im Prinzip wäre es mögliche, die universellen Felder dann
  aus den regionalen Feldern und gewissen regionalen Regeln
  zu rekonstruieren, aber so etwas erzeugt Komplexität, also
  Kosten, welche bei einem Unternehmen dann geringer als der
  resultierende Nutzen (Gewinn) sein sollten.

[toc] | [prev] | [next] | [standalone]

#52457

Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> wrote:
> Aber meine weitere Aussage war: wenn man MEHR STruktur braucht, hat man
> international verloren. Grund: Anschrift ist international nicht
> normbar.

Man könnte eine Fallunterscheidung nach Ländern oder Regionen machen.
Und dann jedes Land mit einer konkreten, spezifischen Struktur versehen.

/ralph

[toc] | [prev] | [next] | [standalone]

#52458

Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> wrote:
>Aber meine weitere Aussage war: wenn man MEHR STruktur braucht, hat man
>international verloren. Grund: Anschrift ist international nicht
>normbar.

Abhänging vom Land die landesüblichen Felder in der landesüblichen
Form nehmen ginge.

Grüße
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[toc] | [prev] | [next] | [standalone]

#52459

Marc Haber <mh+usenetspam2616@zugschl.us> writes:

> Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> wrote:
>>Aber meine weitere Aussage war: wenn man MEHR STruktur braucht, hat man
>>international verloren. Grund: Anschrift ist international nicht
>>normbar.
>
> Abhänging vom Land die landesüblichen Felder in der landesüblichen
> Form nehmen ginge.

Und man könnte das dann "LC_ADDRESS" nennen ... ;-)

Viele Grüße, Thomas
-- 
Adresse gilt nur kurzzeitig!

[toc] | [prev] | [next] | [standalone]

#52465

Marc Haber <mh+usenetspam2616@zugschl.us> wrote:
> Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> wrote:
>>Aber meine weitere Aussage war: wenn man MEHR STruktur braucht, hat man
>>international verloren. Grund: Anschrift ist international nicht
>>normbar.
>
> Abhänging vom Land die landesüblichen Felder in der landesüblichen
> Form nehmen ginge.

Nur bedingt. Nimm als Beispiel Japan. Es gibt gute Gründe warum man dort
bei bestimmten Adressen den Ortspolizisten frägt (auch als Japaner) und
nicht die Kartenapp der Wahl. Die Anschriften sind teilweise nicht
strukturierbar. Außer Du packst alles in ein Feld. Aber dann ist es
nicht mehr maschinenauswertbar.

Bye, Stefan

[toc] | [prev] | [next] | [standalone]

#52466

Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> wrote:
>Marc Haber <mh+usenetspam2616@zugschl.us> wrote:
>> Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> wrote:
>>>Aber meine weitere Aussage war: wenn man MEHR STruktur braucht, hat man
>>>international verloren. Grund: Anschrift ist international nicht
>>>normbar.
>>
>> Abhänging vom Land die landesüblichen Felder in der landesüblichen
>> Form nehmen ginge.
>
>Nur bedingt. Nimm als Beispiel Japan. Es gibt gute Gründe warum man dort
>bei bestimmten Adressen den Ortspolizisten frägt (auch als Japaner) und
>nicht die Kartenapp der Wahl. Die Anschriften sind teilweise nicht
>strukturierbar. Außer Du packst alles in ein Feld. Aber dann ist es
>nicht mehr maschinenauswertbar.

Und deswegen und vermutlich einer Handvoll anderer Länder muss die
westliche Welt (mir fallen da Deutschland, USA, GB und die Niederlande
ein die unterschiedliche Adressformate haben) auf korrekte
Adressdarstellung verzichten?

Grüße
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[toc] | [prev] | [next] | [standalone]

#52469

Marc Haber <mh+usenetspam2616@zugschl.us> wrote:
> Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> wrote:
>>Marc Haber <mh+usenetspam2616@zugschl.us> wrote:
>>> Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> wrote:
>>>>Aber meine weitere Aussage war: wenn man MEHR STruktur braucht, hat man
>>>>international verloren. Grund: Anschrift ist international nicht
>>>>normbar.
>>>
>>> Abhänging vom Land die landesüblichen Felder in der landesüblichen
>>> Form nehmen ginge.
>>
>>Nur bedingt. Nimm als Beispiel Japan. Es gibt gute Gründe warum man dort
>>bei bestimmten Adressen den Ortspolizisten frägt (auch als Japaner) und
>>nicht die Kartenapp der Wahl. Die Anschriften sind teilweise nicht
>>strukturierbar. Außer Du packst alles in ein Feld. Aber dann ist es
>>nicht mehr maschinenauswertbar.
>
> Und deswegen und vermutlich einer Handvoll anderer Länder muss die
> westliche Welt (mir fallen da Deutschland, USA, GB und die Niederlande
> ein die unterschiedliche Adressformate haben) auf korrekte
> Adressdarstellung verzichten?

Nein, natürlich nicht. Aber das war auch nicht meine Aussage.
Nochmal: meine Aussage war: wer _Struktur_ haben will _und_ _weltweit_
Adressen strukturiert speichern will, hat Pech gehabt.

Bei Ländern, die halbwegs akzeptable Struktur in ihren Adressen haben,
ist korrekte Darstellung idR kein Problem. Wenn zB Google Contacts das
nicht kann (kommt bei mir öfter vor), dann ist das ein Bug. Oder
Unwille.

Bye, Stefan

[toc] | [prev] | [next] | [standalone]

#52472

Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> wrote:
> Nein, natürlich nicht. Aber das war auch nicht meine Aussage.
> Nochmal: meine Aussage war: wer _Struktur_ haben will _und_ _weltweit_
> Adressen strukturiert speichern will, hat Pech gehabt.

Was spricht gegen Fallunterscheidungen?

Bei den Geschlechtern muss man ja auch nicht entweder alle mit "Herr" 
oder alle mit "Frau" anreden? 

Dann soll von mir aus jemand aus Japan die Möglichkeit von 5 Zeilen
Freitext haben, wenn er die braucht, optional strukturierter, wenn
er in irgendeiner Straße in Tokyo wohnt, und der Brite bekommt seine
Hausnummer vor der Straße und seine Postleitzahl mit Buchstaben drin.

/ralpj

[toc] | [prev] | [next] | [standalone]

#52467

Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> schrieb oder zitierte:
>Nur bedingt. Nimm als Beispiel Japan. Es gibt gute Gründe warum man dort
>bei bestimmten Adressen den Ortspolizisten frägt (auch als Japaner) und
>nicht die Kartenapp der Wahl. Die Anschriften sind teilweise nicht
>strukturierbar. Außer Du packst alles in ein Feld. Aber dann ist es
>nicht mehr maschinenauswertbar.

  Man kann alles in ein großes Feld packen /und/ weitere
  kleine Felder für maschinelle Auswertung verwenden.

  Die Informationen werden sich dann teilweise redundant
  überlappen und die Erfassung wird aufwendiger.

  Diese Redundanz kann abgemildert werden, indem man Adressen
  mit einer Regionskennzahl kennzeichnet, bei denen das große
  Feld nach regionalen Regeln automatisch aus den kleinen Feldern
  rekonstruiert werden kann, und für diese das große Feld leer läßt.

[toc] | [prev] | [next] | [standalone]

#52468

ram@zedat.fu-berlin.de (Stefan Ram) schrieb oder zitierte:
>Man kann alles in ein großes Feld packen /und/ weitere
>kleine Felder für maschinelle Auswertung verwenden.

  Hier ein Beispiel. Es ist etwas vereinfacht, da es nur den 
  Aspekt der Aufschrift auf einer Postsendung illustrieren soll.

  Falls der region_code nicht NULL ist wird das Aufschriftfeld
  "envelope" an Hand der Nachschlagetabelle (s.u.) konstruiert.
  (Die erfundenen Beispielmuster sind hier nicht unbedingt korrekt.)

  Haupttabelle

delivery_id: 1
region_code: US_CAN
envelope: NULL
given_name: Jane
inherited_name: Doe
street: Main St
house_number: 123
city: Springfield
state_province: IL
postal_code: 62701
country: US
phone_number: +1-217-555-0143

delivery_id: 2
region_code: EU_WEST
envelope: NULL
given_name: Jean
inherited_name: Dupont
street: Rue de la Paix
house_number: 45
city: Paris
state_province: NULL
postal_code: 75002
country: FR
phone_number: +33-1-42277856

delivery_id: 3
region_code: UK_STD
envelope: NULL
given_name: Alex
inherited_name: Smith
street: High St
house_number: 10
city: London
state_province: NULL
postal_code: SW1A 1AA
country: GB
phone_number: +44-20-79460192

delivery_id: 4
region_code: IN_URBAN
envelope: NULL
given_name: Rajesh
inherited_name: Kumar
street: MG Road
house_number: Flat 4B, Block C
city: Bengaluru
state_province: Karnataka
postal_code: 560001
country: IN
phone_number: +91-80-25582312

delivery_id: 5
region_code: NULL
envelope: 田中 太郎 様
          〒100-0014 東京都千代田区永田町1丁目7-1
          国会議事堂裏手 憲政記念館の北西角地
          （※本館番号なし・配送口：北側通用門）
given_name: NULL
inherited_name: 田中 太郎
street: NULL
house_number: NULL
city: 千代田区
state_province: 東京都
postal_code: 100-0014
country: JP
phone_number: +81-3-55217400
region_code: US_CAN

  Nachschlagetabelle

US_CAN      {{given_name}} {{inherited_name}}
            {{street}}, {{state_province}}
            {{postal_code}}

EU_WEST     {{given_name}} {{inherited_name}}
            {{street}} {{house_number}}
            {postal_code}} {{city}}

UK_STD      {{given_name}} {{inherited_name}}
            {{house_number}} {{street}}
            {{city}}
            {{postal_code}}

IN_URBAN    {{given_name}} {{inherited_name}},
            {{street}} - {{postal_code}}

[toc] | [prev] | [next] | [standalone]

#52470

Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> schrieb oder zitierte:
>>Nur bedingt. Nimm als Beispiel Japan. Es gibt gute Gründe warum man dort
>>bei bestimmten Adressen den Ortspolizisten frägt (auch als Japaner) und
>>nicht die Kartenapp der Wahl. Die Anschriften sind teilweise nicht
>>strukturierbar. Außer Du packst alles in ein Feld. Aber dann ist es
>>nicht mehr maschinenauswertbar.
>
>   Man kann alles in ein großes Feld packen /und/ weitere
>   kleine Felder für maschinelle Auswertung verwenden.
>
>   Die Informationen werden sich dann teilweise redundant
>   überlappen und die Erfassung wird aufwendiger.

Und es ist mit dieser Lösung vollkommen klar, daß über kurz oder lang
der Inhalt des großen Feldes und der kleinen Felder divergieren wird.

Soviele Sonderfälle kann sich der Entwickler, der diese Lösung ausbaden
muß, gar nicht ausdenken um nicht etliche zu übersehen.

Und ja, ich habe das Mal eine Weile ausprobiert.

Bye, Stefan

[toc] | [prev] | [next] | [standalone]

#52471

Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> schrieb oder zitierte:
>Und es ist mit dieser Lösung vollkommen klar, daß über kurz oder lang
>der Inhalt des großen Feldes und der kleinen Felder divergieren wird.

  Deswegen kann der Datenbankgestalter seinem Kunden diese Möglichkeit
  anbieten und ihn darauf hinweisen, daß dieses Risiko besteht.

  Der Kunde entscheidet dann, ob er diese Lösung unter Inkaufnahme
  solcher Risiken wünscht.

  Und der Chatbot hatte hier ja bereits berichtet, wie so etwas von 
  Unternehmen wie Amazon, eBay, and Shopify tatsächlich gehandhabt wird.

  (Ich habe mich hier zuletzt auf die Datenbankgestaltung im engeren
  Sinne, also auf die Tabellenstruktur konzentiert. Es gibt natürlich
  auch noch den Aspekt der Benutzerschnittstelle samt Datenprüfung.)

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | de.alt.comm.android

csiph-web