gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Demographics schema - urb postcode not null


From: Jim Busser
Subject: Re: [Gnumed-devel] Demographics schema - urb postcode not null
Date: Fri, 07 Oct 2011 16:28:24 -0700

it is both possible (and apparently a notorious problem in some US states) that 
you can have two towns or cities which are known by the same name, despite 
being located in the same state or province, for example as documented here:

        
http://talk.collegeconfidential.com/parent-cafe/770966-why-do-some-states-have-two-towns-same-name.html
        http://answers.yahoo.com/question/index?qid=20080731135833AAfaZFR
        http://en.wikipedia.org/wiki/Middletown,_Pennsylvania

This means that when a person would select a street, even the combination of

        street name, dem.urb.name

does not (unambiguously) confer on the street any geographic meaning.

I recognize it is possible that you could force a user to choose

        which Mountain View, California or
        which Middletown, Pennsylvania

from a list of two or more, but I continue to have a hard time with the idea 
that a city (which may have multiple postal or zip codes) has a 'default'. 
Removal of the requirement for postcode from urb would lose nothing presently 
because

1) a city has no single (granular) location, it has a bounded area
2) it has potentially multiple postcodes
3) it is really only at the level of the street address that we achieve 
anything close to a point location. For the purposes of delivering mail or 
packages or sending an ambulance to get a patient, we need the granularity of 
what is in their address anyway and presently the client enforces the 
requirement to provide a postcode at the level of street (when inputting an 
address).

What this relaxation would then also achieve is to not have to choose which 
among

        multiple cities of same name in same state or province

because the city name is serving only as a crude grouping term, and you could 
always select patients of interest by their required-to-be-inputted 
street-level postcode or zip.


If you do not want to relax the constraint on dem.urb.postcode, then how about 
to relax the 1.0 client which presently requires to input a postcode at the 
level of address / street, reasons being:

1) the backend does not demand a street level postcode
2) I personally rarely send letter mail to patients, and so forcing me to input 
postcodes is extra work for minimal gain
3) if I later needed the postcode to send something to the patient, I could 
look it up

-- Jim




reply via email to

[Prev in Thread] Current Thread [Next in Thread]