Qu'est-ce qu'un moyen universel de stocker une adresse / un emplacement géographique dans une base de données? [fermé]

25

Quel est le format correct d'une adresse / d'un emplacement géographique qui convient bien à n'importe quelle adresse sur la Terre? En ce moment, j'ai:

  • pays
  • ville
  • rue
  • nombre
  • données texte (pour plus de simplicité)
  • Zip *: français
  • lat / lng

Mais je crois que je peux l'améliorer: il pourrait y avoir un état / région d'un pays ou quelque chose comme une région. Ou pas de région / région / état, par exemple, à Singapour ou à Hong Kong.

Il pourrait ne pas y avoir de rue, mais une route ou un boulevard ou autre chose. Un certain nombre de bâtiments peuvent être composés. Il pourrait y avoir un étage. Un numéro de chambre. Etc....

Xwaro
la source
11
Vous devez expliquer pour quelle application et qui fournit cette adresse. Par exemple, sur la plupart des magasins / sites Web commerciaux, je ne saisis aucune "latitude / longitude" qui, au contraire, est essentielle pour les ICBM (ou GPS). De plus, l'altitude (et l'heure et la date) sont importantes dans certains cas (pensez à un navire en mer ou à un voyageur sur l'Everest). Je ne suis donc pas sûr qu'il existe une réponse universelle.
Basile Starynkevitch
6
@BasileStarynkevitch: Je pense que ce n'est pas tellement important "pour quelle application", mais "pour quel (s) cas d'utilisation". Si, par exemple, le cas d'utilisation est de s'assurer que les services postaux du monde entier peuvent livrer des courriers, je suppose que cette question peut trouver une réponse raisonnable. Cependant, pour ce cas d'utilisation, "lat / lng" ne sera pas requis.
Doc Brown
34
Je pense que le format universel pour une adresse est une seule chaîne.
Erik Eidt
12
Le problème que vous soulevez est si douloureux, que certaines entreprises développent leur manière universelle de le résoudre, par exemple: what3words.com (se résume à mapper les coordonnées de localisation sur trois mots). Ils affirment que "Avec what3words, tout le monde et partout dans le monde ont désormais une adresse".
Roman Susi

Réponses:

51

Google a développé une bibliothèque qui permet de valider les adresses postales pour chaque pays du monde, que vous pouvez utiliser pour concevoir un schéma pour stocker ces données.

Recherchez les champs obligatoires les plus courants dans les adresses de votre base de clients cible pour commencer, et au fur et à mesure que vous identifiez d'autres pays avec des exigences différentes, vous pouvez continuer à ajuster votre schéma.

mitchdav
la source
5
+1 pour étudier les solutions existantes. La Addressclasse du SDK Android pourrait être un autre bon point de départ.
Kevin Krumwiede
4
Une analyse rapide de la bibliothèque Google montre qu'elle s'appuie sur oasis-open.org/committee/ciq/download.shtml
grahamj42
@ grahamj42, lol, cette page est tellement cassée.
Nakilon
41

La façon universelle de stocker une adresse / un emplacement géographique dans une base de données est la suivante:

[Address] nvarchar(max) not null

Cela nécessite le moins de code de programmation (et donc réduit les coûts de maintenance) et est entièrement compatible avec n'importe quelle adresse. Il y a cependant trois grands problèmes:

  • L'absence de validation des données signifie que le champ peut être utilisé à d'autres fins que le stockage de l'adresse. L'un des objectifs est une attaque DOS destinée à remplir l'espace de votre base de données en entrant 2 Go de données dans le champ d'adresse.

  • Les données ainsi stockées ne permettent pas de les traiter à des fins de veille économique et d'exploration de données. Par exemple, combien d'utilisateurs viennent d'Inde? Il n'y a pas de moyen facile de le savoir, car ces adresses ne seront pas normalisées.

  • Les utilisateurs peuvent entrer par erreur une adresse incomplète ou manifestement erronée.

Afin d'atténuer le premier problème, limitez le champ à ce que vous pensez être une limite raisonnable. Personnellement, je commencerais par 1000 caractères, puis je le réduirais en fonction de la longueur des adresses saisies par les premiers utilisateurs une fois que vous aurez obtenu un ensemble de données suffisamment volumineux.

Afin d'atténuer les deux autres problèmes, vous pouvez utiliser une API tierce qui analyse les adresses et vous présente les données contenant le pays, la ville, le code postal, etc. Si possible, l'API doit pouvoir afficher l'adresse sur une carte à l'utilisateur pour réduire le risque pour l'utilisateur d'entrer une adresse incomplète ou erronée: la plupart des utilisateurs savent où ils vivent, et voir une position différente sur une carte leur donnerait immédiatement un indice qu'ils devraient vérifier leur entrée.

Notez que quelle que soit l'API que vous utilisez, elle ne sera pas parfaite. Il trouvera la plupart des adresses, mais pas toutes. Cela signifie que si l'API indique que l'adresse n'existe pas, mais que l'utilisateur insiste sur le fait, vous devez a priori faire confiance à l'utilisateur, même s'il peut se tromper.

Cela signifie également que vous devez toujours stocker l'entrée de l'utilisateur d'origine, côte à côte avec le résultat de l'API. Cela signifie que le schéma devient:

[RawAddress] nvarchar(max) not null
[ParsedAddress] xml null
Arseni Mourzenko
la source
Remarque: Au minimum, vous pouvez stocker le pays séparément, si cela est nécessaire. Par exemple, il pourrait être automatiquement déduit du champ d'adresse, avec la possibilité pour l'utilisateur de le modifier.
Matthieu M.
'utiliser une API' signifie simplement que quelqu'un d'autre a obtenu tous les formats officiels du pays. Il n'y a aucune raison pour que vous ne puissiez pas le faire vous
Ewan
@Ewan Aucune raison, sauf pour le temps, l'argent, la langue et d'autres obstacles.
Andrew dit Réintégrer Monica le
Bien sûr, mais fournissons-nous des réponses sur la façon de faire des choses ou de comparer les prix des autres personnes qui font des choses pour vous?
Ewan
@Ewan: la question porte sur le format de stockage des adresses. L'API ne dicte pas ce format: le but de ma réponse est de montrer que dès que vous avez un champ de texte brut et un champ XML / JSON / quel que soit le champ pour les données analysées, vous pouvez à la fois stocker et traiter statistiquement une adresse de n'importe où dans le monde.
Arseni Mourzenko
37

Il n'y en a pas.

Chaque pays a des formats d'adresse différents. Si vous avez de la chance, et ils ont un format du tout!

Évidemment, la latitude / longitude vous donnera un point sur le globe, mais ce n'est pas vraiment utile pour identifier des maisons individuelles. Prenons par exemple un bloc tour.

Votre meilleur pari est de vérifier le service postal de chaque pays pour un format officiel. Cela peut être idéal pour votre base de données backend. Mais vous devrez probablement le simplifier pour les utilisateurs finaux car il contiendra beaucoup plus de champs que la plupart des gens.

Le Royaume-Uni, par exemple, comprend des choses comme «localité à double dépendance», mais personne ne saurait ce que cela signifie si vous leur posez la question.

Ewan
la source
3
Qu'est-ce qu'un moyen universel ...........
Xwaro
40
@Xwaro Ils viennent de dire: il n'y en a pas.
Zymus
6
Je suppose que Xwaro signifie que je suppose des adresses sur terre.
Ewan
3
Ceci est la source officielle des formats d'adresse imprimés: Union postale universelle
grahamj42
3
intéressant. Je pense que c'est la page pertinente cependant: upu.int/en/activities/addressing/s42-standard/… vous pouvez voir comment A: ce ne sont que quelques pays, et B: la correspondance de s42 au format d'adresse des pays n'est pas 1 au 1
Ewan
21

Le seul format universel est d'avoir un seul champ de texte qui peut avoir plusieurs lignes de texte. Cela permettra toute adresse possible sur terre.

JacquesB
la source
2
Génial, maintenant tout le monde peut décrire la même adresse d'une manière différente et incompatible. Je suppose que la question ne portait pas sur les normes, c'est donc techniquement une bonne réponse.
Michael
@Michael: Les adresses sont différentes et incompatibles à travers le monde. Il n'y a pas de modèle standard. Le fait d'avoir un champ sur plusieurs lignes permet à l'utilisateur d'écrire réellement la bonne adresse.
JacquesB
@Michael Des champs séparés me forcent souvent à tronquer / abréger un champ ou l'autre, ce qui conduit également à des représentations incohérentes. (Fonctionne toujours habituellement, les services postaux sont assez expérimentés dans ce domaine).
Hulk
Juste une friandise intéressante, ce n'est pas techniquement vrai. Dans certaines régions des pays, des parties d'adresses sont dessinées sous forme d'images.
KayakinKoder
9

J'ai développé des solutions logicielles à utiliser dans de nombreux pays. Nous abordons ce problème en commençant par l'entité la plus grande en premier, c'est-à-dire que le pays a ensuite des champs jusqu'au moins commun ou le plus petit. Cela fonctionne bien pour tous les pays que nous avons expérimentés jusqu'à présent. Nous avons également un système intelligent de prévention des doublons et une fusion pour ceux qui ont en quelque sorte pénétré le système, car les utilisateurs sont très «créatifs». Dans la section d'administration, nous avons un ordre de champ d'adresse par paramètre de pays. c'est-à-dire que le Japon a le code postal / zip en premier, alors que le Royaume-Uni / États-Unis en dernier.

En général, nous utilisons:

  • Pays
  • Code postal / postal
  • État / Province / Préfecture / Comté
  • Ville / Village / Village
  • Rue / route / bloc
  • Nom / numéro du bâtiment
  • Informations spécifiques / personnalisées

Une fois saisie et enregistrée, une version conjuguée peut être affichée en laissant les champs inutiles.

Comme je l'ai dit, cela fonctionne pour tous les pays dans lesquels nous avons des logiciels et est le résultat du développement depuis 1989.

J'espère que cela aide en quelque sorte ou au moins fournit un autre aperçu.

Billsensei
la source
comment nommez-vous une colonne dans votre base de données pour "Etat / Province / Préfecture / Comté"?
Xwaro
6
@Xwaro Peu importe, nommez-le quel que soit le mot qui vous semble le moins déroutant pour vos développeurs. En effet, le nom est interne à votre logiciel et ne sera jamais vu par les utilisateurs. Les adresses ne sont jamais affichées avec le nom du champ. Autrement dit, vous ne voyez jamais No 10 Street Downing Street, City Westminster, State London, Country UK. Au lieu de cela, vous verrez10 Downing Street, Westminster, London, UK
slebetman
@slebetman La question était: comment nommez-vous une colonne dans votre base de données pour "Etat / Province / Préfecture / Comté"? Pas "comment me recommandez-vous de nommer une colonne dans ma base de données pour" Etat / Province / Préfecture / Comté "?
Dari
@Dari Peu importe, je le nomme quel que soit le mot qui me semble le moins déroutant pour mes développeurs. En effet, le nom est interne à mon logiciel et ne sera jamais vu par les utilisateurs. Cela dépend donc de ce à quoi mon équipe est habituée.
slebetman
@slebetman - comment vous l'appelez?
Dari
0

Comme déjà indiqué, le plus universel (mais peu pratique à valider et peut-être le moins utile) est un seul grand champ unicode.

Vous pouvez séparer le pays du reste de l'adresse et l'enregistrer comme code de pays ISO. Cela normaliserait le pays et offrirait une certaine utilité pour valider le reste de l'adresse.

Vous pouvez également séparer le code postal aka code postal du reste de l'adresse. Cela aurait également une certaine utilité pour valider le reste de l'adresse et pourrait être utile (bien qu'imprécis) pour la géolocalisation. Par exemple: au Canada, vous pouvez identifier de façon unique toute adresse en spécifiant uniquement le code postal et le numéro de rue (alias numéro de maison); cela peut ne pas être vrai dans tous les pays.

Dédier des champs aux états / provinces ou villes commence à devenir plus problématique en raison des variations dans la façon dont chaque pays formule une adresse. J'ai mis en place des tables d'adresses ayant de tels champs parce que le public initial est concentré sur l'Amérique du Nord, sachant qu'un public international poserait un problème pour s'adapter. Dans la plupart des cas, ils peuvent être "à cornes de chaussure", mais c'est un compromis délicat et potentiellement sujet aux pannes - certainement pas universel.

Zenilogix
la source
0

Contrairement à la réponse de Mitchdav, je déconseille d'utiliser la bibliothèque de Google. J'ai cherché dans le référentiel divers endroits internationaux avec des schémas d'adressage peu orthodoxes dans l'espoir de trouver des données de test unitaire, mais de manière inquiétante, je n'ai trouvé aucun résultat dans l'ensemble du référentiel.

Je pense que votre meilleur pari est de traiter une adresse comme un texte multiligne de forme libre. Il est nul que vous ne puissiez pas valider toutes les adresses, mais certains formats d'adressage sont vraiment étranges et peut-être imprévus et, en fin de compte, la responsabilité de remplir la bonne adresse incombe à l'utilisateur et dans la plupart des applications, l'utilisateur supporte les conséquences négatives du remplissage d'un adresse invalide.

Vous pourriez, peut-être, utiliser un validateur pour fournir un avertissement , mais rien de plus. Mais ne rejetez pas les adresses qui ne valident pas, sinon vous risquez de perdre des clients. Ce qui conduit à la question de savoir comment communiquer l'avertissement à l'utilisateur de telle sorte qu'il communique que, si l'utilisateur vit dans une zone avec un format d'adresse étrange, il est sûr d'ignorer l'avertissement ...

Anonyme
la source
-1

Comme vous dites n'importe quelle adresse sur terre, il n'y a que du temps ou ...

https://what3words.com

Qu'est-ce que 3 mots, c'est un algorithme (donc pas une base de données qui peut être intégrée dans quoi que ce soit) qui peut définir un patch de 3x3 mètres n'importe où sur Terre.

Les Tonga et quelques autres États l'ont adopté comme système de code postal, alors qu'il ne le remplacera pas en superposition, c'est plutôt cool, et très bien construit et pensé.

RemarkLima
la source