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

[Jim Busser]

v17?

        relax constraint on dem.urb needing dem.urb.postcode not null?

can we also (with a post-release client 1.x update) remove, from the client, 
the requirement to input a postal code?

ps if in psql you do

        select d_u.name, d_u.postcode, d_st.name from dem.urb d_u
        inner join dem.state d_st
        on d_u.id_state = d_st.id
        where d_u.name = 'Leipzig' ;

yields

          name   | postcode |  name   
        ---------+----------+---------
         Leipzig | 04318    | Sachsen
         Leipzig | 04317    | Sachsen
        (2 rows)

-- Jim


On 2011-10-07, at 4:40 PM, Karsten Hilbert wrote:

> Too late for GNUmed-next.
> 
> Karsten
> 
> 
> -------- Original-Nachricht --------
>> Datum: Fri, 07 Oct 2011 16:28:24 -0700
>> Von: Jim Busser <address@hidden>
>> An: GNUmed list <address@hidden>
>> Betreff: Re: [Gnumed-devel] Demographics schema - urb postcode not null
> 
>> 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
>> 
>> 
>> _______________________________________________
>> Gnumed-devel mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/gnumed-devel
> 
> -- 
> NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!             
> Jetzt informieren: http://www.gmx.net/de/go/freephone
> 
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnumed-devel